AI 测试用例翻车现场：这些“看起来合理”的预期，都是错的

最近我用 AI 根据一份报销审批 PRD 生成测试用例。

第一眼看，输出挺完整：

• 金额边界有了；
• 审批路由有了；
• 撤回、驳回、重提交有了；
• PC、H5 都覆盖了；
• 导出也考虑了；
• 甚至还补了异常场景和兼容回归。

如果只是粗略看一眼，很容易觉得：

这不就可以直接拿去评审，甚至入库了吗？

但我仔细看了一遍后，发现真正危险的地方不在于 AI 漏了多少用例，而在于：

它偷偷帮 PRD 补了不少“看起来合理、但实际没有需求依据”的规则。

这些规则如果直接进入正式用例，就不是测试了，而是测试工程师替产品编需求。

这篇文章不讲概念，直接看一次 AI 测试用例翻车现场。

---

一、先看这份 PRD

这是一个很常见的报销审批规则优化需求：

1. 普通员工可提交本人报销申请。
2. 报销金额 ≤ 5000 元时，仅直属上级审批。
3. 5000 元 < 报销金额 ≤ 20000 元时，需部门负责人审批。
4. 报销金额 > 20000 元时，需财务复审。
5. 提交后申请状态变为“审批中”。
6. 审批中可撤回，撤回后状态回到“草稿”。
7. 任一节点驳回后，状态变为“已驳回”，申请人可修改后重新提交。
8. 是否支持批量导入报销单，待产品确认。
9. 本次改动影响 PC 端、H5 端和报销数据导出。

这个 PRD 看起来不复杂。

AI 第一次生成时，也确实给出了很多测试点：

• 金额 = 3000；
• 金额 = 5000；
• 金额 = 10000；
• 金额 = 20000；
• 金额 = 25000；
• 审批中撤回；
• 驳回后重提交；
• PC 端流程；
• H5 端流程；
• 导出校验；
• 批量导入；
• 审批人异常；
• 历史数据兼容。

但问题也就藏在这些“完整”里面。

---

二、翻车点 1：把“需财务复审”理解成完整审批链

PRD 原文是：

报销金额 > 20000 元时，需财务复审。

AI 生成的测试点里出现过类似表达：

金额 > 20000 元时，验证审批链包含部门负责人 + 财务复审两层。

乍一看，这很合理。

因为很多公司确实可能是：

直属上级 → 部门负责人 → 财务复审

或者：

部门负责人 → 财务复审

但问题是，PRD 没写。

PRD 只明确了一件事：

大于 20000 元时，需要财务复审。

它没有说：

• 是否还需要直属上级；
• 是否还需要部门负责人；
• 财务复审是不是终审；
• 财务复审前后是否还有其他节点。

所以，AI 这条用例的问题不是“业务上不合理”，而是“没有需求依据”。

错误写法

金额 25000 元时，审批链包含部门负责人和财务复审。

修正写法

金额 25000 元时，提交后状态为“审批中”；
审批链中包含财务复审节点；
仅验证财务复审节点存在，不假设其前是否有其他审批节点。

这条规则很重要：

“需某节点审批”不等于“完整审批链已定义”。

---

三、翻车点 2：把“导出受影响”理解成“新增字段”

PRD 原文是：

本次改动影响 PC 端、H5 端和报销数据导出。

AI 很容易继续补充：

导出文件包含审批状态、审批人、审批时间、当前审批节点字段。

这也是一个很典型的“合理推断”。

因为审批规则改了，导出里好像确实应该有这些字段。

但 PRD 没写字段清单。

它只说：

报销数据导出受影响。

“受影响”可能代表很多事情：

• 导出范围变化；
• 导出权限变化；
• 导出字段变化；
• 导出性能变化；
• 导出数据口径变化；
• 只是需要回归验证已有导出能力。

如果产品没有给字段清单，测试不能擅自写字段级预期。

错误写法

导出文件中包含审批状态字段，且状态值正确。
导出文件中包含审批人、审批时间字段。

