test-strategy-review

测试策略评审

适用场景

• 需要判断测试策略草案是否充分、可行，以及是否符合业务和技术约束。
• 评审会议必须区分阻塞项、有时限的条件和可选的非阻塞改进项。
• 需求、角色分析、技术说明或项目约束存在冲突，需要 AI 提供可追溯的建议，由 Human 决策。

输入

必须提供拟议的测试策略。只能使用所提供的需求、角色分析、技术约束和项目约束。将缺失材料记录为缺口；不得自行补充。保留可定位的文档标识、来源和已提供的责任人。

工作流

1. 完整阅读并遵循 prompts/test-strategy-review.md；这是独立的执行规范。
2. 验证策略正文和来源，并记录缺失或冲突的输入。如果不存在可供评审的策略，则停止实质性评审。
3. 评审业务覆盖范围、测试深度、可行性、环境、数据、质量门禁、依赖项和明确排除项。
4. 区分阻塞项和非阻塞项；将每个非阻塞项标记为必须在规定时限内完成的条件，或可选改进项。
5. 应用确定性规则，生成 AI 辅助的 pass、conditional_pass 或 reject 建议，并为缺口指定责任人和可验证的修订要求。
6. 在交付前检查证据、范围、责任归属、建议和 Human 决策边界。

决策约束

• 存在任何阻塞项，都必须建议 reject。
• 没有阻塞项，但存在一项或多项必须在规定门禁前解决的条件时，建议 conditional_pass。
• 既没有阻塞项，也没有条件时，建议 pass；可保留可选的非阻塞改进项。
• 将影响范围、关键风险、门禁或排除项的未解决来源冲突视为阻塞项。未经授权，不得擅自选择任何一方。
• 责任人只能从输入中获取。未提供时填写 unassigned，并创建修订请求以指定责任人。
• 策略描述的是计划开展的工作，而非已执行的测试。不得捏造测试结果、证据、风险接受、豁免或批准。
• 始终将结果标记为AI 辅助建议。最终的 pass、conditional_pass 或 reject 决定由 Human 保留；不得声称最终批准已经完成。

输出约定

按以下顺序输出：评审状态、输入和冲突、维度评审矩阵、阻塞项、非阻塞项、修订请求、排除项评审、建议依据和局限性、Human 决策问题。每项发现和修订请求都必须引用证据、说明影响、保留已提供的责任人，并给出可验证的关闭条件。

条件加载

• 每次运行时都要阅读 prompts/test-strategy-review.md，以了解输入验证、八个维度的评审、分类规则和输出结构。
• 仅在评估或回归测试此 Skill 时阅读 evals/。评估场景不属于真实项目证据。

交付前检查

• 所有八个评审维度都有证据、缺口或不适用说明
• 阻塞项和非阻塞项已分开；条件未与可选改进项混在一起
• 建议符合分类规则，没有因进度压力而忽视质量缺口
• 冲突来源仍清晰可见；没有捏造变更、豁免或决定
• 每项修订请求都包含对象、责任人或 unassigned、时间要求/门禁和关闭证据
• 结果明确标记为 AI 辅助建议，最终 Human 决策仍待作出

常见错误

• 不要根据文档长度推断其完整性；请确认关键风险是否对应到测试和门禁。
• 不要把环境就绪情况当作后续再处理的细节；缺少某项能力可能导致关键测试无法实施。
• 不要自动接受明确的排除项；请检查其获批范围、风险处置方式和来源。
• 不要把 conditional_pass 当作含糊的折中方案；每项条件都必须可分配、可验证，并与关闭门禁关联。