接口改动后测试用例总漏场景？我把 AI 放在了评审前一站

最近做一个订单接口改造，改动不算大：新增一个优惠抵扣字段，调整了状态流转，还补了两个异常分支。代码写完以后，我照例让测试同学看用例，结果评审时还是被问住了几个边界问题。

这类事情在后端项目里挺常见。需求文档不长，接口变更也不复杂，但真正落到测试用例时，总会漏掉一些"不常走但会出事"的场景。比如字段为空、状态重复提交、老版本客户端兼容、金额精度、异步回调顺序等。

后来我尝试把 AI 放在测试评审前面，不是让它直接替代测试同学，而是让它先帮我做一轮"场景补漏"。用了一段时间后，我觉得这个场景比较适合开发者低风险使用 AI：输入可控，输出可验证，不容易变成纯聊天。

为什么不是直接让 AI 写完整测试方案

一开始我也试过把需求文档贴进去，然后问：

请根据下面需求生成完整测试用例。

结果看起来很完整，实际问题不少。

有些用例只是把需求句子换了个说法；有些边界条件写得很泛，比如"验证异常情况是否正确"；还有些用例没法直接落到接口参数和断言上。更麻烦的是，如果需求里某个地方写得模糊，模型会自己补一个"合理设定"，但这个设定未必符合真实业务。

所以我后来改了思路：不让 AI 直接输出最终用例，而是让它参与中间环节。

它主要做三件事：

1. 把需求拆成可验证点；
2. 帮我补充遗漏分支；
3. 对已有测试用例做反向挑错。

最终用例仍然由人确认，必要时再补接口自动化或手工验证步骤。

我现在的处理流程

以一个订单优惠抵扣接口为例，假设接口变更大致如下：

• 新增字段：discountAmount
• 支持用户使用优惠余额抵扣订单金额
• 抵扣金额不能大于订单应付金额
• 订单取消后需要退回未使用的优惠余额
• 已支付订单不能再次修改抵扣金额
• 老版本客户端不传该字段时，按原逻辑处理

如果直接写测试用例，开发很容易只覆盖"正常抵扣成功"和"抵扣金额过大失败"。但真实风险往往在状态、并发、兼容和金额边界上。

我会先把信息整理成这种结构：

业务背景：订单创建时允许使用优惠余额抵扣部分金额。
接口变化：1. 新增 discountAmount 字段，单位为分，整数。2. discountAmount 不能大于 payableAmount。3. 老版本客户端不传 discountAmount 时，按 0 处理。4. 订单取消后，需要返还已使用优惠余额。5. 已支付订单不能修改 discountAmount。
已知约束：- 金额字段均为整数，单位分。- 用户优惠余额可能不足。- 订单存在 CREATED、PAID、CANCELLED 三种状态。
请不要直接生成最终测试用例。请先输出：1. 可验证规则列表；2. 可能遗漏的边界场景；3. 需要向产品或后端确认的问题。

这个 Prompt 的重点是"不直接生成最终测试用例"。先让模型拆规则，比一上来生成表格更稳。

第一轮：让 AI 拆出可验证规则

模型一般会给出类似这样的结果：

规则	可验证点
新字段默认值	不传 discountAmount 时是否按 0 处理
抵扣上限	discountAmount <= payableAmount
余额约束	抵扣金额不能超过用户可用优惠余额
状态约束	已支付订单不能修改抵扣金额
取消返还	订单取消后优惠余额是否返还
金额精度	金额是否统一按分处理
兼容性	老版本客户端请求是否不受影响

这个输出不一定完美，但它能帮开发者从"我知道需求"切换到"我能验证哪些规则"。

我会重点看两类内容：

• 需求里明确写了，但自己容易漏的；
• 需求没写清楚，但上线后可能出问题的。

比如"用户优惠余额不足"这件事，需求原文可能只写了"支持优惠余额抵扣"，但没有说余额不足时返回什么错误码。这时候 AI 提醒出来，就可以提前问产品或补接口约定。

第二轮：让 AI 反查已有用例

很多时候，我们不是没有测试用例，而是用例覆盖不均衡。正常流程写了一堆，异常流程只有两三条。

我会把自己初版用例贴进去，让模型做反向检查：

下面是我已经写好的测试用例。请你只做检查，不要重写。
检查维度：1. 是否覆盖字段边界；2. 是否覆盖订单状态变化；3. 是否覆盖老版本兼容；4. 是否覆盖金额和余额异常；5. 是否存在断言不明确的问题。
输出格式：- 已覆盖：- 明显缺失：- 建议补充：- 需要人工确认：

这个用法比"帮我优化测试用例"更好。因为它把任务限制在检查范围内，模型不会随意扩写太多看似专业但不可执行的内容。

比如它可能会指出：

• 缺少 discountAmount = payableAmount 的边界用例；
• 缺少用户余额小于抵扣金额的场景；
• 缺少订单已支付后重复提交修改抵扣金额的场景；
• 缺少取消订单后余额返还失败时的补偿验证；
• 老版本客户端未传字段时，只验证了成功，没有验证金额计算结果。

这些提醒对开发者很有用，尤其是在接口改动看似很小的时候。

第三轮：把场景落成可执行用例

