摘要
在大型的自动化回归测试中，回归测试通常会耗费大量的时间，随后的结果分析以及对产品的质量反馈周期就很漫长。若是执行中一旦发生中断失败，可能还需要重启回归测试，那样的话，对产品质量的反馈就更慢了。笔者最近参加过一个大型的自动化测试项目，在项目前、中期我们也遇到了这样的问题，团队对自动化回归测试的执行进行了全面而仔细的分析，然后通过一些方案大幅度地提高了执行的效率。
二、项目概况
表1、测试用例数及在IE11上的执行时长
从表1可以看出，在每个模块只有240到260个测试用例的情况下，单个模块在单线程的执行模式下已经需要10个小时了。如果单个模块的测试用例增加到700个以上，在当前模式下的执行时间将以天计，这样的执行效率是不能被接受的。
三、耗时分析
为了解决执行效率的问题，团队分析了各业务模块的回归测试流程和测试结果。从不同的层面，团队发现了一些导致执行耗时较长的因素。限于篇幅，本文仅以"打卡管理"这个业务模块作为例子来阐述发现的问题。
3.1 持续集成层面
3.1.1 并发
在持续集成平台上配置的回归测试任务中，没有嵌套的层级任务结构配置，没有充分利用平台的优势去并行地执行测试任务。
另外，也没有并行地执行测试用例。当时的配置是，一个任务对应一台测试客户端，单线程地执行模块内的所有测试用例。
3.1.2 浏览器窗口+登录
自动化测试脚本采用策略是每个测试用例的执行都需要重新启动应用、重新登录或排除账号互踢。
是否可以不用重启应用和清除数据，保持登录状态，不用重复登录
打卡管理模块的260个测试用例，如果每个测试类平均按照5个测试用例来算，再加上一些必需的重新登录，应该有测试用例可以不用重启应用，也不需要登录，总共可以节省的时间为：260 x 60% x 23 = 3588秒（1小时）。
3.2 测试用例和脚本层面
经过检查测试用例和测试脚本，发现用例和脚本中有比较多不必要的验证点。这些验证点对某些测试用例是必需的，但是对于其他很多的测试用例则是多余的。这些验证点不仅会浪费执行的时间，而且也可能导致测试用例失败在不相关的验证点上。
另外，团队还发现了一些测试用例的执行耗时过长。比如，有的测试用例耗时30分钟左右，甚至近1个小时。经分析发现了如下的问题会导致单个测试用例执行时间过长：
测试用例的问题。有的测试用例要求验证大量的界面元素，或者重复验证大量的界面元素。
准备、销毁测试数据的问题。测试脚本中通过界面创建、销毁比较多的测试数据，这部分界面操作消耗了额外的时间。
测试脚本的问题。有些测试脚本本身存在一些性能问题。
http://www.51testing.com/html/48/n-3721848.html