Test Strategy Writer

Test Strategy Writer

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

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

核心原则

内容边界

应该包含

• 测试目标与质量风险
• In-scope / Out-of-scope
• 独立测试层分配（System Integration / E2E-Journey / Regression / Compatibility / Non-functional）
• API Contract 验证策略（QA 主责的黑盒契约验证范围、覆盖维度、证据与出口要求）
• 阶段化执行规则（阶段是硬约束；环境是推荐执行面与能力边界）
• 环境、数据、依赖与观测策略
• 入口/出口标准、缺陷分级、豁免规则
• 自动化优先级与回归策略
• 开发内建验证前置条件

不应该包含

• 逐条测试步骤、输入、期望结果
• 完整测试用例包
• 测试执行结果或发布 Go/No-Go 结论
• 与 PRD/HLD 冲突的新业务范围
• unit、code-level integration 的设计细节
• provider-side contract harness / 白盒契约自动化的实现细节
• 用环境名称直接替代阶段定义（例如只写“Pre-prod 才测”，但不说明这是哪个执行阶段的硬门禁）

Traceability Metadata（强制）

产出的 Test Strategy 必须内嵌 traceability metadata block，并遵循以下参考：

• ../../references/traceability-schema/traceability-schema-v1.md
• ../../references/traceability-schema/test-strategy-profile-v1.example.yaml
• ../../references/traceability-schema/trace-lint-contract-v1.md
• ../../references/traceability-schema/trace-build-rtm-contract-v1.md

writer 至少要做到：

• artifact.type 固定为 TEST_STRATEGY
• 输出稳定的 RISK-*、MR-*、BEH-*
• artifact.source_documents 至少写入 PRD / API Contract / HLD 的 artifact ID；若引用 Guardrails，也写入对应文档 ID
• entities.requirements / decisions / flows / test_cases 如当前阶段不建模，也必须保留空数组
• 尽量使用 relations[].type=derived_from 或 refines，将 RISK-*、MR-*、BEH-* 追溯到 REQ-*、DEC-*、FLOW-* 或上游 artifact ID（当 HLD 包含 hld-profile-v1 元数据时，优先追溯到具体的架构决策和流程）
• 文档写入文件后，必须先执行 trace-lint；若 PRD 路径可用，再执行 trace-build-rtm 检查跨文档引用

---

执行进度清单

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

□ Phase 0: 基线与上下文
  □ 0.1 Glob 扫描 PRD/API/HLD/Guardrails/ADR
  □ 0.2 AskUserQuestion 确认最新批准基线
  □ 0.3 读取上游文档并提取关键风险
  □ 0.4 输出「上下文收集报告」

□ Phase 1: 风险与范围建模
  □ 1.1 识别业务关键路径与失败代价
  □ 1.2 识别外部依赖、数据风险、兼容风险
  □ 1.3 定义 In-scope / Out-of-scope
  □ 1.4 标注 must-not-regress 能力

□ Phase 2: 独立测试分层与环境策略
  □ 2.1 分配独立测试层次与 owner
  □ 2.2 定义阶段化执行规则
  □ 2.3 定义环境拓扑与数据策略
  □ 2.4 定义 mock / stub / real dependency 策略
  □ 2.5 定义可观测性与验证方式

□ Phase 3: 门禁与自动化策略
  □ 3.1 定义入口标准
  □ 3.2 定义出口标准
  □ 3.3 定义自动化优先级与回归包
  □ 3.4 记录豁免、假设、待确认项

□ Phase 4: 一致性自检
  □ 4.1 PRD/API/HLD 风险覆盖检查
  □ 4.2 环境与依赖可行性检查
  □ 4.3 边界检查（未越界到 test case）
  □ 4.4 输出最终测试策略

---

工作流程

Phase 0：基线与上下文

目标：确认测试策略所依赖的批准基线，避免后续漂移。

1. 使用 Glob 扫描 PRD、API Contract、HLD、Guardrails、ADR、已有测试规范 2. 使用 references/askuser-templates.md 中的模板 AskUserQuestion 确认最新批准基线 3. 读取文档并提取：

