Test Planner

---
name: test-planner
agent_created: true
description: 读取测试来源文档（需求 / 设计 / API 设计），生成可直接落地为可运行测试代码的结构化测试计划（测试策略、框架与断言方式、落盘位置）。触发："生成测试计划"、"写测试用例"、"test plan"、"从设计生成测试"、"根据需求写测试"、"API 契约测试"。
---

# 测试计划生成器

## 何时使用

满足以下任一条件时触发本 skill：

**需求文档模式**（默认）：
- 用户要求基于需求文档生成测试计划或测试用例
- requirement-mining 完成后需要生成测试文档
- 用户说"写测试用例"、"生成测试计划"、"test plan"、"根据需求写测试" 等

**设计文档模式**：
- 用户要求基于技术设计文档生成测试
- design-craft 完成后，希望在编码前从设计点/接口/数据流生成测试
- 用户说"从设计生成测试"、"设计点测试"、"接口契约测试" 等

**API 设计模式**：
- 用户要求基于 API 设计文档生成契约测试
- api-design 完成后，需要生成接口契约/错误码覆盖测试
- 用户说"API 契约测试"、"接口测试用例"、"错误码覆盖测试" 等

### 何时不使用

- 用户要求直接写测试代码（pytest/jest 等）→ 不触发，直接帮写
- 三种来源文档都没有 → 提示用户提供任一来源
- 用户只是问"测试怎么写" → 直接回答，不走完整流程

## 核心原则

1. **需求驱动**：每个测试用例必须追溯到 requirement.md 中的具体 REQ 条目，不凭空编造测试场景
2. **策略匹配**：根据验收标准的文本特征自动选择测试策略，不用同一套模板写所有测试
3. **可执行性**：测试用例必须包含具体步骤和明确的预期结果，不是抽象描述
4. **覆盖率可见**：输出 REQ → 测试用例的覆盖矩阵，一眼看出哪些需求有测试、哪些没有
5. **边界优先**：除正常路径外，每个功能型测试必须包含异常路径和边界条件
6. **体验双轨**：功能型测试必须同时评估正向体验（好不好用）和负向体验（犯错时是否依然好用）
7. **对象模式不越界**：需求模式只测验收标准，设计模式只测设计点/接口/数据流，API 模式只测契约/错误码；不跨模式编造测试来源
8. **测试位置可落地**：测试计划必须判断测试代码的落盘位置（扫描项目测试目录约定，不假设固定路径），标注测试框架 / 运行命令 / 可执行性（✅ 可跑 / ⚠️ 依赖外部环境 / ❌ 无法运行 / 无测试 / ❓ 可执行性未知），使计划可直接落地为可运行测试代码；判断方式参考 expert-team 的测试信息采集

## 工作流总览

```
阶段 0：对象类型识别          → 判定测试来源：需求文档 / 设计文档 / API 设计，决定后续分支
阶段 1：加载来源文档          → 按对象类型读取 requirement.md / DESIGN.md / api-design.md，解析测试对象
阶段 2：来源分析 + 策略选择   → 按对象类型分析验收标准/设计特征/API 契约，自动选择测试策略
阶段 2.5：测试落盘位置判断    → 扫描项目测试目录约定/框架/运行命令，切面级标注可执行性（四态 + 未知，参考 expert-team）
阶段 3：测试计划生成          → 按策略模板逐测试对象生成测试用例
阶段 4：质量检查              → 覆盖率验证 + 用例完整性检查 + 落盘可执行性检查
阶段 5：输出落盘              → 写入测试计划文档，输出覆盖矩阵 + 测试代码落盘指引
```

## 阶段 0：对象类型识别

测试开始前先判定测试来源类型，决定后续所有阶段走哪条分支。

