别再直接让 AI 生成测试用例了：用 Superpowers 做需求分析的 5 步实操

很多测试同学第一次用 AI 辅助测试设计时，最常见的操作是：

把需求文档丢给 AI，然后输入一句：
“请根据以下需求生成测试用例。”

这个方式很直接，也很容易看到效果。

AI 很快就能生成一张表：

• 用例标题
• 前置条件
• 操作步骤
• 预期结果
• 优先级
• 备注

看起来效率很高，甚至有一种“测试用例自动生成了”的感觉。

但真正拿到项目里用，很快就会发现问题：

• 生成了很多条，但关键规则漏了；
• 主流程有了，边界值不够；
• 异常场景偏通用，不贴合业务；
• 预期结果写得太空，执行时不好判断；
• 优先级看起来像随便标的；
• 甚至还会编造需求里没有的规则。

所以，AI 生成测试用例这件事，不能只追求“快”。

更重要的是：

生成出来的内容，是否真的能支撑测试设计。

这也是我越来越不建议测试同学直接让 AI 一步生成用例的原因。

更稳的做法是：
把需求分析和用例设计拆成一套固定流程，让 AI 分阶段辅助测试工程师完成工作。

这时候，Superpowers 的价值就体现出来了。

它不是简单帮你写几条用例，而是可以把一套成熟测试工程师的分析方法固化下来，变成可重复执行的工作流。

这篇文章就用一个具体例子，演示如何用 Superpowers 完成：

PRD 拆解 → 风险识别 → 测试点设计 → 用例生成 → 覆盖检查

也就是一套从需求到测试用例的 5 步实操流程。

---

一、为什么不建议直接让 AI 生成测试用例？

直接生成测试用例，最大的问题不是“生成不了”。

恰恰相反，AI 很擅长生成。

问题在于：

它生成得太像了。

一张结构完整、语言通顺的测试用例表，很容易让人误以为质量不错。

但测试设计的核心，不在于表格长得像不像，而在于：

• 需求规则有没有拆清楚；
• 风险有没有识别出来；
• 边界有没有覆盖；
• 异常有没有贴合业务；
• 权限和状态有没有考虑；
• 预期是否能验证；
• 是否存在需求外编造。

如果前面的需求分析没有做透，AI 后面生成的用例再工整，也可能只是“漂亮的空壳”。

举个简单例子。

需求里写：

报销金额小于等于 5000 元时，仅直属上级审批；
报销金额大于 5000 元且小于等于 20000 元时，需部门负责人审批；
报销金额大于 20000 元时，需财务复审。

如果你直接让 AI 生成用例，它可能会写：

验证不同金额报销进入不同审批流程。

这句话看起来没错，但对测试来说远远不够。

真正需要覆盖的是：

• 4999.99
• 5000
• 5000.01
• 20000
• 20000.01

以及每个金额对应的审批节点。

所以，AI 生成用例之前，必须先让它把规则拆出来。

这就是 Superpowers 五步法的核心：

先分析，再生成。

---

二、准备一个示例 PRD

为了更直观，我们先准备一段简化版需求。

示例需求：报销审批规则优化

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

这段需求不长，但包含了非常典型的测试要素：

• 用户角色
• 金额边界
• 审批流
• 状态流转
• 异常分支
• 待确认项
• 多端影响
• 数据导出影响

非常适合用来演示 Superpowers 的价值。

---

三、第一步：需求拆解，不急着写用例

第一步，不要让 AI 生成测试用例。

先让它拆需求。

你可以这样输入：

请先不要生成测试用例。

请基于以下需求做需求拆解，输出：
1. 功能模块
2. 功能点
3. 业务规则
4. 权限规则
5. 状态流转
6. 影响范围
7. 待确认项

要求：
- 不允许补充需求中没有的规则；
- 不明确的内容标记为“待确认”；
- 用表格输出。

这一步的目标是让 AI 先把 PRD 里的测试对象拆出来。

示例输出

模块	功能点	关键规则	说明
报销申请	普通员工提交报销申请	仅可提交本人报销申请	涉及权限边界
审批规则	按金额匹配审批流	≤5000、5000～20000、>20000	涉及边界值
状态流转	提交、撤回、驳回	审批中、草稿、已驳回	涉及状态变化
影响范围	多端和导出	PC、H5、报销数据导出	涉及回归范围
待确认	批量导入报销单	是否支持待产品确认	不能直接设计为已支持