AI 给出的场景不能直接算完成，还要转成团队能执行的格式。比如在 CSDN 读者常见的后端项目里，最终可能落到接口测试、单元测试或集成测试。

我通常会让模型帮我整理成这种表格：

用例编号	前置条件	请求参数	预期结果	断言重点
TC01	用户余额充足，订单未支付	discountAmount=100	创建订单成功	应付金额减少 100
TC02	用户余额充足，订单未支付	discountAmount=payableAmount	创建订单成功	实付金额为 0
TC03	用户余额不足	discountAmount 大于余额	创建失败	错误码、余额不扣减
TC04	订单已支付	修改 discountAmount	修改失败	状态不变、金额不变
TC05	老版本客户端	不传 discountAmount	创建成功	按 0 抵扣处理
TC06	订单取消	已使用优惠抵扣	取消成功	优惠余额返还

如果要写接口自动化，可以再继续拆成伪代码：

java

@Testvoid shouldCreateOrderWithDiscountWhenBalanceEnough() {    // given    User user = createUserWithDiscountBalance(1000);    Product product = createProductWithPrice(5000);
    // when    OrderResponse response = orderClient.createOrder(user.getId(), product.getId(), 800);
    // then    assertEquals(4200, response.getPayAmount());    assertEquals(800, response.getDiscountAmount());    assertEquals("CREATED", response.getStatus());}

这里要注意，AI 生成的代码只能当草稿。字段名、测试框架、Mock 方式、数据准备方式，都要按自己项目调整。尤其是涉及金额、库存、支付、权限这类逻辑，不能只看测试跑通，还要检查断言是否真的覆盖了风险点。

不同模型在这个场景里的差异

如果只从"测试用例补漏"这个任务看，几个常见模型的表现不太一样。

ChatGPT 更适合把杂乱需求整理成结构化清单，输出比较均衡。Claude 对长需求文档的理解更细，适合处理 PRD、接口说明、会议纪要混在一起的情况。Gemini 适合快速扫一遍材料，先给出初步分支。DeepSeek 在中文技术表达、表格化用例、异常场景补充上比较顺手。Grok 有时会提出比较尖锐的问题，适合做评审前的"挑刺"。

我的做法不是固定用某一个模型，而是按阶段分工：

• 第一轮：快速拆规则；
• 第二轮：检查遗漏；
• 第三轮：整理成用例表；
• 第四轮：人工确认并补测试代码。

如果是影响面较大的接口，比如支付、结算、权限、风控，我会用两个模型交叉看一遍。不是为了找一个"标准答案"，而是看它们是否都指出了同一类风险。

输入材料要先做脱敏

技术社区里经常有人直接把日志、接口文档、数据库字段贴给 AI，这个习惯不太好。

至少要处理这些内容：

• 用户手机号、邮箱、身份证、地址；
• 订单号、支付流水号、合同编号；
• 内部接口域名、Token、密钥；
• 数据库真实表名和敏感字段；
• 公司内部业务规则和未公开信息。

脱敏后不影响模型理解结构。比如把真实用户 ID 改成 userId_A，把接口域名改成 /api/order/create，把金额改成测试样例值。模型需要的是逻辑关系，不是生产数据原文。

我保留下来的几个 Prompt 写法

1. 拆需求

请把下面需求拆成可验证规则。要求：- 不生成完整测试用例；- 每条规则都说明对应的输入、状态或断言；- 标出不明确、需要产品确认的地方。

2. 补遗漏

请从边界值、状态流转、兼容性、并发、异常返回五个角度，检查下面接口测试用例是否有遗漏。只指出问题，不要重写全部内容。

3. 转用例表

请将已确认的测试点整理成接口测试用例表。字段包括：用例编号、前置条件、请求参数、预期结果、断言重点、优先级。不要添加未经确认的新规则。

这几段 Prompt 看起来普通，但关键在于限制模型的职责。每次只让它做一个环节，输出会稳定很多。

常见误区

1. AI 生成的测试用例能直接交付吗？

不建议。它适合做补漏和整理，最终仍然要由开发、测试或产品确认。尤其是业务规则、错误码、状态机变化，必须回到真实系统验证。

2. 需求文档越长，效果越好吗？

不一定。文档长但结构乱，模型也会抓不住重点。最好先按"背景、接口变化、字段说明、状态约束、异常规则"整理后再输入。

3. 多模型对比是不是浪费时间？

普通小需求没必要。高风险接口、多人协作模块、历史 Bug 较多的功能，才值得多模型交叉检查。重点不是谁回答更长，而是谁指出了可验证的风险。

4. AI 能不能替代测试同学做用例设计？

不能。它能提高初稿质量，减少低级遗漏，但无法替代测试经验、业务判断和真实环境验证。复杂链路仍然需要人工设计策略。

结尾：先从低风险场景开始

如果你是后端开发，想把 AI 用进日常研发流程，我建议先从"接口变更后的测试用例补漏"开始。这个场景足够具体，结果也容易验证。

不要一开始就让 AI 给最终答案。先让它拆规则、找遗漏、提问题，再由人把内容落到测试用例和自动化代码里。重要接口可以多模型交叉看一遍，但最终判断仍然要回到需求、代码、测试环境和人工 Review。这样用下来，AI 更像一个评审前的助手，而不是替你负责的外包。