修正写法

导出文件可正常生成、下载和打开；
导出文件非空、未损坏；
导出记录数量与筛选范围内页面记录数量一致；
导出字段清单及字段取值规则待产品确认后补充字段级用例。

这条规则也很常见：

“导出受影响”不等于“新增字段已确认”。

---

四、翻车点 3：把“影响 PC/H5”理解成“两端一致”

PRD 原文是：

本次改动影响 PC 端、H5 端。

AI 生成 H5 用例时，一度写出：

H5 端状态展示与 PC 端一致。

这个表述也很容易被忽略，因为它看起来很正常。

但实际上，PRD 只说两个端受影响，没有说：

• 两端功能完全一致；
• 两端交互完全一致；
• 两端字段展示完全一致；
• 两端状态文案完全一致。

尤其是 H5 和 PC 经常会有端差异。

比如 PC 端可能展示完整审批链，H5 端可能只展示当前状态；PC 端可能有导出入口，H5 端没有；PC 端可能展示更多字段，H5 端做了简化。

所以，测试预期不能写“与 PC 一致”。

错误写法

H5 端状态展示与 PC 端一致。

修正写法

H5 端提交、撤回、驳回重提交操作均可正常执行；
状态正确展示为“审批中”“草稿”“已驳回”。

这条规则可以总结为：

“影响多个端”不等于“多个端完全一致”。

---

五、翻车点 4：把未定义终态写成“流程结束”

PRD 中定义了这些状态：

提交后状态变为“审批中”。
审批中可撤回，撤回后状态回到“草稿”。
任一节点驳回后，状态变为“已驳回”。

但它没有定义：

审批通过后的状态是什么？

没有说是：

• 已通过；
• 已完成；
• 待付款；
• 已付款；
• 审批完成；
• 流程结束。

AI 在生成完整审批通过场景时，很容易写：

审批通过后流程结束。

或者：

财务复审通过后状态变为已完成。

这就是典型的状态机补全。

错误写法

财务复审通过后流程结束，无更多待审批节点。

修正写法

审批通过后的终态 PRD 未定义，需产品确认。
本轮正式用例不生成审批通过后终态场景。

这条规则是：

终态未定义时，不得写“流程结束”。

---

六、翻车点 5：把“待确认”功能写成正式用例

PRD 原文写得很清楚：

是否支持批量导入报销单，待产品确认。

这种内容最简单，也最容易被忽视。

如果 AI 生成：

批量导入报销单成功。
批量导入失败后提示错误原因。
批量导入超过上限时拦截。

那就是明显错误。

因为“是否支持”都还没确认。

这里不应该生成任何正式用例，只能进入待确认清单。

错误写法

批量导入报销单成功。

修正写法

批量导入是否纳入本期，待产品确认；
确认纳入后再补充导入模板、字段校验、失败处理、条数上限等用例。

这条规则最简单：

待确认项不得入库。

---

七、真正危险的不是 AI 漏测，而是 AI 偷偷补规则

以前我们担心 AI 写测试用例时漏场景。

但这次实践后，我觉得更危险的是：

AI 写得太像真的了。

它补出来的东西往往非常合理：

• 大额报销走部门负责人 + 财务复审；
• 导出包含审批字段；
• H5 与 PC 一致；
• 审批通过后流程结束；
• 批量导入有成功和失败场景。

这些内容都符合常识。

但测试用例不能只符合常识，更要符合 PRD 或评审确认结果。

如果没有依据，就应该是待确认，而不是正式用例。

这也是 AI 测试最大的风险之一：

它不是胡说八道，而是一本正经地替需求补全。

---

八、我给 AI 加了 5 条硬规则

为了修正这些问题，我给 AI 加了 5 条硬规则。

规则 1：PRD 没写的，不得写成预期

只要 PRD 没定义，就不能进入正式用例。

包括：

• 终态；
• 审批链；
• 字段清单；
• 端一致性；
• UI 交互方式；
• 权限范围；
• 异常处理策略。

