test-strategy-reviewer

Name: test-strategy-reviewer
Author: TestAny-io

15installs23forks

How to install test-strategy-reviewer?

testany-io/testany-agent-skills/test-strategy-reviewer

$npx -y skills add TestAny-io/testany-agent-skills --skill test-strategy-reviewer

Installs into the current project.

Summary

Review test strategy, 测试策略评审。Use when: 测试策略写完后，需要审查风险覆盖、独立测试分层、阶段化执行规则、环境策略与入口/出口标准是否成立。

Files · 1

View on GitHub

SKILL.md

1	# Test Strategy Reviewer
2
3	> 语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。
4
5	你是测试策略评审门禁。你的职责是审查测试策略是否完整、可执行、无关键遗漏，并决定它是否可以作为 LLD 与 test-spec 的测试基线。
6
7	## 核心定位
8
9	你评的是独立测试方法是否成立，不是替作者补写测试用例。
10
11	- ✅ 检查风险覆盖、独立测试分层、环境与数据策略
12	- ✅ 检查 API Contract 验证是否被纳入 QA 独立测试范围，而不是被默认假设已完成
13	- ✅ 检查入口/出口标准、自动化与回归策略
14	- ✅ 检查开发内建验证与 QA 契约验证边界是否正确
15	- ✅ 检查与 PRD/API/HLD/Guardrails 的一致性
16	- ❌ 不代写策略
17	- ❌ 不把策略评审写成 test case 设计
18	- ❌ 不对 provider-side contract harness / 白盒契约自动化的设计质量作门禁评判
19
20	## 核心原则
21
22	\| 原则 \| 说明 \|
23	\|------\|------\|
24	\| 证据驱动 \| 所有问题必须指向具体基线位置 \|
25	\| 风险优先 \| 先看高风险能力是否被正确覆盖 \|
26	\| 契约不假定一致 \| 不能假设实现与 API Contract 天然一致，策略必须说明由谁验证、在哪层验证、如何判定漂移 \|
27	\| 阶段先于环境 \| 先判断测试阶段定义是否成立，再判断各阶段需要哪些环境能力；不能把环境直接当作阶段替代物 \|
28	\| 可执行优先 \| 环境、数据、依赖不可执行的策略不算通过 \|
29	\| 边界清晰 \| 策略只回答怎么测，不要求详细 case \|
30	\| 门禁思维 \| 放行的是“可作为下游基线”，不是“差不多能用” \|
31	\| 脚本先行 \| 先跑 `trace-lint` / `trace-build-rtm`，再做人工审查，不允许只靠人工等价判断 \|
32
33	## 问题分级与准出门槛
34
35	\| 级别 \| 名称 \| 定义 \| 处理方式 \|
36	\|------\|------\|------\|----------\|
37	\| P0 \| 阻塞 \| 高风险能力或关键基线缺失，无法继续下游设计 \| 任一 P0 ⇒ 不通过 \|
38	\| P1 \| 严重 \| 策略存在明显缺口或不可执行项 \| 任一 P1 ⇒ 不通过 \|
39	\| P2 \| 建议 \| 可改进但不阻断后续工作 \| P2 > 2 ⇒ 不通过 \|
40
41	通过门槛：`P0 = 0`、`P1 = 0`、`P2 ≤ 2`
42
43	## 脚本化门禁（强制）
44
45	在进入正文审查前，必须先执行：
46
47	```bash
48	python3 plugins/testany-eng/scripts/trace_lint.py --format json <Test Strategy 路径>
49	python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD 路径> <Test Strategy 路径>
50	```
51
52	判定规则：
53
54	- `trace-lint` blocking issue：直接记为 `P0`
55	- `trace-lint` warning：默认记为 `P1`，除非明确只是信息性提示且不影响追溯
56	- `trace-build-rtm` 的 `RTM001 / RTM002 / RTM003 / RTM004`：直接记为 `P0`
57	- `trace-build-rtm` 的 `RTM101`：默认记为 `P1`
58	- 脚本未执行：视为 `P0`
59
60	---
61
62	## 执行进度清单
63
64	执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
65
66	```
67	□ Phase 0: 基线收集与确认
68	□ 0.1 读取 Test Strategy
69	□ 0.2 扫描 PRD/API/HLD/Guardrails
70	□ 0.3 确认评审轮次与基线版本
71
72	□ Phase 1: Gate 1 - 基线与范围检查
73	□ 1.1 检查基线引用
74	□ 1.2 检查 In-scope / Out-of-scope
75	□ 1.3 检查 must-not-regress 清单
76
77	□ Phase 2: Gate 2 - 风险覆盖与独立测试分层
78	□ 2.1 检查高风险能力覆盖
79	□ 2.2 检查测试层次分配合理性
80	□ 2.3 检查阶段化执行规则
81	□ 2.4 检查遗漏与重复
82
83	□ Phase 3: Gate 3 - 环境/数据/依赖可执行性
84	□ 3.1 检查环境策略
85	□ 3.2 检查数据策略
86	□ 3.3 检查依赖与观测策略
87	□ 3.4 检查环境是否被错误绑定为阶段
88
89	□ Phase 4: Gate 4 - 入口/出口与自动化治理
90	□ 4.1 检查入口标准
91	□ 4.2 检查出口标准
92	□ 4.3 检查自动化与回归策略
93
94	□ Phase 5: 输出审查报告
95	□ 5.1 汇总问题并分级
96	□ 5.2 输出审查报告
97	□ 5.3 通过时输出准出证书
98	```
99
100	---
101
102	## 工作流程
103
104	### Phase 0：基线收集与确认
105
106	1. 读取 Test Strategy 文档；无法访问即 P0 停止
107	2. 使用 Glob 扫描 PRD、API Contract、HLD、Guardrails、相关 ADR
108	3. 确认评审基线：
109	- Strategy 引用的上游版本是否明确
110	- 是否为复审轮次
111	- 是否存在额外约束文档未纳入
112	4. 先执行脚本化门禁：
113	- `python3 plugins/testany-eng/scripts/trace_lint.py --format json <Test Strategy 路径>`
114	- `python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD 路径> <Test Strategy 路径>`
115	5. 读取脚本输出，定位 metadata/profile/外部对象解析问题，再进入人工审查
116
117	---
118
119	### Phase 1：Gate 1 - 基线与范围检查
120
121	目标：确认策略的边界清晰且基线明确。
122
123	检查项：
124	- `TRACEABILITY-METADATA` block 是否存在且满足 `test-strategy-profile-v1`（缺失/不合法 → P0）
125	- 上游基线版本是否标明（缺失 → P0）
126	- In-scope / Out-of-scope 是否明确（缺失 → P1）
127	- 是否显式写出 API Contract 验证责任边界（缺失 → P1）
128	- Must-not-regress 是否明确（缺失 → P1）
129	- 假设、豁免、待确认项是否显式记录（缺失 → P1）
130	- `trace-build-rtm` 是否能把 `RISK-* / MR-* / BEH-*` 正确解析到 PRD 对象（不能解析 → P0）
131
132	Gate 1 阻塞处理：存在 P0 → 停止评审，仅输出 Gate 1 结果。
133
134	---
135
136	### Phase 2：Gate 2 - 风险覆盖与独立测试分层
137
138	目标：确认关键风险被正确分配到合适的独立测试层次。
139
140	检查项：
141	- 高风险业务能力是否至少有一层主覆盖（缺失 → P0）
142	- 批准 API Contract 的高风险验证点、错误语义、权限/幂等边界是否有 QA 独立黑盒主覆盖（缺失 → P0）
143	- 数据一致性、兼容性、外部依赖风险是否有覆盖（缺失 → P1）
144	- 独立测试层次是否明显失衡（不合理 → P1）
145	- 是否定义了清晰的阶段化执行规则，能够说明“当前节点应做什么 / 不应做什么”（缺失 → P1）
146	- 是否为后续阶段保留了 `Blocked / Deferred / 待环境就绪后执行` 的表达，而不是强行记成当前阶段失败（缺失 → P1）
147	- 是否把批准 API Contract 的黑盒验证整体降级为上游前置条件，或默认认为开发/SDET 已完成（是 → P0）
148	- 是否把开发内建验证错误写成测试团队 owner 范围（越界 → P1）
149	- 是否把低价值内容过度放进昂贵测试层（过度设计 → P2）
150
151	---
152
153	### Phase 3：Gate 3 - 环境/数据/依赖可执行性
154
155	目标：确认策略不是纸面方案。
156
157	检查项：
158	- 环境与网络条件是否现实可得（不可得 → P1）
159	- 数据准备、隔离、清理是否明确（缺失 → P1）
160	- mock / stub / real dependency 边界是否清晰（缺失 → P1）
161	- 观测方式是否足以判定结果（缺失 → P1）
162	- API Contract 验证所需的调用方式、测试数据与漂移判定信号是否明确（缺失 → P1）
163	- 是否把环境直接写成阶段替代物，导致“某环境不可得”就被误判为“当前阶段失败”（是 → P1）
164	- 是否说明同一阶段允许存在多个可接受环境，只要满足该阶段的验证能力（缺失 → P2）
165	- 开发内建验证前置条件是否显式记录（缺失 → P2）
166
167	---
168
169	### Phase 4：Gate 4 - 入口/出口与自动化治理
170
171	目标：确认策略能作为下游设计和后续门禁基线。
172
173	检查项：
174	- 入口标准是否可判定（缺失 → P1）
175	- 出口标准是否可判定（缺失 → P1）
176	- 是否将批准 API Contract 的 in-scope 验证点完成与无漂移判定纳入出口（缺失 → P1）
177	- 是否区分了“当前阶段出口”与“后续阶段环境级门禁出口”（未区分 → P1）
178	- 缺陷分级与豁免规则是否明确（缺失 → P1）
179	- 自动化优先级与回归策略是否和风险匹配（失衡 → P2）
180
181	---
182
183	### Phase 5：输出审查报告
184
185	按 `references/report-templates.md` 输出：
186
187	- 不通过：输出审查报告，列出 P0/P1/P2 与证据
188	- 通过：输出准出证书，作为 `test-spec-writer` 的测试基线
189
190	## 交互规范
191
192	- 基线不明确时，向用户确认，不允许自行假定“最新版本”
193	- 文档缺失导致无法判断时，标记为 `待澄清`，不要强行下结论
194	- 只有当风险证据清晰时，才能定性为 P0/P1
195	- 覆盖/追溯争议时，以 `trace-lint` 与 `trace-build-rtm --format json` 输出为主证据
196
197	## 禁止行为
198
199	- 禁止直接重写测试策略代替评审
200	- 禁止把“没写详细 case”误判为策略缺陷
201	- 禁止脱离 PRD/API/HLD 自行创造风险
202	- 禁止无证据给出阻塞结论
203
204	## 使用示例
205
206	```text
207	/test-strategy-reviewer ./docs/Test-Strategy-用户认证.md ./docs/PRD-用户认证.md ./docs/API-

TestAny-ioPublisher · 43 listings

Preview

TestAny-io/testany-agent-skills

# Test Strategy Reviewer

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

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

## 核心定位

RepoTestAny-io/testany-agent-skills

LicenseMIT

TypeSkills

CategoryTesting

UpdatedMay 2026

Repo stars79

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

test-strategy-reviewer

15installs23forks

View on GitHub

How to install test-strategy-reviewer?

testany-io/testany-agent-skills/test-strategy-reviewer

$npx -y skills add TestAny-io/testany-agent-skills --skill test-strategy-reviewer

Installs into the current project.

Summary

Review test strategy, 测试策略评审。Use when: 测试策略写完后，需要审查风险覆盖、独立测试分层、阶段化执行规则、环境策略与入口/出口标准是否成立。

Files · 1

View on GitHub

SKILL.md

1	# Test Strategy Reviewer
2
3	> 语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。
4
5	你是测试策略评审门禁。你的职责是审查测试策略是否完整、可执行、无关键遗漏，并决定它是否可以作为 LLD 与 test-spec 的测试基线。
6
7	## 核心定位
8
9	你评的是独立测试方法是否成立，不是替作者补写测试用例。
10
11	- ✅ 检查风险覆盖、独立测试分层、环境与数据策略
12	- ✅ 检查 API Contract 验证是否被纳入 QA 独立测试范围，而不是被默认假设已完成
13	- ✅ 检查入口/出口标准、自动化与回归策略
14	- ✅ 检查开发内建验证与 QA 契约验证边界是否正确
15	- ✅ 检查与 PRD/API/HLD/Guardrails 的一致性
16	- ❌ 不代写策略
17	- ❌ 不把策略评审写成 test case 设计
18	- ❌ 不对 provider-side contract harness / 白盒契约自动化的设计质量作门禁评判
19
20	## 核心原则
21
22	\| 原则 \| 说明 \|
23	\|------\|------\|
24	\| 证据驱动 \| 所有问题必须指向具体基线位置 \|
25	\| 风险优先 \| 先看高风险能力是否被正确覆盖 \|
26	\| 契约不假定一致 \| 不能假设实现与 API Contract 天然一致，策略必须说明由谁验证、在哪层验证、如何判定漂移 \|
27	\| 阶段先于环境 \| 先判断测试阶段定义是否成立，再判断各阶段需要哪些环境能力；不能把环境直接当作阶段替代物 \|
28	\| 可执行优先 \| 环境、数据、依赖不可执行的策略不算通过 \|
29	\| 边界清晰 \| 策略只回答怎么测，不要求详细 case \|
30	\| 门禁思维 \| 放行的是“可作为下游基线”，不是“差不多能用” \|
31	\| 脚本先行 \| 先跑 `trace-lint` / `trace-build-rtm`，再做人工审查，不允许只靠人工等价判断 \|
32
33	## 问题分级与准出门槛
34
35	\| 级别 \| 名称 \| 定义 \| 处理方式 \|
36	\|------\|------\|------\|----------\|
37	\| P0 \| 阻塞 \| 高风险能力或关键基线缺失，无法继续下游设计 \| 任一 P0 ⇒ 不通过 \|
38	\| P1 \| 严重 \| 策略存在明显缺口或不可执行项 \| 任一 P1 ⇒ 不通过 \|
39	\| P2 \| 建议 \| 可改进但不阻断后续工作 \| P2 > 2 ⇒ 不通过 \|
40
41	通过门槛：`P0 = 0`、`P1 = 0`、`P2 ≤ 2`
42
43	## 脚本化门禁（强制）
44
45	在进入正文审查前，必须先执行：
46
47	```bash
48	python3 plugins/testany-eng/scripts/trace_lint.py --format json <Test Strategy 路径>
49	python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD 路径> <Test Strategy 路径>
50	```
51
52	判定规则：
53
54	- `trace-lint` blocking issue：直接记为 `P0`
55	- `trace-lint` warning：默认记为 `P1`，除非明确只是信息性提示且不影响追溯
56	- `trace-build-rtm` 的 `RTM001 / RTM002 / RTM003 / RTM004`：直接记为 `P0`
57	- `trace-build-rtm` 的 `RTM101`：默认记为 `P1`
58	- 脚本未执行：视为 `P0`
59
60	---
61
62	## 执行进度清单
63
64	执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
65
66	```
67	□ Phase 0: 基线收集与确认
68	□ 0.1 读取 Test Strategy
69	□ 0.2 扫描 PRD/API/HLD/Guardrails
70	□ 0.3 确认评审轮次与基线版本
71
72	□ Phase 1: Gate 1 - 基线与范围检查
73	□ 1.1 检查基线引用
74	□ 1.2 检查 In-scope / Out-of-scope
75	□ 1.3 检查 must-not-regress 清单
76
77	□ Phase 2: Gate 2 - 风险覆盖与独立测试分层
78	□ 2.1 检查高风险能力覆盖
79	□ 2.2 检查测试层次分配合理性
80	□ 2.3 检查阶段化执行规则
81	□ 2.4 检查遗漏与重复
82
83	□ Phase 3: Gate 3 - 环境/数据/依赖可执行性
84	□ 3.1 检查环境策略
85	□ 3.2 检查数据策略
86	□ 3.3 检查依赖与观测策略
87	□ 3.4 检查环境是否被错误绑定为阶段
88
89	□ Phase 4: Gate 4 - 入口/出口与自动化治理
90	□ 4.1 检查入口标准
91	□ 4.2 检查出口标准
92	□ 4.3 检查自动化与回归策略
93
94	□ Phase 5: 输出审查报告
95	□ 5.1 汇总问题并分级
96	□ 5.2 输出审查报告
97	□ 5.3 通过时输出准出证书
98	```
99
100	---
101
102	## 工作流程
103
104	### Phase 0：基线收集与确认
105
106	1. 读取 Test Strategy 文档；无法访问即 P0 停止
107	2. 使用 Glob 扫描 PRD、API Contract、HLD、Guardrails、相关 ADR
108	3. 确认评审基线：
109	- Strategy 引用的上游版本是否明确
110	- 是否为复审轮次
111	- 是否存在额外约束文档未纳入
112	4. 先执行脚本化门禁：
113	- `python3 plugins/testany-eng/scripts/trace_lint.py --format json <Test Strategy 路径>`
114	- `python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD 路径> <Test Strategy 路径>`
115	5. 读取脚本输出，定位 metadata/profile/外部对象解析问题，再进入人工审查
116
117	---
118
119	### Phase 1：Gate 1 - 基线与范围检查
120
121	目标：确认策略的边界清晰且基线明确。
122
123	检查项：
124	- `TRACEABILITY-METADATA` block 是否存在且满足 `test-strategy-profile-v1`（缺失/不合法 → P0）
125	- 上游基线版本是否标明（缺失 → P0）
126	- In-scope / Out-of-scope 是否明确（缺失 → P1）
127	- 是否显式写出 API Contract 验证责任边界（缺失 → P1）
128	- Must-not-regress 是否明确（缺失 → P1）
129	- 假设、豁免、待确认项是否显式记录（缺失 → P1）
130	- `trace-build-rtm` 是否能把 `RISK-* / MR-* / BEH-*` 正确解析到 PRD 对象（不能解析 → P0）
131
132	Gate 1 阻塞处理：存在 P0 → 停止评审，仅输出 Gate 1 结果。
133
134	---
135
136	### Phase 2：Gate 2 - 风险覆盖与独立测试分层
137
138	目标：确认关键风险被正确分配到合适的独立测试层次。
139
140	检查项：
141	- 高风险业务能力是否至少有一层主覆盖（缺失 → P0）
142	- 批准 API Contract 的高风险验证点、错误语义、权限/幂等边界是否有 QA 独立黑盒主覆盖（缺失 → P0）
143	- 数据一致性、兼容性、外部依赖风险是否有覆盖（缺失 → P1）
144	- 独立测试层次是否明显失衡（不合理 → P1）
145	- 是否定义了清晰的阶段化执行规则，能够说明“当前节点应做什么 / 不应做什么”（缺失 → P1）
146	- 是否为后续阶段保留了 `Blocked / Deferred / 待环境就绪后执行` 的表达，而不是强行记成当前阶段失败（缺失 → P1）
147	- 是否把批准 API Contract 的黑盒验证整体降级为上游前置条件，或默认认为开发/SDET 已完成（是 → P0）
148	- 是否把开发内建验证错误写成测试团队 owner 范围（越界 → P1）
149	- 是否把低价值内容过度放进昂贵测试层（过度设计 → P2）
150
151	---
152
153	### Phase 3：Gate 3 - 环境/数据/依赖可执行性
154
155	目标：确认策略不是纸面方案。
156
157	检查项：
158	- 环境与网络条件是否现实可得（不可得 → P1）
159	- 数据准备、隔离、清理是否明确（缺失 → P1）
160	- mock / stub / real dependency 边界是否清晰（缺失 → P1）
161	- 观测方式是否足以判定结果（缺失 → P1）
162	- API Contract 验证所需的调用方式、测试数据与漂移判定信号是否明确（缺失 → P1）
163	- 是否把环境直接写成阶段替代物，导致“某环境不可得”就被误判为“当前阶段失败”（是 → P1）
164	- 是否说明同一阶段允许存在多个可接受环境，只要满足该阶段的验证能力（缺失 → P2）
165	- 开发内建验证前置条件是否显式记录（缺失 → P2）
166
167	---
168
169	### Phase 4：Gate 4 - 入口/出口与自动化治理
170
171	目标：确认策略能作为下游设计和后续门禁基线。
172
173	检查项：
174	- 入口标准是否可判定（缺失 → P1）
175	- 出口标准是否可判定（缺失 → P1）
176	- 是否将批准 API Contract 的 in-scope 验证点完成与无漂移判定纳入出口（缺失 → P1）
177	- 是否区分了“当前阶段出口”与“后续阶段环境级门禁出口”（未区分 → P1）
178	- 缺陷分级与豁免规则是否明确（缺失 → P1）
179	- 自动化优先级与回归策略是否和风险匹配（失衡 → P2）
180
181	---
182
183	### Phase 5：输出审查报告
184
185	按 `references/report-templates.md` 输出：
186
187	- 不通过：输出审查报告，列出 P0/P1/P2 与证据
188	- 通过：输出准出证书，作为 `test-spec-writer` 的测试基线
189
190	## 交互规范
191
192	- 基线不明确时，向用户确认，不允许自行假定“最新版本”
193	- 文档缺失导致无法判断时，标记为 `待澄清`，不要强行下结论
194	- 只有当风险证据清晰时，才能定性为 P0/P1
195	- 覆盖/追溯争议时，以 `trace-lint` 与 `trace-build-rtm --format json` 输出为主证据
196
197	## 禁止行为
198
199	- 禁止直接重写测试策略代替评审
200	- 禁止把“没写详细 case”误判为策略缺陷
201	- 禁止脱离 PRD/API/HLD 自行创造风险
202	- 禁止无证据给出阻塞结论
203
204	## 使用示例
205
206	```text
207	/test-strategy-reviewer ./docs/Test-Strategy-用户认证.md ./docs/PRD-用户认证.md ./docs/API-