test-planner

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

Files5

View on GitHub

SKILL.md

GitHub

测试计划生成器

何时使用

满足以下任一条件时触发本 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 维度
API 设计 输入含 api-design.md api-design.md 接口契约/错误码 走 API 设计模式：使用 strategies/api.md 维度

三种模式的本质区别：

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

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

输出：

## 测试对象识别

- 对象类型：{需求文档模式 / 设计文档模式 / 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/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）。 API 设计模式：从 api-design.md 提取接口清单 / 接口契约 / 错误码定义 / 鉴权方式 / 写操作（提取项见 strategies/api.md）。

1.3 输出解析结果

## 需求解析结果

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

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

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

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

2.1 来源文本分析

需求文档模式：对每个 REQ 的验收标准做关键词匹配（下表）。设计文档模式：按设计特征（接口/非功能/数据）选策略，映射见 strategies/design.md。API 设计模式：按 API 特征（契约/鉴权/限流）选策略，映射见 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 输出策略选择结果

## 测试策略选择

| 需求 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 输出测试落盘判断

## 测试落盘位置判断

| 被测模块 | 测试代码位置 | 框架 | 运行命令 | 可执行性 |
|----------|-------------|------|----------|----------|
| 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 测试用例结构

每个测试用例包含：

#### 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（设计点/接口契约/数据流/时序）生成；API 设计模式按 strategies/api.md（契约符合/入参边界/错误码/鉴权/幂等并发）生成。

功能型：三路径覆盖

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

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

否定型：权限 + 非法输入

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

度量型：基线 + 目标

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

性能型：单用户 + 并发

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

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

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

数据型：完整性 + 一致性

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

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

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

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

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

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

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

3.3 测试计划结构

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

## 概述
- 测试对象：{需求文档模式 / 设计文档模式 / 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 输出概览

## 测试计划生成完成

- **测试对象**：{需求文档模式 / 设计文档模式 / 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
  • API 设计模式策略：strategies/api.md
  • 测试落盘位置判断方式参考：use_skill("expert-team")（测试信息采集 / 切面级标注 / 四态可执行性 / 测试不可运行跳过）
  • 对比例子：references/examples/

Related in testing

frontend-testing-langgenius-dify

Generate Vitest + React Testing Library tests for Dify frontend components, hooks, and utilities. Triggers on testing, s...

by langgenius
127,079

skill-creator-langgenius-dify

Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an exist...

by langgenius
127,079

browser-use-browser-use-browser-use

Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs...

by browser-use
76,633