做接口改动久了我越来越不想让 AI 直接“生成一整套测试用例”。它很容易写得像那么回事但真正上线时最容易漏的还是那些边界、状态流转和兼容性问题。后来我换了个用法先让 AI 帮我补场景再由我把场景落成可执行用例。这个顺序一改输出稳定了很多。为什么先补场景不先写用例前两周我在做一个订单接口调整新增抵扣字段、改金额计算、补取消回滚还要兼容老版本客户端。需求看起来不长但一到测试评审问题就冒出来了。抵扣金额等于应付金额时怎么算用户余额不足时返回什么订单已支付后能不能改取消订单时优惠余额怎么返老客户端不传新字段时会不会影响原逻辑。这些问题不是测试同学不专业而是需求本身往往只写“支持”“新增”“优化”没把所有分支展开。AI 在这个阶段更适合做“补漏提示”而不是直接当最终答案。我现在的习惯是先把需求、接口字段、状态机、错误码、已有约束整理清楚再让模型帮我拆规则。我会先让模型做三件事第一步我不会问“请生成测试用例”而是这样写text下面是接口变更说明和已有约束。请先不要生成最终测试用例只做三件事1. 拆出可验证规则2. 标出可能遗漏的边界场景3. 提出需要人工确认的问题。这个 Prompt 的好处是它会逼模型先做结构化分析。比起直接吐一大张表这种方式更像真正的测试评审。第二步我会看它有没有把关键风险说出来。比如金额字段是否统一按分处理discountAmount是否允许为 0抵扣金额大于应付金额时的错误处理订单状态从CREATED到PAID后修改请求怎么处理取消订单后已使用额度是否回退老版本客户端不传字段时默认值是否正确。第三步才是把这些点变成测试用例。场景补漏比直接写用例更有价值很多人会觉得既然最终还是要写用例那为什么不让 AI 一步到位我试下来问题在于“一步到位”反而会掩盖缺口。模型很容易根据常见模式补齐一个看上去完整的测试表但它补的是通用模板不一定是你这个接口真正的风险点。比如一个订单接口AI 往往会主动写正常创建成功参数缺失失败金额非法失败状态不对失败。这些当然对但太泛了。真正要命的通常是金额边界值并发提交重复请求状态回写失败部分字段兼容取消和支付的竞态。这些场景如果没有明确提醒模型不一定会主动往深处挖。所以我现在更像是在用 AI 做“评审助手”先问它哪里可能漏再让它帮我确认哪些地方最该测。一个比较实用的用例整理方式我通常会把输出整理成这种表用例编号前置条件请求参数预期结果重点断言TC01用户余额充足订单未支付discountAmount100创建成功实付金额减少 100TC02抵扣金额等于应付金额discountAmountpayableAmount创建成功实付金额为 0TC03用户余额不足discountAmount大于余额创建失败错误码正确余额不变TC04订单已支付修改discountAmount修改失败状态不变金额不变TC05老版本客户端不传discountAmount创建成功默认按 0 处理TC06订单取消已使用抵扣额度取消成功优惠余额回退这种表看上去朴素但对开发和测试沟通很好用。你一眼就能看出它是不是只覆盖了“正常流程”或者有没有把状态、金额、兼容性都兜住。如果要进一步做自动化我会再把这些点转成接口测试或者单元测试骨架但不会直接照搬模型生成的代码。字段名、错误码、初始化数据、Mock 方式最后都得按项目实际来。不同模型在这个任务上的差异这类任务我试过几个常见模型感受还是有差别。ChatGPT 比较擅长把散乱的需求整理成结构化清单做“第一轮拆解”很顺手。Claude 在长文档里更稳适合 PRD、接口说明、会议纪要一起看的场景。Gemini 速度快适合先扫一遍材料。DeepSeek 对中文测试用例、表格化表达比较自然。Grok 有时会更爱追问适合拿来做评审前的挑刺。但我现在不会纠结“哪个最强”而是看谁更适合当前阶段第一轮看谁能把规则拆清楚第二轮看谁能挑出遗漏第三轮看谁能整理成可执行用例第四轮看谁能帮我复核断言是否完整。重要接口我会让两个模型交叉看一遍。不是为了比输赢而是看它们是否都指出了同一类风险。输入材料一定要先脱敏这个点很容易被忽略。接口文档、日志、请求样例、数据库字段、业务规则很多都不该原样贴进去。至少要处理这些内容用户手机号、邮箱、地址订单号、流水号、合同号Token、密钥、内部域名真实业务编号未公开的公司规则。脱敏后不会影响模型理解。比如把订单号改成order_001把接口路径改成/api/order/update把金额改成测试样例值。模型看的是逻辑不是生产原文。我常用的几个 Prompt1. 拆规则text请把下面需求拆成可验证规则。要求- 不要直接生成完整测试用例- 每条规则都要说明输入、状态或断言- 标出需要人工确认的地方。2. 查遗漏text请从边界值、状态流转、兼容性、异常返回四个角度检查我已有的测试点是否有遗漏。只指出缺口不要重写全部内容。3. 转用例表text请将已确认的测试点整理成接口测试用例表。字段包括用例编号、前置条件、请求参数、预期结果、断言重点。不要添加未经确认的新规则。4. 复核断言text请检查这些测试用例的断言是否足够明确。如果断言过于笼统请改成可以直接验证的描述。这几段 Prompt 的共同点是尽量只让模型做一件事。任务越单一结果越稳。常见误区1. AI 写出来的测试用例能直接交付吗不能。它适合做初稿和补漏最终还是要由人确认。尤其是金额、状态、支付、权限这类逻辑必须结合真实系统验证。2. 需求写得越长模型越准吗不一定。长文档如果结构乱模型也容易抓偏。最好先按“背景、变更点、字段、状态、异常、兼容性”整理后再输入。3. 多模型对比是不是太费时间普通小需求不必。高风险接口、历史 Bug 多的模块、跨团队协作场景才值得多看一轮。重点不是答案多漂亮而是有没有把风险点指出来。4. AI 能替代测试同学做设计吗不能。它能减少低级遗漏但不能替代业务理解、测试策略和真实环境验证。尤其是回归、联调、灰度这些环节还是要人来把关。结尾如果你也想把 AI 用进测试流程我建议先从高频、低风险、可验证的接口开始。先让它拆规则、补场景、挑遗漏再由人把内容落成测试用例和自动化代码。重要任务别只看一个模型的结论多模型交叉看一遍会更稳涉及代码、日志和业务资料时先脱敏再输入最后的判断还是要回到需求、系统行为和人工 Review。这样用AI 才是助手不是替你拍板的人。