在测试项目的测试执行阶段,如何才能更快,更好的达到阶段目标？有没有比现在更好的方法了？能不能更近一步？ 这些是我常常思考的问题。
因此我对现有的工作流程，内容，具体工作的过程进行了分析.我发现在版本执行过程, 有着一部分接口/后台业务测试的自动化用例,在每个迭代轮次都会参与用例执行量评估, 并且每个测试人员单独执行自己的自动化用例, 这样的方式存在问题：
1.自动化用例本身执行时间快, 但是由于每个测试人员单独执行, 真正执行的时间无法确定
2. 自动化用例和手工用例一并参与工作量评估, 采用平均值方式, 影响了工作量评估的准确性（尤其是接口/后台业务需求多的版本）
3.针对个人工作,工作内容包含自动化用例多的会出现用例量很大的情况，但是实际花费的时间少，在后期评估工作绩效的时候难以保证相对公平
针对以上问题, 同时考虑自动化用例, 对执行环境、执行人员不存在关键依赖（非某人不可执行）的要求, 考虑将自动化用例合并自动执行, 统一出结果, 预计实现后的好处：
1.自动化用例使用工具执行,减少了对应的人力投入（假设1000用例，原有10人天，换成自动执行，折合1人天，效率提升90%）
2.自动化用例排除在总工作量计算之类, 提高的工作预估的精准度，有利于工作安排。
3.自动执行可以通过任务方式，确保及时执行
改进收益预估：假设有1000个自动化用，按照原有100个/天估算需要10人天，归并后可以在1小时内执行完成，加上修改等约和1天。 节约9人天， 效率提升9/10*100% = 90%.
如何实现呢？
实现以上目标，我们先从抽象层面依次解决几个问题：
1. 自动化脚本从哪来？
2.如何使用非UI（命令行）的方式执行自动化脚本
3. 使用什么工具去触发命令运行(传递意图给工具)
4. 如何展示结果
通过探索初确定使用ANT+jmeter的结构, 具体实现如下：
1. 自动化脚本从哪来？
这里指的自动化脚本是指针对后台服务新增接口的参数校验, 后台接口调用实现业务逻辑验证, 后台接口实现的越权验证, 后台接口的特殊业务状态校验，只依赖数据输入不依赖其他条件的场景，实现工具jmeter. 在设计阶段完成基础自动化用例编写, 在SDV1阶段完成调试和用例固定,保存为JMX文件
2. 如何使用非UI（命令行）的方式执行自动化脚本
通过JMETER官方文档的描述, Jmeter 提供命令行的方式运行jmx文件,执行测试
3. 使用什么工具去触发命令运行(传递意图给工具)
工具使用ANT, 利用jmeter自带的jar 提供anttask指令, 通过ant 调用相应的build.xml 配置文件实现自动测试
4. 如何展示结果
工具使用ANT, 利用JMETER自带的xslt jar包,样式定义文件和 指令, 实现将jmeter运行结果的jtl文件转换为html文件，任一tomcat,发布结果文件所在目录,实现共享查看结果.
以上过程具体和操作如下：
1. ANT引入jmeter task jar
将 jmeter的extras目录中ant-jmeter-1.1.1.jar包拷贝至ant安装目录下的lib目录中
2. 修改jmeter配置文件, 使得测试结果文件格式为xml
修改Jmeter的bin目录下jmeter.properties文件的配置：jmeter.save.saveservice.output_format=xml
3. 修改/创建 build.xml文件, 定义jmeter task 和 指令，运行Jmeter 脚本和转换测试结果
问题和反思：
1. 为什么要在步骤2,修改测试结果文件为xml
答：在步骤3会使用xslt 对xml文件进行转换为html，如果测试结果文件不是xml那xslt将无法正常运行.
2. 如果不使用ANT有没有其他方式实现自动运行？
答：有，可以使用任意的工具（SHEELL,
java， python），只要是可以让系统以命令行方式运行jmeter命令都可以, 但是自己需要实现调用Jmeter的过程，以及单独实现测试过转换的逻辑
3. 如果我的项目需要对测试脚本的执行范围需要进行动态控制，对显示结果进行不同维度的显示（模板不同）那怎么办。
答：你有2个解决思路：
1.基于先用的ant+build.xml+jemeter的方式, 加入交互逻辑（比如UI/Web页面）设置配置信息，将配置信息更新到build.xml中,形成新的build.xml使用ant加载
2. 使用开发语言的策略模式进行输出样式的定义,前台使用xml进行配置设置
网友评论