自动化回归测试工具

上一篇 / 下一篇  2021-06-02 10:50:31 / 个人分类:测试

最近因工作需要,开发了一个回归测试的小工具。可以根据配置读取不同交易报文并进行变量替换,然后自动发起交易并检查结果。自我感觉挺好用的,与大家分享一下设计思路。(代码要保密,就不上传了。有需要可以根据设计思路自己开发。这个是我之前开发时积累的小心得:https://www.cnblogs.com/kingstarer/p/10291348.htmlloadrunner脚本编写经验)
设计背景:
目前系统交易越来越多,需求改动也比较频繁。为防止代码改动影响旧需求,每次修改代码后都需要把相关交易回归测试一次。
目前此项回归测试工作主要靠程序员手工完成,存在以下问题:
  1. 回归测试需要准备很多交易报文,耗时费力;
  2. 由于回归测试比较麻烦,加上版本迭代频繁,有时只能对比较关键的业务场景进行回归测试,存在一定风险。
解决方案:
为避免这种情况,项目组开发了自动化回归测试工具。程序员每次开发完代码后,针对需求的业务场景配置好测试案例,由工具根据案例配置自动执行交易(需要自动生成某些交易报文字段,例如全局流水)并判断案例是否符合要求。
理想情况下,经过多次需求迭代后,测试案例即可全面覆盖所有交易路径。这样可以节省开发人员回归测试时间,对于系统重大升级时保障升级质量也有帮助。
测试工具使用loadrunner脚本编写,这样的好处是
  1. 可以借用loadrunner提供的丰富函数库,如http交互函数,变量替换函数,日志输出函数等;
  2. 可以利用loadrunner的GUI界面;
  3. 通过简单修改配置,可以让本工具用于非功能压测。
不方便的地方有:
  1. 需要电脑安装了loadrunner工具才可以执行测试工具
  2. loadrunner提供的ide不方便调试
  3. 无法引用开源静态库(网上只找到引用动态库的方法)
  4. 由于loadrunner内置编译器与gcc存在部分不兼容,无法直接复用rcc现有功能函数,暂时不能自动检查数据库记录,检查交易日志等。
测试案例配置说明:
配置文件打#开头的行是注释行,脚本读取时会忽略注释行
每一行配置代表一个测试案例,或者一个控制语句
测试案件一般由四个字段组成,字段用空白符分隔,第一个字段代表交易报文名称,脚本执行时会根据报文名称读取对应的xml文件,并对里面配置的变量做替换,然后组装成rcc交易报文发往测试机器并获取返回报文。
第二个字段是案例名称,作用是方便测试人员理解案例用途,对于脚本无意义。
第三个字段是案例验证方式,一般是这样的格式:“状态码-错误码-自定义检查方法”,例如"00-0000000000-have(成功)",意思是期望交易返回报文状态码字段是00,错误码字段是0000000000,返回的内容里面包含"成功"字样。如果有一个条件不满足,脚本会认为案例验证失败,输出日志提醒测试人员。
第四个字段是附加动作,一般可填none代表无附加动作。附加动作需要使用的场景,一般是案例有上下文关系时。例如要测试消费撤销交易,需要先发起消费交易,然后发送撤销交易请求,但此时需要用到前面消费交易的全局流水号。这个时候就需要在前面执行消费交易时使用附加动作save,指示脚本保存此次交易生成的全局事件跟踪号,后面撤销交易时才可以获取到。
控制语句是一些辅助配置测试案例的指令,例如for指令,可以指示脚本重复执行配置案例,适用于期望相同案例重复执行的场景,避免冗余配置。goto/skip指令,可以跳到/跳过指定案例执行,适合调试特定案例的场景。echo,输出日志/变量信息,方便案例验证失败后定位问题。
控制指令说明:
自定义检查方法说明:
支持同时指定多个自定义检查方法,用&&连接
变量说明:
为方便配置报文,脚本预设计了许多变量,测试人员可以直接引用。
如果有需要可以在vugen自行添加,但切记不要修改(loadrunner修改变量的界面非常奇怪,没有保存功能,只要浏览变量值时用鼠标点选不同值就会自动保存,要小心)
附加动作说明:
~~积土成山,风雨兴焉;积水成渊,蛟龙生焉;~~~

TAG:

 

评分:0

我来说两句

日历

« 2024-03-22  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 10567
  • 日志数: 39
  • 建立时间: 2021-05-08
  • 更新时间: 2021-06-21

RSS订阅

Open Toolbar