---
source: ../../../../skills/reverse-engineer/bdd-extraction.md
source_version: 1.0.0
translation_version: 1.0.0
last_synced: 2026-01-19
status: current
---

# BDD 提取工作流程指南

**版本**: 1.0.0
**最后更新**: 2026-01-19

> **语言**: [English](../../../../skills/reverse-engineer/bdd-extraction.md) | [繁體中文](../../../zh-TW/skills/reverse-engineer/bdd-extraction.md) | 简体中文

本指南提供从 SDD 规格中提取 BDD（行为驱动开发）场景的详细工作流程。

---

## 概览

BDD 提取将 SDD 规格中的验收标准转换为可执行的 Gherkin 场景。这实现了自动化测试，同时保持与需求的可追溯性。

```
┌─────────────────────────────────────────────────────────────────────────┐
│                        BDD 提取管道                                       │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  ┌───────────┐   ┌───────────┐   ┌───────────┐   ┌───────────┐        │
│  │   SPEC    │──▶│    AC     │──▶│   格式    │──▶│  转换为   │        │
│  │   文件    │   │   区块    │   │   侦测    │   │  Gherkin  │        │
│  └───────────┘   └───────────┘   └───────────┘   └─────┬─────┘        │
│                                                        │               │
│                                                        ▼               │
│                       ┌───────────────────────────────────┐            │
│                       │        套用确定性标签             │            │
│                       │  [已确认] [推断] [假设]           │            │
│                       └─────────────────┬─────────────────┘            │
│                                         │                              │
│                                         ▼                              │
│  ┌───────────┐   ┌───────────┐   ┌───────────┐                        │
│  │   人类    │◀──│  Feature  │◀──│   标签    │                        │
│  │   审查    │   │   文件    │   │   分配    │                        │
│  └───────────┘   └───────────┘   └───────────┘                        │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
```

---

## 阶段 1：SPEC 文件解析

### 1.1 定位验收标准

在 SPEC 文件中搜寻 AC 区块：

| 区块名称 | 优先顺序 | 常见模式 |
|----------|----------|----------|
| **Acceptance Criteria** | 第一 | `## Acceptance Criteria`、`## AC` |
| **Requirements** | 第二 | `## Requirements`、`## Functional Requirements` |
| **Test Cases** | 第三 | `## Test Cases`、`## Validation` |
| **User Stories** | 第四 | `## User Stories`（从故事中提取 AC） |

### 1.2 提取脉络资讯

收集 Feature 文件标头的脉络数据：

```markdown
## 提取的脉络

来自 SPEC-AUTH.md：
- **功能名称**：用户认证
- **摘要**：使用 JWT 令牌的安全登入系统
- **用户故事**：
  - 作为用户，我想要安全登入
  - 作为管理员，我想要管理用户工作阶段
- **相关规格**：SPEC-SESSION、SPEC-TOKEN
```

### 1.3 解析 AC 内容

识别个别验收标准：

```markdown
## 验收标准（来自 SPEC）

### 格式 A：条列清单
- [ ] 用户可以用 email/密码登入
- [ ] 系统对无效凭证显示错误
- [ ] 帐号在 5 次失败尝试后锁定

### 格式 B：Given-When-Then
Given 一个已注册的用户
When 他们输入有效凭证
Then 他们应该成功登入

### 格式 C：混合
- [ ] 用户可以登入（下方 Given-When-Then）
  - Given：用户在登入页面
  - When：输入 email 和密码
  - Then：重新导向到仪表板
```

---

## 阶段 2：格式侦测

### 2.1 侦测算法

套用模式匹配来分类 AC 格式：

```
侦测规则：

1. Given-When-Then 格式：
   - 包含关键字："Given"、"When"、"Then"
   - 可能包含 "And"、"But"
   - 标签：[已确认] 用于直接转换

2. 条列式格式：
   - 以 `- [ ]` 或 `- ` 开头的列表项目
   - 没有 GWT 关键字
   - 标签：[推断] 转换后

3. 混合格式：
   - 包含两种模式
   - 分别处理每种模式类型

4. 表格格式：
   - 在 markdown 表格中的验收标准
   - 提取「预期行为」栏位
   - 标签：[推断]
```