| 对象类型 | 判定依据 | 测试来源 | 后续分支 |
|----------|---------|----------|---------|
| **需求文档** | 输入含 requirement.md（无 DESIGN.md / api-design.md） | requirement.md 验收标准 | 走需求文档模式：阶段 2 按验收标准关键词选 7 策略 |
| **设计文档** | 输入含 DESIGN.md | DESIGN.md 设计点/接口/数据模型/时序 | 走设计文档模式：使用 [strategies/design.md](strategies/design.md) 维度 |
| **API 设计** | 输入含 api-design.md | api-design.md 接口契约/错误码 | 走 API 设计模式：使用 [strategies/api.md](strategies/api.md) 维度 |

**三种模式的本质区别**：

| 维度 | 需求文档模式 | 设计文档模式 | API 设计模式 |
|------|------------|------------|------------|
| 测试来源 | requirement.md 验收标准 | DESIGN.md 设计点/接口/数据流 | api-design.md 契约/错误码 |
| 策略选择依据 | 验收标准关键词 | 设计特征（接口/非功能/数据） | API 特征（契约/鉴权/限流） |
| 验证目标 | 需求是否被满足 | 设计点是否可测、契约是否一致 | 契约符合性、错误码覆盖 |
| 触发时机 | requirement-mining 之后 | design-craft 之后 | api-design 之后 |

> 若用户同时给了多种来源文档，默认按"最具体者"判定：有 api-design.md 走 API 模式，否则有 DESIGN.md 走设计模式，否则走需求模式。用户明确指定时从其指定。

**输出**：

```markdown
## 测试对象识别

- 对象类型：{需求文档模式 / 设计文档模式 / API 设计模式}
- 测试来源：{requirement.md / DESIGN.md / api-design.md 路径}
- 后续分支：{按验收标准选 7 策略 / 按 strategies/design.md / 按 strategies/api.md}
```

---

## 阶段 1：加载来源文档

### 1.1 定位来源文档

> 本节默认描述**需求文档模式**的定位。设计文档模式定位 `DESIGN.md`（项目根或 `.requirements/.../DESIGN.md`），API 设计模式定位 `api-design.md`（同目录或 api-design 产出路径）；解析规则见 [strategies/design.md](strategies/design.md) / [strategies/api.md](strategies/api.md)。

按以下优先级查找需求文档：

1. 用户指定的路径（直接使用）
2. `.requirements/config` 中的 `storage_path` 配置 → `{storage_path}/{最新日期}-{feature-name}/requirement.md`
3. 项目根目录的 `requirement.md` 或 `requirements.md`

若未找到，提示用户：
```
未找到 requirement.md。请提供需求文档路径，或先运行 requirement-mining 生成需求文档。
```

### 1.2 解析 REQ 列表

从 requirement.md 的「需求拆分清单」表格中提取：

| 提取字段 | 来源 |
|----------|------|
| 需求 ID | `REQ-xx` 列 |
| 需求描述 | 需求描述列 |
| 验收标准 | 验收标准列 |
| 依赖 | 依赖列 |

同时提取「潜在风险与注意事项」和「非功能性约束」，作为补充测试场景的来源。

> **设计文档模式**：从 DESIGN.md 提取设计点 / 接口设计 / 数据模型 / 时序图 / 非功能需求（提取项见 [strategies/design.md](strategies/design.md)）。
> **API 设计模式**：从 api-design.md 提取接口清单 / 接口契约 / 错误码定义 / 鉴权方式 / 写操作（提取项见 [strategies/api.md](strategies/api.md)）。

### 1.3 输出解析结果

```markdown
## 需求解析结果

- **需求文档**：{路径}
- **需求条目数**：{N} 个
- **需求 ID 列表**：REQ-01, REQ-02, ...

请确认解析结果后开始生成测试计划。
```

## 阶段 2：来源分析 + 策略选择

**辅助——强关联关系查询**：设计涉及模块间依赖/数据流/集成边界的测试时，可调用 `use_skill("ki-memory-lookup")` 检索相关模块的强关联关系（跨模块契约/业务耦合），辅助判断需覆盖的集成测试与契约测试范围（查询失败或无可用记录，忽略继续）。

