自动化测试落地为什么那么难

管理好预期

提效从来不意味着降本，如果你是想通过自动化测试，来减少测试人员的数量，节约人力成本，以此为目标的话，大概率是失败的。个人认为，自动化测试的意义在于构建快速反馈的能力，不论是集成在CICD流水线上，还是作为线上巡检的一部分，都能够提升质量反馈的速度。在敏捷研发的大环境下，快速反馈能力是必不可少的。不能让测试执行成为团队交付瓶颈。

记住这个初衷，它将影响后续一系列的动作。不要让它变形了。

自动化的前提是标准化

在之前的《通过抓包能否做好接口测试》中，有提到过，只有标准化后，才有可能自动化，很多测试负责人仅从测试的角度出发，通过一些取巧的方式来实现接口自动化（比如通过Curl或者录制har文件，来实现接口测试），虽然能在短期内看似落地了接口自动化，但是缺乏对接口的理解，是无法长期执行并产生效果的。

这里的标准化，指的是接口文档的时效性问题，很多团队也有自动维护的接口文档，但都是第一稿的信息，后续在实现过程中的变更都没有办法在文档中体现，那么做接口自动化就会非常的痛苦。

所以，推动上游的接口标准化、实时性，就成为关键问题，其实这是个双赢的事。对研发而言规范了接口，自己联调也方便。并不难推动。

需要具备工程化思维

如何解决第2点的问题呢？你不能期待让研发人员手动去维护接口文档，也不能期待研发人员主动告诉你接口变更了，这是不现实的，也不要抱怨。解决这类问题，需要从工程能力的角度去着手。基于现在的研发能力，不论是Swagger还是ApiDoc，都有能力直接从代码工程上自动生成接口文档，而且还是实时的。

个人的实践是，如果团队比较小，那就直接引用Swagger的标准化框架，然后直接对接Swagger路径，去自动解析接口，监听接口变更。如果团队较大，可以写个SDK，来主动上报Swagger路径，从而获取接口信息。

一个完整的接口自动化全链路大致如下：

这样对研发而言，改动量最小，又能规范研发代码，让研发主管也能从中受益，相互绑定利益，推动起来也容易。

贴合实际业务的场景化脚本

很多时候，自动化测试沦为鸡肋的原因是，大多数的测试用例都只是单接口的用例，通过参数的等价类、边界、异常值作为入参就完事了。不是说这类测试不重要，而是真的没太必要把时间花在这上面。这些完全可以通过接口定义和参数注解来约束，出问题的概率不大（做好Code Review和静态扫描，用好框架，能解决90%的这类问题）。

从测试覆盖的角度看，我们更希望看到的是多接口串联场景，能够真实地模拟业务操作，把数据流完整地跑通，配合上有效的检查点，来帮助我们发现、拦截问题。

这部分的具体内容，可参考《接口测试这么玩才明白》。

所以，贴合实际业务场景的链路接口操作，合理的检查点设置，才能让自动化有效地运转起来，能帮助我们有效地去拦截问题。测试用例的数量和覆盖率并不是我们追求的数据。切记。

最大化接口测试的价值

基于接口自动化的脚本，我们还可以做很多事，让这件事的价值最大化。常见的有以下几类：

1. CICD门禁：由于自动化的执行效率高，可以集成到CICD中，作为质量门禁的一部分，把问题拦截在开发环境，及时反馈问题。

2. 造数工具：在合理的参数化场景下，多数接口测试场景都能用于测试数据的制造，特别是对于链路比较长的前置数据，接口造数是个非常可行的方案

3. 辅助回归测试：基于接口自动化测试，可以快速覆盖核心功能，把时间节约出来，做针对性的专项测试或者对新功能进行验证。前提是你的用例足够清晰和健壮。

4. 线上巡检：线上环境的拨测已经被越来越多的团队重视，也是测试右移的一项重要能力，自动化测试可以作为业务线上巡检的一部分，快速发现问题。

小结

自动化测试是构建测试人员快速反应能力的基本要求，也是提升效率的有效手段，它需要前期的投入，标准化的维护以及有效的测试用例设计，才能最大化地发挥它的价值。自动化测试的负责人，需要具备推动标准化落地的能力，并让自动化在更多的地方体现出价值来。

任意一项技术手段的推广与实践，不论是研发过程的规范，还是测试活动的规范，都不是一次性的投入，都需要长期持续地投入维护，潜移默化地影响其他人。