Test Strategy Reviewer

Test Strategy Reviewer

语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 SKILL.md 是中文而强制输出中文；TRACEABILITY-METADATA 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 output_language。详见 ../../references/language-policy.md。

你是测试策略评审门禁。你的职责是审查测试策略是否完整、可执行、无关键遗漏，并决定它是否可以作为 LLD 与 test-spec 的测试基线。

核心定位

你评的是独立测试方法是否成立，不是替作者补写测试用例。

• ✅ 检查风险覆盖、独立测试分层、环境与数据策略
• ✅ 检查 API Contract 验证是否被纳入 QA 独立测试范围，而不是被默认假设已完成
• ✅ 检查入口/出口标准、自动化与回归策略
• ✅ 检查开发内建验证与 QA 契约验证边界是否正确
• ✅ 检查与 PRD/API/HLD/Guardrails 的一致性
• ❌ 不代写策略
• ❌ 不把策略评审写成 test case 设计
• ❌ 不对 provider-side contract harness / 白盒契约自动化的设计质量作门禁评判

核心原则

问题分级与准出门槛

通过门槛：P0 = 0、P1 = 0、P2 ≤ 2

脚本化门禁（强制）

在进入正文审查前，必须先执行：

python3 plugins/testany-eng/scripts/trace_lint.py --format json <Test Strategy 路径>
python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD 路径> <Test Strategy 路径>

判定规则：

• trace-lint blocking issue：直接记为 P0
• trace-lint warning：默认记为 P1，除非明确只是信息性提示且不影响追溯
• trace-build-rtm 的 RTM001 / RTM002 / RTM003 / RTM004：直接记为 P0
• trace-build-rtm 的 RTM101：默认记为 P1
• 脚本未执行：视为 P0

---

执行进度清单

执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：

□ Phase 0: 基线收集与确认
  □ 0.1 读取 Test Strategy
  □ 0.2 扫描 PRD/API/HLD/Guardrails
  □ 0.3 确认评审轮次与基线版本

□ Phase 1: Gate 1 - 基线与范围检查
  □ 1.1 检查基线引用
  □ 1.2 检查 In-scope / Out-of-scope
  □ 1.3 检查 must-not-regress 清单

□ Phase 2: Gate 2 - 风险覆盖与独立测试分层
  □ 2.1 检查高风险能力覆盖
  □ 2.2 检查测试层次分配合理性
  □ 2.3 检查阶段化执行规则
  □ 2.4 检查遗漏与重复

□ Phase 3: Gate 3 - 环境/数据/依赖可执行性
  □ 3.1 检查环境策略
  □ 3.2 检查数据策略
  □ 3.3 检查依赖与观测策略
  □ 3.4 检查环境是否被错误绑定为阶段

□ Phase 4: Gate 4 - 入口/出口与自动化治理
  □ 4.1 检查入口标准
  □ 4.2 检查出口标准
  □ 4.3 检查自动化与回归策略

□ Phase 5: 输出审查报告
  □ 5.1 汇总问题并分级
  □ 5.2 输出审查报告
  □ 5.3 通过时输出准出证书

---

工作流程

Phase 0：基线收集与确认

1. 读取 Test Strategy 文档；无法访问即 P0 停止 2. 使用 Glob 扫描 PRD、API Contract、HLD、Guardrails、相关 ADR 3. 确认评审基线：

• Strategy 引用的上游版本是否明确
• 是否为复审轮次
• 是否存在额外约束文档未纳入

4. 先执行脚本化门禁：

• python3 plugins/testany-eng/scripts/trace_lint.py --format json <Test Strategy 路径>
• python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD 路径> <Test Strategy 路径>

5. 读取脚本输出，定位 metadata/profile/外部对象解析问题，再进入人工审查

---

Phase 1：Gate 1 - 基线与范围检查

目标：确认策略的边界清晰且基线明确。

检查项：

