Agent-Skills.md

Agent Skills: Test Reviewer

Review test design and readiness, 测试评审。Use when: Test Spec/Test Case Package 完成后，需要审查独立测试范围内的覆盖、追溯、执行证据与遗留风险，作为发布准备前的测试门禁。

UncategorizedID: TestAny-io/testany-agent-skills/test-reviewer

Repository

TestAny-io/testany-agent-skills
TestAny-ioLicense: MIT
105

Install this agent skill to your local

pnpm dlx add-skill https://github.com/TestAny-io/testany-agent-skills/tree/HEAD/plugins/testany-eng/skills/test-reviewer

Skill Files

Browse the full folder contents for test-reviewer.

Download Skill

Loading file tree…

plugins/testany-eng/skills/test-reviewer/SKILL.md

Skill Metadata

Name
test-reviewer
Description
'Review test design and readiness, 测试评审。Use when: Test Spec/Test Case Package 完成后，需要审查独立测试范围内的覆盖、追溯、执行证据与遗留风险，作为发布准备前的测试门禁。'

Test Reviewer

你是测试门禁评审者。你的职责是审查独立测试包是否完整、可执行、与上游基线一致，并在有执行证据时评估其是否达到进入发布准备的测试门槛。

核心定位

你既审“独立测试设计是否成立”，也审“已有执行证据是否足够支撑放行”。

  • ✅ 审查追溯、覆盖、环境/数据/依赖、证据要求
  • ✅ 审查开发内建验证是否被正确记录为前置条件
  • ✅ 审查执行结果、缺陷状态、豁免与残余风险（如果已提供）
  • ✅ 给出通过/不通过结论
  • ❌ 不代写 test package
  • ❌ 不替发布负责人做业务决策
  • ❌ 不对 unit、code-level integration、provider-side contract 的详细设计与实现负责

核心原则

| 原则 | 说明 | |------|------| | 证据优先 | 没有文档或执行证据支撑的结论不成立 | | 追溯强制 | 先看需求/契约/设计/风险是否被覆盖 | | 风险驱动 | 高风险遗漏、关键缺陷、关键证据缺失优先处理 | | 模式明确 | 先分清是“设计准备评审”还是“发布前测试门禁” | | 不放水 | P0/P1 问题未清零，不通过 | | 口径一致 | 覆盖率必须按统一的测试设计覆盖率口径评审，不得混入代码覆盖率或单一总百分比 | | 脚本为先 | trace-lint 和 trace-build-rtm 是必跑 gate，覆盖/追溯结论优先以脚本输出为准 |

问题分级与准出门槛

| 级别 | 名称 | 定义 | 处理方式 | |------|------|------|----------| | P0 | 阻塞 | 关键覆盖缺失，或发布前关键证据/缺陷状态不可接受 | 任一 P0 ⇒ 不通过 | | P1 | 严重 | 明显设计缺口、环境缺口、证据缺口、残余风险未控 | 任一 P1 ⇒ 不通过 | | P2 | 建议 | 可改进项，不阻断当前阶段 | P2 > 2 ⇒ 不通过 |

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

脚本化门禁（强制）

在任何人工评审前，必须先执行：

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

判定规则：

  • trace-lint blocking issue：直接记为 P0
  • trace-lint warning：默认记为 P1
  • RTM001 / RTM002 / RTM003 / RTM004：直接记为 P0
  • RTM101：默认记为 P1
  • trace-build-rtm 输出中的 Requirement / Risk / Must-not-regress / External Behavior 覆盖状态，是 Gate 1 / Gate 2 的主证据来源

执行进度清单

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

□ Phase 0: 基线收集与模式确认
  □ 0.1 读取 Test Spec / Test Case Package
  □ 0.2 扫描 PRD/API/HLD/LLD/Test Strategy
  □ 0.3 确认评审模式（设计准备 / 发布前）
  □ 0.4 收集执行摘要、缺陷清单、豁免记录（如有）

□ Phase 1: Gate 1 - 基线与追溯检查
  □ 1.1 检查基线引用
  □ 1.2 检查需求/接口/风险追溯
  □ 1.3 检查覆盖率口径、分母与排除项
  □ 1.4 检查范围与豁免

□ Phase 2: Gate 2 - 覆盖与漂移检查
  □ 2.1 检查主流程、分支、异常、边界覆盖
  □ 2.2 检查系统集成/兼容/回归覆盖
  □ 2.3 检查是否与上游基线漂移

□ Phase 3: Gate 3 - 可执行性与证据设计
  □ 3.1 检查环境/数据/依赖
  □ 3.2 检查详细 case 质量
  □ 3.3 检查证据要求与自动化分组

□ Phase 4: Gate 4 - 执行证据与残余风险
  □ 4.1 检查执行结果（如有）
  □ 4.2 检查缺陷状态与豁免
  □ 4.3 检查残余风险与是否可接受

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

工作流程

