BDD风格(行为驱动开发风格)是一种以系统行为为核心，用自然语言描述可执行规范的敏捷开发与测试方法，强调业务人员、开发者和测试人员三方协作，确保软件功能符合实际业务需求。
一、核心定义与起源
- BDD = Behavior-Driven Development（行为驱动开发），由Dan North在2003年提出，是TDD(测试驱动开发)的语义升级与扩展
- 核心思想：先定义行为，再实现功能，用通用语言（Ubiquitous Language）统一团队认知，避免需求理解偏差
- 定位：连接业务语言与技术语言的”翻译官”，让测试用例同时成为活文档
二、BDD风格的关键特征
| 特征 | 说明 |
|---|---|
| 以行为为中心 | 关注”系统应该如何表现”（可观测的外部行为），而非”代码如何实现” |
| 自然语言描述 | 使用Gherkin语法（Given-When-Then结构）编写场景，非技术人员也能看懂 |
| 三方协作 | 业务、开发、测试共同参与场景定义，确保需求一致理解 |
| 可执行规范 | 场景描述既是需求文档，也是自动化测试脚本，自动验证功能正确性 |
| 实例化需求 | 通过具体场景示例明确需求，避免模糊表述 |
三、标志性的Gherkin语法格式
BDD风格最显著的特点是使用Given-When-Then结构描述场景，通常组织为：
Feature: 功能名称（如用户登录）
描述：简要说明该功能的业务价值
Scenario: 场景名称（如成功登录）
Given 前置条件（如用户有有效账号）
And 其他前置条件（可选）
When 触发动作（如用户提交登录信息）
Then 预期结果（如用户被认证并跳转到仪表盘）
And 其他验证（可选）
Scenario Outline: 场景模板（处理多组数据）
Given ...
When ...
Then ...
Examples:
| 参数1 | 参数2 | 预期结果 |
| 值1 | 值2 | 结果1 |
四、与TDD的核心区别
| 维度 | TDD(测试驱动开发) | BDD(行为驱动开发) |
|---|---|---|
| 关注点 | 代码单元（函数/方法）的正确性 | 系统整体行为与业务价值 |
| 语言 | 技术断言（如assertEquals） | 自然语言（业务术语） |
| 参与方 | 主要由开发者主导 | 业务+开发+测试三方协作 |
| 驱动目标 | 代码实现行为 | 可观测的外部用户行为 |
| 文档价值 | 测试代码，非技术人员难理解 | 同时作为活文档，易读易懂 |
总结：BDD风格本质是一种协作式需求定义与验证方法，通过自然语言描述系统行为，让技术实现始终围绕业务价值展开，是现代敏捷开发中连接业务与技术的重要实践。