规则 2：“需某节点审批”不等于完整审批链

如果 PRD 只写“需财务复审”，只能验证财务复审节点存在。

不能自动补：

直属上级 → 部门负责人 → 财务复审

规则 3：“导出受影响”不等于新增字段

字段清单未确认前，只能做基础导出回归：

• 文件可生成；
• 文件可下载；
• 文件可打开；
• 文件非空；
• 记录数量一致。

字段级校验必须等待字段清单确认。

规则 4：“影响 PC/H5”不等于两端一致

如果 PRD 没说两端一致，不要写：

与 PC 端一致。

应该写本端可验证结果：

状态展示为“审批中”“草稿”“已驳回”。

规则 5：“待确认”不得生成正式用例

只要 PRD 中出现：

• 待确认；
• 需产品确认；
• 暂未明确；
• 是否支持待定；
• 后续补充；

对应内容不能入库。

只能进入待确认清单。

---

九、加规则后，输出发生了什么变化？

我没有让 AI 一次性直接生成最终用例，而是按流程拆开：

需求评审问题
→ 评审问题收敛
→ 测试点设计
→ 测试点收敛
→ 可入库用例筛选
→ 正式用例生成
→ 用例自检
→ 修正版输出

最后结果是：

阶段	数量
原始评审问题	23 个
原始测试点	52 条
收敛后测试点	33 条
核心已确认测试点	10 条
核心待确认测试点	14 条
扩展风险	9 条
最终正式用例	15 条
待产品确认问题	15 个

这组数字很重要。

因为它说明：

AI 不是生成越多越好，而是要经过筛选后留下能真正入库的部分。

原始 52 条测试点看起来很多，但最后真正可入库的是 15 条用例。

其余很多内容不是没价值，而是需要先确认、后补充。

---

十、修正后的正式用例长什么样？

下面看几条最终保留下来的用例。

用例 1：金额 5000 边界

项目	内容
用例标题	≤5000 元报销，边界值 5000 元仍触发直属上级审批
前置条件	普通员工账号存在直属上级
操作步骤	填写报销金额 5000 元并提交
预期结果	提交成功，状态为“审批中”；直属上级待办中出现该报销单；仅直属上级一个审批节点
优先级	P0

这条用例是可以入库的。

因为 PRD 明确写了：

报销金额 ≤5000 元时，仅直属上级审批。

5000 的边界归属清楚。

---

用例 2：金额 20000 边界

项目	内容
用例标题	5000<金额≤20000 元报销，边界值 20000 元触发部门负责人审批
前置条件	普通员工所属部门有部门负责人
操作步骤	填写报销金额 20000 元并提交
预期结果	提交成功，状态为“审批中”；部门负责人待办中出现该报销单
优先级	P0

注意标题最好写成：

5000<金额≤20000 元

不要写成：

5000~20000 元

因为后者容易让人误解 5000 也属于中档。

---

用例 3：金额 25000 高档审批

项目	内容
用例标题	>20000 元报销，审批链包含财务复审节点
前置条件	系统中存在财务复审角色或人员
操作步骤	填写报销金额 25000 元并提交，查看财务复审人员待办
预期结果	提交成功，状态为“审批中”；财务复审人员待办中存在该报销单；仅验证财务复审节点存在，不假设其前是否有其他审批节点
优先级	P0

这条用例的关键是克制。

它没有写：

部门负责人 + 财务复审

也没有写：

财务复审通过后流程结束

---

用例 4：导出基础回归

项目	内容
用例标题	报销数据导出功能可用性验证
前置条件	存在若干条报销记录；账号有导出权限
操作步骤	设置导出筛选条件，执行导出，下载文件并打开
预期结果	导出操作可正常执行；导出文件可成功下载并正常打开；文件非空、未损坏
优先级	P1

这条用例没有写字段明细。

因为字段清单没有确认。

---

用例 5：导出数量一致性

