标签归档:BDD

新一代支持BDD的测试框架Gauge+Taiko

BDD是什么

BDD,Behavior Driven Development,行为驱动开发。

如果你不是很了解BDD,可以参考我四年前的一篇文章说起BDD,你会想到什么,其中介绍过BDD的理论和应用。

我们可以这样来概括BDD:

  • BDD采用统一的领域特定语言(DSL)来描述业务场景和用户行为,让团队各个不同角色对业务需求有一致认识,从而做到更有效的沟通和更高效的协作
  • BDD的目的不是自动化测试,但是BDD可以有效指导自动化测试,基于BDD的自动化测试相当于维护了一份需求活文档,对项目需求的维护和管理非常有价值。

BDD应用框架之Cucumber

BDD的应用

BDD是为解决下面三个方面的问题而生:

  1. 协作:多个角色在一个团队,如何从一致理解需求开始高效协作?
  2. 语言:不同的角色业务、开发和测试人员分别说自己的语言,如何统一语言,更有效的沟通?
  3. 文档:编写和维护的成本都很高,如何低成本的维护一份有价值的文档?

Cucumber是一款支持BDD的框架,有助于帮助团队解决以上问题。

Cucumber支持用自然语言描述业务场景,需要遵循Given-When-Then的格式,这样就可以容易的对应到自动化测试的3A步骤Arrange-Act-Assert,从而实现业务场景的自动化测试。

Cucumber的理想是将可执行的需求规范、自动化测试和活文档有机的结合,如下图所示:

理想很丰满,现实很骨感。Cucumber在实际应用中的情况又如何呢?

Cucumber的痛点

Cucumber框架实现Web自动化测试包括两个部分:Feature(特性)文件和Step Definition(测试实现),在实际应用中人们普遍感觉到它的复杂。

  • Cucumber特别强调的是协作,Feature文件通常由偏业务的人员来编写,要求遵循Given-When-Then的格式。这种固定的语法对编写人员要求较高,写起来比较费劲,尤其对新人不友好,很多团队反映要写出好的Feature文件特别费时费力。
  • Cucumber支持多种语言实现测试代码,但它本身并不能实现自动化,对于Web自动化测试需要跟其他自动化工具结合,比如Selenium-WebDriver。实现代码不仅复杂,还有着元素定位难、执行时间长、不够稳定的痛点。

Cucumber-js+Selenium WebDriver实现的代码长这样:

Feature定义:

Feature: Google Search
  Scenario: Finding some cheese
    Given I am on the Google search page
    When I search for "Cheese!"
    Then the page title should start with "cheese"

Steps实现

Given('I am on the Google search page', async function () {
    await driver.get('http://www.google.com');
});

When('I search for {string}', async function (searchTerm) {
    const element = await driver.findElement(By.name('q'));
    element.sendKeys(searchTerm, Key.RETURN);
    element.submit();
});

Then('the page title should start with {string}', {timeout: 60 * 1000}, async function (searchTerm) {
    const title = await driver.getTitle();
    const isTitleStartWithCheese = title.toLowerCase().lastIndexOf(`${searchTerm}`, 0) === 0;
    expect(isTitleStartWithCheese).to.equal(true);
});

新一代BDD框架

蓝鲸项目曾经就是用Cucumber+Selenium WebDriver实现的UI层自动化测试,由于上述痛点,大家觉得UI自动化测试越来越难写,我也因此对BDD丧失了信心。

自从遇到了两款新的工具Gauge+Taiko,我又重新对Web系统的实现基于BDD的自动化测试燃起了希望。

Gauge

Gauge是一款开源的轻量级跨平台自动化测试工具,它的愿景是用更少的代码、更少的维护工作实现更多的自动化测试,有如下特性:

  • 采用Markdown格式,支持用自然语言编写Spec,语法自由,编写工作简单易上手,不管是对业务人员还是技术人员都很友好;写出来的文档格式清晰,很好维护。
  • Gauge本身可以实现对Web页面的访问和控制,支持多种语言,各种API封装的很好,代码实现部分比Selenium要简单很多,尤其对于编程技能不是那么强的QA来讲非常友好,易上手,代码的可读性也更强一些。

Taiko

Taiko也是一款开源浏览器自动化测试工具,它的特性如下:

