提起自动化测试能力，作为现在测试人员技术能力体现的一部分，越来越多的人关注到这部分能力的提升。但是，很多团队的落地效果并不佳，在轰轰烈烈的开始中，慢慢沦为 PPT 产物。那么，如何让团队真实地享受到自动化带来的提效呢？结合个人在不同公司的落地情况，说说自己的想法。
提效从来不意味着降本，如果你是想通过自动化测试，来减少测试人员的数量，节约人力成本，以此为目标的话，大概率是失败的。个人认为，自动化测试的意义在于构建快速反馈的能力，不论是集成在 CICD 流水线上，还是作为线上巡检的一部分，都能够提升质量反馈的速度。在敏捷研发的大环境下，快速反馈能力是必不可少的。不能让测试执行成为团队交付瓶颈。
记住这个初衷，它将影响后续一系列的动作。不要让它变形了。
在之前的《通过抓包能否做好接口测试》中，有提到过，只有标准化后，才有可能自动化，很多测试负责人仅从测试的角度出发，通过一些取巧的方式来实现接口自动化（比如通过 Curl 或者录制 har 文件，来实现接口测试），虽然能在短期内看似落地了接口自动化，但是缺乏对接口的理解，是无法长期执行并产生效果的。
这里的标准化，指的是接口文档的时效性问题，很多团队也有自动维护的接口文档，但都是第一稿的信息，后续在实现过程中的变更都没有办法在文档中体现，那么做接口自动化就会非常的痛苦。
所以，推动上游的接口标准化、实时性，就成为关键问题，其实这是个双赢的事。对研发而言规范了接口，自己联调也方便。并不难推动。
如何解决第 2 点的问题呢？你不能期待让研发人员手动去维护接口文档，也不能期待研发人员主动告诉你接口变更了，这是不现实的，也不要抱怨。解决这类问题，需要从工程能力的角度去着手。基于现在的研发能力，不论是 Swagger 还是 ApiDoc，都有能力直接从代码工程上自动生成接口文档，而且还是实时的。
个人的实践是，如果团队比较小，那就直接引用 Swagger 的标准化框架，然后直接对接 Swagger 路径，去自动解析接口，监听接口变更。如果团队较大，可以写个 SDK，来主动上报 Swagger 路径，从而获取接口信息。
一个完整的接口自动化全链路大致如下：
这样对研发而言，改动量最小，又能规范研发代码，让研发主管也能从中受益，相互绑定利益，推动起来也容易。
很多时候，自动化测试沦为鸡肋的原因是，大多数的测试用例都只是单接口的用例，通过参数的等价类、边界、异常值作为人参就完事了。不是说这类测试不重要，而是真的没太必要把时间花在这上面。这些完全可以通过接口定义和参数注解来约束，出问题的概率不大（做好 Code Review 和静态扫描，用好框架，能解决 90% 的这类问题）。
从测试覆盖的角度看，我们更希望看到的是多接口串联场景，能够真实地模拟业务操作，把数据流完整地跑通，配合上有效的检查点，来帮助我们发现、拦截问题。
这部分的具体内容，可参考《接口测试这么玩才明白》。
所以，贴合实际业务场景的链路接口操作，合理的检查点设置，才能让自动化有效地运转起来，能帮助我们有效地去拦截问题。测试用例的数量和覆盖率并不是我们追求的数据。切记。
基于接口自动化的脚本，我们还可以做很多事，让这件事的价值最大化。常见的有以下几类：
CICD 门禁：由于自动化的执行效率高，可以集成到 CICD 中，作为质量门禁的一部分，把问题拦截在开发环境，及时反馈问题。
造数工具：在合理的参数化场景下，多数接口测试场景都能用于测试数据的制造，特别是对于链路比较长的前置数据，接口造数是个非常可行的方案
辅助回归测试：基于接口自动化测试，可以快速覆盖核心功能，把时间节约出来，做针对性的专项测试或者对新功能进行验证。前提是你的用例足够清晰和健壮。
线上巡检：线上环境的拨测已经被越来越多的团队重视，也是测试右移的一项重要能力，自动化测试可以作为业务线上巡检的一部分，快速发现问题。
自动化测试是构建测试人员快速反应能力的基本要求，也是提升效率的有效手段，它需要前期的投入，标准化的维护以及有效的测试用例设计，才能最大化地发挥它的价值。自动化测试的负责人，需要具备推动标准化落地的能力，并让自动化在更多的地方体现出价值来。
任意一项技术手段的推广与实践，不论是研发过程的规范，还是测试活动的规范，都不是一次性的投入，都需要长期持续地投入维护，潜移默化地影响其他人。
关于自动化测试的 ROI，东东也写了一篇估算的文章，大家可以参考下：自动化测试投入产出效益与价值
