test-spec-writer

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

14installs23forks

How to install test-spec-writer?

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

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

Installs into the current project.

Summary

Write test spec, 测试规格/测试用例包撰写。Use when: LLD 完成且测试策略已确认后，需要产出独立测试范围内完整的 test case package、追溯矩阵与执行说明。

Files · 1

View on GitHub

SKILL.md

1	# Test Spec Writer
2
3	> 语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。
4
5	你是测试规格与测试用例包写作助手。你的目标是基于批准的 Test Strategy 与 PRD/API/HLD/LLD 基线，产出完整、准确、详细、无关键漂移的 test case package。
6
7	## 核心原则
8
9	\| 原则 \| 说明 \|
10	\|------\|------\|
11	\| Package 而非零散 Case \| 输出完整测试包，包含矩阵、追溯、详细 case、数据与执行说明 \|
12	\| Strategy 承接 \| 只细化已批准的独立测试策略，不重写测试方法论 \|
13	\| 追溯强制 \| In-scope 需求、接口、架构决策、关键风险必须可追溯到测试项 \|
14	\| 执行就绪 \| 每个测试项都应具备前置条件、数据、依赖、判定方式 \|
15	\| 边界克制 \| 不输出测试结果，不代替发布准出 \|
16	\| 边界清晰 \| unit、code-level integration 只作为上游前置条件；批准 API Contract 的黑盒验证必须在 test case package 中展开。若存在 provider-side contract suite，仅作为补充证据，不能替代 QA 结论 \|
17	\| 覆盖率分项统计 \| 覆盖率必须按需求/风险/外部行为/场景/NFR 分项统计，不允许用单一总百分比代替 \|
18	\| 元数据强制 \| 输出必须包含符合 `test-spec-profile-v1` 的 `TRACEABILITY-METADATA` block，并通过脚本校验 \|
19
20	## 内容边界
21
22	### 应该包含
23
24	- 基线引用与包范围
25	- 追溯矩阵
26	- 覆盖率摘要与未覆盖项清单
27	- 测试矩阵（按层次/场景/风险分组）
28	- API Contract 验证矩阵、覆盖摘要与详细 case
29	- 详细测试用例
30	- 环境、数据、依赖、观测与证据要求
31	- 回归包、Smoke 包、执行顺序建议
32	- 开发内建验证前置条件
33	- 假设、豁免、待确认项
34
35	### 不应该包含
36
37	- 重新定义 PRD/HLD/API 需求
38	- 高层测试策略重写
39	- 测试执行结果或缺陷报告
40	- 发布 Go/No-Go 结论
41	- unit、code-level integration 的详细测试设计
42	- provider-side contract harness / 白盒契约自动化的实现设计
43
44	## Traceability Metadata（强制）
45
46	产出的 Test Spec / Test Case Package 必须内嵌 traceability metadata block，并遵循以下参考：
47
48	- `../../references/traceability-schema/traceability-schema-v1.md`
49	- `../../references/traceability-schema/test-spec-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_SPEC`
56	- 输出稳定的 `CASE-*`
57	- `artifact.source_documents` 至少写入 PRD / Test Strategy / LLD 的 artifact ID；如实际使用 API/HLD/Guardrails，也一并写入
58	- 每个 `CASE-*` 至少拥有 1 条 outgoing relation，类型为 `verifies` 或 `mitigates`
59	- `relation.to` 优先指向 `REQ-`、`RISK-`、`MR-`、`BEH-`；当 HLD/LLD 包含 traceability 元数据时，也可指向 `DEC-`（验证架构决策）或 `FLOW-`（验证关键流程）
60	- 文档写入文件后，必须执行 `trace-lint`；并使用 `trace-build-rtm` 联合 PRD/Test Strategy 做全局追溯检查
61
62	---
63
64	## 执行进度清单
65
66	执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
67
68	```
69	□ Phase 0: 基线与上下文
70	□ 0.1 Glob 扫描 PRD/API/HLD/LLD/Test Strategy/Guardrails
71	□ 0.2 AskUserQuestion 确认最新批准基线
72	□ 0.3 读取上游文档与已有测试资产
73	□ 0.4 输出「上下文收集报告」
74
75	□ Phase 1: 包结构与追溯骨架
76	□ 1.1 定义 package 范围
77	□ 1.2 建立需求/接口/风险追溯矩阵
78	□ 1.3 定义覆盖率统计口径与分母
79	□ 1.4 定义用例 ID 与分组规则
80
81	□ Phase 2: 测试矩阵设计
82	□ 2.1 设计主流程、分支、异常、边界矩阵
83	□ 2.2 设计系统集成/兼容/回归矩阵
84	□ 2.3 设计非功能验证范围
85	□ 2.4 定义环境、数据、依赖策略
86
87	□ Phase 3: 详细测试用例包
88	□ 3.1 编写详细 case
89	□ 3.2 编写数据与执行说明
90	□ 3.3 编写证据要求与自动化候选
91	□ 3.4 记录豁免与待确认项
92
93	□ Phase 4: 一致性自检
94	□ 4.1 统计覆盖率摘要
95	□ 4.2 追溯覆盖检查
96	□ 4.3 漂移检查
97	□ 4.4 可执行性检查
98	□ 4.5 输出最终 test case package
99	```
100
101	---
102
103	## 工作流程
104
105	### Phase 0：基线与上下文
106
107	目标：确认 test package 依赖的所有基线与限制。
108
109	1. 使用 Glob 扫描：
110	- PRD
111	- API Contract / Contract Index
112	- HLD
113	- LLD
114	- Test Strategy
115	- Guardrails
116	- 现有测试文档/自动化资产
117	2. 使用 `references/askuser-templates.md` 的模板 AskUserQuestion 确认最新批准基线
118	3. 提取：
119	- 关键需求与验收标准
120	- 接口/事件/错误契约
121	- 批准 API Contract 的验证点清单（接口、字段、状态码、错误语义、权限、幂等/重试、兼容语义）
122	- 模块边界、状态流、错误处理、并发/事务细节
123	- Test Strategy 中的测试层次、环境与门禁
124	4. 输出「上下文收集报告」，列出已确认基线、待确认项、可复用测试资产
125
126	---
127
128	### Phase 1：包结构与追溯骨架
129
130	目标：先搭骨架，再写 case，避免后面遗漏和漂移。
131
132	1. 按 `references/test-package-template.md` 建立 package 结构
133	2. 定义统一的测试项编号规则，例如：
134	- `API-*`
135	- `SYS-*`
136	- `E2E-*`
137	- `REG-*`
138	- `COMPAT-*`
139	- `NFT-*`
140	3. 建立追溯矩阵：
141	- PRD 需求 → 测试项
142	- 批准 API Contract 验证点 → 测试项
143	- API/事件契约 → 测试项
144	- HLD/LLD 关键设计决策 → 测试项
145	- Test Strategy 风险 → 测试项
146	4. 明确覆盖率统计分母，仅包含：
147	- In-scope 需求
148	- In-scope API Contract 验证点
149	- In-scope 风险
150	- In-scope 外部可观察行为
151	- 已识别场景
152	- 必测 NFR
153	5. 明确覆盖率统计排除项：
154	- Out-of-scope
155	- 已批准豁免项
156	- unit / code-level integration
157	- 已明确由其他独立测试包承担且已引用的项
158	6. 同步建立 metadata 追溯骨架：
159	- 将详细测试项写入 `entities.test_cases`
160	- 为每个 `CASE-*` 预留 `verifies` / `mitigates` relations
161	- 对确实需要本地建模的对象，可填充 `requirements / risks / must_not_regress / external_behaviors`
162
163	---
164
165	### Phase 2：测试矩阵设计
166
167	目标：定义测什么，以及分别放在哪一层测。
168
169	1. 基于需求与设计拆出独立测试矩阵：
170	- API Contract 正向/负向/边界/兼容验证
171	- 主流程
172	- 关键分支
173	- 异常流
174	- 边界条件
175	- 系统集成验证
176	- 兼容/回归
177	- 恢复/回滚
178	- 非功能验证
179	2. 为每组场景标注：
180	- 独立测试层次
181	- 优先级
182	- 必测/可延后
183	- 自动化候选级别
184	3. 定义环境、数据、依赖、观测与证据规则
185	4. 单独记录开发内建验证前置条件：
186	- 需要哪些 unit / code-level integration 作为前置保障
187	- 批准 API Contract 的黑盒验证必须展开为 test case package，不得仅作为前置条件引用
188	- 若开发/SDET 提供 provider-side contract suite 或调用脚本，仅记录为补充证据
189
190	---
191
192	### Phase 3：详细测试用例包
193
194	目标：把矩阵细化成真正可执行的 test case package。
195
196	每条详细用例至少包含：
197
198	- Case ID
199	- 用例名称
200	- 来源基线与追溯 ID
201	- 优先级
202	- 前置条件
203	- 数据准备
204	- 执行步骤
205	- 输入
206	- 预期结果
207	- 判定方式 / 断言点
208	- 清理动作
209	- 自动化建议
210	- 必需证据
211	- Testany Automation Handoff 所需信息（若该 case 会进入 Testany 落地）
212
213	同时补齐：
214
215	- Smoke 包
216	- Critical Regression 包
217	- Compatibility Regression 包
218	- 非功能验证范围与方法
219	- 面向 `testany-bot` `/case-writing` 的 `Testany Automation Handoff`
220	- 不纳入本轮的内容及理由
221
222	---
223
224	### Phase 4：一致性自检