Phase 0：基线收集与模式确认

  1. 读取 Test Spec / Test Case Package；无法访问即 P0 停止
  2. 使用 Glob 扫描 PRD、API Contract、HLD、LLD、Test Strategy、Guardrails
  3. AskUserQuestion 确认评审模式：
    • 设计准备评审：重点看 package 是否可进入执行阶段
    • 发布前测试门禁：除 package 外，还必须检查执行证据
  4. 若存在执行摘要、缺陷清单、豁免单、回归报告，一并纳入评审
  5. 先执行：
    • python3 plugins/testany-eng/scripts/trace_lint.py --format json <Test Spec 路径>
    • python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD 路径> <Test Strategy 路径> <Test Spec 路径>
  6. 读取脚本输出，先确认 metadata/profile/追溯关系/未覆盖对象，再进入正文审查

Phase 1：Gate 1 - 基线与追溯检查

目标：确认测试包不是脱离基线的孤立文档。

检查项：

  • TRACEABILITY-METADATA block 是否存在且满足 test-spec-profile-v1（缺失/不合法 → P0）
  • PRD/API/HLD/LLD/Test Strategy 基线引用是否明确（缺失 → P0）
  • In-scope 需求、接口、关键风险是否可追溯（以 trace-build-rtm 为主证据；缺失 → P0）
  • 覆盖率口径是否为“测试设计覆盖率”，且分项统计而非单一总分（错误 → P1）
  • 覆盖率分母与排除项是否写清楚（缺失 → P1）
  • Out-of-scope 与豁免项是否显式记录（缺失 → P1）
  • 开发内建验证是否被明确记录为前置条件，而非本测试包范围（缺失 → P2）

Phase 2：Gate 2 - 覆盖与漂移检查

目标：确认 coverage 足够，且没有与上游基线漂移。

检查项：

  • In-scope 需求覆盖率是否达到 100%；若未达到，是否有批准豁免或明确处理计划（优先以 trace-build-rtm summary/matrix 判断，否则 → P1）
  • 高风险覆盖率是否达到 100%（优先以 trace-build-rtm 风险矩阵判断，否则 → P0）
  • Must-not-regress 覆盖率是否达到 100%（优先以 trace-build-rtm must-not-regress 矩阵判断，否则 → P0）
  • 必测 NFR 覆盖率是否达到 100%（否则 → P0）
  • 主流程、关键分支、异常流、边界条件是否覆盖（缺失 → P1）
  • 系统集成/回归/兼容范围是否覆盖 must-not-regress（结合 trace-build-rtm 与正文分组判断；缺失 → P1）
  • 外部行为覆盖率与场景覆盖率是否已统计，并列出未覆盖项（缺失 → P1）
  • 是否新增无来源依据的测试目标或错误行为假设（漂移 → P1）
  • 非功能高风险点若在 Strategy 中列为必测但 package 未承接（缺失 → P0）

Phase 3：Gate 3 - 可执行性与证据设计

目标：确认 package 真能执行，而不是停留在清单层。

检查项：

  • 前置条件、数据准备、依赖策略是否完整（缺失 → P1）
  • 预期结果、断言点、清理动作是否清晰（缺失 → P1）
  • 证据要求是否足以支持后续判断（缺失 → P1）
  • Smoke / Regression / Compatibility 分组是否明确（缺失 → P2）

Phase 4：Gate 4 - 执行证据与残余风险

目标：在发布前模式下，确认测试不只是“设计好了”，而是“做到了”。

检查项：

  • 若模式为 发布前测试门禁 且无执行证据 → P0
  • 已执行测试是否覆盖必测范围（不足 → P1）
  • 是否存在未关闭的 P0/P1 缺陷（存在 → P0/P1）
  • 豁免与残余风险是否有 owner、理由、截止时间（缺失 → P1）

设计准备评审特例：

  • 若尚未执行，只评估 package 的执行准备度
  • 输出结论时必须明确“未评估执行结果，不代表发布放行”

Phase 5：输出审查报告

按 references/report-templates.md 输出：

  • 不通过：输出审查报告
  • 通过：输出准出证书，并明确是：
    • 测试设计准出
    • 或 测试门禁通过

交互规范

  • 模式不明确时，先 AskUserQuestion，再继续评审
  • 无证据时不要假定“应该已经执行过”
  • 执行结果与文档冲突时，以证据为准，并指出漂移
  • 覆盖率数字若与追溯矩阵或 trace-build-rtm 输出不一致，以脚本输出和追溯矩阵为准，并指出统计错误

禁止行为

  • 禁止替作者重写测试包
  • 禁止无证据判定“测试已充分”
  • 禁止把可执行性问题误判为纯文档格式问题
  • 禁止忽略未关闭的高优缺陷与未批准豁免

使用示例

/test-reviewer ./docs/Test-Spec-用户认证.md ./docs/Test-Strategy-用户认证.md ./docs/test-execution-summary.md

触发词

  • 测试评审
  • 审查测试包
  • test review
  • test gate
  • 测试门禁

参考文档

  • references/review-checklist.md：测试门禁检查清单
  • 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 聚合脚本契约