汇总资料#

接口资料通常散落在五处：契约文件（可机器校验的形式化描述）、说明文档、变更记录、历史缺陷，以及同事随手留下的请求示例。汇总之后要把它整理成结构化的接口描述——每个接口的方法、路径、参数、请求体、响应和认证方式。

汇总时有两件事要守住：

• 标注来源：每条结论是来自说明文档、来自契约文件，还是由材料推断得出，要分得清楚。
• 保留空缺：材料里查不到的信息，列成待确认清单，挂起待核实。

分清项目事实与模型推测#

AI 见过很多系统，会依据经验补全资料里缺失的部分。这类补全要与项目事实分开标注，否则后面的测试就建立在假设上了。待确认清单把还不知道的部分显式留下来，留待核实。

确认规范版本#

上面说的契约文件，遵循的是一套接口描述规范，而这套规范有不同版本，语法和字段位置各不相同，解析之前先确认版本。版本信息连同它的来源，一并记入接口清单。

梳理依赖#

接口很少是孤立的。常见的依赖有五类：

• 鉴权：需要先登录换取凭证
• 数据接力：需要上游接口返回的标识才能调用
• 强顺序业务：必须按业务顺序执行
• 开关与租户：不同配置下行为不同
• 延迟可见：写入之后要等一段时间才能查到，验证要轮询到目标状态出现或超时

前四类决定调用先后与数据传递方式；开关与租户不影响顺序，它影响的是同一接口在不同配置下的期望值。

探索阶段把这些整理成一份接口依赖关系清单，记录每对接口之间的关系与传递的字段，作为计划阶段排顺序的候选输入。

产出：结构化接口清单、接口依赖关系清单、待确认问题清单。

范围与优先级#

设计阶段先定两件事：这次测哪些接口，以及先测哪些。

排优先级看三件事：会不会挡住发布，要不要每次回归，断了之后损失最大的是哪一环。

AI 负责把模块、接口、场景的清单列成候选，人负责决定先测哪些。

覆盖层次#

范围定下来之后，按几个层次各过一遍，检查有没有整类场景被漏掉：

• 主路径：正常流程能不能走通
• 边界值：参数取到契约允许的上下边界时，接口如何回应；越界一档的期望是拒绝，归入下一类
• 拒绝场景：协议不合法、业务规则不允许的请求，有没有被正确拒绝
• 基础观测：响应时间在什么量级
• 低成本安全项：未授权、越权这类基础检查，成本低，顺手补上

这几层是一张查漏用的清单，各层比例由业务风险决定。并发扣库存、重复提交这类场景不在这几层之内，需要另外补上。

期望值#

期望值要回答的是：请求发出去之后，什么样的返回才算对。它是一条用例里最难定的一半——发什么请求照着接口清单抄一遍就有，期望什么样的返回没有现成的地方可抄。

定期望值时按顺序找依据：契约文件写明的以契约为准，说明文档写明的以文档为准，业务规则明确的以规则为准。同一接口在不同配置下期望不同，差异按配置分别记录。三者都没有的，记入待确认清单并挂起。

断言粒度#

断言分层写：

• 协议层：状态码与响应格式
• 结构层：关键字段是否存在且类型正确
• 业务层：结果是否符合业务规则
• 链路层：上游接口返回的数据能否被下游接口正常使用。这一层只在跨接口的场景用例里出现；上游失败时，下游用例应当跳过

断言只写到依据链上明确承诺的那一层：只断言其中声明为必填的字段，以及业务规则约定的值。可选字段、扩展字段、字段顺序，以及时间戳的具体取值，都不作断言对象。

产出：测试策略（范围与优先级、覆盖层次、期望值、断言粒度）。

结构化用例#

把策略展开成一条条用例，每条说明调用哪个接口、传什么数据、期望什么结果、这个期望的依据，需要哪些前置条件，并带上自己的编号。

