基于XM SPY进行QTP自动化设计.docVIP

基于XML SPY进行QTP自动化设计 TOC \o 1-3 \h \z \u HYPERLINK \l _Toc175976312 一、GS业务功能自动化测试框架的发展 PAGEREF _Toc175976312 \h 2 HYPERLINK \l _Toc175976313 二、最新自动化框架简介 PAGEREF _Toc175976313 \h 3 HYPERLINK \l _Toc175976314 三、基本脚本库 PAGEREF _Toc175976314 \h 5 HYPERLINK \l _Toc175976315 四、控制台 PAGEREF _Toc175976315 \h 8 HYPERLINK \l _Toc175976316 五、测试集配置文件 PAGEREF _Toc175976316 \h 11 HYPERLINK \l _Toc175976317 六、业务测试数据文件 PAGEREF _Toc175976317 \h 12 HYPERLINK \l _Toc175976318 七、操作测试数据文件 PAGEREF _Toc175976318 \h 14 HYPERLINK \l _Toc175976319 八、函数库 PAGEREF _Toc175976319 \h 16 HYPERLINK \l _Toc175976320 九、测试用例自动化实例 PAGEREF _Toc175976320 \h 20 上帝欲让其灭亡，必先使其疯狂 一、GS业务功能自动化测试框架的发展 大家都在寻找一种更好的方法在产品发布前进行软件测试，从而保障发布后产品的质量。有人从规范发布流程入手，有人从规范测试流程入手，有人想到投入更多的测试，。。。。。我们还能做些什么呢？ 一个持续而又稳定的回归测试，将很大保证发布的信心，而在资源限制条件下，自动化是最好地一种技术手段的保障。 业务功能自动化测试最初的阶段就是录制回放，选择一种工具模拟测试人员操作，然后通过回放功能实现回归测试。对于迈入自动化测试的新手来说，这种经历将是非常新奇和激动的。 由于目前的业务系统每次操作的保单号等一般都不一样，录制后直接回放会无法进行，需要进行简单参数化。这些参数化方法包括：环境变量，Data Table或文件操作等。 随着自动化覆盖率提高，基本类似的业务操作，需要多份保存和维护多份脚本非常不方便，于是出现了可以共用的Action脚本,即将这些业务操作中相同的部分提炼出作为公用部分，这就是我们现在的基础脚本库的雏形。 随着自动化覆盖率进一步提高，我们会发现每次只需修改测试数据就可以完成很多测试覆盖，于是出现关键业务测试数据与脚本分离的要求，从而出现专门的测试数据表示方法，从最初利用QTP自带的Data Table，到不依赖QTP的Excel，到目前基于XML的表述方法等，而且总体趋势是与具体的测试工具依赖度越来越低，操作越来越方便。 随着自动化覆盖率再进一步提高，上述脚本或测试数据表示方式的优化都是针对某个测试用例开展，无法满足如何高效组织几百个测试用例的问题。Altova公司提供的XML SPY，可以帮助我们很方便地操作各种XML相关的文档，同时考虑到XML目前已经成为文档保存和交换的标准，于是出现这套基于XML SPY进行二次自动化设计的业务功能测试框架，并将它应用到GSBLV3.1版本中，从而最终实现： 操作XML文件玩转GS业务功能自动化测试。 二、最新自动化框架简介 为了满足设计几百个测试用例自动化要求，GS-ST测试团队设计了一套GSBL自动化框架。测试人员在该框架基础上通过XML SPY设计测试用例对应的测试数据和调用的基础脚本名就可以比较轻松完成自动化测试设计工作，从而实现大多数熟悉业务模块的测试人员都可以参与到自动化设计工作中。 框架重要组成部分如下图所示： 基础脚本库：按照业务实现的QTP脚本，其中每个Action基本对应某个相对比较独立重复操作（如Login, Logout）或最低层子菜单 (如，NB中Data Entry) 。 控制台(ControlCenter)：自动化测试用例执行的控制中心，该控制台根据配置文件获取需要运行的测试用例，然后根据每个测试用例对应的操作测试数据文件调用基础脚本库中Action执行。 测试集配置文件：该文件包含了自动化测试用例集合，其中每个自动化测试用例包括本次测试是否执行设置（true/false），该测试用例对应的业务测试数据文件和操作测试数据文件的保存路径。 业务测试数据文件：每个自动化测试用例包含的关键业务测试数据。 操作测试数据文件：每个自动化测试用