这一步非常重要。

因为测试设计不是从“写用例”开始的，而是从“看清需求结构”开始的。

如果这一步做得好，后面用例质量会明显更稳。

---

四、第二步：风险识别，先找容易出问题的地方

需求拆完后，第二步也不要急着写用例。

先让 AI 帮你识别测试风险。

可以这样输入：

基于上面的需求拆解结果，请识别测试风险。

重点关注：
1. 金额边界风险
2. 权限风险
3. 状态流转风险
4. 多端一致性风险
5. 导出数据风险
6. 待确认需求风险

请输出风险点、风险说明和测试关注点。

示例输出

风险点	风险说明	测试关注点
金额阈值判断	5000 和 20000 是关键审批边界，容易出现等于值处理错误	覆盖 4999.99、5000、5000.01、20000、20000.01
本人提交限制	普通员工只能提交本人报销申请，存在越权风险	验证是否可替他人提交
撤回状态回退	审批中撤回后应回到草稿，可能出现状态不一致	验证撤回后是否可编辑、重新提交
驳回后重提	已驳回申请可修改后重新提交，审批流需重新生成	验证驳回、编辑、重新提交完整链路
多端一致性	PC 和 H5 均受影响，可能出现规则不一致	验证两端审批流和状态展示一致
导出数据影响	报销数据导出受影响，可能漏审批节点或状态字段	验证导出数据字段和页面一致
批量导入待确认	需求未明确是否支持，不能作为本轮确定功能	标记为待确认，不生成确定性用例

这一步比直接生成用例更有价值。

因为它把测试工程师最关心的问题提前暴露出来了：

哪些地方最容易出问题？
哪些地方必须重点测？
哪些地方需要找产品确认？

这也是 Superpowers 在需求分析阶段最实用的地方。

---

五、第三步：先生成测试点，再生成测试用例

很多人会跳过测试点，直接从需求到用例。

但更稳的方式是：

先生成测试点清单，再基于测试点生成用例。

测试点是测试设计的骨架。

用例是测试点的结构化表达。

你可以这样输入：

请基于需求拆解和风险识别结果，生成测试点清单。

要求按以下维度输出：
1. 主流程
2. 边界值
3. 异常流程
4. 权限
5. 状态流转
6. 影响范围
7. 待确认项

请标注优先级 P0/P1/P2，并说明原因。

示例输出

测试维度	测试点	优先级	说明
主流程	普通员工提交本人报销申请	P0	核心业务路径
边界值	金额等于 5000 时仅直属上级审批	P1	金额阈值边界
边界值	金额 5000.01 时进入部门负责人审批	P1	超过第一阈值
边界值	金额等于 20000 时仍为部门负责人审批	P1	第二阈值等于值
边界值	金额 20000.01 时触发财务复审	P0	高金额审批风险
权限	普通员工不能替他人提交报销申请	P0	越权风险
状态流转	提交后状态变为审批中	P0	主状态变化
状态流转	审批中撤回后回到草稿	P1	异常路径
异常流程	任一节点驳回后变为已驳回	P1	驳回分支
异常流程	已驳回申请可修改后重新提交	P1	回流路径
影响范围	PC 和 H5 规则一致	P1	多端一致性
影响范围	报销数据导出包含正确审批状态	P1	数据一致性
待确认项	批量导入不作为确定功能测试	P1	避免需求外编造

这一张测试点清单，已经比直接生成的用例更有价值。

它能帮助测试工程师快速判断：

• 重点在哪里；
• 风险在哪里；
• 哪些必须测；
• 哪些暂时不能测。

---

六、第四步：基于测试点生成测试用例

到这里，再生成测试用例就比较稳了。

因为前面已经完成了：

• 需求拆解
• 风险识别
• 测试点设计

现在生成用例，不是让 AI 自由发挥，而是让它基于已确认的测试点进行结构化输出。

可以这样输入：

请基于上面的测试点清单生成测试用例。

要求：
1. 不允许编造需求外规则；
2. 步骤必须具体可执行；
3. 预期结果必须清晰可验证；
4. 边界值必须给出具体数据；
5. 待确认内容不能写成确定功能；
6. 输出字段包括：用例标题、前置条件、操作步骤、预期结果、优先级、备注。

示例输出

