naodeng 测试策略评审（中文版）
何时使用
- 已有测试策略草案，需要判断其是否充分、可执行且与业务及技术约束一致。
- 评审会需要区分阻塞缺口、可限时补齐的条件项和非阻塞改进。
- 需求、角色分析、技术说明或项目约束之间存在冲突，需要形成可追溯的 AI 建议供 Human 决策。
输入
必须提供待评审测试策略。结合调用方提供的需求、角色分析、技术约束和项目约束；未提供的材料记为缺口，不补造。保留可定位的文档编号、来源和责任人。
执行流程
- 读取并完整遵循
prompts/test-strategy-review.md；该 Prompt 是独立执行规范。 - 校验策略正文与来源，记录缺失和冲突；没有可评审策略时停止实质评审。
- 逐项评审业务覆盖、测试深度、可执行性、环境、数据、质量门禁、依赖与明确排除项。
- 将发现分为阻塞项和非阻塞项；非阻塞项再标为必须限时关闭的条件项或可选改进。
- 按确定性规则生成
pass、conditional_pass或reject的 AI 辅助建议，并为缺口给出责任归属和可验证修订请求。 - 执行证据、范围、责任人、结论与 Human 决策边界自检。
决策约束
- 有任一阻塞项时只能建议
reject。 - 无阻塞项但有必须在指定门槛前关闭的条件项时建议
conditional_pass。 - 无阻塞项和条件项时建议
pass；可保留不影响建议的非阻塞改进。 - 来源冲突影响范围、关键风险、门禁或排除项且未解决时视为阻塞；不得自行选择一方。
- 责任人只取自输入。未提供时写“待指派”，并把指派责任人作为修订请求。
- 策略描述的是计划，不是已执行测试；不得虚构测试结果、证据、风险接受、豁免或批准。
- 输出始终标记为 AI 辅助建议。Human 保留
pass、conditional_pass或reject的最终决定权；不得声称最终批准已经发生。
输出合同
依次输出：评审状态、输入与冲突、维度评审矩阵、阻塞项、非阻塞项、修订请求、排除项审查、建议依据与限制、Human 待决问题。每个发现和修订请求应引用证据、说明影响、保留已有责任人，并给出可验证关闭条件。
按需加载
- 每次执行都读取
prompts/test-strategy-review.md，使用其中的输入校验、八维检查、分类规则和输出结构。 - 仅在评测或回归本 Skill 时读取
evals/；其中场景不是实际项目证据。
交付前自检
- 八个评审维度均有证据、缺口或不适用说明
- 阻塞项与非阻塞项已分区，条件项没有混入可选改进
- 建议值严格匹配分类规则，没有用排期压力覆盖质量缺口
- 冲突来源均被保留，未擅自裁决或虚构变更/豁免
- 每个修订请求都有对象、责任人或“待指派”、时点/门槛和关闭证据
- 输出明确是 AI 辅助建议，Human 最终决定仍为待定
常见误区
- 不要因策略篇幅长就判断完整；应检查关键风险是否真正映射到测试和门禁。
- 不要把“环境以后再说”当作小问题；环境能力缺失可能使关键测试不可执行。
- 不要把明确排除项自动视为合理；需要与批准范围、风险处置和来源一致。
- 不要把
conditional_pass当作模糊折中；每个条件必须可分派、可验证且有关闭门槛。