软件行业中，软件研发项目的产品交付经常被推迟、研发费用经常超出预算、经常遗漏客户所需的软件功能、有将近20%的项目最终无法交付，或者取消。这些软件研发往往花费了大量的资金、人力和时间，但所交付给用户的产品功能却有很大部分用户不会用到，或者没有能够帮助用户解决问题。
导致软件研发项目失败的原因是多种多样的，但最终结果可以分为两类：
- 没能正确的研发软件。
- 没能研发正确的软件。
没能正确的研发软件，主要是交付满足质量要求的软件，软件缺陷多且难以维护。没能研发正确的软件，主要表现在费用超出预算、软件产品延期交付、软件功能遗漏、产品功能错误或交付了客户根本不用的产品功能。
有鉴于此，行为驱动开发（Behavior Driven Development，BDD）借鉴了敏捷和精益实践，让敏捷研发团队尽可能理解产品经理或业务人员的产品需求，并在软件研发过程中及时反馈和演示软件产品的研发状态，让产品经理或业务人员根据获得的产品研发信息及时对软件产品特性进行调整。BDD 帮助敏捷研发团队把精力集中在识别、理解和构建跟业务目标有关的产品特性上面，并让敏捷研发团队能够确保识别出的产品特性能够被正确设计和实现出来。
图1 BDD 增进研发团队与业务人员的交流水平
引入 BDD 的软件研发团队通过充分的交流沟通和待实现的产品功能的使用场景举例，来帮助研发团队理解产品特性对业务的价值。BDD 采用更容易测试的软件需求描述方式鼓励需求分析人员、软件开发人员、测试人员密切协同开展软件产品研发工作。同时 BDD 工具可以帮助把用 BDD 风格描述的业务需求转换成自动化测试脚本，让软件开发人员同步验证自己编写的代码是否满足业务需求描述的产品特性，并在验证软件产品特性的同时形成软件产品特性文档，从而实现了产品研发文档与软件产品代码编写的同步更新。
BDD 并不是一种软件研发方法，也不是用来替代 Scrum、XP、看板等现有的敏捷理论和方法，而是把现有的工作方法融合起来，让软件研发团队更加高效的工作，从而减轻因软件产品计划延误或功能缺失带来的压力。
使用 BDD 的软件研发过程与传统软件研发过程有什么区别呢？
传统软件研发过程
传统软件研发过程是这样的：
业务人员把想要的软件产品需求讲述给软件需求分析人员。
软件需求分析人员把从业务人员那里获得的软件需求记录下来，并根据业务需求编写软件产品需求说明书。
软件开发人员根据软件产品需求说明书编写软件代码和单元测试代码。
软件测试人员根据软件产品需求说明书进行测试需求分析，编写测试案例（用例），并使用测试案例对软件产品进行测试。
最后软件开发团队根据稳定的软件版本编写软件产品的功能说明和技术说明文档。
图2 传统软件开发过程
传统软件研发模式的问题在于，在业务人员把业务需求描述给软件需求分析人员之后，软件需求分析人员按照自己的理解编写软件需求规格说明书，然后由研发人员根据软件需求规格说明进行软件架构设计和编写软件代码，最后由测试人员根据软件需求规格说明书编写测试案例进行测试。由业务需求到软件编码，再到软件测试的过程中，有不同角色和不同人员在不同时段对软件开发所需的信息进行处理，这中间有太多机会可能会导致丢失、弄错、甚至直接忽视业务人员的原始需求。软件研发的众多环节中，只要一个环节出错，软件研发团队就很难按时交付出符合业务人员要求的软件产品。
Behavior Driven Development（BDD），行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA 和非技术人员或商业参与者之间的协作。行为驱动开发特别适用于敏捷项目。行为驱动开发由一系列软件工程实践组成，这些软件工程实践可以用来帮组研发团队提高交付效率、交付质量和交付价值。 BDD 引入了敏捷管理、精益研发等思想，尤其包括测试驱动开发（TDD）和领域驱动设计（DDD）等软件研发方法。行为驱动开发（BDD）利用简单的格式化自然语言（包括英语、中文等语言）来提升敏捷研发团队和产品经理或业务人员之间的沟通水平，使得敏捷研发团队能够更好的理解业务目标，从而更好的满足产品经理或业务人员的产品需求。
BDD 的软件研发过程
BDD 的软件研发过程是这样的：
产品经理（业务人员）通过具体的用户故事使用场景来告诉软件需求分析人员他（她）想要什么样的软件产品。使用软件产品的使用场景来描述软件需求可以尽可能的避免相关人员错误理解软件需求或增加自己的主观想象的需求。
软件需求分析人员（BA）和研发团队（研发人员、测试人员）一起对产品经理（业务人员）的用户故事进行分析，并梳理出具体的软件产品使用场景举例，这些场景举例使用结构化的关键字自然语言进行描述，例如中文、英文等。
研发团队使用 BDD 工具把用户故事场景文件转化为可执行的自动化测试代码，研发人员运行自动化测试用例来验证开发出来的软件产品是否符合用户故事场景的验收要求。
测试人员可以根据自动化测试结果开展手工测试和探索性测试。
产品经理（业务人员）可以实时查看软件研发团队的自动化测试结果和 BDD 工具生成的测试报告，确保软件实现符合产品经理（业务人员）的软件期望。
图3 BDD 软件研发过程
如何实施行为驱动开发（BDD）呢？其实本课程之前章节的主线就是 BDD 的过程。我们把小明同学的机票销售系统的研发过程进行梳理，就是 BDD 的实践过程。
总结小明同学使用 BDD 研发机票销售系统的过程如下。
第一步：老板提出战略目标。（产品愿景）
同学们，市场竞争越来越激烈，飞机票代订业务也越来越难做。董事会要求我们今年的营业额要比去年增加20%，成本要降低10%。今天召集大家开会的目的就是请市场部、销售部和研发的童鞋一起献计献策，群策群力完成今年的业务目标。
第二步： 业务部门提出具体业务目标和软件需求。
- 增加常旅客积分积累和使用功能，通过我们公司电子商务网站或相关渠道购买机票的旅客可以积累里程积分。这些积分可以在下次购买机票时使用积分购买机票，也可以设置积分共享，让他（她）的亲友使用自己的积分购买机票。
- 增加电子商务网站访问渠道，例如可以通过微信或支付宝平台查询机票，购买机票，查看和共享里程积分。
- 为了增加客户的黏着度，新增用户登录积分和信息共享积分，用户登录使用我们电子商务网站越多，积分也越多。用户在我们电子商务网站发表旅行心得或为他人提供帮助信息也可以获取积分。使用积分可以这换成里程积分兑换机票。
第三步：产品经理（需求分析人员）与研发团队一起梳理用户故事，并实例化用户故事验收条件。
用户故事场景：新会员注册后初始状态为铜牌会员
# language: zh-CN
场景：新会员注册后初始状态为铜牌会员。
假如：小明同学还不是一位常旅客会员。
当：小明同学注册常旅客会员，注册时输入信息：
用户名 密码 xiaoming 12345678 [email protected] 那么：注册成功后，小明同学的初始会员级别为“铜牌会员”。
第四步： 研发人员（测试人员）使用 BDD 工具，例如 Cucumber，转化为可以运行的验收测试说明文档，也是自动化验收测试案例
@假如("^小明童鞋还不是一位常旅客会员$")
public void 小明童鞋还不是一位常旅客会员() throws Throwable {
//TODO： 注册前小明童鞋还不是常旅客会员
throw new PendingException();
}
@当("^小明童鞋注册常旅客会员:$")
public void 小明童鞋注册常旅客会员(DataTable arg1) throws Throwable {
///TODO：小明童鞋注册为会员
throw new PendingException();
}
@那么("^注册成功后，小明童鞋的初始会员级别为'铜牌会员'$")
public void 注册成功后_小明童鞋的初始会员级别为_铜牌会员() throws Throwable {
//TODO： 注册成功后检查小明童鞋的会员状态
throw new PendingException();
}
第五步：研发人员根据用户故事设计软件功能，编写单元测试和实现代码，当软件功能通过单元测试时，表示软件功能满足了设计需求。
public class WhenCheckingMinimumStatusPoints {
FrequentFlyer member;
@Before
public void newFrequentFlyer() {
member = FrequentFlyer.newMemberWithUsername("xiaoming").password("12345678").email("[email protected]");
}
@Test
public void should_have_bronze_status_initially() {
assertThat(member.getStatus()).isEqualTo(FrequentFlyerStatus.BRONZE);
}
enter code here
}
第六步：研发人员运行第四步中生成的验收测试代码，验收测试可以是 UI 层端到端测试也可以是接口测试。
public class UserRegisterPage extends PageObject {
@FindBy(name="username")
private WebElement username;
@FindBy(name="password")
private WebElement password;
@FindBy(name="email")
private WebElement email;
@FindBy(css = ".btn[value='Sign up']")
private WebElement signup;
public void signupAs(String username, String userPassword, String userEmail ) {
username.sendKeys(username);
password.sendKeys(userPassword);
email.sendKeys(userEmail);
//点击注册按钮
signup.click();
}
}
第七步：产品经理可以实时查看验收测试报告，验收测试报告同时也是产品说明文档。
图4 BDD测试生成文档
最后说明一下，BDD 自动化测试代码可以使用持续集成平台或 DevOps 平台根据指定的持续集成规则运行，这样可以提高团队协作效率，及时公布单元测试、集成测试和用户验收测试的测试状态。