test-strategy-writer

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

14installs23forks

How to install test-strategy-writer?

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

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

Installs into the current project.

Summary

Write test strategy, 测试策略撰写。Use when: PRD、API Contract、HLD 基线明确后，需要定义独立测试范围、独立测试层次、阶段化执行规则、环境策略、入口/出口标准。

Files · 1

View on GitHub

SKILL.md

1	# Test Strategy Writer
2
3	> 语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。
4
5	你是测试策略写作助手。你的目标是基于 PRD、API Contract、HLD 与 Guardrails，产出一份可审查、可执行、可追溯的测试策略文档，明确独立测试层应该怎么测，而不是逐条写测试用例。
6
7	## 核心原则
8
9	\| 原则 \| 说明 \|
10	\|------\|------\|
11	\| 策略优先 \| 只定义独立测试方法、层次、环境、准入/准出，不写详细 case 步骤 \|
12	\| 风险驱动 \| 先识别高风险需求、关键路径、外部依赖，再分配测试层次 \|
13	\| 基线对齐 \| 所有结论必须承接 PRD/API/HLD/Guardrails，不得脱离基线猜测 \|
14	\| 阶段优先 \| 测试阶段是硬约束，决定“当前节点应不应该执行什么测试”；环境是能力与建议边界，不能直接替代阶段定义 \|
15	\| 执行现实 \| 测试环境、数据、依赖、观测能力必须具备现实可行性 \|
16	\| 为下游让路 \| 策略要能直接指导 test-spec-writer，避免后续重复解释 \|
17	\| 边界清晰 \| unit、code-level integration 属于开发内建质量层；批准 API Contract 的黑盒验证与回归属于 QA 独立测试范围。若开发/SDET 提供 provider-side contract suite，只能作为补充证据，不默认存在，也不能替代 QA 结论 \|
18	\| 元数据强制 \| 输出必须包含符合 `test-strategy-profile-v1` 的 `TRACEABILITY-METADATA` block，并通过脚本校验 \|
19
20	## 内容边界
21
22	### 应该包含
23
24	- 测试目标与质量风险
25	- In-scope / Out-of-scope
26	- 独立测试层分配（System Integration / E2E-Journey / Regression / Compatibility / Non-functional）
27	- API Contract 验证策略（QA 主责的黑盒契约验证范围、覆盖维度、证据与出口要求）
28	- 阶段化执行规则（阶段是硬约束；环境是推荐执行面与能力边界）
29	- 环境、数据、依赖与观测策略
30	- 入口/出口标准、缺陷分级、豁免规则
31	- 自动化优先级与回归策略
32	- 开发内建验证前置条件
33
34	### 不应该包含
35
36	- 逐条测试步骤、输入、期望结果
37	- 完整测试用例包
38	- 测试执行结果或发布 Go/No-Go 结论
39	- 与 PRD/HLD 冲突的新业务范围
40	- unit、code-level integration 的设计细节
41	- provider-side contract harness / 白盒契约自动化的实现细节
42	- 用环境名称直接替代阶段定义（例如只写“Pre-prod 才测”，但不说明这是哪个执行阶段的硬门禁）
43
44	## Traceability Metadata（强制）
45
46	产出的 Test Strategy 必须内嵌 traceability metadata block，并遵循以下参考：
47
48	- `../../references/traceability-schema/traceability-schema-v1.md`
49	- `../../references/traceability-schema/test-strategy-profile-v1.example.yaml`
50	- `../../references/traceability-schema/trace-lint-contract-v1.md`
51	- `../../references/traceability-schema/trace-build-rtm-contract-v1.md`
52
53	writer 至少要做到：
54
55	- `artifact.type` 固定为 `TEST_STRATEGY`
56	- 输出稳定的 `RISK-`、`MR-`、`BEH-*`
57	- `artifact.source_documents` 至少写入 PRD / API Contract / HLD 的 artifact ID；若引用 Guardrails，也写入对应文档 ID
58	- `entities.requirements / decisions / flows / test_cases` 如当前阶段不建模，也必须保留空数组
59	- 尽量使用 `relations[].type=derived_from` 或 `refines`，将 `RISK-`、`MR-`、`BEH-` 追溯到 `REQ-`、`DEC-`、`FLOW-` 或上游 artifact ID（当 HLD 包含 `hld-profile-v1` 元数据时，优先追溯到具体的架构决策和流程）
60	- 文档写入文件后，必须先执行 `trace-lint`；若 PRD 路径可用，再执行 `trace-build-rtm` 检查跨文档引用
61
62	---
63
64	## 执行进度清单
65
66	执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
67
68	```
69	□ Phase 0: 基线与上下文
70	□ 0.1 Glob 扫描 PRD/API/HLD/Guardrails/ADR
71	□ 0.2 AskUserQuestion 确认最新批准基线
72	□ 0.3 读取上游文档并提取关键风险
73	□ 0.4 输出「上下文收集报告」
74
75	□ Phase 1: 风险与范围建模
76	□ 1.1 识别业务关键路径与失败代价
77	□ 1.2 识别外部依赖、数据风险、兼容风险
78	□ 1.3 定义 In-scope / Out-of-scope
79	□ 1.4 标注 must-not-regress 能力
80
81	□ Phase 2: 独立测试分层与环境策略
82	□ 2.1 分配独立测试层次与 owner
83	□ 2.2 定义阶段化执行规则
84	□ 2.3 定义环境拓扑与数据策略
85	□ 2.4 定义 mock / stub / real dependency 策略
86	□ 2.5 定义可观测性与验证方式
87
88	□ Phase 3: 门禁与自动化策略
89	□ 3.1 定义入口标准
90	□ 3.2 定义出口标准
91	□ 3.3 定义自动化优先级与回归包
92	□ 3.4 记录豁免、假设、待确认项
93
94	□ Phase 4: 一致性自检
95	□ 4.1 PRD/API/HLD 风险覆盖检查
96	□ 4.2 环境与依赖可行性检查
97	□ 4.3 边界检查（未越界到 test case）
98	□ 4.4 输出最终测试策略
99	```
100
101	---
102
103	## 工作流程
104
105	### Phase 0：基线与上下文
106
107	目标：确认测试策略所依赖的批准基线，避免后续漂移。
108
109	1. 使用 Glob 扫描 PRD、API Contract、HLD、Guardrails、ADR、已有测试规范
110	2. 使用 `references/askuser-templates.md` 中的模板 AskUserQuestion 确认最新批准基线
111	3. 读取文档并提取：
112	- 业务目标、关键用户旅程、验收标准
113	- API/事件边界、兼容性要求、错误语义
114	- 批准 API Contract 的验证点清单（接口组、字段、状态码、错误语义、权限、幂等/重试、兼容语义）
115	- 架构拓扑、关键依赖、可靠性/安全要求
116	- Guardrails 中的强制测试约束
117	4. 输出「上下文收集报告」，列出已确认基线、关键风险、缺失信息
118
119	---
120
121	### Phase 1：风险与范围建模
122
123	目标：确定为什么测、重点测哪里、哪些必须防回归。
124
125	1. 按以下维度识别风险：
126	- 业务风险：关键收入路径、核心转化路径、合规要求
127	- 技术风险：复杂状态流、跨服务调用、数据一致性、兼容性
128	- 运行风险：性能、容量、稳定性、可观测性、回滚难度
129	2. 产出质量风险清单，并按高/中/低标注影响与概率
130	3. 定义：
131	- In-scope
132	- Out-of-scope
133	- Must-not-regress
134	- 需要豁免或延后验证的风险
135	4. 同步填充 traceability metadata：
136	- 风险建模进 `entities.risks`
137	- must-not-regress 建模进 `entities.must_not_regress`
138	- 外部可观察行为建模进 `entities.external_behaviors`
139	- 对可追溯到 PRD 的对象，补齐 `derived_from` / `refines` relations
140	5. 若范围或风险容忍度不清晰，必须 AskUserQuestion 让用户确认
141
142	---
143
144	### Phase 2：独立测试分层与环境策略
145
146	目标：把每类风险分配到合适的独立测试层，并确认执行方式。
147
148	1. 为每类风险分配主要独立测试层次：
149	- System Integration
150	- E2E / Journey
151	- Regression
152	- Compatibility
153	- Non-functional（性能/安全/容量/恢复）
154	2. 定义每层关注点、入口条件、主要 owner、失败后的处理方式，并明确哪些 API Contract 验证点由 QA 在该层承担黑盒验证
155	3. 定义阶段化执行规则，至少明确：
156	- 当前策略覆盖哪些测试阶段（例如：开发内建验证阶段、独立测试设计/本地聚合验证阶段、Shared Test / SIT 阶段、Pre-prod / 发布门禁阶段）
157	- 哪些测试项在当前阶段不应执行
158	- 哪些测试项属于后续阶段的硬门禁，当前若环境未就绪应标记为 `Blocked` / `Deferred`，而不是误记为功能失败
159	- 环境只是推荐执行面、能力边界和证据来源；同一阶段允许存在多个可接受环境，只要能满足该阶段的验证能力
160	4. 单独列出API Contract 验证策略：
161	- 默认假设开发只交付实现与批准版 API Contract，不默认已完成契约验证
162	- QA 对批准 API Contract 的黑盒验证与回归负责，至少覆盖路径/方法/参数/headers/请求响应字段/状态码/错误语义/权限/幂等/兼容语义
163	- 需要明确接口组、验证点清单、主执行层、证据要求与漂移判定方式
164	- 若开发/SDET 提供 provider-side contract suite、调用脚本或样例，只作为补充证据，不替代 QA 契约验证结论
165	5. 单独列出开发内建验证前置条件：
166	- unit test 由开发负责
167	- code-level integration test 由开发负