### 2.1 来源文本分析

> **需求文档模式**：对每个 REQ 的验收标准做关键词匹配（下表）。**设计文档模式**：按设计特征（接口/非功能/数据）选策略，映射见 [strategies/design.md](strategies/design.md)。**API 设计模式**：按 API 特征（契约/鉴权/限流）选策略，映射见 [strategies/api.md](strategies/api.md)。

对每个 REQ 的验收标准做关键词匹配，识别测试策略类型。详细策略见 `references/test-strategies.md`。

| 验收标准特征 | 关键词/模式 | 测试策略 |
|-------------|------------|----------|
| 功能型 | 「可以」「能够」「支持」「正常」「完成」 | 正常路径 + 异常路径 + 边界条件 |
| 否定型 | 「不能」「禁止」「不可」「拒绝」「阻止」 | 越权/注入/非法输入测试 |
| 度量型 | 数字 + 比较（≥/≤/>/< /减少/提升/达到） | 构造对比场景 + 量化断言 |
| 性能型 | 「响应时间」「延迟」「并发」「吞吐」「< Xms」 | 压测 + 响应时间断言 |
| 安全型 | 「权限」「加密」「认证」「授权」「防护」 | 权限矩阵 + 认证绕过测试 |
| 数据型 | 「数据」「记录」「持久化」「同步」「备份」「一致」 | 数据完整性 + 数据流断言 |
| 体验型 | 「步骤减少」「满意度」「学习成本」「易用」 | 用户流程测试 + 可用性验证 |

**多策略匹配**：一个验收标准可能同时匹配多种策略（如「无权限用户不能访问数据，响应时间 < 200ms」= 否定型 + 性能型）。此时生成多种类型的测试用例。

### 2.2 项目类型识别

从 requirement.md 或项目结构推断项目类型，影响测试框架和断言方式选择：

| 项目类型 | 测试框架倾向 | 特殊测试考虑 |
|----------|-------------|-------------|
| 库/SDK | 单元测试框架 | API 契约、向后兼容、类型安全 |
| CLI | 终端测试工具 | exit code、stdout/stderr、管道组合 |
| Web 应用 | E2E + API 测试 | 浏览器兼容、响应式、无障碍 |
| 插件/扩展 | 集成测试 | 宿主兼容性、配置组合矩阵 |

### 2.3 输出策略选择结果

```markdown
## 测试策略选择

| 需求 ID | 验收标准关键词 | 识别策略 | 项目类型调整 |
|---------|---------------|----------|-------------|
| REQ-01 | 「可以正常登录」 | 功能型 | Web → E2E 登录流程 |
| REQ-02 | 「减少 50%」 | 度量型 | — |
| REQ-03 | 「响应时间 < 200ms」 | 性能型 | — |

确认后开始生成测试用例。
```

## 阶段 2.5：测试代码落盘位置判断

> 测试计划最终要落地为可运行的测试代码。**参考 expert-team 模块扫描时的测试信息采集方式**：不假设固定位置，通过扫描项目结构判断测试代码应存放的位置，并标注测试框架、运行命令与可执行性，确保计划可直接落地。本阶段对三种对象模式通用，在生成测试用例前完成。**若用户明确只需要计划文档、暂不落地测试代码，可将本阶段简化为「按项目类型给出默认建议位置 + 标注待确认」，不做完整扫描**。

### 2.5.1 扫描定位测试目录（不假设固定路径）

用 `list_dir` / `search_file` 扫描项目结构，识别测试代码的存放约定：