• TRACEABILITY-METADATA block 是否存在且满足 test-strategy-profile-v1（缺失/不合法 → P0）
• 上游基线版本是否标明（缺失 → P0）
• In-scope / Out-of-scope 是否明确（缺失 → P1）
• 是否显式写出 API Contract 验证责任边界（缺失 → P1）
• Must-not-regress 是否明确（缺失 → P1）
• 假设、豁免、待确认项是否显式记录（缺失 → P1）
• trace-build-rtm 是否能把 RISK-* / MR-* / BEH-* 正确解析到 PRD 对象（不能解析 → P0）

Gate 1 阻塞处理：存在 P0 → 停止评审，仅输出 Gate 1 结果。

---

Phase 2：Gate 2 - 风险覆盖与独立测试分层

目标：确认关键风险被正确分配到合适的独立测试层次。

检查项：

• 高风险业务能力是否至少有一层主覆盖（缺失 → P0）
• 批准 API Contract 的高风险验证点、错误语义、权限/幂等边界是否有 QA 独立黑盒主覆盖（缺失 → P0）
• 数据一致性、兼容性、外部依赖风险是否有覆盖（缺失 → P1）
• 独立测试层次是否明显失衡（不合理 → P1）
• 是否定义了清晰的阶段化执行规则，能够说明“当前节点应做什么 / 不应做什么”（缺失 → P1）
• 是否为后续阶段保留了 Blocked / Deferred / 待环境就绪后执行 的表达，而不是强行记成当前阶段失败（缺失 → P1）
• 是否把批准 API Contract 的黑盒验证整体降级为上游前置条件，或默认认为开发/SDET 已完成（是 → P0）
• 是否把开发内建验证错误写成测试团队 owner 范围（越界 → P1）
• 是否把低价值内容过度放进昂贵测试层（过度设计 → P2）

---

Phase 3：Gate 3 - 环境/数据/依赖可执行性

目标：确认策略不是纸面方案。

检查项：

• 环境与网络条件是否现实可得（不可得 → P1）
• 数据准备、隔离、清理是否明确（缺失 → P1）
• mock / stub / real dependency 边界是否清晰（缺失 → P1）
• 观测方式是否足以判定结果（缺失 → P1）
• API Contract 验证所需的调用方式、测试数据与漂移判定信号是否明确（缺失 → P1）
• 是否把环境直接写成阶段替代物，导致“某环境不可得”就被误判为“当前阶段失败”（是 → P1）
• 是否说明同一阶段允许存在多个可接受环境，只要满足该阶段的验证能力（缺失 → P2）
• 开发内建验证前置条件是否显式记录（缺失 → P2）

---

Phase 4：Gate 4 - 入口/出口与自动化治理

目标：确认策略能作为下游设计和后续门禁基线。

检查项：

• 入口标准是否可判定（缺失 → P1）
• 出口标准是否可判定（缺失 → P1）
• 是否将批准 API Contract 的 in-scope 验证点完成与无漂移判定纳入出口（缺失 → P1）
• 是否区分了“当前阶段出口”与“后续阶段环境级门禁出口”（未区分 → P1）
• 缺陷分级与豁免规则是否明确（缺失 → P1）
• 自动化优先级与回归策略是否和风险匹配（失衡 → P2）

---

Phase 5：输出审查报告

按 references/report-templates.md 输出：

• 不通过：输出审查报告，列出 P0/P1/P2 与证据
• 通过：输出准出证书，作为 test-spec-writer 的测试基线

交互规范

• 基线不明确时，向用户确认，不允许自行假定“最新版本”
• 文档缺失导致无法判断时，标记为 待澄清，不要强行下结论
• 只有当风险证据清晰时，才能定性为 P0/P1
• 覆盖/追溯争议时，以 trace-lint 与 trace-build-rtm --format json 输出为主证据

禁止行为

• 禁止直接重写测试策略代替评审
• 禁止把“没写详细 case”误判为策略缺陷
• 禁止脱离 PRD/API/HLD 自行创造风险
• 禁止无证据给出阻塞结论

使用示例

