构建与众不同的软件
Behavior Driven Development【行为驱动开发】是一种软件设计思想，用于实现更快地构建和交付有价值、
高质量的软件。
BDD from 50000 feet
1）客户人员告诉业务分析人员，他需要一个新的功能模块来支持业务发展。
2）业务分析人员将客户的请求转换为一系列的需求文档，这些文档用来描述软件应该做什么。
3）开发人员将这些需求分解为指定的特性，并用代码实现这些特性，同时编写单元测试。
4）测试人员将需求文档转换为测试用例，并用这些用例来验证新特性是否满足需求。
5）文档工程师将为新的功能编写技术文档和功能文档。
信息在传递的过程中容易出现丢失、被忽视、被误解等问题，导致最终交付的特性不能满足用户的真实需求。
1）客户人员向业务分析人员提出他想要什么功能，并使用具体的实例来描述该特性需要做什么。
2）在实现该功能之前，业务分析人员、开发人员和测试人员一起开会，将特性分解为符合指定规范的实例化需求。
3）开发人员使用 BDD 工具将这些实例化需求转换为自动化验收标准，
验收测试将运行程序代码来确定指定的特性是否已经实现。
4）测试人员将基于验收测试的结果，来执行手动测试和探索性测试。
5）自动化验收测试充当低级的技术文档，并提供具体的特性描述。客户人员可以查看测试报告来确定哪些功能已经实现，是否符合预期。
BDD 极大地减少了信息丢失、被忽略、被误解等问题，降低了软件的不确定性。
What problems are you trying to solve?
软件项目失败的原因有很多，但主要有以下两大类：
- 1）没有正确地构建软件：软件有缺陷、不可靠、很难维护和变更、没有好的自动化测试
开发人员花费大量的时间来修复缺陷，同时要保证变更代码没有不可预知的副作用
软件代码紧密耦合，新增一个新的特性要花费很长的时间
存在的技术文档早已过时
新特性实现之后，需要执行大量的手动测试，以保证旧的功能不受影响
- 2）没有构建正确的软件：软件没有正确地实现用户需求，不能为业务发展提供价值
软件解决方案没有和商业目标保持一致，不能为客户达成商业目标提供价值。
交付的特性从未被用户使用，纯粹是浪费时间、精力、金钱。
需求变更是项目发展的常态。
随着项目的发展，市场状况、商业策略、技术约束等都会变化。
积极地向最终用户和利益相关人了解他们需要实现的高级目标，这会帮助你更好的理解业务和系统功能，
更好的发现和交付匹配商业目标的有效解决方案。
Introducing Behavior-Driven Development
- 1）BDD 最初设计为 TDD【Test Driven Development，测试驱动开发】 的改进版本
单元测试和特定的代码实现紧密耦合，
许多传统的单元测试都只关注于方法或函数的功能，而不是此代码应该实现什么业务特性
使用 Given-When-Then 格式的场景语句实例化需求，清晰的描述功能特性。
1）关注于交付业务价值的特性【特性是帮助实现业务的有形的、可交付的功能】。
2）业务分析人员、开发人员、测试人员和最终用户一起讨论确定特性【挑战】。
在传统的软件开发过程中，业务分析人员接收用户需求，并根据自己的理解将其传递给团队中的其他成员，
需求在理解和传递的过程中，容易导致信息丢失和误解。
3）拥抱不确定性。
4）使用具体的例子说明特性【
Feature：账户间转账
为了<更有效的理财>
作为<一个银行客户>
我希望<在我的账户间实现转账>
Scenario：把钱转到储蓄账户
Given：我的活期账户有 1000 元
And：我的储蓄账户有 2000 元
When：我从活期账户转账 500 元到储蓄账户
Then：我的活期账户还剩 500 元
And：我的储蓄账户有 2500 元
】，示例非常重要。
5）编写可执行的规范【Cucumber 验收测试】。
6）编写底层规范【Junit 单元测试】。
7）交付活文档和进度报告【验收测试生成的测试报告】
8）使用活文档支持正在执行的维护工作
Benefits of BDD
- 1）减少浪费：只专注于发现和交付能够给用户提供商业价值的特性、通过及时、有效的反馈来减少返工
- 2）缩减成本：减少浪费的直接成果就是降低成本
- 3）更容易、更安全的变更：自动化验收测试和单元测试能够降低变更的风险
- 4）快速交付：自动化回归测试加快了特性开发和交付，测试人员不需要在特性发布前进行大量的手工测试，
只需要根据验收测试报告进行有针对性的探测测试。
BDD 的缺点和挑战
- 1）BDD 需要高度的业务协作
- 2）BDD 在敏捷开发或迭代开发中效果最好
- 3）BDD 在竖井业务模式下不能很好的工作
- 4）编写糟糕的测试会导致更高的测试维护成本