行为驱动测试历史发展与现状

行为驱动开发（Behavior Driven Development）即BDD，是一种敏捷开发方法，通常应用在自动化测试中，或者也可称为行为驱动测试。通过使用自然描述语言确定自动化脚本，通过这种方式，能够大大促进团队之间的沟通。实现BDD的工具有Cucumber、JBehave、RBehave，以及桌面客户端CukeTest。 下面以自动化测试开发模式的发展过程来说明下行为驱动测试历史发展与现状。

自动化测试方法的现状

随着 Agile 开发模式在越来越多的项目组中推广，持续集成 (CI) 作为 Agile 的重要组成部分，也被越来越多的项目组采纳并实施，在这个部署实施过程中，自动化测试在软件测试中占有越来越重要的地位，如何让我们的自动化测试能更快，更有效的运作，一直是我们探索的目标。在实际的项目中，我们可能随时面对各种不同的需要，而这些也决定了我们采用什么样的开发模式。

下面为常用几种开发模式

TDD

测试驱动开发（Test Driven Developme
4000
nt）。它的想法来自于极限编程（Extreme Programming）。TDD 是 Agile 开发中的一项核心实践和技术，也是一种设计方法。引用 Wikipedia 上的关于 TDD 的介绍：

测试驱动开发（英语：Test-driven development，缩写为TDD）是一种软件开发过程中的应用方法，由极限编程中倡导，以其倡导先写测试程序，然后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。

TDD 的基本思想是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计和质量控制量化的过程。TDD 简单的说就是：每写一段代码之前，先写一个单元测试；根据单元测试的功能，开始编码；待到代码可以使之前的测试通过后，编码完成；在保持测试通过情况下，重构代码。

引自维基百科的解释

测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。

对于测试驱动开发，有优点也有缺点：

优点

可以有效的避免过度设计带来的浪费。但是也有人强调在开发前需要有完整的设计再实施可以有效的避免重构带来的浪费。

可以让开发者在开发中拥有更全面的视角。

缺点

开发者可能只完成满足了测试的代码，而忽略了对实际需求的实现。有实践者认为用结对编程的方式可以有效的避免这个问题。

会放慢开发实际代码的速度，特别对于要求开发速度的原型开发造成不利。这里需要考虑开发速度需要包含功能和品质两个方面，单纯的代码速度可能不能完全代表开发速度。

对于GUI,资料库和Web应用而言。构造单元测试比较困难，如果强行构造单元测试，反而给维护带来额外的工作量。有开发者认为这个是由于设计方法，而不是开发方法造成的困难。

使得开发更为关注用例和测试案例，而不是设计本身。目前，对于这个观点有较多的争议。

测试驱动开发会导致单元测试的覆盖度不够，比如可能缺乏边界测试。在实际的操作中，和非测试驱动开发一样，当代码完成以后还是需要补充单元测试，提高测试的覆盖度。

ATDD

验收性测试驱动开发（Acceptance Test Driven Development）。这种开发模式是整个团队在开发工作之前，一起讨论、制定每个任务的验收标准，并提取测试用例。ATDD 是从 TDD 发展过来的，ATDD 就是为了解决 TDD 的一些缺点而出现。

因为 TDD 只涉及到开发人员，测试人员及业务经理。如果开发人员可能只完成了满足测试的代码却忽略实际需求的实现，那么将会造成测试人员写的测试用例是不够的也有可能是错误的。所以在 ATDD 中首先要求团队定义出期望的质量标准和验收细则，以明确而且达成共识的验收计划（报告测试用例）来驱动开发人员 TDD 实践和测试人员的测试脚本。

在明确而且达成共识的验收计划中，通常情况下，我们以如下的文档格式来定义我们的文档。

Given (setup)
A specified state of a system

When (trigger)
An action or event occurs

Then (verification)
The state of the system has changed or an output has been produced

