你是不是也遇到：需求一长就漏测、AI 一生成就幻觉、用例一多就根本评不动？
Treeify 专注把测试设计变成可建模、可评审、可持续迭代的过程——用结构化方法把问题空间拆开，再生成更少但更有覆盖的用例。
想一起把测试设计做得更工程化，欢迎来共创/内测。
添加 V：【TreeifyAI】进内测共创群，获得 Treeify 内测资格 / 免费 credits / MCP Server 试用

• 微信公众号：Treeify - AI测试用例生成
• 联系微信：TreeifyAI

Treeify 是一支专注“测试设计过程工程化”的团队。我们不做“让 AI 一口气吐出 100 条黑盒用例”的捷径，而是把测试设计拆成需求 → 测试对象 → 测试场景的结构化过程，让结果可评审、可追溯、可精准修改、可持续维护。

如果你也正在经历“生成很快、评审很慢、改动很痛、最后还得人工返工”，这篇文章会把问题讲透：Prompt 生成测试用例到底哪里不靠谱、为什么难修、怎么止损，以及怎样走向可控的测试设计。

---

一、先说结论：生成不难，难的是“可控 + 可维护”

很多团队第一次用 Prompt 生成测试用例都很兴奋：给它一段 PRD、几分钟就出几十上百条用例。问题是，真实项目里测试用例不是“交付一次就结束”，而是一个会反复被使用、被评审、被修改、被回归的长期资产。

在团队协作里，一套测试用例是否“能用”，关键不是它能不能生成出来，而是它是否满足三条硬指标：

1）可 Review：评审时能快速判断覆盖是否充分、规则是否正确、风险是否被关注。
2）可精准修改：只改错的那一条，不影响其他正确内容，不引入新混乱。
3）可持续维护：需求变化后，更新成本可控，不会变成“文档债”。

对话式 Prompt 生成的问题在于：它本质是黑盒输出。你得到了一堆结果，但你看不到依据、没有结构，更难以局部编辑与长期维护。于是出现一种非常常见的现象——“生成很快，落地很慢；越改越乱，最后返工”。

下面我们用“六宗罪”把这些问题拆开讲，并且每条都用真实项目里高频出现的示例说明：它具体怎么坑你、怎么浪费时间、怎么造成漏测与事故。

---

二、罪 1：幻觉——它敢编，你敢信吗？

所谓幻觉，不是“瞎说八道”那么简单，而是它在需求缺失和描述模糊时，会非常自然地补齐它认为合理的逻辑。写文案、写总结时这是优点；写测试用例时，这是隐形炸弹。

示例 1：PRD 没写权限，AI 自动脑补“管理员逻辑”

假设你的 PRD 只写了：

“用户可以在订单详情页申请退款。退款申请成功后，订单状态进入退款中。退款结果会通过站内信通知用户。”

PRD 没提任何“角色与权限”。你让 AI 生成测试用例，它很可能给出一条看起来“很专业”的用例：

用例：管理员可在后台直接审批退款并强制通过
步骤：后台进入退款列表 → 选择订单 → 点击强制通过
预期：退款立即成功，用户收到通知

问题在哪里？

这条用例并不是“测试覆盖更全”，而是把“未定义需求”当成“已定义需求”。如果你把它加入用例库，评审时就会出现争论：产品有没有后台？有没有管理员审批？是不是仅用户端申请、系统自动处理？最后你浪费时间在对齐“AI 编出来的需求”。

更糟的是，如果团队默认“AI 生成的都挺靠谱”，你甚至可能拿它去验证不存在的功能。测试资源就这样被消耗掉，而真正应该补齐的是：权限模型、审批流是否存在、自动退款还是人工审核、触发条件是什么。

示例 2：PRD 没写“异常与边界”，AI 给出“默认正确”的预期

假设 PRD 写：

“优惠券面额 0-100，订单金额满 100 可用。”

你问 AI：生成测试用例。它通常会给出大量“正常使用”的用例，但当你追问边界，它可能说：

用例：输入优惠金额为 100，成功创建优惠券
用例：输入优惠金额为 0，成功创建优惠券

看似没问题，但很多系统对 0 的处理是“无意义券”或“禁止创建”。PRD 没写清楚时，AI 会选择一种默认解释。测试用例看起来完整，实际是把歧义掩盖掉了。有歧义时，正确做法是暴露歧义：需要补充规则，而不是替产品做决定。

幻觉的真实后果：
1）评审会上大量时间用来“查证 AI 编没编”；
2）用例库掺入假逻辑，长期污染质量体系；
3）你无法追溯这条用例到底基于哪条需求或规则。

---

三、罪 2：漏测——漏掉的 bug，谁来负责？

Prompt 生成最危险的不是写错，而是漏掉“事故高发点”。因为模型更擅长生成主流程，对并发、状态、异常、权限、数据一致性这些“高赔付维度”很容易漏。

示例 1：订单“待支付”场景，漏掉重复提交与并发扣库存

PRD 常见一句话：

“用户提交订单后进入待支付状态，支付成功后进入已支付。”

AI 生成的用例一般是：

