update blog

Author: hyglgithub

src/content/posts/20260920.md

@@ -0,0 +1,231 @@
+---
+title: AI 能把接口自动化做到哪一步？
+description: AI 做接口自动化测试的五个阶段各自解决什么问题、遵循什么原则、产出什么，以及 AI 与人在其中各自承担的部分。
+published: 2026-09-19
+tags: [接口测试, 自动化测试, 测试方法论, AI自动化]
+category: 原创
+draft: false
+
+---
+
+AI 做接口自动化测试，工作流可以拆成五个阶段：
+
+> **探索 → 设计 → 计划 → 执行 → 自愈**
+
+上一阶段的产出就是下一阶段的输入，每个阶段产出的每一条结论，都要能追回到它的来源。
+
+| 阶段 | 回答的问题                 | 产出                               |
+| ---- | -------------------------- | ---------------------------------- |
+| 探索 | 有哪些接口、它们怎么连     | 接口清单、依赖关系、待确认清单     |
+| 设计 | 这一轮验证什么、到什么程度 | 测试策略                           |
+| 计划 | 这些验证怎么落成安排       | 结构化用例（含数据规格与顺序约束） |
+| 执行 | 跑出来的是不是真的         | 脚本、执行报告                     |
+| 自愈 | 失败之后怎么办             | 修复后的测试                       |
+
+---
+
+## 一、探索：整理出接口清单与依赖关系
+
+探索阶段要回答的是：有哪些接口，它们怎么连。做法是把散落的资料汇总成结构化的接口清单。
+
+### 汇总资料
+
+接口资料通常散落在五处：契约文件（可机器校验的形式化描述）、说明文档、变更记录、历史缺陷，以及同事随手留下的请求示例。汇总之后要把它整理成结构化的接口描述——每个接口的方法、路径、参数、请求体、响应和认证方式。
+
+汇总时有两件事要守住：
+
+- **标注来源**：每条结论是来自说明文档、来自契约文件，还是由材料推断得出，要分得清楚。
+- **保留空缺**：材料里查不到的信息，列成待确认清单，挂起待核实。
+
+### 分清项目事实与模型推测
+
+AI 见过很多系统，会依据经验补全资料里缺失的部分。这类补全要与项目事实分开标注，否则后面的测试就建立在假设上了。待确认清单把还不知道的部分显式留下来，留待核实。
+
+### 确认规范版本
+
+上面说的契约文件，遵循的是一套接口描述规范，而这套规范有不同版本，语法和字段位置各不相同，解析之前先确认版本。版本信息连同它的来源，一并记入接口清单。
+
+### 梳理依赖
+
+接口很少是孤立的。常见的依赖有五类：
+
+- **鉴权**：需要先登录换取凭证
+- **数据接力**：需要上游接口返回的标识才能调用
+- **强顺序业务**：必须按业务顺序执行
+- **开关与租户**：不同配置下行为不同
+- **延迟可见**：写入之后要等一段时间才能查到，验证要轮询到目标状态出现或超时
+
+前四类决定调用先后与数据传递方式；开关与租户不影响顺序，它影响的是同一接口在不同配置下的期望值。
+
+探索阶段把这些整理成一份接口依赖关系清单，记录每对接口之间的关系与传递的字段，作为计划阶段排顺序的候选输入。
+
+**产出**：结构化接口清单、接口依赖关系清单、待确认问题清单。
+
+---
+
+## 二、设计：决定验证什么、到什么程度
+
+探索回答了"有哪些接口"，设计要回答"这一轮做到什么程度"。答案定下来就是测试策略；至于这些验证怎么安排，留到计划阶段。
+
+设计阶段先做一件事：把探索阶段留下来的待确认清单核实掉。核实不了的，写明处置口径——是阻塞相关用例，还是带标记执行。
+
+### 范围与优先级
+
+设计阶段先定两件事：这次测哪些接口，以及先测哪些。
+
+排优先级看三件事：会不会挡住发布，要不要每次回归，断了之后损失最大的是哪一环。
+
+AI 负责把模块、接口、场景的清单列成候选，人负责决定先测哪些。
+
+### 覆盖层次
+
+范围定下来之后，按几个层次各过一遍，检查有没有整类场景被漏掉：
+
+- **主路径**：正常流程能不能走通
+- **边界值**：参数取到契约允许的上下边界时，接口如何回应；越界一档的期望是拒绝，归入下一类
+- **拒绝场景**：协议不合法、业务规则不允许的请求，有没有被正确拒绝
+- **基础观测**：响应时间在什么量级
+- **低成本安全项**：未授权、越权这类基础检查，成本低，顺手补上
+
+这几层是一张查漏用的清单，各层比例由业务风险决定。并发扣库存、重复提交这类场景不在这几层之内，需要另外补上。
+
+### 期望值
+
+期望值要回答的是：请求发出去之后，什么样的返回才算对。它是一条用例里最难定的一半——发什么请求照着接口清单抄一遍就有，期望什么样的返回没有现成的地方可抄。
+
+定期望值时按顺序找依据：契约文件写明的以契约为准，说明文档写明的以文档为准，业务规则明确的以规则为准。同一接口在不同配置下期望不同，差异按配置分别记录。三者都没有的，记入待确认清单并挂起。
+
+### 断言粒度
+
+断言分层写：
+
+- **协议层**：状态码与响应格式
+- **结构层**：关键字段是否存在且类型正确
+- **业务层**：结果是否符合业务规则
+- **链路层**：上游接口返回的数据能否被下游接口正常使用。这一层只在跨接口的场景用例里出现；上游失败时，下游用例应当跳过
+
+断言只写到依据链上明确承诺的那一层：只断言其中声明为必填的字段，以及业务规则约定的值。可选字段、扩展字段、字段顺序，以及时间戳的具体取值，都不作断言对象。
+
+**产出**：测试策略（范围与优先级、覆盖层次、期望值、断言粒度）。
+
+---
+
+## 三、计划：把策略展开成用例
+
+探索产出的接口清单和依赖关系，加上设计定下的测试策略，到这一步要变成可以逐条执行的用例。
+
+### 结构化用例
+
+把策略展开成一条条用例，每条说明调用哪个接口、传什么数据、期望什么结果、这个期望的依据，需要哪些前置条件，并带上自己的编号。
+
+这个形态是可评审的结构化数据，下游代码环节直接消费，返工量小得多。
+
+### 测试数据
+
+数据按用途分两类：正常数据用于验证主路径，边界数据用于验证契约允许范围的临界值。
+
+计划阶段定下的是**数据规格**：字段约束、唯一性、清理方式、来源。具体取值在执行时生成。
+
+数据管理有三条通用原则：
+
+- 写入型测试使用唯一数据，避免重复运行与并行运行相互干扰
+- 每条写入的数据配一个清理动作，另有一套按前缀批量回收的兜底清理，不依赖用例正常退出
+- 账号、凭证和环境地址通过环境变量提供，不写进用例
+
+### 执行顺序
+
+顺序主要从探索阶段的依赖结构推导：
+
+- 图上没有相连的接口归入同一批。图上无连接只是必要条件——能不能真的并行，还要看它们是否共用同一份可变数据，比如库存、余额、账号、全局开关
+- 有依赖的优先用前置数据构造消除；确实打断不了的，显式标记为顺序执行，并在失败时跳过后续
+- 写入后延迟可见的接口，额外带上轮询与超时条件
+
+**产出**：结构化用例——每条用例连同它的数据规格与顺序约束一并确定，进入执行阶段后可以直接照着写代码。
+
+---
+
+## 四、执行：生成脚本并取得证据
+
+计划产出的用例还不能跑。执行阶段把它变成脚本，跑出结果。
+
+### 从用例到脚本
+
+转换的主体可以机械化，真正需要安排的是公共部分：环境地址、超时这类配置从环境变量读取，认证、数据生成这类每条用例都要用的逻辑集中管理。断言按设计阶段定下的层级写。
+
+此外，每条用例保留自己的编号，报告里的结果才能回溯到计划阶段的用例。
+
+### 运行前的准入检查
+
+跑之前先做准入检查：服务可达、账号有效、接口已部署、当前环境允许写数据。这四件事只能在真实运行中确认。任何一项不通过，整批终止，标记为环境阻塞，不生成用例级报告，不进入自愈。
+
+准入通过之后，按计划阶段确定的顺序执行。
+
+### 报告解读
+
+运行留下的证据汇总成报告。报告要能回答两个问题：这条结果对应哪一条用例，失败时的现场是什么样。因此每条记录包含：
+
+- 用例编号与名称
+- 调用的接口，以及该用例的期望值及其依据
+- 通过/失败状态
+- 失败时的请求、响应、状态码与运行环境
+
+请求与响应里的凭据和令牌，在落盘之前先脱敏。自愈从这份报告取用证据，不再另建留存路径。
+
+**产出**：测试脚本、执行报告。
+
+---
+
+## 五、自愈：从失败归因到自动修复
+
+报告里的失败，一部分是被测系统真的变了，一部分是测试自己写错了。自愈的做法是先归因，再决定改什么。
+
+### 失败分类
+
+常见的失败现象有几类，每类的原因和修复方向都不同：
+
+| 现象                   | 常见原因                           | 修复方向             |
+| ---------------------- | ---------------------------------- | -------------------- |
+| 响应结构和预期对不上   | 字段改名、嵌套层级变了             | 改断言或解析方式     |
+| 认证类拒绝             | 凭证过期、请求头名称不对、权限不足 | 刷新凭证、改正请求头 |
+| 路径类失败             | 路径变了、版本前缀变了、卡在网关   | 改地址或路径拼接     |
+| 状态码正常但业务码不对 | 产品改了规则                       | 更新期望值           |
+| 请求体校验不通过       | 数据不符合契约                     | 改测试数据或边界值   |
+
+现象与原因是一对多：业务码不对，可能是产品改了规则，也可能是上一轮遗留数据、期望值本身写错、环境开关没开。期望值的改动以已确认的变更为前提；证据不足以区分时，标记为待人工判断。
+
+### 自动修复流程
+
+分类定下来，修复方向也就定了。自动修复分三步：
+
+1. **捕获失败信息**：把失败时的请求、响应、状态码和运行环境一起留存下来。证据在执行阶段已经脱敏落盘，这里直接引用。
+2. **生成修复补丁**：按失败类别给出对应的改动方案，连同判断依据一起记下来——判定为路径类失败，补丁就是调整地址或路径拼接。改动涉及期望值或核心断言的，补丁以待确认形式提交，不直接应用。
+3. **应用并复跑**：可直接应用的补丁应用后，把这条用例重新跑一遍，跑通了才算修复完成。复跑走执行阶段的同一套流程与报告。
+
+### 修复纪律
+
+- **改动从局部开始**：配置、路径拼接、数据唯一性、认证获取、等待逻辑。这几处覆盖了大部分失败；框架和核心断言不在这批改动范围内。
+- **关键期望值的更新以已确认的变更为前提**：响应少了一个字段，先确认是契约变了，还是产品缺陷。
+- **该转人工的时候转人工**：同一用例连续失败达到预设次数，或者补丁会改变核心业务断言。当现有证据分不清"产品有缺陷"和"测试写错了"的时候，人工判断是最快的路径。
+
+**产出**：修复后的测试——补丁回写到设计、计划、执行三处的产物上，每次回写留记录。
+
+---
+
+## 小结
+
+从探索到自愈，五个阶段环环相扣，每一段的产出交给下一段当输入。这条链路上，AI 与人的分工是这样的：
+
+| AI 承担                      | 人承担                     |
+| ---------------------------- | -------------------------- |
+| 检索与整理材料               | 确认每个用例的期望值       |
+| 解析接口描述、梳理依赖关系   | 决定风险优先级             |
+| 批量展开候选场景             | 判断规则是否真的发生了变化 |
+| 翻译代码、汇总证据、提出补丁 | 对最终结论负责             |
+
+这张表划出的是 AI 目前的位置：**别指望 AI 端到端兜底，它担得起过程成本，担不起最终结论**** 单条用例从零到能跑，二十分钟的活它做掉十五分钟，人只留最后五分钟做必须由人做的判断。
+
+它的产出因此止于一份待确认的初稿：标出的异常、展开的场景、提出的补丁，触及期望值和核心断言的部分要经过人的判断才能成立。
+
+落到具体场景：主干链路先跑一遍，明显异常和与需求的偏差标出来，人只看这份异常清单；用例按需求生成覆盖主干的初稿，人做的是取舍与优先级确认。
+
+人剩下的时间，都花在表格右列的那几件事上，其中最要紧的一件是确认期望值合不合理。确认期望值这件事贯穿了从设计到自愈的每一个阶段——**一套测试可不可信，最终取决于每个期望值能不能追回到它的来源。**