本人主要是侧重电信领域的软交换及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架构的特性比较：

下面的表格是IBM RATIONAL ROBOT与ROBOT的特性比较

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_1 1 ACCOUNT CONTACTPERSON 2 ACCOUNTNUM=114 sdf

SAMSOAPSERVER InsertAccount_1 1 ACCOUNT CANCELDATE 3 ACCOUNTNUM=114

SAMSOAPSERVER InsertAccount_1 1 ACCOUNT BILLINGMONTH 2 ACCOUNTNUM=114

SAMSOAPSERVER InsertAccount_1 1 ACCOUNT CREATEDATE 3 ACCOUNTNUM=114 2008-05-29 00:00:00

SAMSOAPSERVER InsertAccount_1 1 ACCOUNT CREDITLIMIT 1 ACCOUNTNUM=114 30

SAMSOAPSERVER InsertAccount_1 1 ACCOUNT CREDITEXPIREDATE 2 ACCOUNTNUM=114 2008-05-29

SAMSOAPSERVER InsertAccount_1 1 ACCOUNT CREDITCARDNUMBER 2 ACCOUNTNUM=114 2323

SAMSOAPSERVER InsertAccount_1 1 ACCOUNT ACCOUNTNAME 2 ACCOUNTNUM=114 UTStar_SST_Rain

SAMSOAPSERVER InsertAccount_1 1 ACCOUNT AVERAGEUSAGE 1 ACCOUNTNUM=114 20

SAMSOAPSERVER InsertAccount_1 1 ACCOUNT ACTIVATEDATE 3 ACCOUNTNUM=114 2008-06-20 06:53:55

SAMSOAPSERVER InsertAccount_1 1 ACCOUNT BILLINGADDRESSID 1 ACCOUNTNUM=114 654

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT CREDITCARDNUMBER 2 ACCOUNTNUM=109 2323

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT CREDITLIMIT 1 ACCOUNTNUM=109 30

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT CREDITEXPIREDATE 2 ACCOUNTNUM=109 2008-05-29

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT ACCOUNTNAME 2 ACCOUNTNUM=109 UTStar_SST_Rain

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT CREATEDATE 3 ACCOUNTNUM=109 2008-05-29 00:00:00

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT AVERAGEUSAGE 1 ACCOUNTNUM=109 20

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT BILLINGMONTH 2 ACCOUNTNUM=109

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT BILLINGADDRESSID 1 ACCOUNTNUM=109 642

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT ACTIVATEDATE 3 ACCOUNTNUM=109 2008-06-20 04:58:19

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT CONTACTPERSON 2 ACCOUNTNUM=109 sdf

SAMSOAPSERVER InsertAccount_1 2 ACCOUNT CANCELDATE 3 ACCOUNTNUM=109

这段时间正在为这个架构申请公司的一个创新大奖，也就准备了一下PPT介绍，我把其中的几页摘下来供大家参考。有同事推荐这个创新大奖完了之后，我将有可能会去申请一下专利。

下面是对该架构技术的一些重点：

我还想谈一下测试与开发的关系，因为这个架构在测试公司的新项目(Web service类的BOSS业务)中发现了大量的问题，这个新项目设计到的SOAP接口也就是20几个新接口，但是通过ROBOT架构自动产生了超过5000个CASE(其中包括了枚举值，边界值，异常数据，各类自定制的参数组合)，自动产生200000的数据库检查点，完全通过自动化回归的方式进行CASE执行和结果点检查，结果短短几个星期内发现了超过一百个问题，而且很多是严重问题。在刚支持的IPTV业务上，也只是花了几天时间就支持了其中一个应用的自动化测试，结果也发现了几个严重问题，这种成果是以前任何一种架构的自动化所无法比拟的。开发部门也对这个架构刮目相看，专门组织了几次培训来学习这个架构，因此我这段时间也在帮开发建立他们内部的单元测试体系，开发也认真的投入到了测试当中，和我们一起为提高测试质量而共同探讨测试技术，我们也向开发提出了各种要求来配合我们自动化CASE的产生，从这点来看，开发与测试的关系并不一定是对立的，当我们的创新给开发带来了软件质量水平的提高，他们反过来会更加尊敬测试团队。

这几天有点忙，我们的BOSS系统已经比较稳定，但是最近根据某个运营商提的需求对系统的框架进行了比较大的改动，安排了几个同事进行新接口的测试，从上星期开始，一切似乎比较正常，没有发现一些大的问题。但是，做测试的人一般都会有这种直觉，没有发现问题才是最大的问题！而且与开发沟通知道改动量并不少，所以有抱着比较怀疑的态度，本来想着在测试的后期再安排回归的，在这种状况下就要把回归提前了。