ATDD的这种文档格式借鉴BDD的概念，并把它应用到验收测试中。下面我们给大家介绍一下应用广泛的BDD和相关的工具。

BDD

行为驱动开发（Behavior Driven Development）。它也是 Agile 开发的技术，引用 Wikipedia 上的关于 BDD 的介绍：

行为驱动开发（英语：Behavior-driven development，缩写BDD）是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。

这种开发模式鼓励软件项目中的开发人员，测试人员和非技术人员或者客户之间的协作，从用户的需求出发，强调系统行为。在 TDD 中，我们并不能完全保证根据设计所编写的测试就是用户所期望的功能，用户并一定能看懂测试用例。BDD 将这一部分用更接近自然语言的形式来描述，让测试用例更自然化和简单，使开发人员，测试人员和客户能在这个基础上达成一致。

TDD 与 BDD 的自动化测试比较

图 1 显示了在 TDD 技术下测试人员的测试过程，TDD 的测试用于单元测试，一般开发人员用什么语言，单元测试就用什么语言。在此其中，测试人员参与的机会不多，通常有了测试任务后，测试人员会将它分成测试计划，然后再细分成测试点列表，每一份测试列表可能又对应着一份自动化测试用例，所以这个阶段就需要保持三份文档： 需求文档 + 测试点文档（计划和测试点）+ 自动化测试用例，整个 TDD 的过程中，自动化测试用例的编写是在测试点列表出来之后。

图 1. TDD 技术下的测试过程



与 TDD 侧重于针对单元测试不同，BDD 以用户的目标以及他们为了实现这些目标而采取的步骤为侧重点，BDD 将三种文档进行了整合，用户行为描述了用户与系统交互的场景，而系统行为描述了系统提供的功能场景，模块行为描述模块间交互的场景，整个过程中只需要一份文档，用户行为也是用户需求，也是测试点文档和自动化测试用例，随着系统行为或模块的行为的实现，一系列的测试活动都已经自动化了。

图 2. BDD 技术下的测试过程

BDD的发展

BDD最初是由Dan North在2003年命名，2009年，在伦敦发表的“敏捷规格，BDD和极限测试交流”中，Dan North对BDD给出了如下定义：

BDD是第二代的、由外及内的、基于拉(pull)的、多方利益相关者的(stakeholder)、多种可扩展的、高自动化的敏捷方法。它描述了一个交互循环，可以具有带有良好定义的输出（即工作中交付的结果）：已测试过的软件。

Dan North创造了首个BDD框架：JBehave；之后是Ruby语言的基于故事的RBehave，后来被纳入了RSpec项目。他还与大卫赫利姆斯基、Aslak Hellesøy及其他人开发了RSpec，并一起编写了《The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends》。RSpec中第一个基于故事的框架，后来被主要由Aslak Hellesøy开发的Cucumber取代。

BDD的现状

Cucumber的出现，促进了以BDD开发模式的自动化测试实践，大量公司使用BDD的方式做为产品自动化测试技术的实现。Cucumber团队同时也想开发一款Cucumber Pro的产品，但是，不幸的是，当Cucumber团队开发了2年之后却宣布原有开发要丢弃重来，截稿为止，在Cucumber官网上Pro版本依旧未能与大家见面。不过，现在已经有支持专门开发Cucumber脚本的桌面端工具CukeTest，它提供了node.js开发环境，并提供可视化界面进行测试用例的编写，用户不用专门记忆Cucumber的语法，还支持自动生成代码和从代码定位到场景步骤的功能。此外还有一些其它功能如可视化报表、视频录制、代码智能提示等。CukeTest还可以便捷的进行测试用例管理。大家可以去CukeTest官网免费下载使用。

BDD近两年在欧美企业得到越来越高的重视，这跟它的一系列优越性是分不开的，其它原因还包括持续集成的广泛实施和有越来越完善的BDD工具支持等，相信不久在中国的企业当中也会被更广泛的采用。