为什么需要BDD？

“开发软件系统最困难的部分就是准确说明开发什么” (“The hardest single part of building a software system is deciding precisely what to build” — No Silver Bullet, Fred Brooks) 。
看一下下面的开发场景：

• 场景一：业务分析人员觉得自己分析的需求已经写的很清晰了，并且跟技术人员进行了足够的沟通，可是开发完做Desk check的时候，发现所开发的功能还是跟期望有差距。
• 场景二：开发团队辛辛苦苦开发完一个功能，满怀信心的去给产品经理/客户展示的时候，才发现原来客户需求的功能不是这样的。
  这些场景是不是似曾相识？为什么会这样？

第一个场景是开发团队内部技术人员跟需求分析人员的理解有偏差，导致大家理解的需求其实是不一样的；
第二个场景是开发团队没有真正理解产品经理／客户所提出来的真实需求，导致开发的产品跟需求不一致。其实，产生这两个不一致的真正原因是因为不同角色有着不同的领域知识，说着不同的语言，大家在沟通的时候，如果都用自己领域语言，必然会产生沟通代沟，导致理解的不一致性。
领域知识不同、语言不通导致沟通障碍，这个客观存在的问题该如何解决呢？BDD正是为此而生。.

BDD究竟是什么？

BDD的提出者Dan North强调BDD不是关于测试的，它是在应用程序存在之前，写出用例与期望，从而描述应用程序的行为，并且促使在项目中的人们彼此互相沟通。

要给BDD下个清晰易懂的定义很难，包括大师们也这么认为，这里试着总结以下几点：

1. 关注的是业务领域，而不是技术：BDD强调用领域特定语言（DSL, domain specific language）描述用户行为，定义业务需求，而不会关心系统的技术实现。
2. 不是工具，强调的是一种协作方式：BDD要求各个角色共同参与系统行为的挖掘和定义，以实现对业务价值的一致理解。
3. 不是关于测试的：BDD源自TDD，又不同于TDD，重点不是关于测试的，但可以指导更好的做自动化测试。
4. 全栈敏捷方法：BDD促使团队所有角色从需求到最后的测试验证，进行高度的协作和沟通，以交付最有价值的功能。

BDD的作用

BDD的作用是把利益关系人、交付团队等不同方面的项目相关人员集中到一起，形成共同的理解，共同的价值观以及共同的期望值。它可以帮助我们：

1. 关注用户行为
   2.交付最有用的功能
2. 在团队内部维护一致的术语
3. 探究需求实例
4. 编写和维护需求
5. 创建活的文档
6. 消除协作与沟通障碍

BDD 中的常见概念

在BDD中，常用的概念如下：

• Epic: 史诗，一般指一个版本或一批功能更新
• Feature: 特性，一般指一个功能点，如登录，添加商品，查询商品等，在测试中对应一个测试套件
• Scenario：场景，即Story，一个明确的场景，对应一个测试用例
• Step: 步骤，测试步骤有Given/When/Then三种
• Given: 假设，给定数据或前置条件，对应测试中的setup
• When: 当…时，对应一个测试步骤
• Then: 然后，即期望结果，对应一个测试断言
• And: 同上，可以用于Given/When/Then后

什么样的项目适合BDD？

• 简单的一次性项目，沟通交流成本都较低的情况下，没有必要使用BDD；
• 业务比较轻量，重在技术方面的项目，可以使用简单的白板上的BDD，不需要在BDD工具记录需求用例文档；
• 业务复杂、团队成员较多的项目，沟通成本高，BDD很有必要。

BDD规格怎么写？

用例场景的描述格式“GIVEN… WHEN… THEN… ”对大家都不陌生，但用这个格式写出好的用例却是非常的难，尤其是新手。这里总结几点供大家参考：

1.业务层抽取，业务语言描述

根据业务层的数据流，在每个数据停留点进行纵切，抽取出一个个用例场景。描述语言一定是业务领域可懂的，不要涉及任何实现相关的技术细节。所描述的场景一定是从业务层抽象出来，体现真实业务价值的。

2.技术人员可懂，自动化友好