• 提交订单 → 待支付

• 支付成功 → 已支付

• 支付失败 → 提示失败

但线上事故最常见的不是这些，而是：

场景 A：用户连续点两次“提交订单”（或网络抖动导致请求重发）

你要验证：

• 是否生成两笔订单？还是同一订单 idempotent？

• 库存是否扣了两次？优惠券是否占用两次？

• 重复请求返回什么？是否可恢复/可追踪？

场景 B：两个人同时买最后一件库存

你要验证：

• 第二个人是下单失败还是支付失败？

• 失败提示是否准确？

• 库存扣减发生在下单还是支付？是否有超卖？

Prompt 生成如果没有“覆盖模型”驱动，它往往不会主动把这些高风险拆出来。最终你得到 100 条“看起来很多”的用例，却漏掉几条“最可能出事故”的场景。

示例 2：退款状态机，漏掉非法跳转与中间态

PRD：
“申请退款后状态为退款中，退款成功状态为已退款。”

AI 生成：

• 申请退款 → 退款中

• 退款成功 → 已退款

现实系统可能有更多状态：退款中、退款失败、退款关闭、退款中途取消、客服介入、部分退款。真正容易出 bug 的是非法跳转：

• 已退款后再次申请退款（是否拒绝/幂等）

• 退款中再次申请退款（是否合并/更新原因/拒绝）

• 退款失败后是否允许重试

• 退款中订单是否允许发货/确认收货

Prompt 不会“自带状态模型”，没有结构约束就很难覆盖完整的状态机。

漏测的真实后果：
你以为 AI 帮你“补全覆盖”，实际它在用大量低价值主流程用例掩盖盲区。漏掉的 bug 上线后，责任还是落在测试团队，因为“用例库看起来很满”。

---

四、罪 3：不可 Review——黑盒输出，你敢用吗？

很多团队说：“没关系，AI 生成后我们 Review 一遍。”问题是：非结构化黑盒输出，让评审成本极高、且评审质量不稳定。

示例 1：100 条用例混在一起，你根本审不动

假设 AI 输出这样一段：

用例 1：测试登录功能

• 步骤：打开登录页…
• 预期：登录成功…

用例 2：测试注册功能

• 步骤：填写表单…
• 预期：注册成功…

……（还有 95 条）

问题不是“它写得不像用例”，而是你无法快速回答评审真正关心的问题：

• 这些用例覆盖了哪些测试对象？哪些对象根本没提？

• 有哪些规则被覆盖？哪些边界漏了？

• 并发/异常/权限/一致性这些维度覆盖了吗？

• 是否重复？是否重叠？维护成本会不会爆炸？

非结构化文本迫使你用“人肉读全文”的方式评审。读到第 40 条，注意力就开始下降；读到第 80 条，基本只剩扫字。评审质量严重依赖个人状态，团队无法规模化。

示例 2：缺少“需求映射”，你无法证明覆盖

如果用例没有关联需求点（或验收标准 AC），你无法证明“这个需求被测了”。更糟糕的是：出现线上缺陷时，你也无法快速回溯：这条缺陷对应的需求点有没有用例？没测还是测漏了？

这就是为什么很多团队 AI 用例“堆了很多”，但依然缺乏覆盖的可证明性。

---

五、罪 4：不可精准修改——改不准，急不急？

对话式修改的最大坑：你只想改一条，AI 会“顺便”改很多条。因为它不是在编辑文档，而是在重新生成一段更像的文本。

示例：你只想改“用例 3 的预期结果”，结果它把一串都改乱了

你对 AI 说：
“把用例 3 的预期结果从‘登录成功’改成‘提示密码错误’。”

AI 可能输出：

• 用例 3 改了（看起来正确）
  但同时：

• 用例 5 的步骤也被重写了

• 用例 8 消失了

• 甚至用例顺序全乱了

这在工程上等价于：你每次做局部改动，都要重新对全文件做回归审查。于是“修改成本”比“写一遍”更高。到最后你会发现：AI 不是减轻维护工作，而是在制造维护工作。

---

六、罪 5：多轮无效——对话再多，也是白搭？

多数团队的真实使用轨迹是这样的：

第一轮：AI 生成 100 条（看起来很开心）
第二轮：你发现漏了状态机/并发/边界，让它补
第三轮：补了但重复了，顺序也乱了，再让它去重
第四轮：去重后缺了关键一条，再让它补
第五轮：补完格式不符合规范，再让它按模板改写
第 N 轮：还在改……

示例：优惠券规则的“补洞循环”

当业务规则比较复杂（例如：新客券不可与店铺券叠加、指定类目可用、部分商品不可用、退款后券是否返还、多张券优先级…），Prompt 生成几乎一定会进入“补洞循环”。每补一次，就引入新的重复、新的假设、新的遗漏。你会觉得自己像在把一个不停流动的沙堆捏成砖。

多轮无效的本质原因：缺少中间产物。

你没有测试对象清单，没有规则表/决策表，没有状态模型，没有覆盖维度清单。你只是跟一个模型聊天，想让它在纯文本里完成工程化收敛，这几乎不可能稳定。