用例标题	前置条件	操作步骤	预期结果	优先级
验证普通员工可提交本人报销申请	普通员工账号已登录	1. 进入报销申请页；2. 填写本人报销信息；3. 点击提交	申请提交成功，状态变为“审批中”	P0
验证普通员工不能替他人提交报销申请	普通员工账号已登录	1. 进入报销申请页；2. 尝试选择或填写他人作为申请人；3. 提交申请	系统不允许替他人提交，或申请人字段固定为当前用户	P0
验证报销金额等于 5000 元时仅直属上级审批	普通员工账号已登录	1. 新建报销单；2. 金额输入 5000；3. 提交申请	审批流仅包含直属上级节点，不触发部门负责人和财务复审	P1
验证报销金额 5000.01 元时进入部门负责人审批	普通员工账号已登录	1. 新建报销单；2. 金额输入 5000.01；3. 提交申请	审批流包含部门负责人节点，不触发财务复审	P1
验证报销金额等于 20000 元时不触发财务复审	普通员工账号已登录	1. 新建报销单；2. 金额输入 20000；3. 提交申请	审批流进入部门负责人审批，不包含财务复审节点	P1
验证报销金额 20000.01 元时触发财务复审	普通员工账号已登录	1. 新建报销单；2. 金额输入 20000.01；3. 提交申请	审批流包含财务复审节点	P0
验证审批中申请可撤回并回到草稿	申请已提交且状态为审批中	1. 打开申请详情；2. 点击撤回；3. 确认撤回	申请状态变为“草稿”，申请人可继续编辑	P1
验证已驳回申请可修改后重新提交	申请已被任一审批节点驳回	1. 打开已驳回申请；2. 修改报销信息；3. 重新提交	申请状态变为“审批中”，审批流重新生成	P1
验证 PC 与 H5 审批流规则一致	同一账号可访问 PC 和 H5	1. 分别在 PC 和 H5 提交相同金额报销单；2. 查看审批流	两端生成的审批节点一致	P1
验证报销数据导出包含正确审批状态	存在不同状态报销单	1. 导出报销数据；2. 查看导出文件中的金额、审批节点、状态字段	导出数据与页面展示一致	P1

这批用例比“直接让 AI 生成”更可用。

因为它有几个明显优点：

• 边界值具体；
• 操作步骤可执行；
• 预期结果可验证；
• 没有把待确认项写成确定功能；
• 优先级有业务依据。

---

七、第五步：做覆盖检查，别生成完就结束

很多人用 AI 生成用例后，直接复制到文档里。

这一步很危险。

因为 AI 输出看起来完整，不代表真的没有漏。

所以最后一定要做覆盖检查。

可以这样输入：

请基于原始需求和已生成测试用例做覆盖检查。

检查内容包括：
1. 是否覆盖所有业务规则；
2. 是否覆盖金额边界；
3. 是否覆盖权限；
4. 是否覆盖状态流转；
5. 是否覆盖影响范围；
6. 是否存在需求外编造；
7. 是否存在重复用例；
8. 预期结果是否可验证；
9. 还需要补充哪些用例。

示例输出

检查项	结果	说明
业务规则覆盖	基本覆盖	已覆盖提交、审批、撤回、驳回、重提
金额边界覆盖	部分覆盖	已覆盖 5000、5000.01、20000、20000.01，建议补充 4999.99、19999.99
权限覆盖	基本覆盖	已覆盖本人提交限制，建议补充不同角色查看权限
状态流转覆盖	已覆盖	已覆盖审批中、草稿、已驳回状态
影响范围覆盖	部分覆盖	已覆盖 PC、H5、导出，建议补充导出字段明细校验
需求外编造	未发现	未将批量导入写成已支持
重复用例	未发现明显重复	用例目标区分较清晰
预期结果可验证	基本可验证	个别导出类用例可进一步明确字段
建议补充	需要补充	金额 4999.99、19999.99；审批通过状态；不同角色查看范围

这一步非常关键。

它能把 AI 生成用例从“初稿”进一步推向“可评审”。

尤其是下面这些检查，很适合长期固化：

• 是否漏边界值；
• 是否漏权限；
• 是否漏状态；
• 是否存在需求外编造；
• 是否预期不可验证；
• 是否重复堆数量。

如果没有覆盖检查，AI 生成用例很容易停留在“看起来还行”。

---

八、直接生成 vs 五步法，有什么区别？

可以简单对比一下。