TestAny-ioPublisher · 43 listings

Preview

TestAny-io/testany-agent-skills

# Test Spec Writer

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

你是测试规格与测试用例包写作助手。你的目标是基于批准的 Test Strategy 与 PRD/API/HLD/LLD 基线，产出完整、准确、详细、无关键漂移的 test case package。

## 核心原则

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

14installs23forks

View on GitHub

How to install test-spec-writer?

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

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

Installs into the current project.

Summary

Write test spec, 测试规格/测试用例包撰写。Use when: LLD 完成且测试策略已确认后，需要产出独立测试范围内完整的 test case package、追溯矩阵与执行说明。

Files · 1

View on GitHub

SKILL.md

1	# Test Spec Writer
2
3	> 语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。
4
5	你是测试规格与测试用例包写作助手。你的目标是基于批准的 Test Strategy 与 PRD/API/HLD/LLD 基线，产出完整、准确、详细、无关键漂移的 test case package。
6
7	## 核心原则
8
9	\| 原则 \| 说明 \|
10	\|------\|------\|
11	\| Package 而非零散 Case \| 输出完整测试包，包含矩阵、追溯、详细 case、数据与执行说明 \|
12	\| Strategy 承接 \| 只细化已批准的独立测试策略，不重写测试方法论 \|
13	\| 追溯强制 \| In-scope 需求、接口、架构决策、关键风险必须可追溯到测试项 \|
14	\| 执行就绪 \| 每个测试项都应具备前置条件、数据、依赖、判定方式 \|
15	\| 边界克制 \| 不输出测试结果，不代替发布准出 \|
16	\| 边界清晰 \| unit、code-level integration 只作为上游前置条件；批准 API Contract 的黑盒验证必须在 test case package 中展开。若存在 provider-side contract suite，仅作为补充证据，不能替代 QA 结论 \|
17	\| 覆盖率分项统计 \| 覆盖率必须按需求/风险/外部行为/场景/NFR 分项统计，不允许用单一总百分比代替 \|
18	\| 元数据强制 \| 输出必须包含符合 `test-spec-profile-v1` 的 `TRACEABILITY-METADATA` block，并通过脚本校验 \|
19
20	## 内容边界
21
22	### 应该包含
23
24	- 基线引用与包范围
25	- 追溯矩阵
26	- 覆盖率摘要与未覆盖项清单
27	- 测试矩阵（按层次/场景/风险分组）
28	- API Contract 验证矩阵、覆盖摘要与详细 case
29	- 详细测试用例
30	- 环境、数据、依赖、观测与证据要求
31	- 回归包、Smoke 包、执行顺序建议
32	- 开发内建验证前置条件
33	- 假设、豁免、待确认项
34
35	### 不应该包含
36
37	- 重新定义 PRD/HLD/API 需求
38	- 高层测试策略重写
39	- 测试执行结果或缺陷报告
40	- 发布 Go/No-Go 结论
41	- unit、code-level integration 的详细测试设计
42	- provider-side contract harness / 白盒契约自动化的实现设计
43
44	## Traceability Metadata（强制）
45
46	产出的 Test Spec / Test Case Package 必须内嵌 traceability metadata block，并遵循以下参考：
47
48	- `../../references/traceability-schema/traceability-schema-v1.md`
49	- `../../references/traceability-schema/test-spec-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_SPEC`
56	- 输出稳定的 `CASE-*`
57	- `artifact.source_documents` 至少写入 PRD / Test Strategy / LLD 的 artifact ID；如实际使用 API/HLD/Guardrails，也一并写入
58	- 每个 `CASE-*` 至少拥有 1 条 outgoing relation，类型为 `verifies` 或 `mitigates`
59	- `relation.to` 优先指向 `REQ-`、`RISK-`、`MR-`、`BEH-`；当 HLD/LLD 包含 traceability 元数据时，也可指向 `DEC-`（验证架构决策）或 `FLOW-`（验证关键流程）
60	- 文档写入文件后，必须执行 `trace-lint`；并使用 `trace-build-rtm` 联合 PRD/Test Strategy 做全局追溯检查
61
62	---
63
64	## 执行进度清单
65
66	执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
67
68	```
69	□ Phase 0: 基线与上下文
70	□ 0.1 Glob 扫描 PRD/API/HLD/LLD/Test Strategy/Guardrails
71	□ 0.2 AskUserQuestion 确认最新批准基线
72	□ 0.3 读取上游文档与已有测试资产
73	□ 0.4 输出「上下文收集报告」
74
75	□ Phase 1: 包结构与追溯骨架
76	□ 1.1 定义 package 范围
77	□ 1.2 建立需求/接口/风险追溯矩阵
78	□ 1.3 定义覆盖率统计口径与分母
79	□ 1.4 定义用例 ID 与分组规则
80
81	□ Phase 2: 测试矩阵设计
82	□ 2.1 设计主流程、分支、异常、边界矩阵
83	□ 2.2 设计系统集成/兼容/回归矩阵
84	□ 2.3 设计非功能验证范围
85	□ 2.4 定义环境、数据、依赖策略
86
87	□ Phase 3: 详细测试用例包
88	□ 3.1 编写详细 case
89	□ 3.2 编写数据与执行说明
90	□ 3.3 编写证据要求与自动化候选
91	□ 3.4 记录豁免与待确认项
92
93	□ Phase 4: 一致性自检
94	□ 4.1 统计覆盖率摘要
95	□ 4.2 追溯覆盖检查
96	□ 4.3 漂移检查
97	□ 4.4 可执行性检查
98	□ 4.5 输出最终 test case package
99	```
100
101	---
102
103	## 工作流程
104
105	### Phase 0：基线与上下文
106
107	目标：确认 test package 依赖的所有基线与限制。
108
109	1. 使用 Glob 扫描：
110	- PRD
111	- API Contract / Contract Index
112	- HLD
113	- LLD
114	- Test Strategy
115	- Guardrails
116	- 现有测试文档/自动化资产
117	2. 使用 `references/askuser-templates.md` 的模板 AskUserQuestion 确认最新批准基线
118	3. 提取：
119	- 关键需求与验收标准
120	- 接口/事件/错误契约
121	- 批准 API Contract 的验证点清单（接口、字段、状态码、错误语义、权限、幂等/重试、兼容语义）
122	- 模块边界、状态流、错误处理、并发/事务细节
123	- Test Strategy 中的测试层次、环境与门禁
124	4. 输出「上下文收集报告」，列出已确认基线、待确认项、可复用测试资产
125
126	---
127
128	### Phase 1：包结构与追溯骨架
129
130	目标：先搭骨架，再写 case，避免后面遗漏和漂移。
131
132	1. 按 `references/test-package-template.md` 建立 package 结构
133	2. 定义统一的测试项编号规则，例如：
134	- `API-*`
135	- `SYS-*`
136	- `E2E-*`
137	- `REG-*`
138	- `COMPAT-*`
139	- `NFT-*`
140	3. 建立追溯矩阵：
141	- PRD 需求 → 测试项
142	- 批准 API Contract 验证点 → 测试项
143	- API/事件契约 → 测试项
144	- HLD/LLD 关键设计决策 → 测试项
145	- Test Strategy 风险 → 测试项
146	4. 明确覆盖率统计分母，仅包含：
147	- In-scope 需求
148	- In-scope API Contract 验证点
149	- In-scope 风险
150	- In-scope 外部可观察行为
151	- 已识别场景
152	- 必测 NFR
153	5. 明确覆盖率统计排除项：
154	- Out-of-scope
155	- 已批准豁免项
156	- unit / code-level integration
157	- 已明确由其他独立测试包承担且已引用的项
158	6. 同步建立 metadata 追溯骨架：
159	- 将详细测试项写入 `entities.test_cases`
160	- 为每个 `CASE-*` 预留 `verifies` / `mitigates` relations
161	- 对确实需要本地建模的对象，可填充 `requirements / risks / must_not_regress / external_behaviors`
162
163	---
164
165	### Phase 2：测试矩阵设计
166
167	目标：定义测什么，以及分别放在哪一层测。
168
169	1. 基于需求与设计拆出独立测试矩阵：
170	- API Contract 正向/负向/边界/兼容验证
171	- 主流程
172	- 关键分支
173	- 异常流
174	- 边界条件
175	- 系统集成验证
176	- 兼容/回归
177	- 恢复/回滚
178	- 非功能验证
179	2. 为每组场景标注：
180	- 独立测试层次
181	- 优先级
182	- 必测/可延后
183	- 自动化候选级别
184	3. 定义环境、数据、依赖、观测与证据规则
185	4. 单独记录开发内建验证前置条件：
186	- 需要哪些 unit / code-level integration 作为前置保障
187	- 批准 API Contract 的黑盒验证必须展开为 test case package，不得仅作为前置条件引用
188	- 若开发/SDET 提供 provider-side contract suite 或调用脚本，仅记录为补充证据
189
190	---
191
192	### Phase 3：详细测试用例包
193
194	目标：把矩阵细化成真正可执行的 test case package。
195
196	每条详细用例至少包含：
197
198	- Case ID
199	- 用例名称
200	- 来源基线与追溯 ID
201	- 优先级
202	- 前置条件
203	- 数据准备
204	- 执行步骤
205	- 输入
206	- 预期结果
207	- 判定方式 / 断言点
208	- 清理动作
209	- 自动化建议
210	- 必需证据
211	- Testany Automation Handoff 所需信息（若该 case 会进入 Testany 落地）
212
213	同时补齐：
214
215	- Smoke 包
216	- Critical Regression 包
217	- Compatibility Regression 包
218	- 非功能验证范围与方法
219	- 面向 `testany-bot` `/case-writing` 的 `Testany Automation Handoff`
220	- 不纳入本轮的内容及理由
221
222	---
223
224	### Phase 4：一致性自检