开放性敏捷自动化测试架构介绍
本人主要是侧重电信领域的软交换及BOSS业务的测试，从本人多年所处理的现场问题来看，在现场发生的约80%的问题来源于软件版本升级后引入的新功能带来的对老功能的影响，有过不少沉痛的经验教训。我们公司曾经设置过专门的自动化测试部门，轰轰烈烈的从事自动化平台的开发，基本上发动了测试部门的所有同事从事测试CASE的脚本开发，时间力行半年，结果由于众所周知的原因，整个自动化体系以失败告终，最后，该自动化测试部门也就无疾而终了。我总结了一下，主要是下面的原因造成，这基本上也是行业内不同公司实施自动化失败的主要原因：
1.自动化平台的思路缺乏创造性，基本上都是以脚本编写CASE，录制回放为主。
2.传统的自动化体系存在以下成本因素，导致自动化的投入产出比较高，从而制约了自动化的有效实施
2.1 开发成本
2.2 调试成本
2.3 维护成本
2.4 培训成本
2.5 规范化成本
众所周知，BOSS系统以业务众多为主，以业务受理单一个接口为例，我们的测试案例库就存在不下3000个CASE，如果通过传统的编写自动化脚本来进行CASE转化的话，从我们以前实施的代价是：由于每个CASE都要涉及到脚本编写，环境清理，环境设置，结果检查，调试等几个步骤，一个人一个月能完成的CASE不过50个，一旦应用的业务发生变化，相关的CASE也就作废了，在这种情况下，大家也就清楚了自动化为何操作不下去的原因了.
通过分析传统自动化所固有的缺陷，我重新定义了自动化架构的核心新思路：自动化架构必须实现CASE的产生，执行，结果检查三大要素的分离。我把新自动化的架构命名为ROBOT，无巧不成书，IBM也存在名字为RATIONAL ROBOT的一个架构产品，文章后面，我把我们的UT ROBOT和IBM的RATIONAL ROBOT的特性进行了比较。
通过将近六个月左右时间的开发，这个架构基本开发成功，并应用到了10多个应用的接口测试中，发现了超过200个问题，实现了以下功能：
1.对新应用的接口支持只需要不到2周的时间
2.以通用模板为基础，所有CASE自动产生
3.结果检查点自动产生，可以快速产生包括100万的结果检查点
4.可支持多协议
通过ROBOT框架测试过的产品在多个现场实施之后，竟然在半年的时间内没有报过任何一个问题，以前1个月都跑不了100个CASE通过ROBOT框架可以在2天的时间内完成3000个CASE,50万结果检查点的检查，这点也印证了这篇文章的标题：开放性敏捷自动化测试架构
下面是传统自动化体系与ROBOT架构的特性比较：
传统自动化体系 UT ROBOT通用架构
============================================================
CASE生成全部CASE需要脚本支持 无需脚本支持
数据驱动比较困难，不同的应用需要写大量的代码采用强大的模板解析引擎，数据驱动轻而易举
继承性 自动化脚本容易被测应用的变化而失效 应用逻辑变化只需要调整数据
可读性 不同的脚本编写人员有不同的编码风格 全部基于数据表达，清晰易懂
自然语言不支持 支持，设计CASE的自然语言可以通过解析器识别，所见即所得
CASE转化 比较死板，需要逐一CASE编写脚本 采取全新的自动化思路，CASE转化交给机器
扩展性 增加新的应用需要写大量的脚本 只需对应用进行模板定义
CASE维护难以维护，需要大量的管理成本 基于数据，维护成本很低
CASE执行需要很多时间提前准备环境 可以快速执行
检查点设置比较单一，通常与CASE写在一起 CASE产生与检查点相分离，极低的耦合度，检查点强大无比，维护成本极低
可靠性 不可靠，因为检查点比较单一 可靠，通过数据库跟踪技术，可以确保检查精确到字段级别
下面的是IBM RATIONAL ROBOT与UT ROBOT的特性比较
IBM RATIONAL ROBOT UT ROBOT
CASE生成全部CASE需要脚本支持 无需脚本支持
后台应用 不支持 主要支持
开放性 较好 较好
数据驱动 支持，不太方便 采用强大的模板解析引擎，数据驱动轻而易举
可读性 不同的脚本编写人员有不同的编码风格 全部基于数据表达，清晰易懂
自然语言 不支持 支持，设计CASE的自然语言可以通过解析器识别，所见即所得
扩展性 比较困难，因为是商用产品 比较好，可根据不同的需求进行扩展
检查点设置优于传统，但不太灵活 CASE产生与检查点相分离，极低的耦合度，检查点强大无比，维护成本低
本文建立在多年的测试管理及自动化的心得之上，ROBOT项目是对我成功实施自动化的一次总结,希望与行业的专家共同探讨自动化的前进方向，写得不好，请大家多多指正。如果有兴趣可以发邮件给我：benwu1976@hotmail.com
转自楼主在csdn上的回复
BOSS是指为电信运营商提供的营帐支撑系统，因为移动电信的业务的特点是业务非常复杂，有成千上万的价格计划套餐，计费也比较复杂，后台的支持网元有上百个，我们现在整套BOSS系统能支撑软交换，GSM，IPTV等等多业务，现在的BOSS相关网元已经超过300个，所以接口是非常多的，因为这种特点，所以接口协议和后台数据的测试就是主要方面UT ROBOT的主要成绩体现在我们通过ROBOT回归的部分网元，在现场实施之后几乎没有再报回归方面的遗漏问题。BUG下降了85%，因为有了这个数据说话，所以坚定了我们在这个架构上的信心
UT Robot强调的是框架，也就是可以适用在多个应用，多业务的测试中，即使不是我们公司的产品也可以应用
自动化测试需要考虑以下方面：
1.CASE执行前的环境准备：这是为了保证批量测试的时候不影响其它CASE的执行
2.CASE执行后的环境清理：这也是为了保证批量测试的时候不影响其它CASE的执行
3.结果检查点：非常重要，这是测试准确性的根本
4.参数的组合关系：只有可以自由组合CASE，才能覆盖各种场景
5.核心思想：CASE的生成，执行，结果记录，以及回归要分离
6.协议无关：具体完成协议发送的功能与框架想分离
7.业务无关
现在Robot已经应用到我们BOSS的部分网元的测试中，并且做到了与协议和业务无关，我们现在的效率是，一周之内就可以支持新的简单网元的自动化测试。
举例：对于WebService的SOAP接口测试，通过CASE的生成，执行，结果记录，以及回归要分离，可以实现数据库基本的所有字段的测试。可以在短时间内完成40个接口，超过5000个CASE的生成，生成的CASE中包括：枚举值、边界值、异常值、各种自定义组合的CASE，这个测试效果非常好，不仅发现了大量的功能问题，同时也发现了大量的版本变更过程中回归业务的问题。因为ROBOT在实现功能测试的同时也要支持自动化回归测试，当然，这是要求测试人员按照规范来写的。
因为采用的是模板定制测试数据的方式，测试人员不需要编写任何代码，只需要关注业务层面，即使webservice发生了变化，也只需要进行数据的变更就可以了，同时数据的版本管理可以很好的适应不同版本的变化情况。
为了更好的说明，我把测试环境中的数据拿出来说明一下，下面是SOAPSERVER几个CASE的返回结果，如第1个case，caseid=InsertAddress_2从WEBSERVICE返回的值是1，可能有些人认为这个CASE就算PASS了，实际，这还远远不够，我们需要关注的是数据级别的变化，因此，我们需要另外的手段去记录所有数据库变化的情况，一个CASE，所涉及到的结果检查点就达到几十甚至上百个。
说到这里，大家应该明白了，UT ROBOT的特点是将结果检查点与CASE的回归执行时相分离的，否则在一个CASE中同时包含了上百个结果检查点的检查，得写多少脚本才能完成，维护代价得多大？
在这里，还得提到我们的数据库变化追踪技术(就是一次接口的请求带来的后台数据库的所有表所有字段的变化情况)，这个技术保障了所有结果检查点的完整性。
CASESET CASEID CASETYPE VERSIONID TYPE PARATYPE RESULT
1 SAMSOAPSERVER InsertAddress_1.1_0_0 IMPORT 1 -1600
2 SAMSOAPSERVER InsertAddress_2.1_0_0 IMPORT 1 1
3 SAMSOAPSERVER InsertAddress_2.1_1_0 IMPORT 1 1
4 SAMSOAPSERVER InsertAddress_1 IMPORT 1 1
5 SAMSOAPSERVER InsertAddress_2 IMPORT 1 1-1 -1555
6 SAMSOAPSERVER UpdateAddress_1.1_0_0 IMPORT 1 1
下面是对CASEID=InsertAccount_1的具体表的具体数据的结果，只有到了字段级别的检查才是有效的结果检查
CASESET CASEID CASETYPE VERSIONID TABLE_NAME FIELD_NAME VALUETYPE UNITE_KEY_VAL LAST_VALUE LAST_VALUE2
SAMSOAPSERVER InsertAccount_11 ACCOUNT CONTACTPERSON 2 ACCOUNTNUM=114sdf
SAMSOAPSERVER InsertAccount_11 ACCOUNT CANCELDATE 3 ACCOUNTNUM=114
SAMSOAPSERVER InsertAccount_11 ACCOUNT BILLINGMONTH 2 ACCOUNTNUM=114
SAMSOAPSERVER InsertAccount_11 ACCOUNT CREATEDATE 3 ACCOUNTNUM=1142008-05-29 00:00:00
SAMSOAPSERVER InsertAccount_11 ACCOUNT CREDITLIMIT 1 ACCOUNTNUM=11430
SAMSOAPSERVER InsertAccount_11 ACCOUNT CREDITEXPIREDATE 2 ACCOUNTNUM=1142008-05-29
SAMSOAPSERVER InsertAccount_11 ACCOUNT CREDITCARDNUMBER 2 ACCOUNTNUM=1142323
SAMSOAPSERVER InsertAccount_11 ACCOUNT ACCOUNTNAME 2 ACCOUNTNUM=114UTStar_SST_Rain
SAMSOAPSERVER InsertAccount_11 ACCOUNT AVERAGEUSAGE 1 ACCOUNTNUM=11420
SAMSOAPSERVER InsertAccount_11 ACCOUNT ACTIVATEDATE 3 ACCOUNTNUM=1142008-06-20 06:53:55
SAMSOAPSERVER InsertAccount_11 ACCOUNT BILLINGADDRESSID 1 ACCOUNTNUM=114654
SAMSOAPSERVER InsertAccount_12 ACCOUNT CREDITCARDNUMBER 2 ACCOUNTNUM=1092323
SAMSOAPSERVER InsertAccount_12 ACCOUNT CREDITLIMIT 1 ACCOUNTNUM=10930
SAMSOAPSERVER InsertAccount_12 ACCOUNT CREDITEXPIREDATE 2 ACCOUNTNUM=1092008-05-29
SAMSOAPSERVER InsertAccount_12 ACCOUNT ACCOUNTNAME 2 ACCOUNTNUM=109UTStar_SST_Rain
SAMSOAPSERVER InsertAccount_12 ACCOUNT CREATEDATE 3 ACCOUNTNUM=1092008-05-29 00:00:00
SAMSOAPSERVER InsertAccount_12 ACCOUNT AVERAGEUSAGE 1 ACCOUNTNUM=10920
SAMSOAPSERVER InsertAccount_12 ACCOUNT BILLINGMONTH 2 ACCOUNTNUM=109
SAMSOAPSERVER InsertAccount_12 ACCOUNT BILLINGADDRESSID 1 ACCOUNTNUM=109642
SAMSOAPSERVER InsertAccount_12 ACCOUNT ACTIVATEDATE 3 ACCOUNTNUM=1092008-06-20 04:58:19
SAMSOAPSERVER InsertAccount_12 ACCOUNT CONTACTPERSON 2 ACCOUNTNUM=109sdf
SAMSOAPSERVER InsertAccount_12 ACCOUNT CANCELDATE 3 ACCOUNTNUM=109 顶！
实践证明，ROBOT取得很好的测试效果，Robot对基于数据库的应用系统回归测试能很好的支持。
希望更多的人能够关注，并加以应用。 效果很显著啊。
请问每一步的执行结果和结果检查如何做到分离?
另外，方便告知哪个公司的么？呵呵，我们也想更深入了解框架实现细节:) 谢谢fishy帮我的转贴，因为我一直不知道51testing和CSDN在测试上的讨论会更加有效。
不过这段时间倒是有不少的同行对这个架构比较感兴趣，我在这里就多谈一点，我和SAP公司及其他公司的一些从事自动化的同行业做了不少的探讨。
这段时间正在为这个架构申请公司的一个创新大奖，也就准备了一下PPT介绍，我把其中的几页摘下来供大家参考。
有同事推荐这个创新大奖完了之后，我将有可能会去申请一下专利。
下面是对该架构技术的一些重点：
我还想谈一下测试与开发的关系，因为这个架构在测试公司的新项目(Web service类的BOSS业务)中发现了大量的问题，这个新项目设计到的SOAP接口也就是20几个新接口，但是通过ROBOT架构自动产生了超过5000个CASE(其中包括了枚举值，边界值，异常数据，各类自定制的参数组合)，自动产生200000的数据库检查点，完全通过自动化回归的方式进行CASE执行和结果点检查，结果短短几个星期内发现了超过一百个问题，而且很多是严重问题。在刚支持的IPTV业务上，也只是花了几天时间就支持了其中一个应用的自动化测试，结果也发现了几个严重问题，这种成果是以前任何一种架构的自动化所无法比拟的。开发部门也对这个架构刮目相看，专门组织了几次培训来学习这个架构，因此我这段时间也在帮开发建立他们内部的单元测试体系，开发也认真的投入到了测试当中，和我们一起为提高测试质量而共同探讨测试技术，我们也向开发提出了各种要求来配合我们自动化CASE的产生，从这点来看，开发与测试的关系并不一定是对立的，当我们的创新给开发带来了软件质量水平的提高，他们反过来会更加尊敬测试团队。 我对这个感兴趣，但你们提到的UI robot 是公司自己开发的还是其他公司的产品？？ 可否留个你们的联系方式交流一下？:) 首先更正一下，不是UI ROBOT，是UT ROBOT。这是我们自由知识产权的自动化测试框架，有兴趣的同行可以通过email和我讨论：benwu1976@hotmail.com，或者关注我的博客：http://www.51testing.com/?195689
我将会和大家一起分享设计及开发敏捷的自动化框架的一些思想 UT ROBOT自动化测试框架体系无需脚本支持即可自动生成成千上万个case，执行效率高，测试效果很好，正在学习中。 赞一个:hug: ，使用ing! 非常棒!!!:victory: 顶一个.使用这种工具可以大大缩减回归测试时的工作量,测试人员只需要合理的编写CASE,而不需要去完成重复枯燥的操作. 从描述来看感觉很好，达到了一个理想的自动化测试状态，非常想了解细节，具体是怎么实现，希望能借鉴提高 这几天有点忙，我们的BOSS系统已经比较稳定，但是最近根据某个运营商提的需求对系统的框架进行了比较大的改动，安排了几个同事进行新接口的测试，从上星期开始，一切似乎比较正常，没有发现一些大的问题。但是，做测试的人一般都会有这种直觉，没有发现问题才是最大的问题！而且与开发沟通知道改动量并不少，所以有抱着比较怀疑的态度，本来想着在测试的后期再安排回归的，在这种状况下就要把回归提前了。
因为改动的主要是业务受理接口，主要是对这块的CASE进行回归，CASE大概是2000个，结果检查点有200000。于是运用了UT ROBOT框架做了一次回归测试，运行到差不多第100个CASE的时候，以前正常的一个CASE报错，于是查了一下错误的代码，将测试结果交给开发分析，发现对某个表的status字段处理上，对于status=00001与status=000001出了问题，再一细查所有的代码，发现竟然有30多处的判断处理中存在这个问题;而同时进行的手工测试没有发现这个重大问题，与开发沟通知道，这次的改动主要就包括出错的地方。ROBOT再次立功！除此以外，ROBOT也还发现了其它几个重要问题。
回归迭代测试不可少，有效的框架是解决回归迭代测试的最有效途径!
另外，这几天也在忙于IPTV业务的Web Service的自动化支持模板改造，可能要几天之后才能完成，到时再给大家报告新动向。
还有一个事情，就是我们公司最近招聘测试人员，要求如下：
具备以下三项技能
1.熟悉电信业务
2.熟悉C/C++,JAVA,TCL或其它语言
3.掌握测试理论，有2年以上相关工作经验
4.熟悉7号信令，GSM业务流程
5.熟悉IPTV业务。
工作地点在深圳，有兴趣的人可以发简历到我的邮箱，benwu1976@hotmail.com 谢谢楼主的接受..对UT Robort 很感兴趣...关注此贴..:lol
问一个实在的问题
不知道此工具对于返回多条数据的检查点如何循环检查的？ 弱弱的问下楼上某几位 你们咋试用UT ROBOT的类？楼主提供滴？
楼主 打发我一个吧 这么好的东西不能沉了让更多人分享
楼主挺专业，细节哪
好像了解一下楼主的UT ROBOT的细节啊，想你学习 多谢大家的捧场！刚过去的一周事情比较多，除了培训，日程项目安排管理，为下周的客户来公司参观准备DEMO环境之外，也刚刚参加完公司的一个比赛。这个比赛的目的是提升公司各个环节的持续改进能力，最终达到提高质量，降低成本，缩短周期的目标。ROBOT作为参赛项目之一，一共有18只队伍参加，参赛队伍覆盖了从生产线、质量部、客服部、技术支持部、研发部等各个环节的部门；大部分的队伍都是与生产线有关，因为生产线是最好量化及体现成本节约成果的。我们的队伍是两只与软件测试相关的队伍之一。比赛在杭州与深圳通过视频会议两地同步进行，总体感觉演讲的效果还不错，赢得了不少的掌声。有幸的ROBOT项目进入了8强，下周要参加在杭州的总决赛。
言归正传，我们还是来讨论自动化技术方案。上周末参加了IBM举办的技术加油站，主要是以介绍工具为主，感觉IBM的测试工具就是进行界面的自动化录制等等，与行业的LR,QTP没有太本质的区别，对于接口测试，举了SOA应用的例子，感觉也就是简单的手工接口测试，要想实现大规模的接口回归测试还有很大的差距，如果要想支持不同特点的应用的测试就更加不可能。
我一直提倡用有效性来衡量一项创新的用途，包括自动化测试也一样，如果自动化测试单纯停留在宣传上说又多么多么的重要，多么多么的节省人力，另外一方面却发现不了问题，没有数据的支撑的话，是经不起时间考验的，更不能说服别人心甘情愿的学习和推行自动化。另外一方面，如果自动化很有效果，但要花很多时间去写自动化脚本的话，其维护量是惊人的，这条路走起来代价非常大，测试人员根本享受不到自动化带来的便捷，因为我们以前是走过弯路的，所以感受特别深；试想，当你开发了一万个CASE，但是一旦系统修改了设计，要去修改一半的CASE，即使你再有耐心，也会被这种修改脚本的无意义劳动所打倒。
如果想当然的认为一个软件版本到一定程度就能稳定，那是理想的状况，一般情况下除非小软件或者软件被废弃了才会有这种情况，实际情况下，对于有一定规模的软件公司，其软件版本的代码超过千万行是很普遍的，而且系统会随着不同客户的需求不断的增加修改和删除，这就是软件缺陷的来源。UT ROBOT就是在这种背景下产生的，把ROBOT比喻为一条生产线的话，解析引擎是核心，抽象的模板的机器运转的传输带，数据就是原料，数据整合部分一个过滤器，分离的结果检查点则是自动质检系统，每一部分看似都是独立的部分，因为独立也就意味着低耦合，这也就是ROBOT能实现不同类型的软件自动化测试的原因。
有很多人发邮件问我ROBOT怎么可能不需要编写脚本，其实大家有所误解，ROBOT与业务无关，但是对于数据模板的解析还是要根据不同的应用进行模块化扩充的，实际的扩充代价是比较少，因为我把模板中的标签进行了自动解析识别，增加模板中的元素只需要配置解析的规则就可以轻易支持新的模板。另外如果有新的传输协议，还是要增加底层支持的。一旦新的模板加入，测试人员就只需要根据接口文档进行业务数据接口配置，再通过ROBOT的编译引擎产生大量的自动化可执行CASE，一定业务逻辑发生了变化，只需要在数据配置文档进行数据的修改，重新编译数据文档就可以重新生成自动化CASE，维护代价是非常低的。
我认为如果要推行自动化测试，就不要盲目的使用商业测试工具，从长远来讲，要根据各行业各公司的特点去开发符合自己需求的的自动化框架。测试无止境，需要我们在平时的工作中敢于发现问题、多从不同的角度去思考，才能真正开发出有效的自动化测试软件，技术不是自动化最重要的因素，好的想法才是王道。
时间不早了，有空再和大家探讨。
[ 本帖最后由 benwu 于 2008-8-2 00:36 编辑 ]
好的想法才是王道，楼主说的很好
关于自动化测试，最近几个月我也有很多想法。有机会和楼主做详细交流。。 想问一下楼主，你的自动化测试框架是不是主要应用与电信项目的接口测试？
另外， 你提到此框架已经应用于若干项目中，想问一下这些项目是完全不同的项目么？还是框架的实现本身已经包含了对这些项目中共同点的一些假设
还有关于CASE的自动生成，是不是主要是测试数据的不同组合，也就是场景相同，测试数据不同的情况。
谢谢
页:
[1]
2