这个形态是可评审的结构化数据，下游代码环节直接消费，返工量小得多。

测试数据#

数据按用途分两类：正常数据用于验证主路径，边界数据用于验证契约允许范围的临界值。

计划阶段定下的是数据规格：字段约束、唯一性、清理方式、来源。具体取值在执行时生成。

数据管理有三条通用原则：

• 写入型测试使用唯一数据，避免重复运行与并行运行相互干扰
• 每条写入的数据配一个清理动作，另有一套按前缀批量回收的兜底清理，不依赖用例正常退出
• 账号、凭证和环境地址通过环境变量提供，不写进用例

执行顺序#

顺序主要从探索阶段的依赖结构推导：

• 图上没有相连的接口归入同一批。图上无连接只是必要条件——能不能真的并行，还要看它们是否共用同一份可变数据，比如库存、余额、账号、全局开关
• 有依赖的优先用前置数据构造消除；确实打断不了的，显式标记为顺序执行，并在失败时跳过后续
• 写入后延迟可见的接口，额外带上轮询与超时条件

产出：结构化用例——每条用例连同它的数据规格与顺序约束一并确定，进入执行阶段后可以直接照着写代码。

从用例到脚本#

转换的主体可以机械化，真正需要安排的是公共部分：环境地址、超时这类配置从环境变量读取，认证、数据生成这类每条用例都要用的逻辑集中管理。断言按设计阶段定下的层级写。

此外，每条用例保留自己的编号，报告里的结果才能回溯到计划阶段的用例。

运行前的准入检查#

跑之前先做准入检查：服务可达、账号有效、接口已部署、当前环境允许写数据。这四件事只能在真实运行中确认。任何一项不通过，整批终止，标记为环境阻塞，不生成用例级报告，不进入自愈。

准入通过之后，按计划阶段确定的顺序执行。

报告解读#

运行留下的证据汇总成报告。报告要能回答两个问题：这条结果对应哪一条用例，失败时的现场是什么样。因此每条记录包含：

• 用例编号与名称
• 调用的接口，以及该用例的期望值及其依据
• 通过/失败状态
• 失败时的请求、响应、状态码与运行环境

请求与响应里的凭据和令牌，在落盘之前先脱敏。自愈从这份报告取用证据，不再另建留存路径。

产出：测试脚本、执行报告。

失败分类#

常见的失败现象有几类，每类的原因和修复方向都不同：

现象与原因是一对多：业务码不对，可能是产品改了规则，也可能是上一轮遗留数据、期望值本身写错、环境开关没开。期望值的改动以已确认的变更为前提；证据不足以区分时，标记为待人工判断。

自动修复流程#

分类定下来，修复方向也就定了。自动修复分三步：

1. 捕获失败信息：把失败时的请求、响应、状态码和运行环境一起留存下来。证据在执行阶段已经脱敏落盘，这里直接引用。
2. 生成修复补丁：按失败类别给出对应的改动方案，连同判断依据一起记下来——判定为路径类失败，补丁就是调整地址或路径拼接。改动涉及期望值或核心断言的，补丁以待确认形式提交，不直接应用。
3. 应用并复跑：可直接应用的补丁应用后，把这条用例重新跑一遍，跑通了才算修复完成。复跑走执行阶段的同一套流程与报告。

修复纪律#

• 改动从局部开始：配置、路径拼接、数据唯一性、认证获取、等待逻辑。这几处覆盖了大部分失败；框架和核心断言不在这批改动范围内。
• 关键期望值的更新以已确认的变更为前提：响应少了一个字段，先确认是契约变了，还是产品缺陷。
• 该转人工的时候转人工：同一用例连续失败达到预设次数，或者补丁会改变核心业务断言。当现有证据分不清”产品有缺陷”和”测试写错了”的时候，人工判断是最快的路径。

产出：修复后的测试——补丁回写到设计、计划、执行三处的产物上，每次回写留记录。