| 编辑推荐: |
文章主要介绍了行为驱动开发（BDD）是什么？传统的开发流程W模型，W模型与BDD模型的区别等。
本文来自于cnblogs，由火龙果软件Luca编辑、推荐。 |
|
简易BDD
我们知道Cucumber：
可以使用自然语言描述测试用例
可以作为自动化测试运行
作为一个自动化测试工具，这些已经足够了。然而，Cucumber的首页清楚地写着“making BDD
fun”，即让行为驱动开发充满欢乐。行为驱动开发（BDD）是什么？Cucumber的开发者为什么又要给它扣上这个帽子呢？
为了找到答案，我们再次回到Cucumber的首页的六副图。
有了前一章传统流程的基础，这一次我们按照BDD的流程来介绍这六张图。
图1.使用自然语言描述产品行为。此处，行为代表着用户需求。即当用户以某种方式使用该产品，又将获得怎样的反馈。稍后，这个文件又可以作为测试用例。因此，行为在此处即是用户需求，又是测试用例。正因为使用需求来进行测试，这个强大的愿景，才使得BDD可以更加节约、迅捷。
图2.使用ruby进行步骤定义。作为用户需求与测试用例的行为，仅仅是文本。为了让这些文本可以作为自动化测试运行起来，我们需要编写步骤定义的代码。
图3.运行Cucumber，失败。原因很简单：有了可以运行的自动化测试，却没有对应的产品代码。
图4.编写产品代码。
图5.运行Cucumber。因为有了部分产品代码，原来失败的自动化测试通过了。准确的说，暂时，部分通过了。
图6.重复上述步骤，直到所有产品行为都描述完毕，所有产品代码都可以通过行为的自动化测试。即：在产品代码完成后，使用先前编写好的、可以运行的行为来自动化测试产品代码。在自动化测试通过后，完成产品开发。
总结一下上述流程：我们先描述产品行为（Describe behavior）作为用户需求和测试用例。而后，为行为（behavior）提供自动化步骤（step
definitions），使其成为自动化测试。接下来，编写产品代码，以使得它能够通过行为的自动化测试。整个流程中，产品代码的开发，都是由行为驱动（Behavior
Driven）的。因此，我们将这个流程，称之为行为驱动开发（Behavior driven development）。
复杂项目中的BDD
在你发现之前，我先承认。到目前为止，这篇文章有个致命的缺陷：例子太简单了。现实中，有几个人会花钱顾咱们做加法计算器呢？但凡项目，都是需求文档、功能文档、模块设计文档、代码、测试文档、测试用例、系统测试文档、用户验收测试文档一大堆。上述例子这种，一个需求，几个测试用例，几行代码的项目，这个真没有。
咱们先来看看复杂项目中，传统的开发流程W模型，如图：
在W模型中，每一份项目文档，都对应着一份测试文档，如：用户需求文档与用户验收测试文档。每一份测试文档，又可能对应着一份自动化测试代码，如：用户验收测试文档与自动化用户验收测试代码。
说完了传统流程，再回到BDD。2.1的例子中，BDD整合了用户需求、测试用例、自动化测试用例。针对复杂项目，BDD的解决办法依旧是：整合！整合！整合！如图：
在BDD的流程中，行为这一概念，整合了多种文档与代码：
用户行为描述用户与系统交互的场景，作为用户需求，验收测试，和自动化验收测试
系统行为描述系统提供的功能场景，作为系统功能文档，系统测试，和自动化系统测试
模块行为描述模块间交互的场景，作为模块功能文档，模块测试，和自动化模块测试
对比W模型与BDD模型，最主要的区别：
W模型的每个横向阶段，都需要保存三份拷贝：功能文档+测试文档+自动化测试用例
BDD模型只需要一份拷贝，行为
采用BDD流程进行开发，由外而内，持续地描述当前系统或模块的行为，并为之实现自动化（即步骤定义）。当产品代码部分完成后，右侧的一系列测试活动都已经自动化了。(至于如何迭代开发，如何持续集成，如何划分用户故事以保证可持续发布可交付的产品，这里就不做过多讲述。有兴趣的，可以看看敏捷的书。)
维基百科上对BDD的定义，原文为：
BDD is a second-generation, outside–in, pull-based,
multiple-stakeholder, multiple-scale, high-automation,
agile methodology. It describes a cycle of interactions
with well-defined outputs, resulting in the delivery
of working, tested software that matters.
我用中文复述下：
BDD是一个第二代的敏捷开发方法。它有如下特点：
由外而内：用户 -> 系统 -> 模块
以拉力驱动：先设定目标，即行为，而后编写产品代码去实现目标
多利益人：用户、开发人员、测试人员共同维护行为
多扩展性：可以描述用户级、系统级、模块级行为
高度自动化：只要提供步骤定义，所有行为都可以作为自动化测试运行
它定义了一个可持续的周期，在周期中人们先设定目标，再为了达到预期目标而进行编码，只有代码通过验证才可提交。持续交付可工作、经过测试的软件。
理想中的BDD开发，是这样的：周一早晨上班时，团队成员一起书写一个或几个用户行为，并为每个行为估算工作量。从中选出可以在一周内完成的部分，以作为本周目标开始工作。工作中，通过对用户行为的深入理解，书写系统行为以及可能需要的模块行为。在开发人员编写产品代码时，由测试人员编写步骤定义。周五，开发人员陆续将代码提交，并使用测试人员自动化过的行为进行测试。当所有行为都通过时，本周任务完成。如图：
BDD流程中，包含的敏捷思想有：
个人交流胜过流程与工具：一周内，开发人员和测试人员都要肩并肩一起工作
可交付的软件胜过繁复的文档：一周内，几乎没有任何文档产生，所有行为都以代码方式存在
回顾
BDD是一个由外而内、以拉力驱动、高度自动化的敏捷方法
BDD的实践，需要用户、开发人员和测试人员共同努力
BDD中的行为，可以整合传统流程中的诸多文档与代码；可以减少为维护文档而造成的浪费；
在Cucumber中，行为（behavior）是用功能（feature）文件来描述的
Cucumber只是BDD中的一个工具，还有其他工具如Jbehave等
说完正事儿，我得表个态。BDD是好东西，一如TDD，一如AATDD。它够快，够直接，够节约，因此，够敏捷。
可BDD并非适用于所有产品、所有团队。开发Cucumber的人们，有着良好的编码技能与质量意识。Cucumber自己的源码中，就包含Cucumber自己的功能（feature）文件。因此，他们难免会对使用者，有期许，期许他们与自己一样，有着良好的编码技能与质量意识。但大部分我所交流过的团队，测试人员并不具备如此优秀的编码技能，而开发人员又具备如此优秀的质量意识。然后，还要考虑因为忽然接触新事物、新知识导致的短期的效率降低。长远来看，也可能由于人为因素导致其他问题。
因此，我喜欢BDD，但不推荐它、不试图推广。但是，如果抛开BDD，只是把Cucumber当做一个自动化测试工具，在不改变现有流程的情况下，去用，去体会，去思考。渐渐地，一个组或一个项目便可以慢慢地减少浪费，增加自动化，在更短时间提供更多的可交付的产品。甚至于，不知不觉地转型成BDD。这就是我喜欢cucumber，推荐、也试图推广它的原因。
|