### 2.2 格式分类输出

```markdown
## 格式分析报告

文件：specs/SPEC-AUTH.md
分析行数：42-78

| 行范围 | 侦测到的格式 | 动作 |
|--------|--------------|------|
| 42-48 | Given-When-Then | 直接转换 [已确认] |
| 52-58 | 条列式 | AI 转换 [推断] |
| 62-68 | 表格格式 | 提取并转换 [推断] |
| 72-78 | 混合 | 分别处理 |
```

---

## 阶段 3：转换规则

### 3.1 条列式转换为 Gherkin

遵循以下规则转换条列式：

#### 规则 1：动作动词提取

| 条列式模式 | 提取的动作 | When 子句 |
|------------|------------|-----------|
| "用户可以..." | "可以" → 能力 | "用户执行..." |
| "系统应该..." | "应该" → 期望 | "系统应该..." |
| "必须..." | "必须" → 要求 | "必须..." |
| "不能..." | "不能" → 限制 | "不能..." |

#### 规则 2：Given 子句推断

当前置条件不明确时，根据脉络推断：

| 场景类型 | 推断的 Given | 确定性 |
|----------|--------------|--------|
| 认证 | "用户在登入页面" | `[假设]` |
| 购物车操作 | "用户有商品在购物车" | `[假设]` |
| 个人资料更新 | "用户已登入" | `[假设]` |
| 管理员操作 | "管理员已登入" | `[假设]` |
| API 呼叫 | "API 服务正在运行" | `[假设]` |

#### 规则 3：Then 子句生成

| 动作类型 | Then 模式 | 范例 |
|----------|-----------|------|
| 导航 | "应该看到 {页面}" | "应该看到首页" |
| 数据 | "应该显示 {数据}" | "应该显示用户数据" |
| 错误 | "应该看到错误讯息" | "应该看到 '密码错误'" |
| 状态变更 | "{实体} 状态为 {状态}" | "订单状态为已确认" |

### 3.2 转换范例

**范例 1：简单能力**

```markdown
# 输入（条列式）
- [ ] 用户可以用 email 和密码登入

# 输出（Gherkin）
Scenario: 用户可以用 email 和密码登入
  Given 用户在登入页面  # [假设] 前置条件推断
  When 用户输入 email 和 password
  Then 登入成功  # [推断] 隐含成功
  # [来源: specs/SPEC-AUTH.md:45]
```

**范例 2：错误条件**

```markdown
# 输入（条列式）
- [ ] 系统对无效密码显示错误

# 输出（Gherkin）
Scenario: 系统对无效密码显示错误
  Given 用户在登入页面  # [假设]
  And 用户有已注册的帐号  # [假设]
  When 用户输入错误的密码
  Then 系统显示错误讯息  # [推断]
  # [来源: specs/SPEC-AUTH.md:48]
```

**范例 3：边界条件**

```markdown
# 输入（条列式）
- [ ] 帐号在 5 次失败登入尝试后锁定

# 输出（Gherkin）
Scenario: 帐号在 5 次失败登入尝试后锁定
  Given 用户有已注册的帐号  # [假设]
  And 用户已失败登入 4 次  # [推断] 边界设置
  When 用户第 5 次输入错误密码
  Then 帐号应该被锁定  # [推断]
  And 用户应该看到帐号锁定讯息  # [假设] UX 期望
  # [来源: specs/SPEC-AUTH.md:52]
```

---

## 阶段 4：Feature 文件生成

### 4.1 文件结构

