TDD 最大一个问题是在于开发人员最终做出来的东西和实际功能需求可能相偏离，为了解决这一问题有人发明了 BDD。BDD（Behavior-driven development）行为驱动开发，是测试驱动开发延伸出来的一种敏捷软件开发技术。
BDD 解决的另外一个关键问题就是如何定义 TDD 或单元测试过程中的细节。一些不良的单元测试的一个常见问题是**过于依赖被测试功能的实现逻辑。**这通常意味着如果你要修改实现逻辑，即使输入输出没有变，通常也需要去更新测试代码。这就造成了一个问题，让开发人员对测试代码的维护感觉乏味和厌烦。
BDD 核心目的是为了解决 TDD 模式下开发和实际功能需求不一致而诞生，BDD 不需要再面向实现细节设计测试，取而代之的是面向行为来测试。它是从产品角度出发，鼓励开发人员和非开发人员（产品、QA、客户等）之间的协作。由于 BDD 的核心是关注软件的功能测试，所以 BDD 更多的是结合集成测试进行，它是黑盒的。
BDD 的开发流程
1、开发人员和非开发人员一起讨论确认需求
2、以一种自动化的方式将需求建立起来，并确认是否一致
3、最后，实现每个文档示例描述的行为，并从自动化测试开始以指导代码的开发
这样做使得每一次的更改都较小并快速迭代，每次需要更多信息时都将其上移。每次自动化并实现一个新示例时，便为系统添加了一些有价值的内容，并准备响应反馈。
理想中的 BDD 解决方案最流行的是 Cucumber。它的协作流程是这样：
1、开发人员与产品、测试、客户等人员沟通确认需求
2、使用统一的 Gherkin 语法将功能需求转换为需求文档
用描述性自然语言定义的测试，客户、测试人员和开发人员都能看得懂，能达成共识，这种语法叫做 Gherkin Syntax，小黄瓜语法。
以关键字 Scenario、Feature 等来描述场景
以关键字 Given、When、Then 来描述步骤
Feature: 添加任务
Scenario: 在输入框中输入任务名敲回车确定，输出到任务列表中 Given "Hello World" When 在输入框中敲回车 Then 任务列表增加一个名称为 "Hello World" 的任务
Scenario: 在输入框中输入空内容，不输出到任务列表中 Given "" When 在输入框中敲回车 Then 任务列表中不增加任何内容
Cucumber 读取使用 Gherkin 语法描述的纯文本形式的可执行规范，并验证该软件是否满足那些规范所说的内容。规范包含多个示例或方案。
每个方案都是 Cucumber 要执行的步骤的列表。Cucumber 验证软件是否符合规范，并生成一个报告，指出每种情况的成功或失败。
3、开发人员根据 Gherkin 编写测试用例
4、编写代码使测试通过
5、新增功能重复上述步骤
BDD + TDD
BDD 注重的是产品功能，可能无法保证很好的代码质量和测试覆盖率，所以还有人提出一种方案就是 BDD + TDD。
BDD
– 需求分析
– 描述需求定义文档
– 编写集成测试用例
TDD
– 编写单元测试用例
– 编写代码使单元测试通过
– 重构优化
编写代码使集成测试通过
增加功能重复上述步骤
个人理解也可以把 BDD 看作是在需求与 TDD 之间架起一座桥梁，它将需求进一步场景化，更具体地描述系统应该满足哪些行为和场景，让 TDD 的输入更优雅、更可靠。
还有一种更轻量的 BDD 方案就是以集成测试为主的开发方案。
需求分析
编写集成测试用例
运行测试
代码实现使测试通过
重构优化
增加功能重复上述步骤
BDD 的优点：
由于侧重于需求功能的完整度，所以能给开发人员增加更多对程序的信心
由于仅关注功能，不关注实现细节，有利于测试代码和实际代码解耦
由于大多数为编写集成测试，相比 TDD 有更好的开发效率
BDD 的缺点：
因为以功能性的集成测试为主，因此不是那么关注每个函数功能，测试覆盖率比较低
没有 TDD 那么严格的保证代码质量
TDD vs BDD
个人推荐：
建议开发功能函数库使用 TDD 方案
建议开发业务系统使用 BDD 方案
俗话说生活就像一场旅程，不必在乎目的地。虽然对生活来说这可能是正确的，但对开发应用程序来说却恰恰相反，你可以选择单独使用其中一种方法，也可以综合使用这几个方法以取得更好的效果。只要是编写可节省时间的、有价值的测试就可以，如何编写无关紧要。
前端自动化测试的权衡利弊
当我们开始编写自动化测试时，可能想要测试所有的东西。每个搬砖仔可能都体会过未经测试的应用程序带来的痛苦，但在测试过程中，很快我又学到了另一课——测试会减缓开发速度。
在编写测试时，请务必牢记编写测试的目的。通常，测试的目的是为了节省时间。如果你正在进行的项目是稳定的并且会长期开发，那么测试是可以带来收益的。
但是如果测试编写与维护的时间长于它们可以节省的时间，那么你根本不应该编写测试。当然，在编写代码之前你很难知道通过测试可以节省多少时间。但是，假设你正在一个短期项目中创建原型，或者是在一个创业公司迭代一个想法，那你可能不会从编写测试中获得收益。
凡事都有两面性，软件测试也不是银弹，好处虽然明显，却并不是所有的项目都值得引入测试框架，毕竟维护测试用例也是需要成本的。对于一些需求频繁变更、复用性较低的内容，比如活动页面，让开发专门抽出人力来写测试用例确实得不偿失。
而适合引入测试场景大概有这么几个：
需要长期维护的项目。它们需要测试来保障代码可维护性、功能的稳定性。
较为稳定的项目、或项目中较为稳定的部分。给它们写测试用例，维护成本低。
被多次复用的部分，比如一些通用组件和库函数。因为多处复用，更要保障质量。
测试确实会带给我们相当多的好处，但不是立刻就能够体会到。测试就像保险，如果身体健康顺顺利利，几十年可能都用不上。测试也一样，写了可以买个放心，这就是对代码的一种保障，有 bug 可以尽快测出来，没 bug 最好，但不能说“写那么多测试，结果测不出 bug，是浪费时间”。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
