module-test-design

Files (4)

• SKILL.md
• openai.yaml · agents/
• test-design-lite-template.md · references/
• test-design-template.md · references/

SKILL.md (first lines)

---
name: module-test-design
version: "2.3.2.4"
description: 把已定稿的设计目标、契约、流程、异常边界、风险和可测试性输入转化为可执行的最小充分验证集，输出独立测试用例设计文档。本 skill 只输出最小充分测试用例集、覆盖矩阵、断言、建议位置和缺口；不得替设计补内容，不得拆分 AICoding 任务。支持两种模式：严格模式（SR/AR 入口）基于模块目录下的正式《模块详细设计说明书.md》与 `.context/详细设计上下文.md`，生成同目录《模块测试用例设计.md》；轻量模式（dev 入口）基于单份 `dev-design.md`，生成 `.sdd/{SR}/test-design.md`，由工作单显式声明。
---

## 前置操作：工作流编排检查

若本 skill 是由 aaw-workflow 的工作单调用的，跳过本节，直接执行正文。

否则，在执行正文之前，先向用户发起一次二选一确认：

> 是否回到 aaw-workflow 工作流中执行？
> - 是，回到工作流（推荐）——进度会被跟踪和上报
> - 否，单独执行本 skill——本次执行将不纳入流程跟踪

- 用户选“是” → 加载 `aaw-workflow` skill，按其流程执行（其入口意图判定会引导继续已有工作流或新建），不再单独执行本 skill 正文。
- 用户选“否” → 继续执行本 skill 正文，之后不再提及工作流。

本节最多询问一次，不得重复打扰。

若工作单输出已存在，仍按当前要求完整执行：先读取并评估已有成果，复用仍有效的信息和已确认答案，可局部修改或整体重写，并写回原路径。

# SDD 模块测试用例设计

## 模式判定

本 skill 支持两种输入模式，由工作单（或调用上下文）里的标记决定：

- **严格模式（默认）**：SR/AR 入口调用。权威输入是《模块详细设计说明书》与 `.context/详细设计上下文.md`。按下方正文执行，输入缺失时按阻塞规则处理。
- **轻量模式**：dev 入口调用。工作单的 `prompt` 字段会显式声明"本实例为 module-test-design 的【轻量模式】"。此时权威输入只有 `.sdd/{SR}/dev-design.md`，不存在三件套，**也不要求它们**。按「轻量模式分支」执行，不要因为缺三件套而中止或引导用户跑 module-tobe-design / module-design-gate。

判定方法：若工作单 `prompt` 中存在"【轻量模式】"标记，进入轻量模式；否则（含单独调用、无标记的普通调用）一律按严格模式。

## 阶段规则

本 skill 自身定义测试用例设计阶段必须遵守的规则。它位于 `$module-tobe-design` 之后、`$module-design-gate` 之前，用于把 TOBE 中已经定稿的设计目标、契约、流程、异常边界、风险和可测试性输入转化为可执行的最小充分验证集。

本 skill 不编辑正式模块详细设计说明书正文，不覆盖 ASIS 事实，不拆分 AICoding 任务。若发现 TOBE 设计不足以支撑测试设计，必须输出阻塞或待补设计问题，要求回到 TOBE；不得自行补充错误码、字段语义、状态流转、兼容策略或验收阈值。

## 运行方式

本 skill 应由当前主 Agent 直接执行，不要通过 SubAgent 启动；遇到需要用户或上游确认的问题，应在当前会话及时问询，避免 SubAgent 的运转模式导致问询滞后。

如果当前环境提供 `ask_user` 工具，影响测试范围、验收阈值、人工验证边界或回流阶段的待确认项必须优先用 `ask_user` 发起问询，并在 `.context/详细设计上下文.md` 中记录问题、回答、影响范围和处理结论；测试设计只承接已确认的测试结论、缺口或回流建议。工具不可用时，才退回当前会话问询或标记为 `需前置确认`。

## 成果物协作规则

- 输入正式说明书：`.sdd/{SR}/{AR}/{模块组名}/模块详细设计说明书.md`。
- 输入过程上下文：`.sdd/{SR}/{AR}/{模块组名}/.context/详细设计上下文.md`。
- 输出测试设计：`.sdd/{SR}/{AR}/{模块组名}/模块测试用例设计.md`。
- 测试设计是独立成果物，供 Gate 统一审查；不得把测试用例写回 TOBE 正式说明书。
- 详细设计上下文只用于读取 ASIS 测试覆盖、证据索引和 TOBE 推导；测试设计正文必须自洽可读，不能要求后续执行者阅读详细设计上下文才理解用例。
- 正式测试设计只输出验证结论，不输出目标抽取、风险分级、用例合并、候选用例淘汰等推导过程。需要过程审计时，由 Gate 结合详细设计上下文和独立门禁结果反查。

## 测试设计哲学

测试设计的目标不是生成测试用例大全，而是形成“最小充分验证集”：用尽量少但足够有代表性的测试，证明 TOBE 的关键设计可实现、可观察、可回归保护。