---

七、罪 6：无私有知识——你的场景，它懂吗？

企业落地最大的坎：通用 AI 不懂你的组织规范与历史经验。

示例 1：团队强制模板与字段要求，AI 永远不合规

很多团队要求用例必须包含：

• 用例 ID（项目前缀）

• 优先级（P0-P3 或 5 级）

• 类型（功能/接口/兼容/安全…）

• 前置条件、数据准备

• 关联需求（用户故事/AC）

• 风险标签

你让 AI 按模板输出，第一轮能勉强像样。第二轮你补充需求，模板又漂移；第三轮你让它改一个字段，它把其他字段也改了。最终你还是要人工整理成你们的规范格式。

示例 2：历史缺陷经验无法复用，导致“重复踩坑”

比如你们历史上最常出事故的是：

• 订单状态与库存一致性

• 支付回调幂等

• 取消订单的补偿逻辑

• 订阅续费的时区问题

• 缓存与数据库不一致导致的展示错误

这些经验如果不注入，Prompt 生成永远只能泛泛而谈，无法把你们真正的风险点系统性拉进测试设计。这也是为什么很多团队用 AI 生成，仍然挡不住线上事故：它不懂你的“坑”。

---

八、总结：Prompt 生成的“快”，建立在三个不可接受的假设上

把六宗罪合起来，你会发现对话式 Prompt 生成的效率，往往建立在三种假设上：

1）默认它不会幻觉（但它会）
2）默认它不会漏测（但它会）
3）默认它可维护（但它很难）

因此它在 Demo 里很香，在交付里很苦。

---

九、如果你现在仍然要用 Prompt：三步止损（建议团队立刻执行）

我们不是反对用 AI，而是反对“黑盒一次性生成”。如果你现在的团队已经把 Prompt 用在用例生成上，建议至少做三步止损，把风险降到可控。

止损 1：强制结构化输出，让评审可执行
不要让它输出大段文本。要求每条用例最少包含：

• 用例标题（对象 + 行为 + 期望）

• 关联需求点/验收标准（Trace）

• 场景类型（主/替代/异常）

• 覆盖维度标签（状态/权限/异常/边界/并发/一致性）

• 前置条件、步骤、预期、断言点（UI/API/DB/Log/MQ）

示例（对登录功能）：

• 标题：登录-密码错误-提示错误且不生成会话

• Trace：AC-LOGIN-03

• 类型：异常

• 维度：输入校验

• 断言点：接口返回码 + 页面提示文案 + session 未创建

止损 2：强制“缺失即提示”，禁止脑补

在 Prompt 规则里写死：

• 未明确说明的权限/规则/校验禁止补齐

• 必须列出“需要补充”的信息列表

• 必须输出“假设清单”，评审逐条确认

示例（对退款规则）：

需要补充：是否存在人工审核/客服介入？退款失败是否可重试？退款中是否允许发货？
假设清单：默认退款为自动处理；退款中禁止发货（需产品确认）

止损 3：用覆盖清单驱动生成，避免一口气 100 条

不要一次生成 100 条把自己淹死。先生成“覆盖骨架”，再生成用例细节。

建议顺序：
第一步：生成测试对象清单（模块/规则/状态/接口）
第二步：为每个对象生成场景集合（主/支/异常）
第三步：对高风险对象补覆盖维度（状态/并发/异常/权限/一致性/边界）
第四步：最后再输出用例

这至少能显著降低漏测与评审崩溃的概率。

---

十、附：一份可直接贴进评审流程的检查清单（对 Prompt 生成的用例）

A. 幻觉检查

• 是否出现 PRD 未定义但被补齐的规则/权限/流程？

• 是否有假设清单？假设是否被确认？

• 缺失信息是否以“需要补充”明确列出？

B. 漏测检查（高风险维度）

• 状态机：合法/非法跳转是否覆盖？

• 并发：重复提交/竞态/幂等是否覆盖？

• 异常：超时/重试/降级/补偿是否覆盖？

• 权限：角色×资源×操作边界是否覆盖？

• 一致性：缓存/消息/最终一致是否覆盖？

• 边界：空值/超长/精度/时间窗是否覆盖？

C. 可 Review 检查

• 是否按对象/场景分组？

• 每条是否关联需求点/AC？

• 是否有维度标签与断言点？

• 是否明显重复/重叠？

D. 可维护检查

• 需求变更时能否定位影响范围？

• 是否能局部修改而不影响其他用例？

• 是否每次都要重新生成并全量重审？

---

十一、写在最后：你要的不是更多用例，而是更少返工

Prompt 生成测试用例不是完全不能用，它的问题在于：很多团队把它当终点——“生成出来就算完成”。真实项目里，测试设计的核心是可控与可维护：覆盖可证明、评审可执行、变更可收敛。

如果你愿意把 AI 真正用在“工程化测试设计”里，一个更可行的方向是：先把测试设计结构化（需求→对象→场景），让每一步都有中间产物可审可改，再让 AI 在结构约束下生成用例细节。否则你会不断遇到：生成很快，落地很慢；越改越乱，最终返工。