开放性敏捷自动化测试架构介绍(4)

　　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环境之外，也刚刚参加完公司的一个比赛。

原文转自：http://www.uml.org.cn/Test/2008090410.asp