自动化测试优化：时间缩短50%！
微策略产品的灵活性很高，这使得用户能够创建出非常丰富的达析报告。但灵活性也给产品的开发和测试带来很大的挑战。微策略移动端产品的测试量有多大呢，就拿表格(Grid)来说，这个可视化效果的相关的测试用例就多达310条，而在整个移动端产品中复杂的组件和功能点还有很多。
如此复杂的产品，使得我们平时的开发和测试工作都极其依赖自动化测试。开发人员每完成一个功能，修改完一个bug，都希望用自动化测试来验证代码的正确性。测试人员也需要定期运行自动化测试来保证产品的质量。测试需求多，而测试用例的执行又非常耗时，所以经常会遇到测试机器资源不够用的情况。在项目开发紧张的时候，可能要等待一天以上才能拿到自动化测试的结果。为了缓解这个问题，我们分析了自动化测试中的性能瓶颈，并实现了一个优化方案。
在介绍性能优化方案之前，我们先来简单了解一下移动端自动化测试的原理。简单来说就是三个步骤：操作，截图，对比。首先利用自动化脚本模拟用户的点击、输入等行为对待测APP进行操作。然后将APP的输出结果截图保存。最后将截图和baseline进行比较。如果图片一致则测试通过；如果图片不一致则判定APP的输出有误，测试不通过。
下面是一个自动化脚本执行的例子：
在这个用例中，我们模拟了用户点击可收缩的单元格，即依次收缩了“Books”， “Movies”和“Music”单元格。因为有一部分操作结果是带有动画效果的，如果在动画过程中进行截图或者做下一个操作，就会导致测试用例运行失败。所以在每次操作后大约有2~3秒的停顿，用来保证测试结果的稳定性。
经过统计，我们发现这些停顿占用了大约50%的测试运行时间。所以只要能够减少这些停顿，就可以大幅缩短测试运行时间。那么我们能不能加快动画，以此来缩短停顿时间呢？经过研究我们发现iOS系统可以通过设置主window上layer的speed参数来控制动画运行的速度。如果我们想让动画以10倍速运行，就可以将speed参数设为10。
下面是同一个操作在动画加快10倍，同时停顿时间降至1/10的运行效果。在提速之前这个操作用时15秒，提速之后4秒就完成了：
应用了这个优化后，自动化测试性能可以提升多少呢？下表统计了8个测试集共307个测试用例的提速前后对比：
可以看到速度确实飞起了，提升了35%左右，但是同样飞起的还有失败率，比之前多了61个失败的用例，失败率升高了约19%。稳定性是自动化测试的第一指标，因为如果自动化测试失败，需要人工介入对比结果并修改用例，开销巨大。所以提升速度不能以牺牲稳定性为代价。
难道这个办法不可行吗？从上表中我们可以看出，在这8个测试集中，有约26%的用例会失败，其余的用例是可以在10倍速模式下稳定运行的。针对这26%的用例，我们尝试用5倍速执行，发现有11%的用例可以通过测试。接下来我们再次尝试了2倍速运行，发现又有7%的用例可以通过测试。至此，只有9%的用例只能在原速度下运行才能通过测试：
基于这个思路，就有了对自动化测试优化的方案：
- 先评估测试的稳定性，为每一个测试用例分配一个合适的加速参数，在保证稳定性的前提下尽可能地提高APP运行速度
- 在执行测试用例时，依照该加速参数来加快测试运行速度。主要通过加快动画速度和缩短操作之间的停顿时间来实现
下表是按照以上方法优化后，这8个测试集的运行结果：
这个方案要求在运行某个测试用例之前预先了解它是否稳定，以决定用什么样的速度去运行它。而这个定速的过程只要稍微改动自动化测试的流程就可以实现，我们称之为训练任务。
训练任务先给每个测试用例设置一个较高的速度，然后多次运行用例。每当用例失败就降低其运行速度，如果成功则维持速度不变。经过几次迭代之后，训练任务就能给每个测试用例设定一个能够稳定运行的最优速度，今后我们用这个最优速度执行该用例，就可以既快又稳地完成测试啦！改进后的流程如下图所示：
该系统可以利用训练任务先给每个用例生成一个最优速度，然后把结果和baseline一起保存到服务器上。当测试任务要运行时，就会把速度参数和图片baseline一起取回到本地，然后根据最优运行速度来运行测试。在上线了这个系统之后，我们将该方案其应用在了更多的测试用例上。有71%的用例以最高的10倍速运行，12%以5倍速运行，9%以2倍速运行，有8%的用例只能以1倍速运行。整个训练过程是自动化的，无需添加额外的工作。统计结果如下：
经过训练后，总体的运行时间节省了45.5%，而系统的稳定性还和之前一样优秀。这也基本符合我们最开始的分析结果，即操作之间的停顿时间约占了测试总时间的50%。
以上就是我们在测试性能优化上的成果。在今后的工作中，我们要将这个系统应用到更多的测试集中，并继续提高其易用性和稳定性。还可以通过探索其他方案，比如并行运行测试用例、利用开发机器的空余时间来运行测试等等，进一步提升测试效率。