| 项目结构线索 | 判定 |
|-------------|------|
| 顶层 `tests/` 或 `test/` 目录 | 测试集中存放，按被测模块分文件（如 `tests/test_auth.py`） |
| 与源码同目录的 `test_*.py` / `*_test.py` / `*_test.go` / `*.test.ts` | 测试与被测代码同目录、镜像结构 |
| `src/` 下镜像的 `__tests__/` 目录 | 前端常见，测试与被测模块一一对应 |
| `pytest.ini` / `pyproject.toml` / `package.json` / `go.mod` / `Cargo.toml` / `Makefile` 中声明的测试路径 | 以配置声明的测试路径为准 |

**判定规则**：
- 存在既有测试目录 → 新测试代码**落入既有约定**，不新建目录
- 无既有测试目录 → 按项目类型推荐默认位置（库/SDK → `tests/`；Web → `src/**/__tests__/`；CLI → `tests/`；插件/扩展 → `tests/` 或宿主约定），标注「新建测试目录」，落地时按项目团队约定调整
- **项目代码不可达**（仅提供来源文档、无代码可扫描）→ 按项目类型推荐默认位置，标注「待确认」，落地时由实施方按实际项目约定调整，不强行断言
- 多模块项目 → **切面级标注**：每个被测模块单独标注测试位置（如 `tests/test_auth.py`、`tests/test_billing.py`），不混级

### 2.5.2 识别测试框架与运行命令

从配置 / 依赖 / 既有测试文件推断框架，给出运行命令：

| 技术栈 | 常见框架 | 运行命令示例 |
|--------|---------|-------------|
| Python | pytest / unittest | `uv run pytest tests/test_auth.py` |
| JS/TS | jest / vitest / mocha | `npm test -- tests/auth.test.ts` |
| Go | go test | `go test ./tests/...` |
| Rust | cargo test | `cargo test` |
| Java | JUnit / TestNG | `mvn test -Dtest=AuthTest` |

### 2.5.3 测试可执行性标注（四态 + 未知标注）

参考 expert-team 的测试可执行性标注，对目标测试位置给出四态结论；**无法确认可执行性时标注「可执行性未知」，不强行四态**：

| 标注 | 含义 | 对测试计划的影响 |
|------|------|-----------------|
| ✅ 可跑 | 环境就绪，可直接运行 | 用例可直接落地为代码并执行验证 |
| ⚠️ 依赖外部环境 | 需 DB / MQ / Redis / 外部服务 | 用例标注环境依赖，落地时补齐环境后运行 |
| ❌ 无法运行 | 环境缺失且无法补齐 / 命令跑不起来 | 按「测试不可运行跳过」规则：标注跳过运行验证，只产出用例内容 |
| 无测试 | 项目无测试基础设施 | 标注「新建测试基础设施」，落地时先搭建框架 |
| ❓ 可执行性未知 | 项目代码不可达 / 无法确认能否运行 | 标注「待确认」，落地时先验证环境再定运行方式 |

### 2.5.4 输出测试落盘判断

```markdown
## 测试落盘位置判断

| 被测模块 | 测试代码位置 | 框架 | 运行命令 | 可执行性 |
|----------|-------------|------|----------|----------|
| auth | tests/test_auth.py（既有约定） | pytest | `uv run pytest tests/test_auth.py` | ✅ 可跑 |
| billing | tests/test_billing.py（新建） | pytest | `uv run pytest tests/test_billing.py` | ⚠️ 依赖 DB |
| profile | tests/test_profile.py（待确认） | pytest | `uv run pytest tests/test_profile.py` | ❓ 可执行性未知 |
```

## 阶段 3：测试计划生成

### 3.1 测试用例结构

每个测试用例包含：

```markdown
#### TC-{REQ-ID}-{序号}：{用例标题}

- **关联需求**：REQ-{xx}
- **测试策略**：{功能型/度量型/性能型/...}
- **优先级**：P0/P1/P2

**前置条件**：
- {条件 1}
- {条件 2}

**测试步骤**：
1. {步骤 1}
2. {步骤 2}
3. ...

**预期结果**：
- {结果 1}
- {结果 2}

**通过标准**：
- {明确的判定条件，如「返回状态码 200」/「操作步骤 ≤ 3 步」}
```

