• 需求文档不完整、有歧义或变更频繁。
• 你需要在写用例前先做风险识别和测试边界确认。
• 团队对“现在能测什么、还缺什么”不清晰。

• 产出需求层面的风险与可测性分析。
• 给出清晰范围、依赖项和验证策略。
• 把模糊需求转成可决策的问题清单。

1. 拆解业务规则、状态流转和异常处理逻辑。
2. 标记歧义点：输入缺失、结果不明确、规则冲突。
3. 映射测试维度：功能、数据、接口、流程、非功能。
4. 按业务影响和变更频率做优先级。
5. 形成澄清问题并指定决策责任人。
6. 输出分析结论和下一步测试动作建议。

输入：

• PRD：优惠叠加规则 + 会员等级 + 退款例外

输出：

• 规则矩阵与边界说明
• 高风险清单（舍入、冲突规则、回滚行为）
• 澄清问题与建议验收标准

输入：

• “读一下 PRD，给我测试点”

输出（问题）：

• 只给通用测试点，没有发现规则冲突和未决问题
• 无法支撑后续用例质量

• 不把缺失规则当成既定事实。
• 不在歧义未处理前直接进入用例编写。
• 不忽视上下游依赖影响。
• 不给“无依据”的风险排序。
• 不在缺少验收标准时宣称“需求可测”。