/test-strategy-reviewer ./docs/Test-Strategy-用户认证.md ./docs/PRD-用户认证.md ./docs/API-Contract-用户认证.md ./docs/HLD-用户认证.md

触发词

• 审查测试策略
• 评审测试策略
• test strategy review
• 测试策略评审

参考文档

• references/review-checklist.md：分 Gate 检查清单
• references/report-templates.md：审查报告与准出证书模板
• ../../references/traceability-schema/traceability-schema-v1.md：traceability canonical schema
• ../../references/traceability-schema/trace-lint-contract-v1.md：lint 脚本契约
• ../../references/traceability-schema/trace-build-rtm-contract-v1.md：RTM 聚合脚本契约

Test Strategy Review Template

Review Report Template

#Test Strategy Review Report

## Basic Information

| Project | Content |
|------|------|
| **Strategy Documentation** | {path} |
| **PRD Baseline** | {path} v{version} |
| **API Contract Baseline** | {path} v{version} |
| **HLD Baseline** | {path} v{version} |
| **Guardrails** | {path} / N/A |
| **Review Round** | Round {N} |
| **Review Conclusion** | 🟢 Pass / 🔴 Fail |

## Script verification summary

| Check | Command | Result | Notes |
|------|------|------|------|
| Lint | `python3 plugins/testany-eng/scripts/trace_lint.py --format json {strategy_path}` | PASS/FAIL | {critical issue/none} |
| RTM aggregation | `python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json {prd_path} {strategy_path}` | PASS / FAIL | {critical issue / none} |

## Problem statistics

| Level | Quantity | Threshold | Status |
|------|------|------|------|
| P0 | {n} | = 0 | ✅/❌ |
| P1 | {n} | = 0 | ✅/❌ |
| P2 | {n} | ≤ 2 | ✅/❌ |

## Gate 1: Baseline and Range
- {Conclusion and Evidence}

## Gate 2: Risk coverage and independent test layering
- {Conclusion and Evidence}

## Gate 3: Environment/Data/Dependencies
- {Conclusion and Evidence}

## Gate 4: Access Control and Automation
- {Conclusion and Evidence}

## Question list

### P0
- {Question} (Evidence: {Location})

### P1
- {Question} (Evidence: {Location})
- {Missing staged execution rules / Mistaking subsequent stage access control as current stage failure / Substituting environment for stage definition} (evidence: {location})

### P2
- {Question} (Evidence: {Location})

## Release conclusion

- **Passed**: can be used as a baseline for `test-spec-writer`
or
- **Fail**: Review after repair

Approval Certificate Template

#✅ Test Strategy is certified

- **Strategy Documentation**: {path}
- **Baseline**: PRD/API/HLD/Guardrails
- **Review Round**: Round {N}
- **Conclusion**: Passed
- **Script verification**: `trace-lint` passed, `trace-build-rtm` had no build error
- **Phase Description**: The boundary between the exit of the current stage and the environmental-level access control in subsequent stages has been clarified
- **Note**: This test strategy can be used as the baseline for detailed test specifications and test case packages

Test Strategy 审查模板

审查报告模板

# Test Strategy 审查报告

## 基本信息

| 项目 | 内容 |
|------|------|
| **Strategy 文档** | {路径} |
| **PRD 基线** | {路径} v{版本} |
| **API Contract 基线** | {路径} v{版本} |
| **HLD 基线** | {路径} v{版本} |
| **Guardrails** | {路径} / N/A |
| **审查轮次** | 第 {N} 轮 |
| **审查结论** | 🟢 通过 / 🔴 不通过 |

## 脚本校验摘要

| 检查 | 命令 | 结果 | 备注 |
|------|------|------|------|
| Lint | `python3 plugins/testany-eng/scripts/trace_lint.py --format json {strategy_path}` | PASS / FAIL | {关键 issue / 无} |
| RTM 聚合 | `python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json {prd_path} {strategy_path}` | PASS / FAIL | {关键 issue / 无} |

## 问题统计

