需求不清楚时，别急着写用例：测试工程师如何用 AI 追问出隐藏规则？

需求不清楚时别急着写用例测试工程师如何用 AI 追问出隐藏规则很多测试同学都有这样的经历需求文档看起来写了不少但真正准备写用例时发现很多地方都不清楚。比如等于边界值时怎么算驳回后能不能重新提交普通员工能不能查看别人提交的数据历史数据要不要迁移H5、PC、移动端是否都要支持导出字段是否跟页面一致这个功能一期做不做AI 结果能不能直接写入正式系统这时候如果直接写测试用例很容易出现两种情况。一种是你按自己的理解补了规则最后产品说这个不是本期范围。另一种是你没有覆盖到测试中或上线后才发现这个场景之前没人想清楚。所以需求不清楚时测试工程师不要急着写用例。更好的做法是先把隐藏规则问出来。以前这个过程主要靠测试经验。现在有了 AI可以让 AI 帮我们做第一轮需求澄清问题生成。但要注意AI 不是替你决定规则而是帮你从测试视角把“该问的问题”列出来。这篇文章就用一个具体需求演示测试工程师如何用 AI 追问出隐藏规则并把这些问题转成测试点和用例。一、为什么需求不清楚时不能直接写用例测试用例的质量很大程度取决于需求规则是否清楚。如果需求本身模糊用例很容易写偏。举个例子。需求里写用户提交报销申请后系统按金额进入不同审批流程。这句话看起来有用但对测试来说远远不够。你至少需要继续确认金额分段是多少等于边界值时怎么算金额是否支持小数金额为 0 是否允许修改金额后审批流是否重新计算历史报销单是否适用新规则PC 和 H5 是否规则一致审批中能否撤回驳回后能否修改重新提交如果这些问题没问清测试用例只能凭猜。而凭猜写出来的用例风险很大。所以测试工程师在需求评审阶段的价值不只是听产品讲需求而是要主动暴露规则空白。一句话需求越模糊越不能急着写用例越应该先追问规则。二、用 AI 追问需求不是让 AI 决定答案这里要先说清楚一个边界。用 AI 做需求澄清不是问 AI这个规则应该怎么设计而是让 AI 帮你找出这个需求里有哪些没说清楚、但会影响测试设计的问题AI 适合做的是扫描需求中的模糊点按测试维度生成问题提醒边界、权限、异常、状态、数据、兼容等风险输出待确认问题清单帮助测试工程师准备需求评审问题。AI 不适合做的是替产品决定业务规则替研发决定实现方案替测试确认上线范围把猜测写成确定结论。所以正确用法是AI 负责帮你发现“应该问什么” 人负责决定“答案是什么”。三、准备一个示例需求我们继续用一个中性业务场景。示例 PRD报销审批规则优化1. 普通员工可提交本人报销申请。 2. 报销金额 ≤ 5000 元时仅直属上级审批。 3. 5000 元 报销金额 ≤ 20000 元时需部门负责人审批。 4. 报销金额 20000 元时需财务复审。 5. 提交后申请状态变为“审批中”。 6. 审批中可撤回撤回后状态回到“草稿”。 7. 任一节点驳回后状态变为“已驳回”申请人可修改后重新提交。 8. 是否支持批量导入报销单待产品确认。 9. 本次改动影响 PC 端、H5 端和报销数据导出。这段需求比很多真实 PRD 已经清楚不少但仍然有很多隐藏问题。接下来我们用 AI 做需求澄清。四、第一步让 AI 按测试维度生成澄清问题不要直接问这个需求有什么问题这样输出可能比较泛。更好的提示词是请从测试工程师视角审查以下需求生成需求澄清问题。 要求 1. 不要替我回答问题 2. 只列出会影响测试范围、测试用例、上线风险的问题 3. 按维度分类输出 4. 维度包括业务规则、边界值、权限、状态流转、异常流程、数据一致性、多端兼容、导出、历史数据、待确认项、上线灰度 5. 每个问题说明为什么要确认以及如果不确认会带来什么测试风险。这个提示词的关键是明确角色明确不要替你回答明确输出维度明确每个问题要说明风险。五、第二步AI 输出第一版澄清问题AI 可能会输出类似下面的内容。维度澄清问题为什么要确认不确认的风险边界值金额等于 5000 和 20000 时分别走哪个审批流影响边界用例设计可能漏测等于值判断金额规则报销金额是否支持小数小数精度到几位影响金额输入和审批判断可能出现前后端精度不一致权限普通员工是否只能提交本人报销申请是否能代他人提交影响权限用例可能出现越权提交状态流转审批中撤回后是否允许修改金额后再次提交影响撤回后的测试路径状态回退后流程可能异常驳回流程驳回后重新提交是否重新生成审批流影响金额变更后的审批节点可能沿用旧审批流多端兼容PC 和 H5 是否都支持完整流程影响多端测试范围可能只测 PC 漏 H5数据导出导出文件是否需要包含审批状态和当前节点影响导出校验导出数据可能与页面不一致历史数据已存在的报销单是否适用新审批规则影响回归范围历史单据状态或流程异常待确认项批量导入是否属于本期范围影响是否设计导入用例可能把未实现功能纳入测试灰度上线是否只对部分用户开放影响上线验证范围灰度用户与非灰度用户表现不一致这就是一份有价值的需求评审问题清单。它不是答案但能帮助测试工程师在评审会上更有针对性地提问。六、第三步把问题分成三类处理AI 生成的问题不能全部无脑丢给产品。测试工程师还要筛选。建议分成三类类型说明处理方式必须确认不确认无法设计用例或影响上线风险评审会重点确认建议确认影响测试范围或边界但可通过默认规则处理记录并确认优先级可测试发现不一定要评审确认可在测试中验证转成探索测试点以前面的输出为例可以这样整理。必须确认问题问题原因金额等于 5000 和 20000 时分别走哪个审批流直接影响边界用例批量导入是否属于本期范围影响是否纳入测试范围驳回后重新提交是否重新生成审批流影响状态流转和审批规则历史报销单是否适用新规则影响回归范围是否存在灰度范围影响上线验证建议确认问题问题原因金额是否支持小数及小数位数影响金额输入细节导出是否包含审批状态和当前节点影响导出校验PC 和 H5 是否完全一致影响多端覆盖可测试发现问题问题测试动作撤回后是否可编辑实际操作验证H5 状态是否同步多端交叉验证导出与页面是否一致页面和导出数据对比这样整理后评审问题就不会显得杂乱。七、第四步把澄清问题转成评审发言很多测试同学知道要问但评审会上不容易表达得清楚。可以把问题改成更适合沟通的表达。比如不要直接问5000 怎么算可以问PRD 里写金额 ≤ 5000 仅直属上级审批5000 金额 ≤ 20000 走部门负责人审批。为了避免边界理解不一致我确认一下金额正好等于 5000 时走直属上级金额正好等于 20000 时不触发财务复审对吗这样表达更专业也更容易得到明确答案。再比如不要问批量导入测不测可以问PRD 中写“是否支持批量导入报销单待产品确认”。为了避免把未确定能力纳入本轮测试请确认批量导入是否属于本期交付范围。如果不属于我会把它记录为待确认项不生成正式用例。这类表达既说明了问题也说明了测试影响。八、第五步把确认结果转成测试设计需求评审不是问完就结束。确认结果要进入测试设计。例如评审后得到这些答案澄清问题确认结果金额等于 5000 怎么走直属上级审批金额等于 20000 怎么走部门负责人审批不触发财务复审批量导入是否本期支持本期不支持驳回后重新提交是否重新生成审批流如果金额变化需要重新生成PC 和 H5 是否都支持都支持功能一致导出是否包含审批状态需要包含审批状态和当前节点接下来就要转成测试点。确认结果转成测试点5000 走直属上级验证金额 5000 元时仅直属上级审批20000 不触发财务复审验证金额 20000 元时为部门负责人审批本期不支持批量导入验证页面不展示批量导入入口或入口不可用金额变化需重新生成审批流验证驳回后修改金额为 20000.01重新提交后触发财务复审PC 和 H5 功能一致验证两端相同金额审批流一致导出包含审批状态验证导出文件包含审批状态和当前节点这一步很关键。如果确认结果没有进入测试点评审就只是聊天。九、第六步把测试点转成用例继续把上面的测试点转成用例。用例标题前置条件操作步骤预期结果优先级验证金额 5000 元时仅直属上级审批普通员工已登录新建报销单金额输入 5000提交审批流仅包含直属上级节点P1验证金额 20000 元时不触发财务复审普通员工已登录新建报销单金额输入 20000提交审批流进入部门负责人审批不包含财务复审节点P1验证本期不支持批量导入普通员工已登录进入报销申请相关页面页面不展示批量导入入口或入口置灰不可用P1验证驳回后修改金额重新生成审批流报销单已被驳回原金额为 3000修改金额为 20000.01 后重新提交审批流重新生成并包含财务复审节点P1验证 PC 和 H5 审批流一致同一账号可访问 PC 和 H5分别提交金额为 5000.01 的报销单两端审批流均为部门负责人审批P1验证导出文件包含审批状态和当前节点存在不同状态报销单导出报销数据导出文件包含审批状态、当前审批节点且与页面一致P1这就是完整链路AI 帮你发现要问什么 ↓ 评审会上确认答案 ↓ 确认结果转测试点 ↓ 测试点转测试用例这比直接让 AI 生成用例更稳。十、可以直接复用的 AI 提示词下面是一套可以直接复制使用的提示词。提示词一生成需求澄清问题你是资深测试工程师。请从测试视角审查以下需求生成需求澄清问题。 要求 1. 不要替我回答问题 2. 不要编造需求中没有的规则 3. 只提出会影响测试范围、测试用例设计、上线风险的问题 4. 按维度分类输出 5. 维度包括业务规则、边界值、权限、状态流转、异常流程、数据一致性、多端兼容、导出、历史数据、待确认项、上线灰度 6. 每个问题说明“为什么要确认”和“不确认的风险”。 输出格式 | 维度 | 澄清问题 | 为什么要确认 | 不确认的风险 |提示词二筛选重点问题请基于上面的需求澄清问题帮我分成三类 1. 必须确认不确认会影响用例设计或上线判断 2. 建议确认会影响测试范围或优先级 3. 可测试发现不一定需要评审确认可以通过测试验证。 请用表格输出并说明分类原因。提示词三生成评审发言稿请把以下需求澄清问题改写成适合需求评审会上提问的表达。 要求 1. 语气专业、简洁 2. 说明为什么要确认 3. 说明对测试范围或用例设计的影响 4. 避免质问式表达 5. 输出为“问题 建议表达”。提示词四确认结果转测试点请根据以下需求澄清问题及确认结果转换成测试点清单。 要求 1. 每条确认结果至少对应一个测试点 2. 标注测试维度 3. 标注优先级 P0/P1/P2 4. 说明测试目的。 输出字段 | 确认结果 | 测试维度 | 测试点 | 优先级 | 测试目的 |提示词五测试点转用例请基于以下测试点生成测试用例。 要求 1. 用例步骤必须可执行 2. 预期结果必须可验证 3. 不允许补充未确认规则 4. 对仍不明确的内容标记为待确认 5. 输出字段包括用例标题、前置条件、操作步骤、预期结果、优先级。这五个提示词连起来就是一套完整的需求澄清流程。十一、测试工程师用 AI 追问需求的注意事项1. 不要让 AI 替你决定业务规则错误用法你觉得金额等于 20000 应该怎么走正确用法请列出金额边界中需要产品确认的问题。AI 可以帮你找问题但不能替业务拍板。2. 不要把 AI 生成的问题全部丢给产品AI 可能会生成很多问题。测试工程师要筛选避免评审会上问题过多、过散。优先问不确认无法写用例的问题不确认可能造成线上风险的问题不确认会影响测试范围的问题。3. 问题要和测试影响绑定好的问题不是单纯提问而是说明影响。比如请确认金额等于 20000 时是否触发财务复审。这个规则会直接影响边界值测试用例设计。这样产品更容易理解为什么要回答。4. 确认结果必须沉淀评审会上确认了规则要沉淀到PRD 备注测试点测试用例待确认问题清单回归用例测试报告风险说明。否则下次还会重复问。十二、需求澄清记录模板可以用下面这个模板记录。编号问题维度确认结果测试影响后续动作Q1金额等于 5000 时走哪个审批流边界值直属上级审批补 5000 边界用例已补用例Q2金额等于 20000 是否触发财务复审边界值不触发补 20000 边界用例已补用例Q3批量导入是否本期支持待确认项本期不支持不生成导入成功用例记录待确认Q4驳回后修改金额是否重算审批流状态流转需要重算补驳回后改金额用例已补用例Q5导出是否包含审批状态导出需要包含补导出字段校验已补用例这个模板很适合放在需求评审纪要或测试分析文档里。十三、小结需求不清楚时别急着写用例。更好的流程是先用 AI 生成澄清问题 ↓ 测试工程师筛选重点问题 ↓ 需求评审会上确认答案 ↓ 确认结果转测试点 ↓ 测试点再转测试用例AI 在这里的价值不是替你决定业务规则而是帮你更快发现哪些边界没说清哪些权限没定义哪些状态没闭环哪些异常没处理哪些影响范围没确认哪些待确认项不能直接写成用例。一句话总结AI 不是需求答案机而是测试工程师的提问放大器。写在最后测试工程师真正的价值不只是会写用例。更重要的是能在需求还不清楚的时候问出那些会影响质量的问题。很多线上问题不是因为测试不会执行而是因为需求阶段没有把规则问清楚。AI 可以帮我们更快发现问题清单但最终要靠测试工程师判断哪些问题必须问哪些问题可以测哪些答案会影响范围哪些规则必须沉淀成用例哪些风险要写进测试报告。所以下一次看到一份不够清楚的需求不要急着让 AI 生成用例。先让 AI 帮你列问题。因为好的测试设计往往从一个好问题开始。