行为驱动开发是什么
BDD（Behavior-Driven Development）由 Dan North 在 2006 年提出：用业务语言描述系统行为并驱动开发。团队从具体示例出发澄清需求，用 Given-When-Then 表达场景，让需求、测试与实现共享同一套描述。Gherkin（Feature/Scenario 语法）是常见载体，场景可被自动化框架执行，成为「活文档」。它的核心是三方的对话，而不是脚本语法。
基本信息
| 提出 | Dan North（2006） |
|---|---|
| 描述语言 | Gherkin（Feature/Scenario/Given-When-Then） |
| 价值 | 需求澄清、统一术语、可执行文档 |
| 协作形式 | 产品、开发、测试三方共同编写与评审场景 |
| 落地载体 | Cucumber 等框架把场景映射到步骤定义 |
Gherkin 示例
Gherkin 示例
Scenario: 余额不足时拒绝取款
Given 账户余额为 100 元
When 尝试取款 150 元
Then 提示余额不足且余额保持 100 元
# 场景用业务术语表达，三方都能读懂并确认典型使用场景
- 需求澄清会：用具体示例替代抽象描述，歧义当场暴露。
- 验收标准编写：场景直接作为验收依据与回归基线。
- 活文档维护：场景随需求演进更新，始终反映系统现状。
- 跨部门协作：产品、开发、测试共用一套术语清单。
- 回归自动化：稳定场景转化为自动化执行的用例。
- 新人理解业务：按 Feature 目录浏览系统行为。
- 术语统一：把「订单」「账单」等叫法差异在场景评审里当场对齐。
把 BDD 当作脚本语法而不做三方澄清，会得到格式漂亮但业务不认可的场景。
场景写业务行为不写界面操作：点哪个按钮属于步骤定义的实现细节，不该出现在场景层。
示例是 BDD 的燃料：从「规则 + 代表性示例」出发比写抽象规则更快暴露理解分歧。
评审要留记录：把分歧点与最终结论写进场景描述，下个迭代讨论同一条规则时不用从头吵起。