### 3.2 各策略的用例生成规则

> 下表为**需求文档模式**的 7 策略用例规则。**设计文档模式**按 [strategies/design.md](strategies/design.md)（设计点/接口契约/数据流/时序）生成；**API 设计模式**按 [strategies/api.md](strategies/api.md)（契约符合/入参边界/错误码/鉴权/幂等并发）生成。

#### 功能型：三路径覆盖

每个功能型验收标准生成 3 类用例：

| 路径 | 说明 | 示例 |
|------|------|------|
| 正常路径 | 按预期输入操作，验证功能可用 | 正确密码登录 → 成功 |
| 异常路径 | 非法/错误输入，验证系统容错 | 错误密码登录 → 提示错误 |
| 边界条件 | 极值/空值/特殊字符 | 空密码登录 → 提示必填 |

#### 否定型：权限 + 非法输入

| 场景 | 说明 |
|------|------|
| 越权访问 | 用低权限账户尝试高权限操作 |
| 非法输入 | SQL 注入、XSS、路径遍历等 |
| 绕过认证 | 直接访问受保护接口，不携带凭证 |

#### 度量型：基线 + 目标

| 步骤 | 说明 |
|------|------|
| 建立基线 | 记录当前指标值 |
| 执行操作 | 完成目标功能 |
| 对比验证 | 指标是否达到验收标准中的数值 |

#### 性能型：单用户 + 并发

| 场景 | 说明 |
|------|------|
| 单用户响应 | 单次请求的响应时间 |
| 并发压测 | N 个并发请求下的响应时间和成功率 |
| 持续负载 | 长时间运行下的稳定性 |

#### 安全型：认证 + 授权 + 注入

| 场景 | 说明 |
|------|------|
| 认证测试 | 登录绕过、Token 过期、会话管理 |
| 授权测试 | 越权访问、角色权限矩阵 |
| 注入测试 | SQL/NoSQL/命令注入 |

#### 数据型：完整性 + 一致性

| 场景 | 说明 |
|------|------|
| 写入验证 | 数据写入后能正确读取 |
| 流转验证 | 数据在各模块间正确传递 |
| 异常恢复 | 数据损坏/丢失后的恢复能力 |

#### 体验型：正向体验 + 负向体验

体验型测试分为两个维度，**必须同时覆盖**：

**① 正向体验（功能正确时，体验是否良好）**

| 场景 | 说明 | 评估要点 |
|------|------|----------|
| 操作流畅度 | 完成核心功能的操作是否连贯顺畅 | 有无不必要的页面跳转/等待/重复操作 |
| 反馈及时性 | 操作后系统反馈是否即时且清晰 | 成功/进度/完成状态是否有明确提示 |
| 优化空间 | 当前流程是否还能进一步简化 | 是否有可合并的步骤、可省略的中间态 |
| 认知负担 | 用户完成操作需要记住多少信息 | 关键信息是否可见而非需要记忆 |

**② 负向体验 / 傻瓜式测试（用户犯错时，体验是否依然良好）**

| 场景 | 说明 | 评估要点 |
|------|------|----------|
| 错误可理解性 | 错误信息是否用用户能理解的语言描述 | 避免技术黑话（如 "NullPointerException"），用用户语言（如 "找不到对应记录，请检查名称是否正确"） |
| 错误引导性 | 错误信息是否不仅指出问题，还引导解决 | 好的错误信息 = 描述问题 + 原因 + 建议操作（如 "密码至少 8 位，当前仅 6 位，请补充 2 位以上"） |
| 恢复路径 | 出错后用户能否轻松回到正确路径 | 是否提供「重试」「返回修改」等操作，而非让用户自行重新开始 |
| 防呆设计 | 系统是否提前阻止明显错误的操作 | 输入时即校验（如格式提示、下拉选择而非自由输入），而非提交后才报错 |
| 故意作恶测试 | 故意输入错误参数/乱操作，观察系统反应 | 乱点按钮、输入超长字符串、上传错误格式文件、并发重复提交 — 错误信息是否仍有引导 |

