---
source: ../../../../skills/atdd-assistant/SKILL.md
source_version: 1.0.0
translation_version: 1.0.0
last_synced: 2026-02-05
status: current
scope: partial
description: |
  引导团队完成验收测试驱动开发工作流程。
  使用时机：定义验收标准、进行规格研讨会、撰写含验收测试的用户故事、PO 签核。
  关键字：ATDD, acceptance test, acceptance criteria, user story, product owner, specification workshop, 验收测试驱动开发.
---

# ATDD 助手

> **语言**: [English](../../../../skills/atdd-assistant/SKILL.md) | 简体中文

**版本**: 1.0.0
**最后更新**: 2026-01-19
**适用范围**: Claude Code Skills

---

## 目的

本技能引导团队完成验收测试驱动开发工作流程，协助：
- 进行有效的规格研讨会
- 以 Given-When-Then 格式撰写可测试的验收标准
- 将标准转换为可执行的验收测试
- 确保 PO、Dev 和 QA 之间的适当协作
- 整合 ATDD 与 BDD 和 TDD 以完成完整工作流程

---

## 快速参考

### ATDD 工作流程检查清单

```
┌─────────────────────────────────────────────────────────────────┐
│  🤝 规格研讨会阶段                                               │
│  □ 产品负责人说明用户故事                                        │
│  □ 团队提出澄清问题                                              │
│  □ 共同定义验收标准                                              │
│  □ 为每个 AC 撰写具体示例                                        │
│  □ 讨论边界案例和错误情境                                        │
│  □ 明确记录范围外内容                                            │
├─────────────────────────────────────────────────────────────────┤
│  🧪 精炼阶段                                                     │
│  □ 将示例转换为可执行测试                                        │
│  □ 移除测试中的歧义                                              │
│  □ 测试采用可执行格式（Gherkin、FitNesse 等）                    │
│  □ 产品负责人签核测试                                            │
├─────────────────────────────────────────────────────────────────┤
│  💻 开发阶段                                                     │
│  □ 验收测试初始失败（RED）                                       │
│  □ 功能测试使用 BDD，单元测试使用 TDD                            │
│  □ 逐步达成 AT 通过                                              │
│  □ 所有验收测试通过（GREEN）                                     │
│  □ 代码重构且整洁                                                │
├─────────────────────────────────────────────────────────────────┤
│  🎬 演示阶段                                                     │
│  □ 所有验收测试通过                                              │
│  □ 演示环境已准备                                                │
│  □ 关键利益相关方出席                                            │
│  □ 产品负责人验证功能                                            │
│  □ 故事被接受或标准被优化                                        │
└─────────────────────────────────────────────────────────────────┘
```

### 验收标准快速参考

| 元素 | 格式 | 示例 |
|------|------|------|
| **用户故事** | As a / I want / So that | 作为客户，我想要重设密码，以便我能重新访问账号 |
| **AC 格式** | Given / When / Then | 假设我在登录页面，当我点击「忘记密码」，那么我应该看到重设表单 |
| **范围外** | 项目清单 | - SMS 重设、- 管理员重设功能 |
| **技术备注** | 项目清单 | - Token 24 小时后过期 |

### INVEST 准则

| 原则 | 描述 | 检查 |
|------|------|------|
| **I**ndependent 独立 | 可独立开发 | 无阻塞依赖 |
| **N**egotiable 可协商 | 细节可讨论 | 非合约 |
| **V**aluable 有价值 | 传递商业价值 | PO 能解释「为什么」 |
| **E**stimable 可估算 | 可被估算 | 团队理解范围 |
| **S**mall 小 | 可在一个 Sprint 内完成 | < 1 周工作量 |
| **T**estable 可测试 | 可被验证 | 明确的验收标准 |

---

## 工作流程协助

### 规格研讨会指引

进行规格研讨会时：

1. **故事说明** (5 分钟)
   ```
   用户故事: [标题]

   作为 [角色]
   我想要 [功能]
   以便 [好处]

   商业价值: [为什么重要]
   ```

2. **澄清问题** (10 分钟)
   - 商业：「价值是什么？」「用户是谁？」
   - 开发：「影响是什么？」「依赖？」
   - 测试：「可能出什么错？」「边界案例？」

3. **AC 定义** (20 分钟)
   ```markdown
   ### AC-1: [标准名称]
   **Given** [前置条件]
   **When** [动作]
   **Then** [预期结果]
   ```

4. **范围外** (10 分钟)
   - 明确列出不包含的内容
   - 防止开发期间范围蔓延

5. **技术备注** (5 分钟)
   - 实现提示
   - 已知限制
   - 依赖

### 精炼指引

将 AC 转换为可执行测试时：

1. **审查每个 AC**
   - 是否明确无歧义？
   - 可以自动化吗？
   - 是否验证商业价值？

2. **选择测试格式**
   | 格式 | 最适合 |
   |------|--------|
   | Gherkin | 行为导向、商业可读 |
   | FitNesse | 数据驱动、Wiki 表格 |
   | Robot Framework | 复杂工作流程 |
   | Code (xUnit) | 技术团队 |

3. **撰写可执行测试**
   ```gherkin
   # AC-1: 密码重设请求
   Scenario: 请求密码重设
     Given 我在登录页面
     And 我有一个已注册账号
     When 我点击「忘记密码」
     And 我输入我的电子邮件地址
     Then 我应该看到「重设链接已发送」
     And 我应该在 5 分钟内收到电子邮件
   ```

