背景

这段时间和小伙伴在整理我们当前的自动化运行模式。觉得有些技术之外的东西值得总结记录一下。

1. 自动化测试的定位、目的和对应策略

由于我们团队负责的是一个长期运营的产品，并且在可预见的未来，都会继续长期地运行下去。因此自动化测试的目的，就很直接和纯粹：

通过提高回归测试的自动化测试覆盖率，节省每个开发周期里的回归测试时间和工作量，成为季度版本、月度版本开发发布环节中的重要一环

为了实现这一目的，我们对自动化测试的范围进行了如下界定：

1. 整理出完整的产品回归测试用例库
2. 从回归测试用例库中，挑选出可被自动化的用例，打上 “待自动化” 的标签。这就是我们的自动化目标。
3. 将所有待自动化的用例进行归类和拆分，根据模块分配到对应的同事头上，并制定具体的实施计划。
4. 已完成自动化的用例打上 “已自动化” 的标签。这样可以很直接的通过 “已自动化”/“待自动化” 算出自动化进度；通过 “已自动化”/总用例数，算出自动化覆盖率。
5. 每个开发版本结束后，整理更新产品回归测试用例库：根据产品的迭代更新，对回归测试用例进行增删改。
6. 根据回归测试的级别不同，自动化测试用例也设置不同的级别标签，执行某个测试任务时可以精确匹配对应的测试用例。简单来说冒烟测试就只执行冒烟用例，全回归就执行所有用例。

通过梳理出以上的流程，团队对于我们的自动化任务的目的和计划都会有相对清晰的理解，大家执行起来也会更快速。

2. 如何让自动化测试真正帮助回归测试

上面讲到我们的自动化测试目的就是为了帮助回归测试。相信每个团队都有自己的思考和尝试。我们的做法是这样的：

背景：我们所有的测试用例和测试执行都是在 jira 上面管理。

1. 将自动化测试脚本和 jira 用例进行一一关联。在每一条自动化测试用例的代码上，都备注上对应的是哪一条 jira 用例，标记上对应的 id。
2. 每次回归测试时，都会通过 jira 建立对应版本的 test cycle，将所有回归测试用例拉到 cycle 中。这些就是本次回归测试需要测试的范围。
3. 对应的自动化用例执行完成后，我们会在 Jenkins pipeline 中加入一步：读取整个测试中每条用例的执行状态，并通过 jira api，将 cycle 中的测试用例标记为通过。

通过将自动化用例和回归测试的管理真正打通，实现了每天晚上的自动化测试 pipeline 跑完之后，第二天马上可以看到有多少用例已被自动化执行通过。这样测试的同事只需要将剩下的用例（未被自动化，或者自动化执行失败）手工执行即可。

自动化测试覆盖率越高，自动化通过率越高，直接决定了回归测试中为团队节省的工作量。
直接让大家看到自动化测试的收益，才能更大程度地激励小伙伴们投入到自动化用例编写和维护的热情；而且从产出的角度来看，也确实节省了工作量。

3. 如何提高自动化测试的执行效率

在最开始的阶段，所有的自动化测试用例都是按线性的方式来执行的。随着用例数量的不断提升，整个测试任务的时间就会拉得越来越长，很明显不能满足未来的需求。
所以我们针对性地做了一些策略上的调整：

1. 将单线程的任务改成多线程： 将整个测试库按照模块拆分成不同的集合，同时启动多个不同的子任务去执行。简单地看，1000 条用例拆分成 5 个子任务，理想状态下就是把执行时间缩短到 20%。
2. 配合多线程任务，配置不同的测试帐号：由于我们系统上单点登录的，所以必须为不同的线程配置单独的测试帐号和测试数据。
3. API 测试：结合测试框架的能力，设置多线程并发执行。

4. 针对不同的测试需求，设置不同的验证策略

一般的自动化测试用例，在用例的验证断言部分，通常的做法就是每个字段，每个元素都做一个断言。但在某些情况下，是有缺陷的：

1. 某些页面上会特别关注页面布局，比如 app 的登录页面等。如果单个元素逐个去验证，即使元素都存在，也无法验证位置、大小、颜色是否正确。所以我们加入了图像对比的验证方式（diff image），即自动化到了这个页面的时候直接截图，和预设的期待图片进行对比。如果图片差别超出我们设置的阈值就直接报错，并且高亮两种图片中不一样的地方。这种方式就不需要关心页面每个元素对不对，而是更直接更准确地识别页面中的错误。
2. 在 API 测试中，某些情况下我们需要回归验证整个返回中的每个字段、结构都是正确的。这种情况下我们也是可以通过 json diff 的方式，将测试返回和预设值进行对比，快速识别任何错误和变化。

总结

以上是我们其中的一些经验。虽然对于自动化测试来说，发展到现在有很多不同的语言、工具和框架来选择。但在真正做自动化的过程中，还是建议大家可以抛开具体的技术细节，去想如何完成和优化自动化这个工程。想法和思路是无限的，不要被技术的细节限制了自己。