方式	优点	主要问题
直接让 AI 生成用例	快，输出多	容易漏规则、边界不足、预期泛、可能编造
人工纯手写	理解深，质量可控	耗时较长，受个人经验影响
Superpowers 五步法	兼顾效率和质量	需要分步骤执行，前期要设计好流程

我更推荐第三种。

不是让 AI 替你写完，而是让 AI 参与整个测试设计过程：

AI 负责拆解、补全、结构化；
测试工程师负责判断、取舍、确认。

这才是更合理的人机协同方式。

---

九、这套流程适合哪些场景？

比较适合：

• 常规业务 PRD；
• 审批流需求；
• 权限类需求；
• 多端验收需求；
• 表单和数据流转需求；
• 回归测试点补充；
• 新人测试用例初稿生成；
• 测试主管做用例质量检查。

不太适合完全自动化处理：

• 需求极不清晰的场景；
• 强依赖历史系统逻辑的复杂需求；
• 金融、法务、合规类高风险最终判断；
• 需要大量业务背景才能理解的特殊领域需求。

这些场景可以用 AI 辅助分析，但不能完全依赖 AI 输出。

---

十、可以直接复用的 Superpowers Prompt

最后给一版完整 Prompt，你可以直接作为 Superpower 使用。

# 角色
你是资深测试架构师，擅长从 PRD 中进行需求分析、风险识别和测试用例设计。

# 任务
请基于我提供的需求文档，完成从需求分析到测试用例设计的完整过程。

# 基本要求
1. 不允许编造需求中没有明确说明的规则；
2. 对需求不明确的地方，必须标记为“待确认”；
3. 测试点必须覆盖主流程、边界值、异常流程、权限、状态流转、数据校验、多端影响、接口影响、历史数据影响；
4. 用例步骤必须可执行；
5. 预期结果必须清晰可验证；
6. 输出优先级 P0/P1/P2，并说明原因；
7. 最后反向检查是否存在漏测、重复用例和需求外编造。

# 输出结构

## 一、需求摘要
用 5 条以内说明本需求核心内容。

## 二、功能点拆解
| 模块 | 功能点 | 说明 |
|---|---|---|

## 三、业务规则提取
| 规则编号 | 规则内容 | 需求依据 | 测试影响 |
|---|---|---|---|

## 四、风险与待确认问题
| 问题 | 风险 | 建议确认对象 |
|---|---|---|

## 五、测试点清单
| 测试维度 | 测试点 | 优先级 | 说明 |
|---|---|---|---|

## 六、测试用例
| 用例标题 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 备注 |
|---|---|---|---|---|---|

## 七、覆盖检查
| 检查项 | 结果 | 说明 |
|---|---|---|
| 功能点是否覆盖完整 |  |  |
| 业务规则是否覆盖完整 |  |  |
| 边界值是否覆盖 |  |  |
| 异常流程是否覆盖 |  |  |
| 权限场景是否覆盖 |  |  |
| 状态流转是否覆盖 |  |  |
| 影响范围是否覆盖 |  |  |
| 是否存在需求外编造 |  |  |
| 是否存在重复用例 |  |  |
| 预期结果是否可验证 |  |  |

这版 Prompt 的重点不是“生成更多用例”，而是让 AI 按测试分析流程逐层推进。

---

十一、小结

用 Superpowers 做需求分析和用例设计，最重要的不是让 AI 一步生成结果。

而是把测试设计拆成 5 步：

1. 需求拆解；
2. 风险识别；
3. 测试点设计；
4. 用例生成；
5. 覆盖检查。

这样做的好处是：

• 需求看得更清楚；
• 风险暴露得更早；
• 测试点更完整；
• 用例更可执行；
• 更容易发现遗漏和编造；
• 输出结果更适合评审和沉淀。

Superpowers 真正的价值，不是替代测试工程师，而是把测试工程师的专业分析过程固化下来。

一句话总结：

别让 AI 直接替你写用例，要让 AI 跟着你的测试思路一步步分析。

---

写在最后

AI 进入测试工作后，最容易带来的错觉是：

只要输入需求，测试用例就能自动生成。

但真正的测试设计，从来不是简单把需求改写成表格。

它需要理解业务规则，识别风险，判断边界，分析状态，确认影响范围，最后才能形成可执行用例。

所以，AI 最适合做的不是替代测试判断，而是参与测试分析过程。

人负责判断质量，AI 负责辅助拆解和结构化。
人负责识别风险，Superpowers 负责固化流程和提升效率。

这才是 AI 对测试工作真正有价值的用法。