- 从设计风险出发，不从测试类型出发。先判断哪些 TOBE 设计点如果错了会导致需求不成立、契约漂移、数据不一致、回退失效或关键风险失控。
- 优先验证行为闭环，而不是覆盖表面字段。测试应证明输入进入模块后，关键决策、状态变化、副作用、异常收敛和可观察信号符合设计。
- 合并验证目标，不机械展开用例。共享前置、执行路径和观察面的等价输入优先合并为一条参数化/表驱动用例；允许一条高质量用例覆盖多个 TOBE 决策、契约、状态变化或观察点。
- 默认最小集，风险触发才扩展。每个需求点优先覆盖主路径、关键失败路径、关键边界/兼容路径；契约、数据、配置、观测、安全、性能、并发、迁移等只在 TOBE 触发时补充。
- 不能验证的设计就是设计缺口。若无法写出输入、前置条件、预期结果、断言或观察点，应输出测试缺口并回流 TOBE / ASIS / 上游确认，不得硬凑用例。
- **本集合是下限，不是上限**：设计期只能看到设计面，实现期才会暴露真正的测试面（生命周期、边界行为、配置归一化等）。实现阶段发现的补充验证面由 `task-dev` 在实现期补测，并在 tasks-overview 执行记录的「实现期补充与残余风险」小节登记，不要求回流本文件。

## 输入

可以接受：

- 正式 TOBE 说明书路径或内容。
- `.context/详细设计上下文.md` 中的 ASIS 变更类型、ASIS 测试覆盖现状、证据索引和 TOBE 追踪矩阵，以及 `.context/模块设计门禁结果.md` 中的历史门禁问题。
- 上游验收标准、用户补充的测试要求。
- 代码仓中现有测试目录、测试框架、Fixture、Mock、构建命令和测试命令。

## 轻量模式分支

仅当工作单声明【轻量模式】时适用。

### 输入

| 输入 | 默认路径 | 要求 |
|---|---|---|
| 轻量设计文档 | `.sdd/{SR}/dev-design.md` | 必需。方案与契约变更章节是被验证设计的事实来源；验收标准章节是需求侧验收口径 |
| 轻量门禁结果 | `.sdd/{SR}/.context/dev-design-gate.md` | 可选。存在时参考其历史问题 |
| 软件架构 | `.sdd/software_architecture.md` | 可选 |

启动后校验：`dev-design.md` 真实存在且可读；其方案与契约变更足以支撑测试设计，验收标准覆盖需求的全部目标。**不要**校验三件套文档，**不要**因其缺失而中止。

`dev-design.md` 缺失，或验收/契约不足以写出输入、预期结果、断言时，按"不能验证的设计就是设计缺口"输出缺口并回流 `dev-design`；不得硬凑用例，也不得替设计补充错误码、字段语义或兼容策略。

### 与严格模式的差异

| | 严格模式 | 轻量模式 |
|---|---|---|
| 实现设计来源 | 《模块详细设计说明书》 | `dev-design.md` 的方案与契约变更章节 |
| 验收口径来源 | TOBE 可测试性与验收口径 | `dev-design.md` 的验收标准章节（需求侧口径） |
| 输出路径 | `.sdd/{SR}/{AR}/{模块组名}/模块测试用例设计.md` | `.sdd/{SR}/test-design.md` |
| 模板 | `references/test-design-template.md` | `references/test-design-lite-template.md` |
| 覆盖矩阵行 | TOBE 决策/契约/风险 | 验收标准条目 + 契约变更项 |
| 「首次可验证阶段」列 | 无 | 预留：设计时空着，由 task-split 回填 |

### 轻量模式附加要求

- **引用而不复述**：用例通过 `dev-design.md` 的契约项名称、章节锚点或验收标准原文引用设计，不复述设计内容——两份文档各管一头，防止漂移。
- **覆盖矩阵必须含「首次可验证阶段」列**：设计阶段留空；只有端到端才能验证的条目在该列标"端到端（末阶段）"。`task-split` 拆分任务时回填阶段归属，并在 `tasks-overview.md` 为每个任务圈定负责的用例 ID。
- **测试层级按项目实情裁剪**：依据仓库现有测试组织确定可支撑的层级；没有测试框架时提供可执行的手动验证步骤并说明原因。
- 交付对象为下游 `dev-design-gate`（验收闭环检查）与 `dev-task-split`（阶段回填与任务圈定）。

除输入来源、输出路径、模板和覆盖矩阵形态外，其余——测试设计哲学、内部工作法、阻塞规则、质量标准——全部沿用本 skill 正文。

## 内部工作法

以下步骤是 LLM 的内部工作法，用于生成高质量测试设计；不得把这些步骤、候选目标、评分过程或合并推导原样写入正式《模块测试用例设计.md》。

### 1. 定位输入与输出

- 定位同一模块目录下的正式说明书、`.context/详细设计上下文.md` 和目标测试设计文件。
- 读取 TOBE 中的需求/AR、设计决策、契约清单、接口/数据/流程/异常/配置/日志/风险和 `可测试性与验收口径`。
- 读取 ASIS 测试覆盖现状，识别可复用测试文件、测试框架、Fixture、Mock、历史回归测试和测试缺口。

From pi-ixel/Awesome-Agent-Workflow, MIT.

More from pi-ixel/Awesome-Agent-Workflow