Jbehave 学习JBehave行为驱动开发（BDD）是一个框架。

BDD是测试驱动开发（TDD）和验收测试驱动开发（ATDD）的一种演进，目的是使新手和专家开发实践起来更加方便和直观。

它改变了从被测试为基础到以行为为基础的词汇，将自己定位为一个设计理念。

一、BDD课题研究之测试思想和方法总结此次研究的课题是BDD，主要涉及两个方面：测试的思想和方法、技术框架。

这里做测试思想和方法的总结。

BDD是什么全称： Behaviour Driven Development（行为驱动开发）。

BDD改变了我们对软件测试的认识。

先前我对测试的认识是：从大的角度来讲，软件测试就是对一个软件系统从功能上进行确认测试和验证测试，从性能上进行压力测试和负载测试，以及对系统的配置测试和兼容性测试等，从类别上又有单元测试，集成测试，回归测试，所有的这些测试工作都有一个目的：交付一套高质量的软件系统。

我们软件测试人员的工作就是：尽可能早的找出软件缺陷，并确保其得以修复。

顺理成章的，在我们的思维中是：我们先拿到系统的既成品，然后开展测试工作，而BDD恰好颠覆了我们的思维。

回到BDD正题，BDD中有两个大的概念：测试先行和系统设计。

测试先行：BDD提倡我们在开发者的编码工作开展之前，先写测试用例，然后由测试来推动着开发的工作，具体解释为：在设计如何实现一个功能前，先考虑如何测试这个功能，测试的代码完成后，再编写功能实现代码，并且使得该测试用例通过，即完成了系统的一个功能模块。

系统设计：在系统功能实现代码编写之前，我们需要先编写测试代码，在我们的测试代码中实现对系统行为的描述，这个描述其实就是用一种接近自然语言的方式对系统进行详细的设计，并且使项目相关人员，即使是非技术人员也能很容易看懂。

关于系统行为，举例说明：用户在一个特定的条件下对系统做请求，系统在该条件下做什么样的处理，这就是系统的一个行为。

总结一下BDD的概念：在项目之初，由客户、开发人员、测试人员一起通过充分的沟通对系统的行为进行设计，由测试人员以接近自然语言的方式编写可以描述系统行为的测试用例，然后由开发人员编写相关的实现代码，并确保该测试用例通过。

循环这个过程实现整个系统的功能。

BDD的测试思想先前在写日报的过程中，以关键字的形式来描述，这里用同样的方式来表达。

关键字：TDD，代码即文档，系统设计，合作。

1.TDD全称：Test Driven Development（测试驱动开发）。

BDD是基于TDD发展起来的，BDD中测试先行的理念也是来自于TDD，测试驱动开发，由测试来推动着开发的工作，在具体的项目实施中，测试的工作先行，在功能代码编写前，先编写测试代码，再编写功能实现代码，并且使得该测试用例测试通过，循环这个过程，来实现系统的其他功能。

在一个项目的开发过程中，针对于每一个阶段，都可用TDD的思想来开展工作。

BDD对TDD理念进行了扩展。

TDD要求用测试来驱动开发，其重点偏向开发，测试用例是在约束开发者，使开发者的目标明确，设计出满足需求的系统。

BDD 要求在设计测试用例时对系统进行定义，倡导我们在测试用例中用通用语言把系统的行为描述出来，把测试代码作为系统的定义文档，将系统的设计和测试用例结合起来，进而驱动开发工作。

2.代码即文档很多软件项目的失败源于项目团队人员对文档理解的差错。

文档用来约束一个项目团队成员，使得大家的目标保持一致，总之：文档很重要。

我们用需求文档管理需求，但是这些文档本身都因为容易变更，加上团队人员主观上的理有误，最终做出不能满足产品需求的产品。

BDD的思想是：将我们的产品设计写在我们的测试用例中。

把传统的产品说明书的内容写在测试用例中，在测试用例中描述软件系统的具体行为，体现着系统的设计，而且这是一份“活” 的的文档，因为这是可以运行的测试用例，我们由这些测试用例来驱动开发者的编码工作，开发者必须使这个测试用例通过，才算满足最基本工作。

假如用例不通过，显然我们的系统就存在缺陷，没有满足用户的需求。

这样，就算是开发人员对文档理解有误，也会满足系统的需求。

3.系统设计在测试用例中描述系统的行为，体现出系统的每一步操作所带动相关事件的触发，进而得到相关的结果，这是对一个产品详细的定义，也就要求我们在测试用例中对系统的行为做出详细的设计。

4.合作客户，需求分析人员，测试人员，和开发人员之间的合作，这个合作时间较集中在项目的开始阶段，大家一起对系统的行为进行定义，测试发展起步较晚，到现在开发人员还是有很多不重视测试，再加上测试人员的工作是找出他们代码中存在的bug，所以开发人员和测试人员需要很多的相互沟通理解，处理好关系，这样的合作，无疑提供给我们交流很大的一个空间。

BDD的测试方法关键字：故事&场景，通用语言。

1.故事&场景一个故事描述了系统的一个行为，对应着用户的一个需求。

举例说明：外部开发者开发好的应用经过小二的审核后发布在淘宝开发平台的服务平台上面，供用户订购使用。

现在有一个用户要访问一个应用，此时就发生了一个故事，用户访问应用要经过top-container应用容器的校验，这个故事中描述了top-Container做校验的行为。

