「改了一个字段，忘了改另一处，接口直接 500。」这种事每个做后端或系统集成的人都遇到过。接口测试的本质是重复劳动：每次改动都要把几十上百个接口重跑一遍，人工做不现实，不做又不放心。这正是适合交给 Agent 的活。
但有一个误区要先说清：让 Agent 随机去发请求，不叫接口测试，叫给对方添麻烦。真正能长期跑的接口自动化，前提是有清单、有分层用例、有干净环境和能沉淀的断言基线。缺了这几样，Agent 只会更快地产生噪声。
这篇在站内的位置：AI Agent 自动生成单元测试 管的是代码内部函数级的验证；Agent 压测与容量评估 管的是性能与容量；工具调用失败排查 管的是Agent 自己调工具失败。这一篇管的是另一种对象：你的系统对外提供的接口，改完之后还对不对。
一、先有清单：接口从哪来
没有清单，Agent 就不知道要测什么。三种来源，按可靠性排序：
- 接口文档（OpenAPI / Swagger）。最理想，结构化、字段齐全，能直接解析成清单。前提是文档和实现一致——这本身就是一个值得单独检查的问题。
- 抓包。用浏览器开发者工具或代理抓真实的请求响应，从流量里还原接口与参数。适合文档缺失的老系统。
- 代码里的路由定义。从框架的路由表或注解里抽。最准确，但需要写解析，而且拿不到业务语义。
清单里每条接口至少要记七个字段：路径、方法、鉴权方式、必填参数、成功返回码、业务错误码、依赖的前置数据。最后一列最容易被漏掉，却是自动化能不能跑通的关键——很多接口必须先有订单、先有用户，才能测。
二、四类用例，分开写分开跑
- 正常路径。参数合法时能不能返回预期结果。这是基础，但只有这一类等于没测。
- 参数边界。空值、超长、类型错、越界、特殊字符、多语言。这类用例最能发现真实 bug。
- 异常与权限。不带 token、token 过期、越权访问别人的数据、重复提交、并发提交。越权和幂等是最容易出安全事故的两块，幂等的设计原则可参考 失败重试与幂等设计。
- 业务规则。状态流转（未支付不能发货）、金额与数量约束、时序依赖。这类用例需要人先告诉 Agent 规则，它不会自己知道「业务上不允许」。
三、环境与数据隔离：这一关最容易被跳过
接口测试最容易造成事故的地方就在这。三条硬要求：
- 独立环境与独立账号。绝不让测试用例指向生产库，尤其是写接口。测试账号的权限也要单独配，别复用一个万能账号。
- 用例自建自清，不依赖执行顺序。每条用例自己造前置数据、跑完自己清理。一旦用例集依赖顺序，中间失败后面全废。
- 造数用合成数据。生产数据不能直接拿来测，而测试数据又需要贴近真实——这个矛盾正好由合成数据解决，做法见 用 AI Agent 做合成数据那篇。
另外，写接口的用例建议单独一组、单独跑，并且默认不进入「每次提交都跑」的那一批。道理和 Webhook 验签与去重 里说的一样：会产生副作用的动作，要先隔离再谈自动化。
四、断言与基线
只看 HTTP 200 是最常见的假测试。一个可用的断言至少四层：
- 状态码加业务码。很多系统 HTTP 200 而业务码是失败，只看前者会漏掉一半问题。
- 关键字段值。只验你真正关心的那几个字段，不要全字段比对——全量比对会被无关字段（时间戳、trace id）淹没。
- Schema 契约。字段类型、必填性、枚举范围不能偷偷变。这是契约测试的核心：接口可以加字段，但不能把必填改成可选、把类型换掉。
- 基线快照。首次运行记录一份基线，之后比差异；差异要人工确认是「预期变更」还是「回归」。
五、回归与失败处理
自动化测试只有跑起来才有价值，跑起来之后必须有人看结果。三件事：
- 两种触发：定时跑（每天一次扫全量）和变更后跑（改了哪个模块，跑相关的那批）。变更后跑的组织方式可参考 变更后验证清单。
- 失败分类：真 bug、环境抖动、数据问题、用例本身过时。四类处理方式完全不同，混在一起看会让人很快放弃读报告。
- 重试与升级：只对可重试的失败（超时、网络抖动）重试，断言失败不重试——重试没有意义还会掩盖问题。连续失败按 失败升级规则 升级到人。
六、五个最容易踩的坑
- 直接对生产环境跑写用例。这是最容易造成真实事故的一条，没有例外。
- 用例之间互相依赖顺序。单跑一条失败、按顺序跑却成功，说明用例本身有问题。
- 断言只看状态码。等于只验证了「服务没挂」。
- 硬编码测试数据和固定 ID。换个环境就全挂。数据要用变量和运行时生成。
- 把全量回归塞进每次提交。结果是要么跑不完，要么大家开始忽略红灯。快慢分两批。
七、优缺点与适合人群
优点：把重复劳动真正交给机器，人力从「跑用例」转到「定规则」；参数边界和越权类用例靠人写不全，靠批量生成反而更全；回归结果可以自动留档，成为变更证据；和单元测试、压测形成互补的三层验证。
缺点：前期投入不小——清单、环境、基线都要先建起来；接口文档不能全信，需要和实现对齐；业务规则类用例离不开人工输入；用例集本身需要维护，长期不管会变成「红一片、没人看」。
适合谁：接口数量多、改动频繁的后端与集成团队；有多个系统对接、契约容易走形的项目；需要给客户交付「变更验证材料」的乙方团队；以及已经在用 OpenClaw 做其他自动化的团队——多接一条流水线，边际成本很低。
不适合谁：接口数量个位数、改动极少的小项目，人工点一遍更快；以及还没有独立测试环境的团队——先把环境隔离做出来，比上自动化更紧急。
总结
- 定位：验证对象是「系统对外接口」，与代码内部的单元测试、面向性能的压测、面向工具调用的失败排查都不重叠。
- 清单先行：路径、方法、鉴权、必填、成功码、业务码、前置数据，七列缺一不可。
- 四类用例：正常路径、参数边界、异常与权限、业务规则，分开写、分开跑。
- 隔离三硬要求：独立环境与账号、用例自建自清、写接口单独跑。
- 断言四层：状态码与业务码、关键字段、Schema 契约、基线快照。
- 底线：不对生产跑写用例；断言失败不重试；用例集不维护就等于没有。
最后一句：接口自动化的价值不在于「测得多全」，而在于「改完之后你敢不敢直接发」。如果每次发版前还是要人肉点一遍，那这套东西就没跑起来。
