Cucumber入门2 - 啥是BDD?

我写本书的目的是单纯地介绍Cucumber这个自动化测试工具。而避免涉及敏捷。一怕理论、概念太多,二怕不实用。我不喜欢不实用的东西。可若是略过BDD,单讲Cucumber终究不太合理。因此,这一章,我就说说BDD。

简易BDD

上文中,我们知道Cucumber:

  • 可以使用自然语言描述测试用例
  • 可以作为自动化测试运行

作为一个自动化测试工具,这些已经足够了。然而,Cucumber的首页清楚地写着“making BDD fun”,即让行为驱动开发充满欢乐。行为驱动开发(BDD)是什么?Cucumber的开发者为什么又要给它扣上这个帽子呢?

 

为了找到答案,我们再次回到Cucumber的首页的六副图。

Cucumber入门2 - 啥是BDD?_第1张图片

 

有了前一章传统流程的基础,这一次我们按照BDD的流程来介绍这六张图。

  • 图1.使用自然语言描述产品行为。此处,行为代表着用户需求。即当用户以某种方式使用该产品,又将获得怎样的反馈。稍后,这个文件又可以作为测试用例。因此,行为在此处即是用户需求,又是测试用例。正因为使用需求来进行测试,这个强大的愿景,才使得BDD可以更加节约、迅捷。
  • 图2.使用ruby进行步骤定义。作为用户需求与测试用例的行为,仅仅是文本。为了让这些文本可以作为自动化测试运行起来,我们需要编写步骤定义的代码。
  • 图3.运行Cucumber,失败。原因很简单:有了可以运行的自动化测试,却没有对应的产品代码。
  • 图4.编写产品代码。
  • 图5.运行Cucumber。因为有了部分产品代码,原来失败的自动化测试通过了。准确的说,暂时,部分通过了。
  • 图6.重复上述步骤,直到所有产品行为都描述完毕,所有产品代码都可以通过行为的自动化测试。即:在产品代码完成后,使用先前编写好的、可以运行的行为来自动化测试产品代码。在自动化测试通过后,完成产品开发。

总结一下上述流程:我们先描述产品行为(Describe behavior)作为用户需求和测试用例。而后,为行为(behavior)提供自动化步骤(step definitions),使其成为自动化测试。接下来,编写产品代码,以使得它能够通过行为的自动化测试。整个流程中,产品代码的开发,都是由行为驱动(Behavior Driven)的。因此,我们将这个流程,称之为行为驱动开发(Behavior driven development)。

复杂项目中的BDD

在你发现之前,我先承认。到目前为止,这篇文章有个致命的缺陷:例子太简单了。现实中,有几个人会花钱顾咱们做加法计算器呢?但凡项目,都是需求文档、功能文档、模块设计文档、代码、测试文档、测试用例、系统测试文档、用户验收测试文档一大堆。上述例子这种,一个需求,几个测试用例,几行代码的项目,这个真没有。

咱们先来看看复杂项目中,传统的开发流程W模型,如图:

Cucumber入门2 - 啥是BDD?_第2张图片

 

在W模型中,每一份项目文档,都对应着一份测试文档,如:用户需求文档与用户验收测试文档。每一份测试文档,又可能对应着一份自动化测试代码,如:用户验收测试文档与自动化用户验收测试代码。

说完了传统流程,再回到BDD。2.1的例子中,BDD整合了用户需求、测试用例、自动化测试用例。针对复杂项目,BDD的解决办法依旧是:整合!整合!整合!如图:

Cucumber入门2 - 啥是BDD?_第3张图片

在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开发,是这样的:周一早晨上班时,团队成员一起书写一个或几个用户行为,并为每个行为估算工作量。从中选出可以在一周内完成的部分,以作为本周目标开始工作。工作中,通过对用户行为的深入理解,书写系统行为以及可能需要的模块行为。在开发人员编写产品代码时,由测试人员编写步骤定义。周五,开发人员陆续将代码提交,并使用测试人员自动化过的行为进行测试。当所有行为都通过时,本周任务完成。如图:

Cucumber入门2 - 啥是BDD?_第4张图片

BDD流程中,包含的敏捷思想有:

  • 个人交流胜过流程与工具:一周内,开发人员和测试人员都要肩并肩一起工作
  • 可交付的软件胜过繁复的文档:一周内,几乎没有任何文档产生,所有行为都以代码方式存在

回顾

  • BDD是一个由外而内、以拉力驱动、高度自动化的敏捷方法
  • BDD的实践,需要用户、开发人员和测试人员共同努力
  • BDD中的行为,可以整合传统流程中的诸多文档与代码;可以减少为维护文档而造成的浪费;
  • 在Cucumber中,行为(behavior)是用功能(feature)文件来描述的
  • Cucumber只是BDD中的一个工具,还有其他工具如Jbehave等

 

说完正事儿,我得表个态。BDD是好东西,一如TDD,一如AATDD。它够快,够直接,够节约,因此,够敏捷。

可BDD并非适用于所有产品、所有团队。开发Cucumber的人们,有着良好的编码技能与质量意识。Cucumber自己的源码中,就包含Cucumber自己的功能(feature)文件。因此,他们难免会对使用者,有期许,期许他们与自己一样,有着良好的编码技能与质量意识。但大部分我所交流过的团队,测试人员并不具备如此优秀的编码技能,而开发人员又具备如此优秀的质量意识。然后,还要考虑因为忽然接触新事物、新知识导致的短期的效率降低。长远来看,也可能由于人为因素导致其他问题。

因此,我喜欢BDD,但不推荐它、不试图推广。但是,如果抛开BDD,只是把Cucumber当做一个自动化测试工具,在不改变现有流程的情况下,去用,去体会,去思考。渐渐地,一个组或一个项目便可以慢慢地减少浪费,增加自动化,在更短时间提供更多的可交付的产品。甚至于,不知不觉地转型成BDD。这就是我喜欢cucumber,推荐、也试图推广它的原因。

你可能感兴趣的:(入门)