因为改动的主要是业务受理接口，主要是对这块的CASE进行回归，CASE大概是2000个，结果检查点有200000。于是运用了UT ROBOT框架做了一次回归测试，运行到差不多第100个CASE的时候，以前正常的一个CASE报错，于是查了一下错误的代码，将测试结果交给开发分析，发现对某个表的status字段处理上，对于status=00001与status=000001出了问题，再一细查所有的代码，发现竟然有30多处的判断处理中存在这个问题;而同时进行的手工测试没有发现这个重大问题，与开发沟通知道，这次的改动主要就包括出错的地方。ROBOT再次立功！除此以外，ROBOT也还发现了其它几个重要问题。

回归迭代测试不可少，有效的框架是解决回归迭代测试的最有效途径!

另外，这几天也在忙于IPTV业务的Web Service的自动化支持模板改造，可能要几天之后才能完成，到时再给大家报告新动向。

多谢大家的捧场！刚过去的一周事情比较多，除了培训，日程项目安排管理，为下周的客户来公司参观准备DEMO环境之外，也刚刚参加完公司的一个比赛。

这个比赛的目的是提升公司各个环节的持续改进能力，最终达到提高质量，降低成本，缩短周期的目标。ROBOT作为参赛项目之一，一共有18只队伍参加，参赛队伍覆盖了从生产线、质量部、客服部、技术支持部、研发部等各个环节的部门；大部分的队伍都是与生产线有关，因为生产线是最好量化及体现成本节约成果的。我们的队伍是两只与软件测试相关的队伍之一。比赛在杭州与深圳通过视频会议两地同步进行，总体感觉演讲的效果还不错，赢得了不少的掌声。有幸的ROBOT项目进入了8强，下周要参加在杭州的总决赛。

言归正传，我们还是来讨论自动化技术方案。上周末参加了IBM举办的技术加油站，主要是以介绍工具为主，感觉IBM的测试工具就是进行界面的自动化录制等等，与行业的LR,QTP没有太本质的区别，对于接口测试，举了SOA应用的例子，感觉也就是简单的手工接口测试，要想实现大规模的接口回归测试还有很大的差距，如果要想支持不同特点的应用的测试就更加不可能。

我一直提倡用有效性来衡量一项创新的用途，包括自动化测试也一样，如果自动化测试单纯停留在宣传上说又多么多么的重要，多么多么的节省人力，另外一方面却发现不了问题，没有数据的支撑的话，是经不起时间考验的，更不能说服别人心甘情愿的学习和推行自动化。另外一方面，如果自动化很有效果，但要花很多时间去写自动化脚本的话，其维护量是惊人的，这条路走起来代价非常大，测试人员根本享受不到自动化带来的便捷，因为我们以前是走过弯路的，所以感受特别深；试想，当你开发了一万个CASE，但是一旦系统修改了设计，要去修改一半的CASE，即使你再有耐心，也会被这种修改脚本的无意义劳动所打倒。

如果想当然的认为一个软件版本到一定程度就能稳定，那是理想的状况，一般情况下除非小软件或者软件被废弃了才会有这种情况，实际情况下，对于有一定规模的软件公司，其软件版本的代码超过千万行是很普遍的，而且系统会随着不同客户的需求不断的增加修改和删除，这就是软件缺陷的来源。UT ROBOT就是在这种背景下产生的，把ROBOT比喻为一条生产线的话，解析引擎是核心，抽象的模板的机器运转的传输带，数据就是原料，数据整合部分一个过滤器，分离的结果检查点则是自动质检系统，每一部分看似都是独立的部分，因为独立也就意味着低耦合，这也就是ROBOT能实现不同类型的软件自动化测试的原因。

有很多人发邮件问我ROBOT怎么可能不需要编写脚本，其实大家有所误解，ROBOT与业务无关，但是对于数据模板的解析还是要根据不同的应用进行模块化扩充的，实际的扩充代价是比较少，因为我把模板中的标签进行了自动解析识别，增加模板中的元素只需要配置解析的规则就可以轻易支持新的模板。另外如果有新的传输协议，还是要增加底层支持的。一旦新的模板加入，测试人员就只需要根据接口文档进行业务数据接口配置，再通过ROBOT的编译引擎产生大量的自动化可执行CASE，一定业务逻辑发生了变化，只需要在数据配置文档进行数据的修改，重新编译数据文档就可以重新生成自动化CASE，维护代价是非常低的。

我认为如果要推行自动化测试，就不要盲目的使用商业测试工具，从长远来讲，要根据各行业各公司的特点去开发符合自己需求的的自动化框架。测试无止境，需要我们在平时的工作中敢于发现问题、多从不同的角度去思考，才能真正开发出有效的自动化测试软件，技术不是自动化最重要的因素，好的想法才是王道。