在一个故事中又会有多个不同的场景。

用户访问应用时，用户和应用之间有很多种条件需要满足，每一种不同的情况都对应着一个场景。

举例说明：用户在没有订购此应用，并且此应用恰好又需要订购才能够访问，这种情况下，top-Container拒绝其访问；再比如，用户没有订购过这个应用，此应用是一个基础应用不需要用户订购，这种情况下，top-Container容许其访问。

故事和场景的作用就是定位，故事定位要描述系统的功能模块，场景定位要描述该功能模块下哪种条件下的系统行为。

2.通用语言语言是用于沟通，向别人表达自己的意思的工具，我们的基于BDD的测试用例的代码描述着系统的一个行为，可以按照传统的写法将这个行为描述清楚，但是别人来看时，肯定要花不少的精力。

所以BDD提供一个通用的模板，并且要客户，开发人员和测试人员一起定义一套通用语言来做描述，这样做，既可以方便测试人员自己写测试代码，也能方便别人看懂，也可以为开发人员的实现代码提供类名，方法名。

3.示例通用模板示例：Story: 标题（描述故事）As a [角色]I want [特征]So that [利益]Scenario 1: 标题（描述场景）Given [上下文]And [其他上下文]...When [事件]Then [结果]And [其他结果]举例说明：Story: 用户访问应用As a 用户I want 访问淘宝开放平台的一个应用So that 我可以使用这个应用提供的服务Scenario 1: 用户未订购此应用Given 一个应用And 此应用需要订购才能访问And 用户没有订购此应用When 该用户访问此应用Then 访问被拒绝And 返回用户没有订购此应用的错误码及错误信息。

BDD的优势1.代码即文档，由测试用例管理需求，最大限度的消除项目团队人员对需求理解不一致。

2.由测试代码监督，约束着开发代码。

开发者需要时刻考虑去满足测试的需要。

这样使得开发者的代码保持着方向的正确性，也使开发者的代码足够的精练，产生较少的垃圾代码。

3.开发者需要设计良好定义的接口，来满足测试的需要，降低系统模块的耦合度。

4.有测试用例的保障，系统代码可以放心的重构。

5.增强开发者的信心。

一个测试用例的通过标志着系统一个需求的实现，这样的成果可以增加开发者的成就感与信心。

BDD的缺点1.测试用例只能体现系统细节设计，不能体现系统总体设计。

2.测试用例无法覆盖全部的测试工作。

3.约束开发者的发挥，开发者需要时刻考虑能否满足系统行为，能否使测试用例通过，这样会局限创造力。

4.项目初期在测试方面投入过多，引起开发人员的不满。

这一点上尤其对于新近实行TDD理念的团队来说，这方面的怀疑更多。

总结BDD基于TDD发展起来，具有很好的实践基础，并且越来越多的人开始接触并且接受其的测试理念，受到了很多人的热捧。

个人认为，我们可以在小范围内用BDD的方式来开展项目开发工作，然后看效果，调整成为最符合我们公司开发需要的方式，进而推广。

在我们的日常测试中，我们也可以借鉴其系统设计的概念，将我们的测试用例设计成可以体现系统行为的风格，这样做的好处有两点，一是方便维护，别人一看就懂得我们的测试用例的校验点在哪里；二是方便我们定位问题，导致用例不通过的原因是系统的哪一步处理出错，不需要我们调试跟踪就直接看出来，可以节约我们大量的时间。

最后，用一个博友的话来总结BDD：优美的测试代码，就是一个个优美的故事。

也用一句话说出我们所有测试人员的心声：我不做软件，但我使软件变得更好！二、BDD课题研究之jbehave介绍1、什么是JBehaveJBehave是一个用java编写的BDD（Behavior-Driven-Design)框架， java界的Cucumber。

(注: 1、BDD主要的目的是能够从业务领域专家的视角来编写测试用例，以解决技术人员和业务领域专家的沟通问题。

2、Cucumber是基于Ruby 的BDD框架)2、JBehave的特点1）、纯Java实现，能调用java API的地方就能使用。

2）、能够定义和执行基于文本的Story,让我们能够从用户价值出发进行开发。

（BDD都是这个目的）。

3）、User stories可以放在classpath，也可通过外部URL传进来。

4）、User stories可以并发执行且能够指定并发执行的线程数。

5）、可以通过一些用户定义的信息把User Stories形成一部完整文档。

6）、通过Anotation把Story的步骤对应到Java类中，还能够把自动把Story 中的String参数转换成方法对应的参数类型。

（How？）7）、基于Anotation的运行配置信息，指定Story对应的Steps类文件8）、支持通过第三方IOC容器（Spring，Guice，PicoContainer，Weld）管理配置信息和Steps类9）、支持通过Groovy写配置信息和Steps文件10）、支持报表，既可以生成可读性良好的报表格式（HTML，TXT ），还支持Json，XML格式供外部程序调用。

11）、未实现的步骤会自动标记Pending12）、支持任何语言书写Story13）、可以使用Junit或者任何基于anotation的测试框架运行Story测试14）、支持Maven，Ant集成，通过脚本运行BDD测试脚本。

3、JBehave的结构Story：系统想要具有的功能Scenario：Story描述的功能的Key-Example 。