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

最近做一个订单接口改造改动不算大新增一个优惠抵扣字段调整了状态流转还补了两个异常分支。代码写完以后我照例让测试同学看用例结果评审时还是被问住了几个边界问题。这类事情在后端项目里挺常见。需求文档不长接口变更也不复杂但真正落到测试用例时总会漏掉一些“不常走但会出事”的场景。比如字段为空、状态重复提交、老版本客户端兼容、金额精度、异步回调顺序等。后来我尝试把 AI 放在测试评审前面不是让它直接替代测试同学而是让它先帮我做一轮“场景补漏”。用了一段时间后我觉得这个场景比较适合开发者低风险使用 AI输入可控输出可验证不容易变成纯聊天。为什么不是直接让 AI 写完整测试方案一开始我也试过把需求文档贴进去然后问请根据下面需求生成完整测试用例。结果看起来很完整实际问题不少。有些用例只是把需求句子换了个说法有些边界条件写得很泛比如“验证异常情况是否正确”还有些用例没法直接落到接口参数和断言上。更麻烦的是如果需求里某个地方写得模糊模型会自己补一个“合理设定”但这个设定未必符合真实业务。所以我后来改了思路不让 AI 直接输出最终用例而是让它参与中间环节。它主要做三件事把需求拆成可验证点帮我补充遗漏分支对已有测试用例做反向挑错。最终用例仍然由人确认必要时再补接口自动化或手工验证步骤。我现在的处理流程以一个订单优惠抵扣接口为例假设接口变更大致如下新增字段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用户余额充足订单未支付discountAmount100创建订单成功应付金额减少 100TC02用户余额充足订单未支付discountAmountpayableAmount创建订单成功实付金额为 0TC03用户余额不足discountAmount 大于余额创建失败错误码、余额不扣减TC04订单已支付修改 discountAmount修改失败状态不变、金额不变TC05老版本客户端不传 discountAmount创建成功按 0 抵扣处理TC06订单取消已使用优惠抵扣取消成功优惠余额返还如果要写接口自动化可以再继续拆成伪代码javaTestvoid 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 更像一个评审前的助手而不是替你负责的外包。