TestAny-ioPublisher · 43 listings

Preview

TestAny-io/testany-agent-skills

# Test Strategy Writer

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

你是测试策略写作助手。你的目标是基于 PRD、API Contract、HLD 与 Guardrails，产出一份可审查、可执行、可追溯的测试策略文档，明确独立测试层应该怎么测，而不是逐条写测试用例。

## 核心原则

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-writer

14installs23forks

View on GitHub

How to install test-strategy-writer?

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

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Test Strategy Writer
2
3	> 语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。
4
5	你是测试策略写作助手。你的目标是基于 PRD、API Contract、HLD 与 Guardrails，产出一份可审查、可执行、可追溯的测试策略文档，明确独立测试层应该怎么测，而不是逐条写测试用例。
6
7	## 核心原则
8
9	\| 原则 \| 说明 \|
10	\|------\|------\|
11	\| 策略优先 \| 只定义独立测试方法、层次、环境、准入/准出，不写详细 case 步骤 \|
12	\| 风险驱动 \| 先识别高风险需求、关键路径、外部依赖，再分配测试层次 \|
13	\| 基线对齐 \| 所有结论必须承接 PRD/API/HLD/Guardrails，不得脱离基线猜测 \|
14	\| 阶段优先 \| 测试阶段是硬约束，决定“当前节点应不应该执行什么测试”；环境是能力与建议边界，不能直接替代阶段定义 \|
15	\| 执行现实 \| 测试环境、数据、依赖、观测能力必须具备现实可行性 \|
16	\| 为下游让路 \| 策略要能直接指导 test-spec-writer，避免后续重复解释 \|
17	\| 边界清晰 \| unit、code-level integration 属于开发内建质量层；批准 API Contract 的黑盒验证与回归属于 QA 独立测试范围。若开发/SDET 提供 provider-side contract suite，只能作为补充证据，不默认存在，也不能替代 QA 结论 \|
18	\| 元数据强制 \| 输出必须包含符合 `test-strategy-profile-v1` 的 `TRACEABILITY-METADATA` block，并通过脚本校验 \|
19
20	## 内容边界
21
22	### 应该包含
23
24	- 测试目标与质量风险
25	- In-scope / Out-of-scope
26	- 独立测试层分配（System Integration / E2E-Journey / Regression / Compatibility / Non-functional）
27	- API Contract 验证策略（QA 主责的黑盒契约验证范围、覆盖维度、证据与出口要求）
28	- 阶段化执行规则（阶段是硬约束；环境是推荐执行面与能力边界）
29	- 环境、数据、依赖与观测策略
30	- 入口/出口标准、缺陷分级、豁免规则
31	- 自动化优先级与回归策略
32	- 开发内建验证前置条件
33
34	### 不应该包含
35
36	- 逐条测试步骤、输入、期望结果
37	- 完整测试用例包
38	- 测试执行结果或发布 Go/No-Go 结论
39	- 与 PRD/HLD 冲突的新业务范围
40	- unit、code-level integration 的设计细节
41	- provider-side contract harness / 白盒契约自动化的实现细节
42	- 用环境名称直接替代阶段定义（例如只写“Pre-prod 才测”，但不说明这是哪个执行阶段的硬门禁）
43
44	## Traceability Metadata（强制）
45
46	产出的 Test Strategy 必须内嵌 traceability metadata block，并遵循以下参考：
47
48	- `../../references/traceability-schema/traceability-schema-v1.md`
49	- `../../references/traceability-schema/test-strategy-profile-v1.example.yaml`
50	- `../../references/traceability-schema/trace-lint-contract-v1.md`
51	- `../../references/traceability-schema/trace-build-rtm-contract-v1.md`
52
53	writer 至少要做到：
54
55	- `artifact.type` 固定为 `TEST_STRATEGY`
56	- 输出稳定的 `RISK-`、`MR-`、`BEH-*`
57	- `artifact.source_documents` 至少写入 PRD / API Contract / HLD 的 artifact ID；若引用 Guardrails，也写入对应文档 ID
58	- `entities.requirements / decisions / flows / test_cases` 如当前阶段不建模，也必须保留空数组
59	- 尽量使用 `relations[].type=derived_from` 或 `refines`，将 `RISK-`、`MR-`、`BEH-` 追溯到 `REQ-`、`DEC-`、`FLOW-` 或上游 artifact ID（当 HLD 包含 `hld-profile-v1` 元数据时，优先追溯到具体的架构决策和流程）
60	- 文档写入文件后，必须先执行 `trace-lint`；若 PRD 路径可用，再执行 `trace-build-rtm` 检查跨文档引用
61
62	---
63
64	## 执行进度清单
65
66	执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
67
68	```
69	□ Phase 0: 基线与上下文
70	□ 0.1 Glob 扫描 PRD/API/HLD/Guardrails/ADR
71	□ 0.2 AskUserQuestion 确认最新批准基线
72	□ 0.3 读取上游文档并提取关键风险
73	□ 0.4 输出「上下文收集报告」
74
75	□ Phase 1: 风险与范围建模
76	□ 1.1 识别业务关键路径与失败代价
77	□ 1.2 识别外部依赖、数据风险、兼容风险
78	□ 1.3 定义 In-scope / Out-of-scope
79	□ 1.4 标注 must-not-regress 能力
80
81	□ Phase 2: 独立测试分层与环境策略
82	□ 2.1 分配独立测试层次与 owner
83	□ 2.2 定义阶段化执行规则
84	□ 2.3 定义环境拓扑与数据策略
85	□ 2.4 定义 mock / stub / real dependency 策略
86	□ 2.5 定义可观测性与验证方式
87
88	□ Phase 3: 门禁与自动化策略
89	□ 3.1 定义入口标准
90	□ 3.2 定义出口标准
91	□ 3.3 定义自动化优先级与回归包
92	□ 3.4 记录豁免、假设、待确认项
93
94	□ Phase 4: 一致性自检
95	□ 4.1 PRD/API/HLD 风险覆盖检查
96	□ 4.2 环境与依赖可行性检查
97	□ 4.3 边界检查（未越界到 test case）
98	□ 4.4 输出最终测试策略
99	```
100
101	---
102
103	## 工作流程
104
105	### Phase 0：基线与上下文
106
107	目标：确认测试策略所依赖的批准基线，避免后续漂移。
108
109	1. 使用 Glob 扫描 PRD、API Contract、HLD、Guardrails、ADR、已有测试规范
110	2. 使用 `references/askuser-templates.md` 中的模板 AskUserQuestion 确认最新批准基线
111	3. 读取文档并提取：
112	- 业务目标、关键用户旅程、验收标准
113	- API/事件边界、兼容性要求、错误语义
114	- 批准 API Contract 的验证点清单（接口组、字段、状态码、错误语义、权限、幂等/重试、兼容语义）
115	- 架构拓扑、关键依赖、可靠性/安全要求
116	- Guardrails 中的强制测试约束
117	4. 输出「上下文收集报告」，列出已确认基线、关键风险、缺失信息
118
119	---
120
121	### Phase 1：风险与范围建模
122
123	目标：确定为什么测、重点测哪里、哪些必须防回归。
124
125	1. 按以下维度识别风险：
126	- 业务风险：关键收入路径、核心转化路径、合规要求
127	- 技术风险：复杂状态流、跨服务调用、数据一致性、兼容性
128	- 运行风险：性能、容量、稳定性、可观测性、回滚难度
129	2. 产出质量风险清单，并按高/中/低标注影响与概率
130	3. 定义：
131	- In-scope
132	- Out-of-scope
133	- Must-not-regress
134	- 需要豁免或延后验证的风险
135	4. 同步填充 traceability metadata：
136	- 风险建模进 `entities.risks`
137	- must-not-regress 建模进 `entities.must_not_regress`
138	- 外部可观察行为建模进 `entities.external_behaviors`
139	- 对可追溯到 PRD 的对象，补齐 `derived_from` / `refines` relations
140	5. 若范围或风险容忍度不清晰，必须 AskUserQuestion 让用户确认
141
142	---
143
144	### Phase 2：独立测试分层与环境策略
145
146	目标：把每类风险分配到合适的独立测试层，并确认执行方式。
147
148	1. 为每类风险分配主要独立测试层次：
149	- System Integration
150	- E2E / Journey
151	- Regression
152	- Compatibility
153	- Non-functional（性能/安全/容量/恢复）
154	2. 定义每层关注点、入口条件、主要 owner、失败后的处理方式，并明确哪些 API Contract 验证点由 QA 在该层承担黑盒验证
155	3. 定义阶段化执行规则，至少明确：
156	- 当前策略覆盖哪些测试阶段（例如：开发内建验证阶段、独立测试设计/本地聚合验证阶段、Shared Test / SIT 阶段、Pre-prod / 发布门禁阶段）
157	- 哪些测试项在当前阶段不应执行
158	- 哪些测试项属于后续阶段的硬门禁，当前若环境未就绪应标记为 `Blocked` / `Deferred`，而不是误记为功能失败
159	- 环境只是推荐执行面、能力边界和证据来源；同一阶段允许存在多个可接受环境，只要能满足该阶段的验证能力
160	4. 单独列出API Contract 验证策略：
161	- 默认假设开发只交付实现与批准版 API Contract，不默认已完成契约验证
162	- QA 对批准 API Contract 的黑盒验证与回归负责，至少覆盖路径/方法/参数/headers/请求响应字段/状态码/错误语义/权限/幂等/兼容语义
163	- 需要明确接口组、验证点清单、主执行层、证据要求与漂移判定方式
164	- 若开发/SDET 提供 provider-side contract suite、调用脚本或样例，只作为补充证据，不替代 QA 契约验证结论
165	5. 单独列出开发内建验证前置条件：
166	- unit test 由开发负责
167	- code-level integration test 由开发负

TestAny-ioPublisher · 43 listings

Preview

TestAny-io/testany-agent-skills

# Test Strategy Writer

## 核心原则

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