别再直接让 AI 生成测试用例了用 Superpowers 做需求分析的 5 步实操很多测试同学第一次用 AI 辅助测试设计时最常见的操作是把需求文档丢给 AI然后输入一句“请根据以下需求生成测试用例。”这个方式很直接也很容易看到效果。AI 很快就能生成一张表用例标题前置条件操作步骤预期结果优先级备注看起来效率很高甚至有一种“测试用例自动生成了”的感觉。但真正拿到项目里用很快就会发现问题生成了很多条但关键规则漏了主流程有了边界值不够异常场景偏通用不贴合业务预期结果写得太空执行时不好判断优先级看起来像随便标的甚至还会编造需求里没有的规则。所以AI 生成测试用例这件事不能只追求“快”。更重要的是生成出来的内容是否真的能支撑测试设计。这也是我越来越不建议测试同学直接让 AI 一步生成用例的原因。更稳的做法是把需求分析和用例设计拆成一套固定流程让 AI 分阶段辅助测试工程师完成工作。这时候Superpowers 的价值就体现出来了。它不是简单帮你写几条用例而是可以把一套成熟测试工程师的分析方法固化下来变成可重复执行的工作流。这篇文章就用一个具体例子演示如何用 Superpowers 完成PRD 拆解 → 风险识别 → 测试点设计 → 用例生成 → 覆盖检查也就是一套从需求到测试用例的 5 步实操流程。一、为什么不建议直接让 AI 生成测试用例直接生成测试用例最大的问题不是“生成不了”。恰恰相反AI 很擅长生成。问题在于它生成得太像了。一张结构完整、语言通顺的测试用例表很容易让人误以为质量不错。但测试设计的核心不在于表格长得像不像而在于需求规则有没有拆清楚风险有没有识别出来边界有没有覆盖异常有没有贴合业务权限和状态有没有考虑预期是否能验证是否存在需求外编造。如果前面的需求分析没有做透AI 后面生成的用例再工整也可能只是“漂亮的空壳”。举个简单例子。需求里写报销金额小于等于 5000 元时仅直属上级审批报销金额大于 5000 元且小于等于 20000 元时需部门负责人审批报销金额大于 20000 元时需财务复审。如果你直接让 AI 生成用例它可能会写验证不同金额报销进入不同审批流程。这句话看起来没错但对测试来说远远不够。真正需要覆盖的是4999.9950005000.012000020000.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、500020000、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. 金额输入 50003. 提交申请审批流仅包含直属上级节点不触发部门负责人和财务复审P1验证报销金额 5000.01 元时进入部门负责人审批普通员工账号已登录1. 新建报销单2. 金额输入 5000.013. 提交申请审批流包含部门负责人节点不触发财务复审P1验证报销金额等于 20000 元时不触发财务复审普通员工账号已登录1. 新建报销单2. 金额输入 200003. 提交申请审批流进入部门负责人审批不包含财务复审节点P1验证报销金额 20000.01 元时触发财务复审普通员工账号已登录1. 新建报销单2. 金额输入 20000.013. 提交申请审批流包含财务复审节点P0验证审批中申请可撤回并回到草稿申请已提交且状态为审批中1. 打开申请详情2. 点击撤回3. 确认撤回申请状态变为“草稿”申请人可继续编辑P1验证已驳回申请可修改后重新提交申请已被任一审批节点驳回1. 打开已驳回申请2. 修改报销信息3. 重新提交申请状态变为“审批中”审批流重新生成P1验证 PC 与 H5 审批流规则一致同一账号可访问 PC 和 H51. 分别在 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 步需求拆解风险识别测试点设计用例生成覆盖检查。这样做的好处是需求看得更清楚风险暴露得更早测试点更完整用例更可执行更容易发现遗漏和编造输出结果更适合评审和沉淀。Superpowers 真正的价值不是替代测试工程师而是把测试工程师的专业分析过程固化下来。一句话总结别让 AI 直接替你写用例要让 AI 跟着你的测试思路一步步分析。写在最后AI 进入测试工作后最容易带来的错觉是只要输入需求测试用例就能自动生成。但真正的测试设计从来不是简单把需求改写成表格。它需要理解业务规则识别风险判断边界分析状态确认影响范围最后才能形成可执行用例。所以AI 最适合做的不是替代测试判断而是参与测试分析过程。人负责判断质量AI 负责辅助拆解和结构化。人负责识别风险Superpowers 负责固化流程和提升效率。这才是 AI 对测试工作真正有价值的用法。
