标签：项目 耦合 实现 程序代码 目的 模块 商业 报告 应该
Behavior Driven Development【行为驱动开发】是一种软件设计思想，用于实现更快地构建和交付有价值、
高质量的软件。1）客户人员告诉业务分析人员，他需要一个新的功能模块来支持业务发展。
2）业务分析人员将客户的请求转换为一系列的需求文档，这些文档用来描述软件应该做什么。
3）开发人员将这些需求分解为指定的特性，并用代码实现这些特性，同时编写单元测试。
4）测试人员将需求文档转换为测试用例，并用这些用例来验证新特性是否满足需求。
5）文档工程师将为新的功能编写技术文档和功能文档。
信息在传递的过程中容易出现丢失、被忽视、被误解等问题，导致最终交付的特性不能满足用户的真实需求。1）客户人员向业务分析人员提出他想要什么功能，并使用具体的实例来描述该特性需要做什么。
2）在实现该功能之前，业务分析人员、开发人员和测试人员一起开会，将特性分解为符合指定规范的实例化需求。
3）开发人员使用 BDD 工具将这些实例化需求转换为自动化验收标准，
验收测试将运行程序代码来确定指定的特性是否已经实现。
4）测试人员将基于验收测试的结果，来执行手动测试和探索性测试。
5）自动化验收测试充当低级的技术文档，并提供具体的特性描述。客户人员可以查看测试报告来确定哪些功能已经实现，是否符合预期。
BDD 极大地减少了信息丢失、被忽略、被误解等问题，降低了软件的不确定性。软件项目失败的原因有很多，但主要有以下两大类：开发人员花费大量的时间来修复缺陷，同时要保证变更代码没有不可预知的副作用
软件代码紧密耦合，新增一个新的特性要花费很长的时间
存在的技术文档早已过时
新特性实现之后，需要执行大量的手动测试，以保证旧的功能不受影响软件解决方案没有和商业目标保持一致，不能为客户达成商业目标提供价值。
交付的特性从未被用户使用，纯粹是浪费时间、精力、金钱。需求变更是项目发展的常态。
随着项目的发展，市场状况、商业策略、技术约束等都会变化。
积极地向最终用户和利益相关人了解他们需要实现的高级目标，这会帮助你更好的理解业务和系统功能，
更好的发现和交付匹配商业目标的有效解决方案。单元测试和特定的代码实现紧密耦合，
许多传统的单元测试都只关注于方法或函数的功能，而不是此代码应该实现什么业务特性使用 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）使用活文档支持正在执行的维护工作标签：项目 耦合 实现 程序代码 目的 模块 商业 报告 应该
原文地址：https://www.cnblogs.com/zhuxudong/p/10242054.html