所描述的用例场景要能驱动开发，必须要让技术人员易于理解；要指导自动化测试，还得要求对于自动化的实现是友好的。这一点似乎是跟第一点有些矛盾，但我们严格遵守BDD的格式要求还是可以做到的。其中，GIVEN从句描述的是场景的前提条件、初始状态，通常是一种现在完成时态；WHEN从句是采取某个动作或者是发生某个事件，一定是动词，通常是一般现在时；THEN从句用“应该…(should be…)”来描述一种期望的结果，而不用断言（assert），后者与测试关联更紧密。

3.数据驱动，需求实例化

抽象的业务语言描述的需求，往往由于太抽象而缺失掉很多关键信息，导致不同人员对需求理解的不一致。想要既抽象又能包含细节信息，就需要采用需求实例来描述。简单说来，就是给场景用例举例说明。举例就会需要列举数据，如果在场景用例描述里边直接添加数据实例，那样的用例将会很混乱，可读性和可维护性都非常差。如果我们能够在描述场景的用例里边用一些变量来代替，把变量对应的值（数据）提取出来存为一个表格或者独立的文件，这样将会使得用例的可读性很好，而且也不会缺失细节信息（数据），后期的维护和修改也较为方便。这就是数据驱动的方法来描述实例化的需求。

下面举几个例子，大家体会一下：

场景一：检查收件箱，可以看出第三个清晰明了且能体现业务价值，比较符合上面的要求。

场景二：限制非法用户查看某些受限内容，BDD要强调什么（What），而不是怎么（How），第二个写的比较好。

场景三：添加图书到购物车并计算总额

实现BDD 的工具

BDD不只是测试， 但是BDD可以很好的指导测试。
在实际的场景中， 实现BDD 主要包括两个部分：

1. 使用通用领域语言编写规格
2. 实现规格的自动化测试

可以帮助实现BDD 的工具有：

1. Cucumber: Cucumber 是最常用的 BDD 工具之一，它使用简洁的自然语言（Gherkin）编写测试用例，并支持多种编程语言和测试框架。

2. JBehave: JBehave 是另一个流行的 BDD 工具，它使用类似 Gherkin 的语法编写测试用例，支持 Java 平台的自动化测试。

3. SpecFlow: SpecFlow 是为 .NET 平台开发的 BDD 工具，它能够将 Gherkin 语法的测试用例与 .NET 代码结合起来执行。

4. Behave: Behave 是一个 Python BDD 工具，它使用 Gherkin 语法编写测试用例并支持 Python 测试框架。

5. Jasmine: Jasmine 是一个用于 JavaScript 的 BDD 框架，它提供了简洁的语法和丰富的断言库，适用于前端开发的 BDD 测试。

6. Robot Framework: Robot Framework 是一个通用的自动化测试框架，它支持 BDD 风格的测试，并提供了许多扩展库和插件。

BDD测试在CI/CD 阶段的位置

在CI/CD（持续集成/持续部署）流程中，BDD（行为驱动开发）测试持续被执行并且在各个阶段都起到关键性的角色。

以下是经典的CI/CD流程中，BDD测试可能出现的位置：

1. 持续集成（Continuous Integration）阶段：

   • 这是开发者提交代码更改到代码存储库的阶段，所有新的代码更改都会自动触发构建和测试过程。在这个阶段，BDD测试（以及单元测试和集成测试）通常会运行，以确保新代码的更改或新增功能没有引入新的错误或改变了预期的行为。

2. 持续交付（Continuous Delivery）阶段：

   • 在这个阶段，所有的提交都会通过实际生产环境的完全自动化的测试。在这个阶段，BDD测试可以用来验证工作流程和业务场景，保证软件的行为与预期一致。

3. 持续部署(Continuous Deployment)阶段：

   • 这个阶段指的是自动将更新的应用版本部署到生产环境的过程。虽然BDD测试通常在持续部署之前就完成了，但是如果你在部署之后有进行任何形式的后期验证（例如: 实时监控，日志分析等），那么这些验证应该再次验证所有预期的行为仍然按预期工作。

整个CI/CD流程中，BDD测试有助于快速捕捉和修复软件错误，并确保应用符合预期的行为。如果发现测试失败或行为不匹配，CI/CD流程会被中断，从而避免将错误的代码推送到生产环境。

---

---