• 业务目标、关键用户旅程、验收标准
• API/事件边界、兼容性要求、错误语义
• 批准 API Contract 的验证点清单（接口组、字段、状态码、错误语义、权限、幂等/重试、兼容语义）
• 架构拓扑、关键依赖、可靠性/安全要求
• Guardrails 中的强制测试约束

4. 输出「上下文收集报告」，列出已确认基线、关键风险、缺失信息

---

Phase 1：风险与范围建模

目标：确定为什么测、重点测哪里、哪些必须防回归。

1. 按以下维度识别风险：

• 业务风险：关键收入路径、核心转化路径、合规要求
• 技术风险：复杂状态流、跨服务调用、数据一致性、兼容性
• 运行风险：性能、容量、稳定性、可观测性、回滚难度

2. 产出质量风险清单，并按高/中/低标注影响与概率 3. 定义：

• In-scope
• Out-of-scope
• Must-not-regress
• 需要豁免或延后验证的风险

4. 同步填充 traceability metadata：

• 风险建模进 entities.risks
• must-not-regress 建模进 entities.must_not_regress
• 外部可观察行为建模进 entities.external_behaviors
• 对可追溯到 PRD 的对象，补齐 derived_from / refines relations

5. 若范围或风险容忍度不清晰，必须 AskUserQuestion 让用户确认

---

Phase 2：独立测试分层与环境策略

目标：把每类风险分配到合适的独立测试层，并确认执行方式。

1. 为每类风险分配主要独立测试层次：

• System Integration
• E2E / Journey
• Regression
• Compatibility
• Non-functional（性能/安全/容量/恢复）

2. 定义每层关注点、入口条件、主要 owner、失败后的处理方式，并明确哪些 API Contract 验证点由 QA 在该层承担黑盒验证 3. 定义阶段化执行规则，至少明确：

• 当前策略覆盖哪些测试阶段（例如：开发内建验证阶段、独立测试设计/本地聚合验证阶段、Shared Test / SIT 阶段、Pre-prod / 发布门禁阶段）
• 哪些测试项在当前阶段不应执行
• 哪些测试项属于后续阶段的硬门禁，当前若环境未就绪应标记为 Blocked / Deferred，而不是误记为功能失败
• 环境只是推荐执行面、能力边界和证据来源；同一阶段允许存在多个可接受环境，只要能满足该阶段的验证能力

4. 单独列出API Contract 验证策略：

• 默认假设开发只交付实现与批准版 API Contract，不默认已完成契约验证
• QA 对批准 API Contract 的黑盒验证与回归负责，至少覆盖路径/方法/参数/headers/请求响应字段/状态码/错误语义/权限/幂等/兼容语义
• 需要明确接口组、验证点清单、主执行层、证据要求与漂移判定方式
• 若开发/SDET 提供 provider-side contract suite、调用脚本或样例，只作为补充证据，不替代 QA 契约验证结论

5. 单独列出开发内建验证前置条件：

• unit test 由开发负责
• code-level integration test 由开发负责
• 不得把“开发已完成 API Contract 验证”写成默认硬入口条件
• 若存在 provider-side contract suite，可记录其状态，但只能作为补充证据

6. 明确环境策略：

• 本地 / CI / Shared Test / Staging / Pre-prod
• 数据准备、数据隔离、数据清理
• mock / stub / sandbox / real dependency 使用边界
• 必须明确“环境 ≠ 阶段”：不能只用环境名称代替执行阶段；应写成“某阶段推荐或要求具备哪些环境能力”

7. 明确可观测性与验证方式：

• 接口响应 / 事件落地 / DB 状态 / 日志 / 指标 / Trace

---

Phase 3：门禁与自动化策略

目标：定义什么时候可以开始测，什么时候可以结束，以及哪些要优先自动化。

1. 定义入口标准：

• 基线版本是否冻结
• 环境和数据是否可用
• 关键依赖是否就绪
• 不以“开发已完成 provider-side contract test”作为默认硬入口；若存在其结果，只能作为补充参考

2. 定义出口标准：