Taiko – REPL
  • 交互式的录制体验。Taiko提供类似于irb的REPL,直接输入命令,可以看到浏览器执行结果,同时后续还可以把成功执行的命令直接生成JS代码,非常方便。
  • Taiko不仅提供常见UI自动化测试工具那样根据Id、name、CSS、Xpath等方式选择页面元素的功能,还提供智能选择器(Smart selector),支持直接根据显示的文本来定位各种类型的页面元素,同时还有支持上、下、左、右这种根据某个元素的相对方位去定位元素的API,很好的解决UI测试页面元素定位难的问题。
  • Taiko采用隐式的等待(Wait)方式,也可以手动设置超时时间以防有些访问等待时间过长。这种隐式等待相比其他自动化工具需要手动设置等待时间的显式等待方式要更高效、更稳定。
  • 与Gauge的完美结合:Taiko在REPL里执行的浏览器操作步骤,可以通过一个简单的命令直接生产Gauge支持的Step,只需要再去简单的加上step名称就可以,操作及其简单。

Gauge+Taiko的代码长这样:

Spec定义

# Google Search

This is an executable specification file. This file follows markdown syntax. 
Every heading in this file denotes a scenario. 
Every bullet point denotes a step.
To execute this specification, use
    npm test

## Finding some cheese
* Goto Google search page
* Google for "Cheese!"
* Page title starts with "Cheese"

Steps实现

step("Goto Google search page", async function() {
    await goto("www.google.com");
});

step("Google for <query>", async (query) => {
    await write(query);
    await click("Google 搜尋");
});

step("Page title starts with <content>", async (content) => {
    await title().then((pageTitle) =>{
        assert.ok(pageTitle.startsWith(content));
    });
});

总结

协作是人的问题,工具可以起到辅助作用,但是不能解决根本问题,过于严格的工具缺乏灵活性,反而阻碍了高效协作的可能。

Gauge不强调协作,可以作为自动化测试工具独立存在,同时又支持高效协作、支持实现BDD,是一款灵活性更好的框架。它的秘密武器Taiko是一款优秀的Web UI自动化工具,两者的结合堪称完美,让需求规范、自动化测试和活文档的有机结合真正成为可能。

本文只是将Gauge和Taiko跟Cucumber框架从对BDD的角度做简单的对比,更多的关于Gauge和Taiko的高级特性,请参考【延伸阅读】部分相关文章。

延伸阅读

说起BDD,你会想到什么?

在刚接触BDD(Behavior Driven Development,行为驱动开发)的时候,我以为就是用Cucumber这样的工具来编写场景用例,从而实现自动化测试,甚至很长时间分不清BDD和ATDD(Acceptance test driven development)到底有什么区别。那么,BDD真的就是用来做自动化测试的吗?本文就来跟大家分享一下我理解的BDD。

BDD

为什么要BDD?

“开发软件系统最困难的部分就是准确说明开发什么” (“The hardest single part of building a software system is deciding precisely what to build” — No Silver Bullet, Fred Brooks) 。

场景一:业务分析人员觉得自己分析的需求已经写的很清晰了,并且跟技术人员进行了足够的沟通,可是开发完做Desk check的时候,发现所开发的功能还是跟期望有差距。
场景二:开发团队辛辛苦苦开发完一个功能,满怀信心的去给产品经理/客户展示的时候,才发现原来客户需求的功能不是这样的。

这些场景是不是似曾相识?为什么会这样?第一个场景是开发团队内部技术人员跟需求分析人员的理解有偏差,导致大家理解的需求其实是不一样的;第二个场景是开发团队没有真正理解产品经理/客户所提出来的真实需求,导致开发的产品跟需求不一致。其实,产生这两个不一致的真正原因是因为不同角色有着不同的领域知识,说着不同的语言,大家在沟通的时候,如果都用自己领域语言,必然会产生沟通代沟,导致理解的不一致性。

领域知识不同、语言不通导致沟通障碍,这个客观存在的问题该如何解决呢?BDD正是为此而生。

BDD是什么?

BDD的提出者Dan North强调BDD不是关于测试的,它是在应用程序存在之前,写出用例与期望,从而描述应用程序的行为,并且促使在项目中的人们彼此互相沟通。

要给BDD下个清晰易懂的定义很难,包括大师们也这么认为,这里试着总结以下几点:

1. 关注的是业务领域,而不是技术:BDD强调用领域特定语言(DSL, domain specific language)描述用户行为,定义业务需求,而不会关心系统的技术实现。
2. 不是工具,强调的是一种协作方式:BDD要求各个角色共同参与系统行为的挖掘和定义,以实现对业务价值的一致理解。
3. 不是关于测试的:BDD源自TDD,又不同于TDD,重点不是关于测试的,但可以指导更好的做自动化测试。
4. 全栈敏捷方法:BDD促使团队所有角色从需求到最后的测试验证,进行高度的协作和沟通,以交付最有价值的功能。

BDD怎么做?

用例场景的描述格式“GIVEN… WHEN… THEN… ”对大家都不陌生,但用这个格式写出好的用例却是非常的难,尤其是新手。这里总结几点供大家参考:

1.业务层抽取,业务语言描述

根据业务层的数据流,在每个数据停留点进行纵切,抽取出一个个用例场景。描述语言一定是业务领域可懂的,不要涉及任何实现相关的技术细节。所描述的场景一定是从业务层抽象出来,体现真实业务价值的。

2.技术人员可懂,自动化友好

所描述的用例场景要能驱动开发,必须要让技术人员易于理解;要指导自动化测试,还得要求对于自动化的实现是友好的。这一点似乎是跟第一点有些矛盾,但我们严格遵守BDD的格式要求还是可以做到的。其中,GIVEN从句描述的是场景的前提条件、初始状态,通常是一种现在完成时态;WHEN从句是采取某个动作或者是发生某个事件,一定是动词,通常是一般现在时;THEN从句用“应该…(should be…)”来描述一种期望的结果,而不用断言(assert),后者与测试关联更紧密。

3.数据驱动,需求实例化

抽象的业务语言描述的需求,往往由于太抽象而缺失掉很多关键信息,导致不同人员对需求理解的不一致。想要既抽象又能包含细节信息,就需要采用需求实例来描述。简单说来,就是给场景用例举例说明。举例就会需要列举数据,如果在场景用例描述里边直接添加数据实例,那样的用例将会很混乱,可读性和可维护性都非常差。如果我们能够在描述场景的用例里边用一些变量来代替,把变量对应的值(数据)提取出来存为一个表格或者独立的文件,这样将会使得用例的可读性很好,而且也不会缺失细节信息(数据),后期的维护和修改也较为方便。这就是数据驱动的方法来描述实例化的需求。

下面举几个例子,大家体会一下:

场景一:检查收件箱,可以看出第三个清晰明了且能体现业务价值,比较符合上面的要求。

场景二:限制非法用户查看某些受限内容,BDD要强调什么(What),而不是怎么(How),第二个写的比较好。

场景三:添加图书到购物车并计算总额

BDD的工具有Cucumber、JBehave、Twist、Concordion等,工具的优缺点和使用方法,网上都有丰富的文档可参考,在此不作介绍。

BDD有什么好处?

BDD的作用是把利益关系人、交付团队等不同方面的项目相关人员集中到一起,形成共同的理解,共同的价值观以及共同的期望值。它可以帮助我们:

1. 关注用户行为

2.交付最有用的功能

3. 在团队内部维护一致的术语

4. 探究需求实例

5. 编写和维护需求

6. 创建活的文档

7. 消除协作与沟通障碍

什么样的项目适合BDD?

简单的一次性项目,沟通交流成本都较低的情况下,没有必要使用BDD;

业务比较轻量,重在技术方面的项目,可以使用简单的白板上的BDD,不需要在BDD工具记录需求用例文档;

业务复杂、团队成员较多的项目,沟通成本高,BDD很有必要。

常见疑惑

1.BDD与TDD/ATDD

TDD是测试驱动开发,ATDD是验收测试驱动开发,都是关于测试的,是与所开发的系统紧密联系的。而BDD则不同,前面提到过BDD不是关于测试的,着重关注需求、关注客户的业务价值,所描述的需求用例是可以独立于软件系统存在的,因为客户的业务是始终存在的,不取决于是否有软件系统来支撑。

2. BDD与SBE

SBE(Specification By Example,实例化需求)是在BDD之后由Gojko提出来的,也是关于需求的,主要强调通过列举实例发现需求中的缺失概念。BDD也是关注需求的,同样会使用实例来描述行为。两者的本质没有区别,只是概念的差异。

(此文发表于TW洞见