用 AI 把接口文档整理成业务链路测试,哪里最容易翻车

我现在会让 AI 帮我整理接口文档。

尤其是一个需求下面有十几个接口时，让它先把接口列表、字段、依赖关系摊开，确实比自己从头翻文档快很多。

但我也越来越谨慎。

因为 AI 很容易把“接口文档整理”做得很漂亮，却没有真正整理成“业务链路测试”。

表格有了，字段有了，请求参数和返回参数也列出来了。

但测试跑起来才发现：前置数据没准备，接口顺序不对，状态没有闭环，异常链路没覆盖，断言只停在返回成功。

我觉得这就是最容易翻车的地方：AI 读懂了接口，没有读懂业务链路。

接口文档通常是按模块或接口名称排的。

AI 很自然会跟着文档结构走：登录接口、查询商品接口、创建订单接口、支付接口、查询订单接口。

这没有错，但还不是业务链路。

业务链路要回答的是：用户从哪里开始，先做什么，后做什么，哪些接口只是辅助查询，哪些接口真正改变状态。

比如下单链路，不是把“创建订单接口”和“支付接口”列出来就够了。

还要看商品是否可售、价格是否试算、优惠是否锁定、库存是否占用、订单是否能查询、支付后状态是否更新。

所以我会让 AI 重新按用户路径整理：

请不要按接口文档顺序整理。请按真实用户路径，把接口串成业务链路，并标出每个接口在链路里的作用：查询、校验、创建、变更状态、回查。

接口链路最容易卡在字段上。

AI 会列出 orderId、skuId、couponId、payNo、token，但不一定会说明这些字段从哪里来。

如果字段来源没写清楚，后面的自动化脚本就很难稳定。

哪些字段来自前置接口？哪些字段需要预置测试数据？哪些字段可以固定？哪些字段必须动态提取？哪些字段来自后台配置或第三方系统？

这些不清楚，测试场景就只是纸面链路。

我会要求 AI 在链路表里多加两列：字段来源、字段去向。

这样才能看出数据是不是接上了。

很多接口测试用例会写：“调用成功，返回 success。”

但业务链路测试不能停在这里。

创建订单成功后，要看订单是否真的生成，状态是不是待支付，金额是否正确，库存有没有锁定。

支付成功后，要看订单状态、支付流水、优惠券核销、库存扣减、权益发放。

AI 很容易把断言写成响应断言，而不是业务结果断言。

我会让它补“后续校验接口”。

比如创建订单后必须查询订单详情，支付后必须查询支付流水和订单状态。链路中每一次状态变化，都应该有一个能观察到结果的地方。

AI 写异常场景时，常常会按单接口写：参数为空、参数错误、权限不足、接口失败。

但业务链路里的异常更复杂。

比如创建订单成功了，支付失败了，库存要不要释放？优惠券要不要退回？订单状态停在哪里？用户能不能重新支付？

再比如支付回调重复推送，订单会不会重复变更？权益会不会重复发放？

这些不是单个接口参数校验能覆盖的。

所以我会让 AI 按链路阶段补异常：前置查询失败、创建失败、状态变更失败、回调失败、重复请求、超时重试、补偿任务失败。

链路测试里的异常，重点不是“失败提示”，而是失败后系统是否保持一致。

AI 很容易把所有接口平均展开。

结果就是用例很多，但重点不清楚。

业务链路测试一定要分层：主链路是什么，关键分支是什么，低频补充场景是什么。

比如下单支付，主链路是正常下单并支付成功；关键分支可能是优惠券、库存不足、支付失败、重复支付、订单取消；低频分支可能是特殊商品、后台改价、跨端同步。

如果 AI 没有做分层，测试人就会被一堆“看起来都有用”的场景淹没。

我会要求它标注 P0/P1/P2，并说明为什么。

优先级不是装饰，它决定时间不够时先测什么。

如果 AI 第一版只是把接口文档整理成表格，我会继续追一轮：

请不要只整理接口列表。请基于接口文档生成业务链路测试设计，按真实用户路径组织。每条链路包含：业务目标、接口调用顺序、字段来源和去向、前置数据、关键断言、后续校验接口、状态流转、异常分支、P0/P1/P2 优先级。请区分主链路、关键分支和低频补充场景。

这个提示词的重点，是把 AI 从“接口文档整理员”拉回到“测试场景设计助手”。

接口文档只是材料，业务链路才是测试对象。

如果你也在用 AI 整理接口文档，可以看一眼它有没有回答这几个问题：

谁触发这条链路？数据从哪里来？哪个接口改变状态？失败后系统保持什么？最后用什么证明业务结果是对的？

这些问题答清楚，接口测试才不只是“每个接口都调通了”。