自动化测试的困境

对应用系统进行大批量的自动化回归测试是当前很多运营商的实际需求。现实中，自动化测试项目有着各种各样的难题。对于刚开始做自动化测试的技术人员来说，首先可能遇到的就是自动化测试工具的问题，总结当前市场上的自动化测试工具，普遍存在如下困境。

一、常见工具提供了对最广泛应用系统环境的支持，但是不针对实际被测应用系统定制任何内容，字符终端、图形界面的自定义控件支持得很不好。

二、一般商业工具直接支持的自动化回归测试方法只是录制回放技术，其他技术都需要测试人员通过编码实现。编写脚本比较花费时间，仅使用录制回放技术来完成自动化回归测试也是不可能的。

三、虽然有的工具号称支持数据驱动技术和关键字技术，但是实际上只提供了对这两种技术的底层支持。而各种商业自动化回归测试工具有一个共同点，那就是脚本和数据、验证条件、同步条件是捆绑在一起的，而且脚本没有经过封装，是非结构化的，不可复用。

四、一般商业工具的数据都与测试用例关联在一起，而不是与业务流关联，不能满足应用系统的测试要求，需要进一步增强。而且现有工具缺少自动调度机制，脚本执行过程中出错即终止，影响后续脚本的运行。

神州数码信息服务集团集成服务战略本部长期致力于电信、金融等行业的软件质量管理，在自动化测试服务方面积累了丰富的经验，并形成了以“锐行服务”为品牌、完整成熟的系列解决方案，在安徽移动、山西移动、湖北移动等多家电信运营商，以及建设银行、工商银行、浦发银行等金融行业客户的实际项目中得到了大量应用推广，极大提高了软件测试的工作效率。

锐行服务自动化回归测试系统

神州数码信息服务集团集成服务战略本部自主研发的“锐行服务”自动化回归测试系统，能够较好地解决上述工具方面的难题。该系统在通用测试工具上构建了一个自动回归测试框架，见图1。

使用锐行服务自动回归测试框架实现自动回归测试的基本过程如下。

1.业务人员通过测试用例设计器完成测试用例的设计工作，指定测试用例每个步骤操作的对象、数据和参数，产生的测试用例定义保存在数据库中；在完成测试用例设计后，通过脚本生成器产生出自动回归测试需要的脚本、产生的脚本也保存在数据库中。

2.业务人员根据现有的测试用例，通过业务流管理器定义需要测试的业务流，并定义业务流中使用的测试用例间数据传递关系，业务流定义和数据传递关系的定义也保存在数据库中；业务人员通过数据管理器为每个业务流配置实际使用的数据，数据保存在数据库中。

3.测试执行人员通过测试调度器启动自动回归测试过程，选择需要执行的业务流，测试调度器从数据库中读入相应业务流的定义和业务流中测试用例间的数据传递关系，解析需要执行的测试用例和测试用例执行顺序，然后顺序执行测试用例，在执行测试用例时，从数据库中读入该测试用例对应的测试脚本和需要使用的测试数据。

4.调用自动测试工具，执行测试用例，每个测试用例执行结束后，根据读入的测试用例间的数据传递关系传递数据，并根据测试用例执行顺序调入下一个测试用例对应的脚本和数据，执行下一个测试用例，直至测试结束；测试结束后，可以通过自动测试工具产生需要的测试报告。