企业官网建设流程全解析

做接口改动久了，我越来越不想让 AI 直接“生成一整套测试用例”。它很容易写得像那么回事，但真正上线时，最容易漏的还是那些边界、状态流转和兼容性问题。

后来我换了个用法：先让 AI 帮我补场景，再由我把场景落成可执行用例。这个顺序一改，输出稳定了很多。

为什么先补场景，不先写用例

前两周我在做一个订单接口调整：新增抵扣字段、改金额计算、补取消回滚，还要兼容老版本客户端。需求看起来不长，但一到测试评审，问题就冒出来了。

• 抵扣金额等于应付金额时怎么算；
• 用户余额不足时返回什么；
• 订单已支付后能不能改；
• 取消订单时优惠余额怎么返；
• 老客户端不传新字段时，会不会影响原逻辑。

这些问题，不是测试同学不专业，而是需求本身往往只写“支持”“新增”“优化”，没把所有分支展开。AI 在这个阶段更适合做“补漏提示”，而不是直接当最终答案。

我现在的习惯是：先把需求、接口字段、状态机、错误码、已有约束整理清楚，再让模型帮我拆规则。

我会先让模型做三件事

第一步，我不会问“请生成测试用例”，而是这样写：

text

下面是接口变更说明和已有约束。请先不要生成最终测试用例，只做三件事：1. 拆出可验证规则；2. 标出可能遗漏的边界场景；3. 提出需要人工确认的问题。

这个 Prompt 的好处是，它会逼模型先做结构化分析。比起直接吐一大张表，这种方式更像真正的测试评审。

第二步，我会看它有没有把关键风险说出来。比如：

• 金额字段是否统一按分处理；
• discountAmount是否允许为 0；
• 抵扣金额大于应付金额时的错误处理；
• 订单状态从CREATED到PAID后，修改请求怎么处理；
• 取消订单后，已使用额度是否回退；
• 老版本客户端不传字段时，默认值是否正确。

第三步，才是把这些点变成测试用例。

场景补漏，比直接写用例更有价值

很多人会觉得，既然最终还是要写用例，那为什么不让 AI 一步到位？

我试下来，问题在于“一步到位”反而会掩盖缺口。模型很容易根据常见模式补齐一个看上去完整的测试表，但它补的是通用模板，不一定是你这个接口真正的风险点。

比如一个订单接口，AI 往往会主动写：

• 正常创建成功；
• 参数缺失失败；
• 金额非法失败；
• 状态不对失败。

这些当然对，但太泛了。真正要命的通常是：

• 金额边界值；
• 并发提交；
• 重复请求；
• 状态回写失败；
• 部分字段兼容；
• 取消和支付的竞态。

这些场景，如果没有明确提醒，模型不一定会主动往深处挖。

所以我现在更像是在用 AI 做“评审助手”：先问它哪里可能漏，再让它帮我确认哪些地方最该测。

一个比较实用的用例整理方式

我通常会把输出整理成这种表：

这种表看上去朴素，但对开发和测试沟通很好用。你一眼就能看出它是不是只覆盖了“正常流程”，或者有没有把状态、金额、兼容性都兜住。

如果要进一步做自动化，我会再把这些点转成接口测试或者单元测试骨架，但不会直接照搬模型生成的代码。字段名、错误码、初始化数据、Mock 方式，最后都得按项目实际来。

不同模型在这个任务上的差异

这类任务我试过几个常见模型，感受还是有差别。

ChatGPT 比较擅长把散乱的需求整理成结构化清单，做“第一轮拆解”很顺手。Claude 在长文档里更稳，适合 PRD、接口说明、会议纪要一起看的场景。Gemini 速度快，适合先扫一遍材料。DeepSeek 对中文测试用例、表格化表达比较自然。Grok 有时会更爱追问，适合拿来做评审前的挑刺。

但我现在不会纠结“哪个最强”，而是看谁更适合当前阶段：

• 第一轮看谁能把规则拆清楚；
• 第二轮看谁能挑出遗漏；
• 第三轮看谁能整理成可执行用例；
• 第四轮看谁能帮我复核断言是否完整。

重要接口我会让两个模型交叉看一遍。不是为了比输赢，而是看它们是否都指出了同一类风险。

输入材料一定要先脱敏

这个点很容易被忽略。接口文档、日志、请求样例、数据库字段、业务规则，很多都不该原样贴进去。

至少要处理这些内容：

• 用户手机号、邮箱、地址；
• 订单号、流水号、合同号；
• Token、密钥、内部域名；
• 真实业务编号；
• 未公开的公司规则。

脱敏后不会影响模型理解。比如把订单号改成order_001，把接口路径改成/api/order/update，把金额改成测试样例值。模型看的是逻辑，不是生产原文。

我常用的几个 Prompt

1. 拆规则

text

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

2. 查遗漏

text

请从边界值、状态流转、兼容性、异常返回四个角度，检查我已有的测试点是否有遗漏。只指出缺口，不要重写全部内容。

3. 转用例表

text

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

4. 复核断言

text

请检查这些测试用例的断言是否足够明确。如果断言过于笼统，请改成可以直接验证的描述。

这几段 Prompt 的共同点是，尽量只让模型做一件事。任务越单一，结果越稳。

常见误区

1. AI 写出来的测试用例能直接交付吗？

不能。它适合做初稿和补漏，最终还是要由人确认。尤其是金额、状态、支付、权限这类逻辑，必须结合真实系统验证。

2. 需求写得越长，模型越准吗？

不一定。长文档如果结构乱，模型也容易抓偏。最好先按“背景、变更点、字段、状态、异常、兼容性”整理后再输入。

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

普通小需求不必。高风险接口、历史 Bug 多的模块、跨团队协作场景，才值得多看一轮。重点不是答案多漂亮，而是有没有把风险点指出来。

4. AI 能替代测试同学做设计吗？

不能。它能减少低级遗漏，但不能替代业务理解、测试策略和真实环境验证。尤其是回归、联调、灰度这些环节，还是要人来把关。

结尾

如果你也想把 AI 用进测试流程，我建议先从高频、低风险、可验证的接口开始。先让它拆规则、补场景、挑遗漏，再由人把内容落成测试用例和自动化代码。

重要任务别只看一个模型的结论，多模型交叉看一遍会更稳；涉及代码、日志和业务资料时，先脱敏再输入；最后的判断，还是要回到需求、系统行为和人工 Review。这样用，AI 才是助手，不是替你拍板的人。