```gherkin
# ============================================================
# Feature: [来自 SPEC 摘要的名称]
# 来源: [SPEC 文件路径]
# 生成时间: [YYYY-MM-DD HH:mm]
#
# 确定性摘要：
#   - [已确认]：N 个场景（直接来自 GWT AC）
#   - [推断]：M 个场景（从条列式转换）
#   - [假设]：K 个步骤（推断的前置条件）
#
# 审查状态：待定
# ============================================================

Feature: 用户认证
  As a user
  I want to log in with my credentials
  So that I can access my account

  Background:
    Given 系统已启动  # [已确认] 系统要求
    And 数据库连线正常  # [已确认]

  # ─────────────────────────────────────────
  # 来自 GWT 格式的场景 [已确认]
  # ─────────────────────────────────────────

  @confirmed @automated
  Scenario: 成功登入
    Given 用户在登入页面
    And 用户有已注册的帐号
    When 用户输入正确的 email 和密码
    Then 用户应该看到首页
    # [来源: specs/SPEC-AUTH.md:42-46] [已确认]

  # ─────────────────────────────────────────
  # 从条列式转换的场景 [推断]
  # ─────────────────────────────────────────

  @needs-review @inferred
  Scenario: 登入失败 - 密码错误
    Given 用户在登入页面  # [假设]
    When 用户输入错误的密码
    Then 用户应该看到错误讯息  # [推断]
    # [来源: specs/SPEC-AUTH.md:48] [推断]

  @needs-review @inferred @edge-case
  Scenario: 帐号锁定 - 连续失败 5 次
    Given 用户已失败登入 4 次  # [推断]
    When 用户第 5 次输入错误密码
    Then 帐号应该被锁定  # [推断]
    # [来源: specs/SPEC-AUTH.md:52] [推断]
```

### 4.2 标签系统

| 标签 | 意义 | 用途 |
|------|------|------|
| `@confirmed` | AC 原本就是 GWT 格式 | 可以安全自动化 |
| `@inferred` | AC 从条列式转换 | 需要审查 |
| `@assumption` | 包含假设的步骤 | 与利害关系人验证 |
| `@needs-review` | 需要人类验证 | 先不要自动化 |
| `@edge-case` | 边界条件 | 测试优先 |
| `@security` | 安全相关 | 高优先级 |
| `@manual` | 无法自动化 | 保留作为文档 |

### 4.3 来源标注

每个场景必须包含来源参考：

```gherkin
# 单一来源
# [来源: specs/SPEC-AUTH.md:45]

# 多个来源
# [来源: specs/SPEC-AUTH.md:45, specs/SPEC-SESSION.md:12]

# 从脉络推断
# [来源: specs/SPEC-AUTH.md:45] [从摘要区块推断]
```

---

## 阶段 5：场景大纲生成

### 5.1 识别可参数化的场景

寻找建议参数化的模式：

```markdown
# 多个相似的 AC：
- [ ] 用户可以用 email 登入
- [ ] 用户可以用用户名称登入
- [ ] 用户可以用电话号码登入

# 转换为 Scenario Outline：
```

```gherkin
@inferred
Scenario Outline: 用户可以用 <credential_type> 登入
  Given 用户在登入页面
  When 用户输入 <credential> 和密码
  Then 登入成功

  Examples:
    | credential_type | credential |
    | email | user@example.com |
    | 用户名称 | john_doe |
    | 电话号码 | 0912345678 |
  # [来源: specs/SPEC-AUTH.md:45-47] [推断 - 合并相似 AC]
```

### 5.2 范例表格提取

当 SPEC 包含数据范例时：

```markdown
# 来自 SPEC：
| 输入 | 预期结果 |
|------|----------|
| 有效 email | 成功 |
| 无效 email | 错误 |
| 空 email | 验证错误 |
```

```gherkin
@inferred
Scenario Outline: 登入验证 - <scenario>
  Given 用户在登入页面
  When 用户输入 <input>
  Then 应该看到 <result>

  Examples:
    | scenario | input | result |
    | 有效 email | user@example.com | 登入成功 |
    | 无效 email | invalid | 错误讯息 |
    | 空 email | | 验证错误 |
  # [来源: specs/SPEC-AUTH.md:60-64] [已确认 - 来自表格]
```