4. **取得 PO 签核**
   - PO 确认测试代表需求
   - 开发开始前签核

### 演示指引

准备演示时：

1. **演示前检查清单**
   ```
   □ 所有验收测试通过
   □ 演示环境就绪
   □ 测试数据已准备
   □ 利益相关方已通知
   ```

2. **演示结构** (15-30 分钟)
   - 背景 (1 分钟)：提醒故事和 AC
   - 测试 (2 分钟)：现场执行验收测试
   - 功能 (5-10 分钟)：逐一展示每个 AC
   - 反馈 (5 分钟)：收集反馈、问答

3. **可能结果**
   - ✅ 接受：故事完成
   - 🔄 需精炼：返回研讨会
   - ❌ 拒绝：识别差距

---

## 用户故事模板

```markdown
## 用户故事: [标题]

**作为** [角色]
**我想要** [功能]
**以便** [好处]

## 验收标准

### AC-1: [Happy path]
**Given** [前置条件]
**When** [动作]
**Then** [预期结果]

### AC-2: [错误情境]
**Given** [前置条件]
**When** [无效动作]
**Then** [错误处理]

### AC-3: [边界案例]
**Given** [边界条件]
**When** [动作]
**Then** [适当结果]

## 范围外
- [未包含的功能 1]
- [延后至未来的功能 2]

## 技术备注
- [实现限制]
- [依赖信息]
- [性能需求]

## 问题 / 假设
- [开放问题 1]
- [假设 1]
```

---

## 与其他工作流程整合

### ATDD → BDD → TDD 流程

```
ATDD 层级（商业验收）
  │
  │  用户故事 + 验收标准
  │  PO 签核
  │
  ▼
BDD 层级（行为规格）
  │
  │  Feature 文件（Gherkin）
  │  三方协作
  │
  ▼
TDD 层级（实现）
  │
  │  单元测试
  │  Red → Green → Refactor
  │
  ▼
验证（演示）
  │
  └──▶ PO 验收
```

---

## 配置侦测

本技能支持项目特定配置。

### 侦测顺序

1. 检查 `CONTRIBUTING.md` 的「Disabled Skills」区段
2. 检查 `CONTRIBUTING.md` 的「ATDD Standards」区段
3. 检查现有的验收测试模式
4. 若未找到，**默认使用标准 ATDD 实务**

### 首次设置

若未找到配置：

1. 询问：「此项目尚未配置 ATDD 偏好。您偏好哪种验收测试格式？」
   - Gherkin (Cucumber, SpecFlow)
   - FitNesse 表格
   - 代码基础 (xUnit)

2. 选择后，建议记录在 `CONTRIBUTING.md`：

```markdown
## ATDD 标准

### 验收测试格式
- Gherkin (Cucumber.js)

### 用户故事模板
- 需要 INVEST 准则
- AC 使用 Given-When-Then 格式

### 工作流程
- 所有故事需要规格研讨会
- 开发前需要 PO 签核
- 每个完成的故事需要演示
```

---

## 详细指南

完整标准请参阅：
- [ATDD 核心标准](../../../../core/acceptance-test-driven-development.md)
- [ATDD 工作流程指南](./atdd-workflow.md)
- [验收标准撰写指南](./acceptance-criteria-guide.md)

相关标准：
- [BDD 标准](../../../../core/behavior-driven-development.md)
- [TDD 标准](../../../../core/test-driven-development.md)
- [测试标准](../../../../core/testing-standards.md)

---

## 反模式快速侦测

| 症状 | 可能问题 | 快速修复 |
|------|---------|---------|
| 功能标记完成但 PO 拒绝 | AC 未与 PO 验证 | 强制 PO 签核 |
| 长期开发无进展 | AC 太大或模糊 | 拆分为更小的标准 |
| 验收测试首次就通过 | 实现后才写测试 | 开发前写测试 |
| 无尽的范围讨论 | 没有「范围外」定义 | 明确范围外 |
| AC 无法自动化 | QA/Dev 未参与 AC 定义 | 研讨会纳入技术观点 |

---

## RACI 矩阵

| 活动 | 产品负责人 | 开发人员 | QA/测试人员 |
|------|-----------|---------|------------|
| 定义用户故事 | **R/A** | C | C |
| 规格研讨会 | **R** | C | C |
| 定义验收标准 | **A** | R | R |
| 撰写可执行测试 | C | R | **R/A** |
| 实现功能 | C | **R/A** | C |
| 执行验收测试 | I | R | **R/A** |
| 接受/拒绝功能 | **R/A** | I | I |

**图例**: R = 负责, A = 当责, C = 咨询, I = 知会

---

## 相关标准

- [验收测试驱动开发](../../../../core/acceptance-test-driven-development.md) - 核心 ATDD 标准
- [行为驱动开发](../../../../core/behavior-driven-development.md) - BDD 标准
- [测试驱动开发](../../../../core/test-driven-development.md) - TDD 标准
- [规格驱动开发](../../../../core/spec-driven-development.md) - SDD 工作流程
- [测试标准](../../../../core/testing-standards.md) - 测试框架
- [BDD 助手](../bdd-assistant/SKILL.md) - BDD 技能
- [TDD 助手](../tdd-assistant/SKILL.md) - TDD 技能

---

## 版本历史

| 版本 | 日期 | 变更 |
|------|------|------|
| 1.0.0 | 2026-01-19 | 初始发布 |

---

## 授权

本技能以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授权发布。

**来源**: [universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)