### 3.3 测试计划结构

```markdown
# 测试计划：{功能名称}

## 概述
- 测试对象：{需求文档模式 / 设计文档模式 / API 设计模式}
- 关联来源：{requirement.md / DESIGN.md / api-design.md 路径}
- 来源条目数：{N}
- 测试用例数：{M}
- 覆盖率：{M/N} 的来源条目有对应测试用例

## 测试用例

### REQ-01：{需求描述}

#### TC-REQ-01-01：{正常路径用例}
...

#### TC-REQ-01-02：{异常路径用例}
...

#### TC-REQ-01-03：{边界条件用例}
...

### REQ-02：{需求描述}
...

## 覆盖矩阵

| 需求 ID | 验收标准 | 测试策略 | 用例数 | 用例 ID 列表 |
|---------|----------|----------|--------|-------------|
| REQ-01 | ... | 功能型 | 3 | TC-REQ-01-01, 02, 03 |
| REQ-02 | ... | 度量型 | 2 | TC-REQ-02-01, 02 |

## 未覆盖需求

| 需求 ID | 原因 |
|---------|------|
| REQ-xx | 验收标准无法自动化验证，需人工评估 |

## 非功能性测试

{从 requirement.md 的「非功能性约束」和「潜在风险」中提取的补充测试场景}

## 风险测试

{从 requirement.md 的「潜在风险与注意事项」中提取的测试场景}

## 测试落盘指引

| 被测模块 | 测试代码位置 | 框架 | 运行命令 | 可执行性 |
|---------|-------------|------|----------|----------|
| {模块} | {tests/test_xx.py（既有约定 / 新建 / 待确认）} | {框架} | {运行命令} | {✅ 可跑 / ⚠️ 依赖外部环境 / ❌ 无法运行 / 无测试 / ❓ 可执行性未知} |

- 每个测试用例标注目标代码位置（基于项目扫描，非假设固定路径）
- 「❌ 无法运行」的模块：标注跳过原因，不产出运行验证步骤
- 「无测试」的项目：标注先搭建测试框架，再落地用例
- 「❓ 可执行性未知」：标注「待确认」，落地时先验证环境
```

## 阶段 4：质量检查

### 4.1 覆盖率检查

- [ ] 每个 REQ 条目至少有一个测试用例（或标注为「未覆盖」并说明原因）
- [ ] P0 需求（核心）100% 覆盖
- [ ] 覆盖矩阵中用例 ID 与实际用例一一对应

### 4.2 用例完整性检查

- [ ] 每个功能型用例包含正常路径 + 异常路径
- [ ] 每个用例有明确的通过标准（可判定 pass/fail）
- [ ] 前置条件完整（不依赖隐含假设）
- [ ] 测试步骤可执行（不含「验证系统正常」等模糊描述）

### 4.3 策略匹配检查

- [ ] 验收标准含数字的 REQ 必须有度量型或性能型用例
- [ ] 验收标准含「不能/禁止」的 REQ 必须有否定型用例
- [ ] 测试策略与验收标准特征匹配

### 4.4 体验深度检查

- [ ] 每个功能型 REQ 必须至少有 1 个正向体验用例（评估操作流畅度/反馈/优化空间）
- [ ] 每个功能型 REQ 必须至少有 1 个负向体验/傻瓜式用例（故意犯错，评估错误引导）
- [ ] 负向体验用例的预期结果中必须包含「错误信息的具体内容」和「是否引导解决」，而非仅写「显示错误提示」
- [ ] 至少有 1 个「故意作恶」测试（超长输入/错误格式/并发重复等极端场景）

