自动化测试，有最佳实践吗？

前几天知识星球里的同学问了这样一个问题：API 自动化测试，业内有没有标杆指标？

问题背景大致如下：

接口自动化建设过程中遇到了一些困境，需要从团队建设角度给出发展目标和具体的指标，主要问题有如下两点：

1. 大厂/有最佳实践的团队，接口自动化在微服务的角度覆盖率需要达到多少？

2. 接口自动化的稳定性(case 通过率)需要达到多少才算是达标，达到多少算比较优秀？

这个问题表面来看，是需要一些明确的指标，为测试团队的自动化测试工作开展指明目标。但仔细思考一下，我个人认为背后的原因在于，在开展接口自动化测试工作时，并没有考虑清楚需要投入的成本，团队当前的现状，以及优先级最高的问题该如何解决。

从自动化测试的投入产出比金字塔模型来说，接口自动化确实是性价比最高的一种自动化测试方式。单元测试的技术要求比较高，大部分测试团队很难胜任；UI 自动化又很考验前端的编码规范和 UI 的稳定性。而接口自动化测试的优势在于如下几点：

• 有赖于系统架构的演进，微服务和前后端分离的设计理念，系统和服务间的交互更为解耦，数据交互基本都在接口层解决；

• 相比于 UI 的变化频率而言，接口变更带来的测试维护成本更低；

• 测试工具和框架越来越成熟，不需要太熟练的编码能力，普通测试同学都可以参与到接口自动化测试工作中；

自动化测试的优势毋庸多说，能提高测试验证效率，缩短结果验证反馈周期，但这些优势之所为能成为团队提效的优势，背后需要的是前期一定成本的投入。且自动化测试在前期建设阶段，投入产出比势必会有一段时间处在亏损状态。

对测试团队来说，自动化测试无论是测试左移右移，都是长期必须建设的技术设施。但需求是做不完的，迭代是几乎不会停止的，如何保证在尽可能的吞吐需求的同时，保障测试的交付质量，同时还要投入一定资源开展自动化测试工作，这一点很考验团队管理者的能力。

业内有没有自动化测试的最佳实践呢？从普世的角度来说，只有一些方法论和注意事项可以参考；从现实角度出发，没有适合绝大多数团队的落地实践案例。因为每个公司的业务特性和复杂度不同，测试团队成员的技术能力不同，做事方式不同，测试方法和流程规范不同，以及测试团队本身所能投入的资源多寡和管理层允许投入这些资源所期望的回报时效都不相同。

相比于前几年互联网行业大刀阔斧招聘和开发各种技术平台，在当下的降本增效共识下，公司和团队领导更需要的是能立即解决问题提高效率的技术实践，而不是看着高大上但实际上回报周期更长的技术项目。在 KPI 和营收压力下，大家更关注的是当下，成本、人效和收益，永远是老板和管理层最关心的。

我个人的观点是，测试团队在当下要实施自动化测试，首先要做的事情是找到低效的原因和环节，能通过自动化测试快速覆盖，让 case 跑起来出结果，缩短反馈周期才是最重要的。

至于所谓的覆盖率，大家不要太迷信这个东西，毕竟统计学，是这个世界上最有魅惑力的学科。统计维度和周期不一样，最终的数据指标上下限超乎你的想象。

本文最后，回答一些关于上述问题，我的一些实践经验，仅供参考。

• 不要迷信 case 覆盖率和测试通过率，重点关注是否缩短了测试和反馈周期；

• 影响测试用例通过率的因素很多：脚本问题，数据问题，断言问题，环境问题；

• 测试覆盖率只是一个统计结果，测试同学更应该关注测试用例和业务场景的匹配度；

• 测试覆盖率从一定角度来说是有用的，便于测试团队评估自动化测试的粒度和投入成本；

• 建议按照核心业务-对应服务-核心接口来梳理，优先覆盖核心业务应用的 P0 接口，以此类推；

• 自动化测试在前期落地过程中，建议优先覆盖增量需求的核心接口，然后再考虑存量业务场景；

最后，我个人认为，是否要做自动化测试，如何做，怎么做，阶段里程碑是什么，都应该根据所处团队的具体情况来制定落地计划，然后根据落地情况实时调整，优先解决核心问题。

一个比较好的技术落地思维方式是这样的：

• 目前团队面临的最大问题是什么？——聚焦问题；

• 这个问题有业内有哪些解决方法？——分析根因，对比评审；

• 目前优先级最高的诉求是什么？——能快速跑起来/规范操作和协作流程；

• 解决这些问题需要投入多少资源？——投入多寡对应的见效时间差距有多大；

• 快速小范围落地实践，观察结果，评估效果和性价比，调整方案，继续迭代！

软件测试好歹也是一个技术岗位，对于技术实践来说，最小可行性方案永远比 PPT 更能解决问题！