测试策略评审

---
name: test-strategy-review
description: Use this skill when a proposed test strategy needs evidence-based review before Human approval; triggers include 测试策略评审、策略评审、测试方案审核, test strategy review and strategy approval review.
---

# 测试策略评审（中文版）

## 何时使用

- 已有测试策略草案，需要判断其是否充分、可执行且与业务及技术约束一致。
- 评审会需要区分阻塞缺口、可限时补齐的条件项和非阻塞改进。
- 需求、角色分析、技术说明或项目约束之间存在冲突，需要形成可追溯的 AI 建议供 Human 决策。

## 输入

必须提供待评审测试策略。结合调用方提供的需求、角色分析、技术约束和项目约束；未提供的材料记为缺口，不补造。保留可定位的文档编号、来源和责任人。

## 执行流程

1. 读取并完整遵循 `prompts/test-strategy-review.md`；该 Prompt 是独立执行规范。
2. 校验策略正文与来源，记录缺失和冲突；没有可评审策略时停止实质评审。
3. 逐项评审业务覆盖、测试深度、可执行性、环境、数据、质量门禁、依赖与明确排除项。
4. 将发现分为阻塞项和非阻塞项；非阻塞项再标为必须限时关闭的条件项或可选改进。
5. 按确定性规则生成 `pass`、`conditional_pass` 或 `reject` 的 AI 辅助建议，并为缺口给出责任归属和可验证修订请求。
6. 执行证据、范围、责任人、结论与 Human 决策边界自检。

## 决策约束

- 有任一阻塞项时只能建议 `reject`。
- 无阻塞项但有必须在指定门槛前关闭的条件项时建议 `conditional_pass`。
- 无阻塞项和条件项时建议 `pass`；可保留不影响建议的非阻塞改进。
- 来源冲突影响范围、关键风险、门禁或排除项且未解决时视为阻塞；不得自行选择一方。
- 责任人只取自输入。未提供时写“待指派”，并把指派责任人作为修订请求。
- 策略描述的是计划，不是已执行测试；不得虚构测试结果、证据、风险接受、豁免或批准。
- 输出始终标记为 **AI 辅助建议**。Human 保留 `pass`、`conditional_pass` 或 `reject` 的最终决定权；不得声称最终批准已经发生。

## 输出合同

依次输出：**评审状态、输入与冲突、维度评审矩阵、阻塞项、非阻塞项、修订请求、排除项审查、建议依据与限制、Human 待决问题**。每个发现和修订请求应引用证据、说明影响、保留已有责任人，并给出可验证关闭条件。

## 按需加载

- 每次执行都读取 `prompts/test-strategy-review.md`，使用其中的输入校验、八维检查、分类规则和输出结构。
- 仅在评测或回归本 Skill 时读取 `evals/`；其中场景不是实际项目证据。

## 交付前自检

- [ ] 八个评审维度均有证据、缺口或不适用说明
- [ ] 阻塞项与非阻塞项已分区，条件项没有混入可选改进
- [ ] 建议值严格匹配分类规则，没有用排期压力覆盖质量缺口
- [ ] 冲突来源均被保留，未擅自裁决或虚构变更/豁免
- [ ] 每个修订请求都有对象、责任人或“待指派”、时点/门槛和关闭证据
- [ ] 输出明确是 AI 辅助建议，Human 最终决定仍为待定

## 常见误区

- 不要因策略篇幅长就判断完整；应检查关键风险是否真正映射到测试和门禁。
- 不要把“环境以后再说”当作小问题；环境能力缺失可能使关键测试不可执行。
- 不要把明确排除项自动视为合理；需要与批准范围、风险处置和来源一致。
- 不要把 `conditional_pass` 当作模糊折中；每个条件必须可分派、可验证且有关闭门槛。