项目	内容
用例标题	导出记录数量与筛选范围一致性验证
前置条件	当前筛选条件下列表记录总数为 N
操作步骤	执行导出，打开导出文件，统计文件内记录条数 M
预期结果	M 与页面筛选结果总数 N 一致
优先级	P1

这条可以入库，因为它不依赖字段清单。

---

十一、AI 自检也发现了问题

正式用例生成后，我又让 AI 做了一次自检。

自检发现了 3 个问题：

问题	为什么有问题	修正
H5 用例写“状态展示与 PC 端一致”	PRD 未明确端一致性	改为“状态正确展示为审批中、草稿、已驳回”
PC 用例写“页面跳转”	PRD 未定义 UI 交互方式	改为“提交后状态展示为审批中”
驳回用例写“查看驳回信息”	PRD 未定义驳回字段	改为“查看状态是否为已驳回”

这说明自检很有必要。

如果没有自检，这些“很像正常需求”的内容很可能就进入正式用例了。

---

十二、这套检查 Prompt 可以直接复用

如果你也在用 AI 生成测试用例，可以直接在生成后追加这段：

请检查刚才生成的测试用例是否存在以下问题：

1. 是否把 PRD 未说明的内容写成了确定性预期；
2. 是否把待确认项写成了正式用例；
3. 是否把“需某节点审批”推断成完整审批链；
4. 是否把“导出受影响”推断成具体字段；
5. 是否把“影响 PC/H5”推断成两端一致；
6. 是否写了“流程结束”“终审”“已完成”等未确认终态；
7. 是否写了页面跳转、弹窗、Toast 等 PRD 未定义交互；
8. 是否存在“正常”“正确”“符合预期”等不可验证预期；
9. 是否遗漏待确认问题清单；
10. 是否存在可以合并的重复用例。

请输出：
一、问题总览；
二、需要删除或转为待确认的用例；
三、需要修改的用例；
四、建议保留的用例；
五、仍需产品确认的问题；
六、最终是否可以入库。

这段 Prompt 不一定让 AI 完全不犯错，但能挡住不少明显问题。

尤其是：

• PRD 外推断；
• 待确认误入库；
• 不可验证预期；
• 多端机械复制；
• 导出字段乱写。

---

十三、我的结论：AI 生成用例前后都要“过筛”

这次实践后，我不建议直接让 AI 从 PRD 生成正式测试用例。

更稳的流程应该是：

PRD
→ 需求评审问题
→ 测试点
→ 测试点收敛
→ 可入库筛选
→ 正式用例
→ 用例自检
→ 修正版用例

这比一句“帮我生成测试用例”麻烦一点，但质量明显更稳。

原因很简单：

测试设计不是生成内容，而是筛选依据。

AI 生成 50 条测试点并不难。

难的是判断：

• 哪些能入库；
• 哪些要待确认；
• 哪些只是扩展风险；
• 哪些是 AI 偷偷补出来的；
• 哪些预期不可验证；
• 哪些用例应该删掉或合并。

这才是测试工程师真正应该把关的地方。

---

十四、写在最后

AI 生成测试用例，真正危险的不是它写得少，而是它写得太像真的。

很多错误不是离谱错误，而是“看起来非常合理”的错误。

比如：

• 大额报销应该走多级审批；
• 导出应该有审批字段；
• H5 应该和 PC 一致；
• 审批通过后应该流程结束；
• 批量导入应该有成功和失败用例。

这些都符合常识。

但测试用例不能只符合常识。

它必须符合 PRD，或者符合产品/研发确认结果。

所以我现在使用 AI 生成测试用例时，会先问自己三个问题：

这条预期 PRD 里写了吗？
这条规则有人确认了吗？
这条结果测试人员能验证吗？

如果答案是否定的，它就不应该进入正式用例。

一句话总结：

AI 可以帮我们生成测试内容，但不能替我们确认需求规则。
真正能入库的，不是 AI 写出来的内容，而是经过规则筛选和自检后留下来的内容。