### 4.5 修正缺陷

检查不通过时，修正后重新检查。

### 4.6 对象模式一致性检查

- [ ] 测试对象与阶段 0 识别一致，未跨模式编造来源
- [ ] 设计文档模式：每个关键设计点至少有 1 个可达性用例；接口的每个错误码都有触发用例
- [ ] API 设计模式：每个定义的错误码都有触发用例；写接口有幂等/并发用例；每个接口有鉴权用例
- [ ] 所有模式：测试用例可追溯到来源文档的具体条目（REQ / 设计点 / 接口）

### 4.7 落盘可执行性检查

- [ ] 每个测试用例标注目标测试代码位置（基于项目扫描，非假设固定路径）
- [ ] 测试框架与运行命令可从配置/依赖/既有测试文件推断，非编造
- [ ] 可执行性标注完整（✅ 可跑 / ⚠️ 依赖外部环境 / ❌ 无法运行 / 无测试 / ❓ 可执行性未知），无法确认时不强行四态
- [ ] 「❌ 无法运行」的模块标注跳过原因，不在运行验证上死磕
- [ ] 多模块项目按切面级标注测试位置，不混级

## 阶段 5：输出落盘

### 5.1 写入文件

将测试计划写入 `{来源文档所在目录}/test-plan.md`（需求模式为 requirement.md 所在目录，设计模式为 DESIGN.md 所在目录，API 模式为 api-design.md 所在目录）。

### 5.2 输出测试代码落盘指引

将阶段 2.5 的判断结果写入测试计划「测试落盘指引」章节（见 3.3）：每个测试用例标注目标代码位置 + 运行命令 + 可执行性标注（四态 + 未知）；「❌ 无法运行」模块标注跳过原因，不产出运行验证步骤；「无测试」项目标注先搭建测试框架。

### 5.3 输出概览

```markdown
## 测试计划生成完成

- **测试对象**：{需求文档模式 / 设计文档模式 / API 设计模式}
- **输出文件**：{路径}
- **来源条目**：{N} 个
- **测试用例**：{M} 个
- **覆盖率**：{P}%（{X}/{N} 个来源条目有测试用例）
- **策略分布**：功能型 {a} 个 / 度量型 {b} 个 / 性能型 {c} 个 / ...

### 验证方式
- 打开 test-plan.md → 检查覆盖矩阵 → 确认 P0 来源条目全部覆盖
- 随机挑一个测试用例 → 检查步骤是否可执行
- 检查「测试落盘指引」→ 每个用例有目标代码位置 + 运行命令 + 可执行性标注
```

## 与相邻 skill 的边界

| skill | 关系 |
|-------|------|
| expert-team | 测试落盘位置判断方式与其模块扫描的测试信息采集一致（扫描定位不假设固定路径 + 切面级标注 + 四态可执行性 + 测试不可运行跳过）；其 `06-测试.md` 记录了既有测试位置，本 skill 生成新测试计划时可引用避免重复判断 |
| code-review | code-review 阶段 8 测试验证取用测试计划中的运行命令与可执行性标注；单测失败无法低成本修复时写入 known-failures |
| api-testing | api-testing 执行 HTTP 接口测试；本 skill 的 API 模式生成契约测试计划，测试代码可交由其执行验证 |
| code-survey | code-survey 是设计前的轻量代码调研；本 skill 在生成测试计划时按需做最小项目结构扫描（仅测试目录/框架），不做全量调研 |

## 参考

- 测试策略定义（需求文档模式）：`references/test-strategies.md`
- 设计文档模式策略：[strategies/design.md](strategies/design.md)
- API 设计模式策略：[strategies/api.md](strategies/api.md)
- 测试落盘位置判断方式参考：`use_skill("expert-team")`（测试信息采集 / 切面级标注 / 四态可执行性 / 测试不可运行跳过）
- 对比例子：`references/examples/`