• 必测范围完成度
• P0/P1 缺陷门槛
• 必需证据是否齐备
• 批准 API Contract 的 in-scope 验证点必须有 QA 黑盒验证范围、执行层、证据要求与漂移判定标准
• 必须区分“当前阶段应完成的出口”与“后续阶段预留的环境级门禁”，避免把后续阶段测试错误地折算成当前阶段失败

3. 定义自动化优先级：

• Smoke
• Critical regression
• Compatibility regression
• 高价值非功能测试

4. 明确哪些内容留给 test-spec-writer 细化，哪些内容需要发布前提供执行证据

---

Phase 4：一致性自检

目标：确保测试策略既不遗漏核心风险，也不越界写成测试用例。

1. 检查每个高风险需求/接口/架构决策是否有对应独立测试层 2. 检查环境、数据、依赖策略是否现实可行 3. 检查是否把环境错误写成阶段替代物；如有，回收到“阶段硬约束 + 环境软边界”的表达 4. 检查是否误把 API Contract 验证降级为开发前置条件；如有，回收到 QA 独立测试范围 5. 检查是否误把开发内建验证写成测试团队负责范围；如有，回收为前置条件 6. 检查是否误写成详细测试步骤；如有，回收为策略级表达 7. 使用 references/strategy-template.md 输出最终文档，并补齐 TRACEABILITY-METADATA block 8. 对已保存的文档执行：

• 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 路径>

9. 若 trace-lint 存在 blocking issue，或 trace-build-rtm 出现 unresolved target / duplicate ID / unresolved relation.from，则必须先修正文档后再输出完成结论

交互规范

必须使用 AskUserQuestion 的场景

1. PRD/API/HLD 基线版本不明确 2. 风险容忍度、关键路径或回归范围不明确 3. 外部依赖使用真实环境还是 mock/stub 不明确 4. 环境限制会影响测试方法选择

问题设计原则

• 每次只问一个决策主题
• 选项控制在 2-4 个
• 描述 trade-off，不要只给标签
• 能从文档推断的，不先问用户

输出格式

按 references/strategy-template.md 输出，至少包含：

• 基本信息与基线引用
• TRACEABILITY-METADATA block（test-strategy-profile-v1）
• 上下文收集报告
• 质量风险清单
• 独立测试层分配矩阵
• API Contract 验证策略
• 阶段化执行规则（至少区分当前阶段与后续阶段门禁）
• 环境/数据/依赖策略
• 入口/出口标准
• 自动化与回归策略
• 开发内建验证前置条件
• 假设、豁免、待确认项

质量标准

• 风险与测试层分配可追溯
• 关键能力与关键接口无遗漏
• 不默认假设开发/SDET 已完成 API Contract 验证；QA 契约验证责任边界与漂移判定方式清晰
• 环境与依赖策略可执行
• 明确区分阶段硬约束与环境软边界，不把环境名称当作阶段定义
• 不侵入开发内建质量层职责
• 不越界到详细 test case
• trace-lint 通过，且在提供 PRD 时 trace-build-rtm 无 build error
• 下游 test-spec-writer 可直接承接

使用示例

/test-strategy-writer ./docs/PRD-用户认证.md ./docs/API-Contract-用户认证.md ./docs/HLD-用户认证.md ./docs/Guardrails.md

触发词

• 写测试策略
• 测试策略
• test strategy
• 测试方法
• 独立测试层
• 入口标准
• 出口标准

参考文档

• references/strategy-template.md：测试策略输出模板
• references/askuser-templates.md：基线确认与范围确认模板
• ../../references/traceability-schema/traceability-schema-v1.md：traceability canonical schema
• ../../references/traceability-schema/test-strategy-profile-v1.example.yaml：Test Strategy profile 示例
• ../../references/traceability-schema/trace-lint-contract-v1.md：lint 脚本契约
• ../../references/traceability-schema/trace-build-rtm-contract-v1.md：RTM 聚合脚本契约

AskUserQuestion 模板

1. 基线确认