---

## 阶段 6：质量检查

### 6.1 完整性检查

```markdown
## BDD 提取质量报告

### 覆盖分析
| SPEC 区块 | 找到的 AC | 生成的场景 | 覆盖率 |
|-----------|-----------|------------|--------|
| 快乐路径 | 5 | 5 | 100% ✅ |
| 错误处理 | 8 | 7 | 87% ⚠️ |
| 边界情况 | 3 | 2 | 67% ⚠️ |

### 缺少的场景
| AC | 原因 | 动作 |
|----|------|------|
| "系统记录所有尝试" | 非功能需求 | 新增为 Background |
| "工作阶段在 1 小时后过期" | 时间相关行为 | 需要手动测试 |
```

### 6.2 确定性分布

```markdown
### 确定性摘要
| 层级 | 数量 | 百分比 |
|------|------|--------|
| [已确认] | 8 | 40% |
| [推断] | 10 | 50% |
| [假设] | 2 | 10% |

### 审查优先级
1. 🔴 高：2 个带有 [假设] 标签的场景
2. 🟡 中：10 个带有 [推断] 标签的场景
3. 🟢 低：8 个带有 [已确认] 标签的场景
```

---

## 处理挑战

### 挑战 1：模糊的 AC

当验收标准不明确时：

```markdown
# 模糊的 AC：
- [ ] 用户登入应该安全

# 解决方案：
Scenario: 用户登入应该安全
  # [未知] "安全" 是什么意思？
  # 建议的解读：
  # - 需要 HTTPS 连线？
  # - 密码不记录？
  # - 工作阶段令牌加密？

  # 动作：询问利害关系人以澄清
  Given [需要澄清：安全要求]
  When 用户登入
  Then [需要澄清：安全验证]
  # [来源: specs/SPEC-AUTH.md:45] [未知 - 需要澄清]
```

### 挑战 2：隐含需求

当需求被暗示但未陈述时：

```markdown
# 明确的 AC：
- [ ] 用户可以重设密码

# 发现的隐含需求：
Scenario: 用户可以重设密码
  Given 用户忘记密码  # [假设] - 触发条件
  And 用户有有效的 email  # [假设] - 先决条件
  When 用户请求重设密码
  Then 系统发送重设连结到 email  # [假设] - 机制
  And 连结在 24 小时后失效  # [假设] - 安全
  # [来源: specs/SPEC-AUTH.md:55] [推断 - 新增多个假设]
```

### 挑战 3：技术 vs 用户场景

区分技术需求：

```gherkin
# 面向用户的场景
@user-story
Scenario: 用户登入成功
  Given 用户在登入页面
  When 用户输入正确凭证
  Then 用户看到首页

# 技术场景（相同 AC，不同视角）
@technical
Scenario: 登入时系统生成 JWT Token
  Given 用户提交有效凭证
  When 系统验证成功
  Then 系统生成 JWT Token
  And Token 包含用户 ID
  And Token 设定 1 小时过期时间
  # [来源: specs/SPEC-AUTH.md:42] [推断 - 技术实作]
```

---

## 整合点

### 与 /reverse-spec

```
/reverse-spec → SPEC-XXX.md → /reverse-bdd → feature.feature
```

### 与 /bdd

提取后，使用 `/bdd` 进行：
- 语法验证
- Step 定义生成
- 三方会谈审查

### 与 /reverse-tdd

```
feature.feature → /reverse-tdd → 覆盖率报告
```

---

## 输出文件

### 主要输出

```
features/
├── auth.feature           # 来自 SPEC-AUTH.md
├── cart.feature           # 来自 SPEC-CART.md
└── checkout.feature       # 来自 SPEC-CHECKOUT.md
```

### 中继数据输出

```
features/.meta/
├── extraction-report.md   # 所有提取的摘要
├── review-checklist.md    # 需要人类审查的项目
└── certainty-matrix.md    # 按场景的确定性层级
```

---

## 版本历史

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