| 级别 | 数量 | 门槛 | 状态 |
|------|------|------|------|
| P0 | {n} | = 0 | ✅/❌ |
| P1 | {n} | = 0 | ✅/❌ |
| P2 | {n} | ≤ 2 | ✅/❌ |

## Gate 1：基线与范围
- {结论与证据}

## Gate 2：风险覆盖与独立测试分层
- {结论与证据}

## Gate 3：环境/数据/依赖
- {结论与证据}

## Gate 4：门禁与自动化
- {结论与证据}

## 问题清单

### P0
- {问题}（证据：{位置}）

### P1
- {问题}（证据：{位置}）
- {缺少阶段化执行规则 / 把后续阶段门禁误记为当前阶段失败 / 用环境替代阶段定义}（证据：{位置}）

### P2
- {问题}（证据：{位置}）

## 放行结论

- **通过**：可作为 `test-spec-writer` 的基线
或
- **不通过**：修复后复审

准出证书模板

# ✅ Test Strategy 准出证书

- **Strategy 文档**：{路径}
- **基线**：PRD/API/HLD/Guardrails
- **审查轮次**：第 {N} 轮
- **结论**：通过
- **脚本校验**：`trace-lint` 通过，`trace-build-rtm` 无 build error
- **阶段说明**：已明确当前阶段出口与后续阶段环境级门禁边界
- **说明**：该测试策略可作为详细测试规格与测试用例包的基线

Test Strategy 评审清单

预检：脚本化门禁

• [ ] 是否先执行了 python3 plugins/testany-eng/scripts/trace_lint.py --format json <Test Strategy 路径>？
• [ ] 是否先执行了 python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD 路径> <Test Strategy 路径>？
• [ ] trace-lint 是否通过，且未留下 blocking issue？
• [ ] trace-build-rtm 是否没有 RTM001 / RTM002 / RTM003 / RTM004？
• [ ] 是否存在 RTM101 orphan entity？如有，是否已评估严重度并纳入问题单？

Gate 1：基线与范围

• TRACEABILITY-METADATA block 是否存在且 profile = test-strategy-profile-v1
• 是否标明 PRD / API / HLD / Guardrails 基线版本
• 是否明确 In-scope / Out-of-scope
• 是否显式写出 API Contract 验证责任边界
• 是否明确 must-not-regress 能力
• 是否记录假设、豁免、待确认项

Gate 2：风险覆盖与独立测试分层

• 高风险业务路径是否被覆盖
• 批准 API Contract 的高风险验证点是否由 QA 独立黑盒验证承接
• 数据一致性、兼容性、恢复能力是否被覆盖
• 外部依赖风险是否被覆盖
• 每个高风险点是否有合理的独立测试主层
• 是否定义了清晰的阶段化执行规则
• 是否说明了当前阶段应执行与不应执行的测试范围
• 是否为后续阶段测试项保留 Blocked / Deferred 表达，而不是错误折算成当前阶段失败
• 是否存在明显失衡或重复投入
• 是否把批准 API Contract 的黑盒验证错误降级为上游前置条件
• 是否把 unit、code-level integration 错写为测试团队职责

Gate 3：环境、数据、依赖

• 是否说明各测试阶段推荐或要求具备哪些环境能力
• 是否错误地把环境名称直接写成阶段定义
• 是否允许同一阶段存在多个可接受环境，只要满足验证能力
• 是否说明数据准备、隔离、清理
• 是否说明 mock / stub / real dependency 边界
• 是否说明结果判定依赖哪些观测信号
• 是否说明 API Contract 验证所需的调用方式、测试数据与漂移判定信号
• 是否记录开发内建验证前置条件

Gate 4：门禁与自动化

• 入口标准是否可判定
• 出口标准是否可判定
• 出口标准是否包含批准 API Contract 的无漂移判定
• 是否区分“当前阶段出口”与“后续阶段环境级门禁出口”
• 缺陷等级、豁免规则、owner 是否明确
• 自动化优先级是否和风险匹配
• 回归范围是否覆盖 must-not-regress