AI 测试工作流：从接口资料到用例验收
结合实际测试交付，说明需求、领域规则、测试剧本和既有 SDK 如何衔接，以及生成失败应回到哪一阶段修正。
我在支付测试工作中搭建了分阶段 LLM 用例生成流程：识别需求和业务接口文档，学习存量脚本的结构、领域模型与业务规则，生成测试剧本，再在契约测试框架的骨架中填充前置构造、业务调用和结果断言。人工审核与执行验证贯穿交付过程。
这项实践已有约 4 周交付 200 多个测试文件、约 7 倍提效的记录。它依赖当时已有的业务 API、测试框架和审核流程。这里解释其中可迁移的组织方法；独立编写的库存示例、完整 Prompt、Skill 和运行命令见从零到一搭建 AI 测试工作流。
先解决生成代码之前的问题
假设要生成一条余额不足的测试。接口参数表告诉模型金额是整数，却未必说明失败时是否允许部分执行、重复请求是否复用原结果，或者拒绝后哪些资源必须不变。缺少这些规则，模型即使写出可运行代码，也不知道应该准备什么前置、断言哪些状态。
我整理的 use-case 工作流把交互步骤、字段列表和业务规则分别组织，再用步骤编号关联。其作用是让“在哪一步检查哪个条件，失败后如何处理”有明确位置。对资金类业务，还要区分同步完成、先受理后处理和仅受理等过程；受理成功不能直接作为最终资金状态正确的证据。
迁移到另一个团队，可以先准备下面五类资料。无需先统一所有业务的文档格式，但每份资料需要能定位到版本和具体条目。
| 输入 | 需要回答的问题 | 缺失时的影响 |
|---|---|---|
| 需求和交互流程 | 系统承诺完成什么，哪些分支会终止 | 无法判断场景是否覆盖需求 |
| 接口契约 | 哪些请求能发送，返回字段表达什么 | 可能绑定错误参数或错误码 |
| 领域规则 | 对象如何关联，操作前后哪些状态改变 | 只检查响应，漏掉副作用 |
| 存量脚本 | 基类、fixture、断言、清理怎样组织 | 代码存在但无法被框架执行 |
| 可测试性 API | 怎样造数、查询和清理 | 剧本在当前环境无法落地 |
存量脚本也需要选择。成功用例说明正常调用，负向用例说明怎样保留非法输入，资源清理用例说明生命周期。把一份脚本当作唯一模板，容易把它的业务特例扩散到所有新用例。
用剧本保留业务判断，再生成代码
下面用教学工程中的库存预占说明这一点。需求要求库存不足时拒绝预占，并且不改变库存、不创建预占记录。剧本应先写出这三个预期，再决定用哪些 API 观察它们。
| 部分 | 库存不足场景的内容 |
|---|---|
| 规则依据 | 库存不足时拒绝，两个资源均不改变 |
| 前置 | 商品存在，可用库存为 1，其他参数合法 |
| 动作 | 以新的请求编号申请 2 件 |
| 响应断言 | 返回库存不足错误码 |
| 状态断言 | 库存仍为 1；该请求编号下没有预占记录 |
如果商品根本不存在，请求可能先在商品检查处结束。此时“接口拒绝了请求”不能证明库存不足规则正确。审核剧本时，需要确认目标条件被违反，而到达该分支所需的其他条件成立。
剧本确定后，再把构造、调用、观察、清理绑定到已有能力。缺少“按请求编号查询预占记录”的能力，就保留这项缺口；不能把实际未检查的条件写成已覆盖。SDK 如果会把非法数量改成默认值，也不适合作为服务端参数拒绝测试的入口。
模型填业务逻辑，框架提供执行约定
已有支付 API 与 SDK提供可复用的业务操作。框架提供测试发现、资源生命周期和报告约定。模型负责将审核过的剧本映射到这些能力，生成前置构造、业务调用和结果校验。
沿着库存例子审阅时，可以先看剧本有没有检查“没有预占记录”，再看代码是否真的调用查询 API 检查了这一项。这样能把测试意图与代码实现分开核对。遇到断言失败，先保存请求、响应和状态快照，确认原因后再修改；让模型直接把预期改成实际值，会丢掉这次失败提供的线索。
| 发现的问题 | 应返回的阶段 | 修正后的检查 |
|---|---|---|
| 将“受理”理解成“处理完成” | 需求与规则 | 补足最终状态和观察方式，重审受影响剧本 |
| SDK 改写了本来要发送的非法参数 | 能力绑定 | 检查实际发出的请求，确认命中被测边界 |
| 前置构造未生效 | 准备与环境 | 回读前置状态，再执行业务动作 |
| 返回拒绝但留下业务记录 | 业务实现或规则冲突排查 | 保留失败，按已确认规则判断是否修复产品 |
| worker 退出，报告少了一条 | 执行器 | 检查结果完整性，不将缺失项算作通过 |
最后一类由执行框架处理。XAT 的结果完整性区分方法结果与整批报告是否齐全；工作流在其上判断交付是否可验收。
迁移时保留流程，替换业务适配
XAT来自内部契约测试框架的提炼：移除公司特定请求协议、数据形式、鉴权和票据等依赖，保留可迁移的执行能力。AI 工作流也需要做相同拆分。
可保留的部分是资料整理、规约与剧本审核、能力绑定、骨架生成、结果验收。需要替换的是业务词汇、规则来源、API 适配器、测试环境和组织内的审批方式。公共教学工程中的单商品库存格式，也需要随目标领域改变，不能只替换服务地址。
第一次试点选择一个成功场景和一个业务拒绝场景，逐项确认前置可构造、请求能到达、结果可观察、数据可清理，再扩展重复请求和异步终态。业务人员审核规则与预期，测试人员审核剧本，测试开发人员维护适配和执行边界。这些职责应在扩大生成量之前落实。
公开工程 ai-test-workflow是上述方法的教学实现，已包含可执行参考场景和缺陷注入。它与工作中的交付数据分别记录。Usecase Factory继续讨论通用化设计中的局部阻塞和恢复；训练计划则说明何时有必要进一步改变模型本身。