接口自动化测试实战-从0到1实现接口测试全流程

很多人第一次做接口自动化，卡的不是写断言，而是框架装好了不知道先测哪个接口、用例写了几十条跑一次全红、跑批不稳定最后没人看结果。这篇不讲测试理论，只按顺序给一条从零到跑通的路径：先定范围和骨架，再补用例与数据，最后接进跑批和报告，每一步都给了可执行的清单和判断标准。

第一次做接口自动化，卡住的地方往往不是写断言，而是框架装好之后不知道先测哪个接口。有人一口气开了五个模块，结果每个都只写了一半；有人用例堆到几十条，跑一次全红，最后没人再点那个按钮。这篇按顺序给一条能照着走的路线：先定范围和骨架，再补用例和数据，最后接进跑批和报告，每一步都给可执行的动作和判断标准。

先说明适用范围：这套流程适合接口相对稳定、有独立测试环境、团队里有人能持续维护脚本的情况。如果你的接口还在大改、需求一周一变、或者根本没有稳定的测试环境，下面这些做完也会很快腐烂，先手工回归更划算。判断要不要投入，看两条：主链路接口是否已经定型，以及有没有人能固定每周花时间维护脚本。

第一步：定范围、搭骨架，别一上来就堆用例

范围要窄。先挑一条主链路接口，登录、下单、查询这类能串起来的，跑通再扩。同时开的模块越多，越容易哪个都不完整；一条链路的验收标准是能连续跑完并且结果可读，不是覆盖率好看。

1. 挑主链路选一条被依赖最多、出问题影响最大的链路，比如登录后查订单。先只覆盖这条，别管其他接口。
2. 定目录结构配置、用例、数据、工具函数、报告分开放。base_url、超时时间、并发数抽到单独配置文件，换环境只改一处。
3. 写最小断言只断言状态码和关键业务字段。新人常见错误是断言写太细，接口字段一改全红，改断言的时间比写用例还多。
4. 验证跑通一条命令跑完一条链路，退出码能反映成败，能自动生成报告文件。这三条都做到才算骨架立住。

第二步：用例与测试数据，让脚本可重复跑

用例能不能重复跑，比用例数量重要得多。核心区别是：造数据和断言数据要分开。用例自己准备前置数据、跑完自己清理，不依赖上一条用例的残留状态。否则一旦执行顺序变了，结果就不可信。

• 参数化驱动：一条用例跑多组入参，覆盖正常值、边界值、异常类型，量不用大但分层要清楚
• 接口有幂等要求时，重复跑同一用例应得到同样结果；做不到就先补接口的幂等设计，再谈自动化
• 测试数据外置，同一套用例能指向测试环境和预发环境，切换只改配置不改代码
• 用例之间不共享状态，执行顺序打乱也能跑通，这是可重复的最低标准

第三步：接入跑批，先把不稳定压下去

不要一上来就把脚本塞进发布流水线。先在单机上定时跑，跑顺了再接持续集成。理由是：跑批不稳定时，塞进流水线只会阻塞发布，最后被团队直接关掉。

失败重试要有边界。只对网络类错误开重试，业务断言失败不要重试，否则会把真 bug 掩盖成偶发问题。并发档位也别拉满，先按被测服务的承受能力估一个值，具体基线到 /tools/speed-test 先量一遍延迟，再决定并发数。

• 先单机定时跑，观察一周的失败分布，再接流水线
• 重试只覆盖超时、连接失败这类网络错误，断言失败一律不重试
• 日志记录请求、响应、耗时、断言结果、环境标识，出错时能分清是环境问题还是代码问题
• 跑批结果要有人看，哪怕先发给一个固定的群，也比没人看强

第四步：出报告、看趋势、决定要不要继续投入

报告里要把通过、失败、跳过分开统计，跳过项写明原因。跳过不写原因，通过率这个数字就会骗人：看起来是全绿，实际上一半用例没跑。

比起单次通过率，更值得看两组趋势：失败用例的原因是否在收敛，以及整体耗时是否稳定。原因反复出现说明脚本或环境有坑，耗时忽高忽低说明跑批资源或被测服务不稳定。

1. 能交接换个人接手，半天内能跑起来。跑批命令、环境说明、数据准备步骤写进 README，别只留在原作者脑子里。
2. 看趋势每周记录失败原因分类和整体耗时，连续两周恶化就停下来修脚本，别继续加用例。
3. 设止损线维护时间明显超过它省下的回归时间，就砍掉不稳定模块，保留主链路。要不要继续投入，到 /guides 对照当时的判断标准核对。