question: "请确认测试策略所依据的最新批准基线："
header: "测试基线"
multiSelect: false
options:
  - label: "当前提供的 PRD/API/HLD 就是最新基线"
    description: "可直接按当前文档编写测试策略"
  - label: "还需补充 Guardrails / ADR"
    description: "存在额外约束文档，补齐后再定策略"
  - label: "基线未冻结"
    description: "先记录草案，暂不形成正式测试策略"

2. 风险容忍度确认

question: "本次变更最不能接受哪类失败？"
header: "风险优先级"
multiSelect: true
options:
  - label: "核心业务流程失败"
    description: "如注册、下单、支付、登录等核心路径"
  - label: "数据错误或不一致"
    description: "写错、漏写、重复写、脏数据"
  - label: "兼容性回归"
    description: "老客户端、老集成方、旧数据受影响"
  - label: "性能或稳定性下降"
    description: "响应时间、吞吐、错误率、恢复能力恶化"

3. 依赖策略确认

question: "外部依赖在测试中优先采用哪种策略？"
header: "依赖策略"
multiSelect: false
options:
  - label: "真实依赖优先"
    description: "更接近生产，但成本更高、稳定性更受限"
  - label: "Sandbox / 测试实例优先"
    description: "兼顾真实度与可控性"
  - label: "Mock / Stub 优先"
    description: "便于覆盖异常与边界，但需补真实联调"

4. 阶段边界确认

question: "当前这轮测试策略，主要要为哪个测试阶段建立门禁？"
header: "测试阶段"
multiSelect: false
options:
  - label: "当前节点只定义本地/聚合验证阶段"
    description: "先收口当前阶段必须做的测试，后续环境级门禁单独列为下一阶段"
  - label: "当前节点覆盖到 Shared Test / SIT 阶段"
    description: "需要把共享测试环境下的门禁也一并纳入当前策略"
  - label: "当前节点直接覆盖到 Pre-prod / 发布门禁阶段"
    description: "当前策略需要明确发布前必须完成的环境级验证"

5. 环境弹性确认

question: "同一测试阶段是否允许多个环境作为等价执行面？"
header: "环境弹性"
multiSelect: false
options:
  - label: "允许，只要满足该阶段能力要求"
    description: "环境是能力载体，不和阶段强绑定"
  - label: "不允许，必须固定在指定环境"
    description: "该阶段只接受唯一环境，便于统一证据和门禁"
  - label: "部分允许，关键门禁仍需固定环境"
    description: "基础验证可灵活，发布前关键门禁要求指定环境"

Test Strategy Template

# Test strategy: {project/function name}

<!-- TRACEABILITY-METADATA:BEGIN -->

schema: name: testany-traceability version: "1.0.0" profile: test-strategy-profile-v1 artifact: id: TSTRAT-[DOMAIN]-001 type: TEST_STRATEGY title: {project/function name} status: draft owners: [] created_at: YYYY-MM-DD updated_at: YYYY-MM-DD source_documents: [] entities: requirements: [] risks: [] must_not_regress: [] external_behaviors: [] decisions: [] flows: [] test_cases: [] relations: [] waivers: []

<!-- TRACEABILITY-METADATA:END -->

## Basic Information

- **PRD Baseline**: {path} v{version}
- **API Contract Baseline**: {path} v{version}
- **HLD Baseline**: {path} v{version}
- **Guardrails**: {path} / N/A
- **Writing time**: {YYYY-MM-DD}
- **Status**: Draft/Reviewed/Approved

## Context Collection Report

### Baseline Confirmed
- {Baseline 1}
- {Baseline 2}

### Key constraints
- {constraint 1}
- {Constraint 2}

### Risks identified
- {Risk 1}
- {Risk 2}

## Test target

- {Target 1}
- {Target 2}

## scope

### In-scope
- {content}

### Out-of-scope
- {content}

### Must-not-regress
- {Capabilities/Processes}

## Quality Risk List

| Risk ID | Risk Description | Source Baseline | Impact | Probability | Priority |
|---------|----------|----------|------|------|--------|
| RISK-XXX-001 | {Description} | PRD/HLD/API | High/Medium/Low | High/Medium/Low | High/Medium/Low |

