摘要
本文通过分析大型系统自动化回归测试执行效率低下的问题，总结了从测试用例、测试脚本、最佳实践、持续集成等方面的解决方案。通过最后的实施结果来看，综合采用这些方案后取得了很好的效果，大幅度地提高了自动化回归测试的执行效率，使产品的质量状态得到了及时的反馈。
一、前言
在大型Web系统的自动化回归测试中，回归测试通常会耗费大量的时间，随后的结果分析以及对产品的质量反馈周期就很漫长。若是执行中一旦发生中断失败，可能还需要重启回归测试，那样的话，对产品质量的反馈就更慢了。笔者最近参加过一个大型的自动化测试项目，在项目前、中期我们也遇到了这样的问题，团队对自动化回归测试的执行进行了全面而仔细的分析，然后通过一些方案大幅度地提高了执行的效率。
二、项目概况
项目是基于Selenium的自动化测试，测试框架为TestNG，持续集成平台为Jenkins。所测试的系统业务规则很多、业务比较复杂，系统三大业务模块（系统配置、排班管理和打卡管理）总共有约2000个自动化测试用例。自动化回归测试按照每个模块单独执行。项目从开始进行到中期时，每个模块的自动化回归测试仍是在单个Jenkins任务中以单线程模式执行的。各模块的用例数以及在IE11上回归测试的时长如表1所示。
表1、测试用例数及在IE11上的执行时长
从表1可以看出，在每个模块只有240到260个测试用例的情况下，单个模块在单线程的执行模式下已经需要10个小时了。如果单个模块的测试用例增加到700个以上，在当前模式下的执行时间将以天计，这样的执行效率是不能被接受的。
三、耗时分析
为了解决执行效率的问题，团队分析了各业务模块的回归测试流程和测试结果。从不同的层面，团队发现了一些导致执行耗时较长的因素。限于篇幅，本文仅以"打卡管理"这个业务模块作为例子来阐述发现的问题。
3.1 持续集成层面
3.1.1 并发
在持续集成平台Jenkins上配置的回归测试任务中，没有嵌套的层级任务结构配置，没有充分利用Jenkins插件的优势去并行地执行测试任务。
另外，也没有利用Selenium Grid并行地执行测试用例。当时的配置是，一个Jenkins任务对应一台测试客户端，单线程地执行模块内的所有测试用例。
3.1.2 浏览器窗口+登录
Jenkins的任务以及自动化测试脚本采用策略是每个测试用例的执行都需要重新启动一个新的浏览器窗口、重新登录以排除其他测试用例的干扰。在结束时，还要退出登录并关闭浏览器窗口。
在分析测试执行日志后发现，每次重新打开浏览器和进行登录都会消耗比较多的时间。图1显示了Testng从启动一个测试用例到登录完成的日志信息。
图 1 启动浏览器并进行登录的日志
从日志信息可以看出，每次启动IE浏览器到登录的总耗时约为23秒。
- 20:50:49 - Testng开始启动测试用例
- 20:51:12 - 登录成功开始检查首页上的菜单按钮是否可点击
打卡管理模块的260个测试用例，如果每个测试类平均按照5个测试用例来算，再加上一些必需的重新登录，应该有60%的测试用例可以重用浏览器窗口，也不需要登录，总共可以节省的时间为：260 x 60% x 23 = 3588秒（1小时）。
3.2 测试用例和脚本层面
经过检查测试用例和测试脚本，发现用例和脚本中有比较多不必要的验证点。这些验证点对某些测试用例是必需的，但是对于其他很多的测试用例则是多余的。这些验证点不仅会浪费执行的时间，而且也可能导致测试用例失败在不相关的验证点上。
另外，团队还发现了一些测试用例的执行耗时过长。比如，有的测试用例耗时30分钟左右，甚至近1个小时。经分析发现了如下的问题会导致单个测试用例执行时间过长：
测试用例的问题。有的测试用例要求验证大量的界面元素，或者重复验证大量的界面元素。
准备、销毁测试数据的问题。测试脚本中通过界面创建、销毁比较多的测试数据，这部分界面操作消耗了额外的时间。
测试脚本的问题。有些测试脚本本身存在一些性能问题。
... ...
查看更多精彩内容，请点击下载：http://www.51testing.com/html/68/n-3721768.html
版权声明：本文出自《51测试天地》第四十七期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
