接口自动化在业务内的应用落地

一、背景
随着业务的快速迭代，这要求我们在保障日常迭代需求质量的同时，也要保障线上已有逻辑的正确性，以持续维护整个系统的准确性。因此，实施上线前的历史功能回归测试，以及对线上系统进行持续的定期检查是非常关键的。这正是接口自动化测试在业务中落地的重要性所在。此外，通过积累的自动化测试用例，我们不仅能对核心业务流程进行有效的回归测试，还对提高测试工作效率有积极的影响。
二、落地方案
根据当前业务现状，制定不同阶段的重点关注内容，整体方案流程如下：

首先需要确定适用业务场景的接口自动化工具，跑通流程；接着需要关注如何去覆盖业务逻辑、如何编写接口用例，对用例进行持续的沉淀；在case有了部分沉淀后需要关注用例的自动执行，包括触发执行时机、执行稳定性、失败问题跟踪等；最后需要制定一套在业务内可持续维护的机制，保障能够在业务内落地，并能够持续保障服务质量。
1、接口自动化工具选型
目前业务接口自动化主要包含以下两种主要场景：
（1）简单场景：单接口测试
（2）复杂场景：需要前后置数据构造/脏数据处理、复杂断言

基于以上两种场景，我们选择了常用的两个工具进行了对比，并确定了最终方案

✅ 最终方案：使用公司内部接口测试平台+代码工程辅助的方案
（1）简单场景：直接使用接口测试平台组装用例。
（2）复杂场景：断言复杂/接口前后置条件复杂的场景，使用代码工程封装通用测试/断言接口，再将该接口组装配置在接口测试平台。
2、接口用例沉淀
这个阶段主要关注以下两点。第一是如何高效率高质量的编写接口case，其中包括历史逻辑核心接口case的补充和新增需求接口case的自动化维护，如何避免测试和开发对于接口case的重复编写。第二就是用例集的组装，由于不同的业务场景需要触发不同的用例，因此我们把用例按照业务集群组装成不同的用例集合，并区分不同环境。
2.1 创建用例
（1）历史case补充
根据业务逻辑、线上接口调用量和服务覆盖率梳理核心接口，按照接口重要程度逐步补充接口case。
（2）新增需求case维护
目前主要分为两步：标记哪些用例可自动化&新增自动化用例。

2.2 组装用例场景（创建用例集）
我们制定了用例集的创建准则，包括按集群拆分和按环境拆分。
（1）按集群拆分：将相同集群的接口用例添加到同一个用例集中，满足部署需求分支后触发回归该服务相关核心功能的业务场景。
（2）按环境拆分：由于不同的环境下配置、用户信息等都不同，所以用例集需要区分线上、沙箱、测试环境，满足相同集群在不同环境执行不同用例的业务诉求。

3、接口用例自动化执行
有了用例的沉淀、用例集的配置后，需要关注用例集如何执行才能满足自动回归、服务巡检的目的。既需要在合适的时机触发满足场景需要，又需要稳定执行保证可靠性。

3.1 触发执行时机
（1）测试&沙箱环境服务部署成功后自动执行：主要目的是在分支部署后回归服务核心功能，自动保证开发代码的准确性。

（2）线上环境定时巡检：配置定时巡检任务，每5min执行一次，主要目的是对线上服务进行巡检和监控，保障服务的稳定性。

3.2 提高执行稳定性
执行稳定性的关注有两个阶段：
阶段一：提高case稳定性
失败的case主要是通知给对应集群的QA，过程中QA针对case不健壮、平台问题、环境问题等外部因素进行不断优化，提高case稳定性。先在QA内部维护，等用例集执行相对稳定后同步给RD，共同维护。

阶段二：提高服务稳定性
在case相对稳定后，将执行结果通知给对应的RD&QA，双方共同关注执行情况，及时定位解决问题，保障服务稳定。

4、制定可持续维护机制
4.1 用例集的补充机制
按周维度统计新上线的业务需求通知给QA&RD负责人，由负责人评估本周是否有需要新增但遗漏的接口自动化case。
4.2 问题的跟踪机制

测试和开发共同维护，对失败case进行及时跟踪解决，并对此过程进行不断的优化
（1）制定集群负责人，对应负责人对失败case进行定位&解决，并记录问题进行归因。
（2）QA定期组织接口自动化应用的复盘，包括近期数据、使用情况、过程中的问题等。

三、 成果
通过接口自动化测试的落地实施，我们取得了以下成果：
（1）核心集群的核心接口覆盖率已达100%，日常迭代需求的核心接口改动不再需要人工回归，可完全依赖自动化回归；
（2）线上服务质量得到保障，能够及时发现问题并解决；
（3）新需求用例转换为接口自动化的成本低，研发资源投入得到有效控制。
近半年的数据显示：执行成功率都维持在99.6%左右，发现线上bug数量约10个（失败原因中因外部门服务不稳定导致的bug占比高达73%，与对应部门建立了沟通机制，推动外部定期解决）。

接口自动化显著提高了回归效率，节省了测试人力，同时保障了线上服务的稳定性。