## Independent test layer allocation matrix

| Risk/Capability | System Integration | E2E / Journey | Regression | Compatibility | Non-functional | Owner |
|-----------|--------------------|---------------|------------|---------------|----------------|-------|
| {Capacity/Risk} | Main/Auxiliary/No | Main/Auxiliary/No | Main/Auxiliary/No | Main/Auxiliary/No | Main/Auxiliary/No | {Role} |

## API Contract Verification Strategy

- **Responsibility Boundary**: QA is responsible for approving the black box verification and regression of the API Contract; if development/SDET provides provider-side contract suite, it is only used as supplementary evidence
- **Validation Scope**: {Interface Group/Operation/Verification Point List}
- **Coverage dimensions**: {path/method/parameters/headers/request fields/response fields/status codes/error semantics/permissions/idempotent/compatible semantics}
- **Execution layer and evidence**: {System Integration / Regression / Evidence requirements}

## Staged execution rules

### Stage definition

| Phase | Phase goal | Current phase must be completed | Current phase should not be executed | Not ready item status |
|------|----------|------------------|------------------|--------------|
| {stage name} | {goal} | {content} | {content} | PASS / FAIL / BLOCKED / DEFERRED / N/A |

### Stage and environment mapping principles

- **Phase is a hard constraint**: You must first define which test phase the current node belongs to, and then decide which tests should be executed.
- **Environment is a soft boundary**: The environment is used to carry the capabilities and evidence sources required for this stage and cannot directly replace the stage definition.
- **Multiple environments are acceptable in the same stage**: as long as these environments can meet the verification capabilities, data conditions and observation requirements of the stage.
- **Subsequent stage access control**: Test items belonging to the subsequent stage. If the environment is not ready in the current stage, it should be marked as `Blocked / Deferred` instead of being directly recorded as a function failure.

## Environment, data, dependency strategy

### Environmental Strategy
- {Environmental Description}
- It must be written clearly: which testing phase the environment serves, what capabilities it provides, and whether it is only a recommended environment rather than the only environment

### Data Strategy
- {Data Preparation/Isolation/Cleaning}

### Dependency strategy
- {mock/stub/real dependency boundary}

### Observation and Verification
- {log/metrics/trace/DB/event}

## Develop built-in validation preconditions

- **Unit Test**: Responsible for development, status/requirements: {Description}
- **Code-level Integration Test**: Responsible for development, status/requirements: {Description}
- **Optional supplementary evidence**: If development/SDET provides provider-side contract suite/calling script, record status: {Description}
- **Note**: Approval of the black box verification of the API Contract belongs to the In-scope of this testing strategy and cannot be excluded as an upstream precondition

## Entry standards

- {Standard 1}
- {Standard 2}
- {Entrance prerequisite for the current stage}

## Export standards

- {Standard 1}
- {Standard 2}
- {Exit threshold at current stage}
- {Transfer conditions for retaining access control in subsequent stages}

## Automation and regression strategies

### Smoke
- {content}

### Critical Regression
- {content}

### Compatibility Regression
- {content}

## Assumptions, exemptions, items to be confirmed

| Type | Content | Impact | Owner | Deadline |
|------|------|------|-------|----------|
| Assumptions/Exemptions/To Be Confirmed | {Description} | {Impact} | {Person/Role} | {Date} |

Test Strategy 模板

# 测试策略：{项目/功能名称}

<!-- TRACEABILITY-METADATA:BEGIN -->

schema: name: testany-traceability version: "1.0.0" profile: test-strategy-profile-v1 artifact: id: TSTRAT-[DOMAIN]-001 type: TEST_STRATEGY title: {项目/功能名称} status: draft owners: [] created_at: YYYY-MM-DD updated_at: YYYY-MM-DD source_documents: [] entities: requirements: [] risks: [] must_not_regress: [] external_behaviors: [] decisions: [] flows: [] test_cases: [] relations: [] waivers: []

<!-- TRACEABILITY-METADATA:END -->

## 基本信息

- **PRD 基线**：{路径} v{版本}
- **API Contract 基线**：{路径} v{版本}
- **HLD 基线**：{路径} v{版本}
- **Guardrails**：{路径} / N/A
- **编写时间**：{YYYY-MM-DD}
- **状态**：Draft / Reviewed / Approved

## 上下文收集报告

### 已确认基线
- {基线 1}
- {基线 2}

### 关键约束
- {约束 1}
- {约束 2}

### 已识别风险
- {风险 1}
- {风险 2}

## 测试目标

- {目标 1}
- {目标 2}

## 范围

### In-scope
- {内容}

### Out-of-scope
- {内容}

### Must-not-regress
- {能力/流程}

## 质量风险清单

| 风险 ID | 风险描述 | 来源基线 | 影响 | 概率 | 优先级 |
|---------|----------|----------|------|------|--------|
| RISK-XXX-001 | {描述} | PRD/HLD/API | 高/中/低 | 高/中/低 | 高/中/低 |

## 独立测试层分配矩阵

| 风险/能力 | System Integration | E2E / Journey | Regression | Compatibility | Non-functional | Owner |
|-----------|--------------------|---------------|------------|---------------|----------------|-------|
| {能力/风险} | 主/辅/否 | 主/辅/否 | 主/辅/否 | 主/辅/否 | 主/辅/否 | {角色} |

## API Contract 验证策略

- **责任边界**：QA 主责批准 API Contract 的黑盒验证与回归；若开发/SDET 提供 provider-side contract suite，仅作为补充证据
- **验证范围**：{接口组 / 操作 / 验证点清单}
- **覆盖维度**：{路径/方法/参数/headers/请求字段/响应字段/状态码/错误语义/权限/幂等/兼容语义}
- **执行层与证据**：{System Integration / Regression / 证据要求}

## 阶段化执行规则

### 阶段定义

| 阶段 | 阶段目标 | 当前阶段必须完成 | 当前阶段不应执行 | 未就绪项状态 |
|------|----------|------------------|------------------|--------------|
| {阶段名} | {目标} | {内容} | {内容} | PASS / FAIL / BLOCKED / DEFERRED / N/A |

### 阶段与环境映射原则

- **阶段是硬约束**：必须先定义当前节点属于哪个测试阶段，再决定应该执行哪些测试。
- **环境是软边界**：环境用于承载该阶段所需能力与证据来源，不能直接替代阶段定义。
- **同一阶段可接受多个环境**：只要这些环境能满足该阶段的验证能力、数据条件和观测要求。
- **后续阶段门禁**：属于后续阶段的测试项，在当前阶段若环境未就绪，应标记为 `Blocked / Deferred`，而不是直接记为功能失败。

## 环境、数据、依赖策略

### 环境策略
- {环境说明}
- 必须写清：该环境服务于哪个测试阶段、提供哪些能力、是否只是推荐环境而非唯一环境

### 数据策略
- {数据准备/隔离/清理}

### 依赖策略
- {mock/stub/real dependency 边界}

### 观测与验证
- {日志/指标/trace/DB/事件}

## 开发内建验证前置条件

- **Unit Test**：由开发负责，状态/要求：{说明}
- **Code-level Integration Test**：由开发负责，状态/要求：{说明}
- **可选补充证据**：若开发/SDET 提供 provider-side contract suite / 调用脚本，记录状态：{说明}
- **说明**：批准 API Contract 的黑盒验证属于本测试策略 In-scope，不得作为上游前置条件排除

## 入口标准

- {标准 1}
- {标准 2}
- {当前阶段的入口前提}

## 出口标准

- {标准 1}
- {标准 2}
- {当前阶段的出口门槛}
- {后续阶段保留门禁的移交条件}

## 自动化与回归策略

### Smoke
- {内容}

### Critical Regression
- {内容}

### Compatibility Regression
- {内容}

## 假设、豁免、待确认项

| 类型 | 内容 | 影响 | Owner | 截止时间 |
|------|------|------|-------|----------|
| 假设/豁免/待确认 | {描述} | {影响} | {人/角色} | {日期} |