开发人员看测试之TDD和BDD

前言:

  已经数月没有来园子了,写博客贵在坚持,一旦松懈了,断掉了,就很难再拾起来。但是每每看到自己博客里的博文的浏览量每天都在增加,都在无形当中给了我继续写博客的动力。最近这两天有听到Jbehave这个名词,上网查了一通,原来是和测试相关的,之前一直做开发,没有做过真正意义上的测试,对于测试的理解更是少之又少。通过这两天的查阅,现将自己的一些理解以及常见概念罗列出来。

正文:

  Behavior Driven Development行为驱动开发是一种敏捷软件开发的技术,它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。
在了解Behavior Driven Development之前,先介绍Test-Driven Development(TDD)测试驱动开发,它是一种测试先于编写代码的思想用于指导软件开发。测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。
它的工作流程如下所示:

TDD方法的一些特点:

  • 有利于更加专注软件设计;
  • 清晰地了解软件的需求;
  • 很好的诠释了代码即文档。

我眼中的测试

  之前一直对于测试都是一个笼统的认知,觉得测试仅仅是一种验证,类似于部分企业中一些比较省事的测试方法,通常在代码写好之后再实施测试工作,用于验证developer的代码是否符合需求。稍微了解TDD、BDD之后才发现,测试不仅仅是一种对于代码的验证,找出几个bug或者一些诸如压力测试、负载测试,更是一种约束,一种规范,是与项目需求息息相关,还需要沟通协调客户、开发人员以及QA,从而帮助更加高效的完成软件设计开发工作。

  通过下面一幅图就可以发现对于测试也有不同的层次和流程:

  从图中可以发现,最下面的是单元测试白盒测试),主要用于测试开发人员编写的代码是否正确,这部分工作都是开发人员自己来做的。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。再往上,就是BDD灰盒测试、黑盒测试),主要用于测试代码是否符合客户的需求,这里的BDD更加侧重于代码的功能逻辑

  从左边的范畴也可以看出,测试的范围也是逐层扩大,从单元测试的类到BDD里面的服务、控制器等,再到最上层的模拟实际操作场景的Selenium(Selenium也是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中,就像真正的用户在操作一样。支持的浏览器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。)对于包括UI界面的测试。之前自己有做过这样的编码测试工作,通过写代码,可以打开IE、FF等浏览器,模拟用户点击、填写数据等操作,从而完成一整套的流程测试。整个测试从小到大,从函数、方法、类到功能模块乃至系统有着一系列严谨的体系。

再说BDD

  BDD是一种敏捷软件开发的技术。它对TDD的理念进行了扩展,在TDD中侧重点偏向开发,通过测试用例来规范约束开发者编写出质量更高、bug更少的代码。而BDD更加侧重设计,其要求在设计测试用例的时候对系统进行定义,倡导使用通用的语言将系统的行为描述出来,将系统设计和测试用例结合起来,从而以此为驱动进行开发工作。

  BDD的通用语言是一种近乎自然语言的描述软件的形式。传统的开发模式中,客户很难从技术层面理解问题,开发人员很难从业务需求考虑问题,基于这种通用语言形式可以尽可能的避免客户和开发者在沟通上的障碍,实现客户和开发者同时定义系统的需求。避免了因为理解需求不充分而带来的不必必要的工作量。

  BDD描述的行为就像一个个的故事(Story),系统业务专家、开发者、测试人员一起合作,分析软件的需求,然后将这些需求写成一个个的故事。开发者负责填充这些故事的内容,测试者负责检验这些故事的结果。通常,会使用一个故事的模板来对故事进行描述

  Story:

As a 角色
I want 特征
so that 利益

 

  As a标识出这个系统行为是为哪一个角色而定义的。

  I want和so that则指明了该角色想做的事, 以及想达到的目的。

  这三个断句定义了这个系统行为的参与者、范围。

  同样的一个Story,可能会有不同的场景。通过上面的模板描述了故事之后,再通过下面的模板对不同场景进行描述

  Scenario:

Given [上下文]
	And [更多的上下文]
When [事件]
Then [结果]
	And [其他结果]

 

  这些场景中的Given…When…Then…实际上就是设定该场景的状态、适用的事件,以及场景的执行结果。

  其实通过这样的Story描述和场景设置,基本就完成了一个完整测试的定义。

  BDD整个测试流程如图所示:

常见的BDD框架:

  • C – Cspec
  • C++ – CppSpec, Spec-CPP
  • .Net – NBehave, NSpecify, SpecFlow
  • Groovy – GSpec, easyb, Cuke4Duke
  • PHP – PHPSpec
  • Python – Specipy
  • Ruby – RSpec, Shoulda, Cucumber

与Java相关的BDD测试工具:

  • JBehave – Java annotations based, Test frameworks agnostic
  • Cuke4duke – Cucumber support for JVM
  • JDave – RSpec (Ruby) inspired, Mojo 2 & Hamcrest based
  • beanSpec – Java based
  • easyb – Java based, Specifications written in Groovy
  • instinct – BDD framework for Java, providing annotations for contexts. Inspired by Rspec
  • BDoc - Extracts behaviour from unit tests
时间: 2024-11-06 03:49:40

开发人员看测试之TDD和BDD的相关文章

开发人员看测试之细说JBehave

上篇我们说到如何从Github上clone出一个JBehave项目,既是为了学习JBehava,也是为了熟悉下Github.从clone下来的项目看来,基本没什么问题,稍微捋一捋就可以运行,但是就clone下来的代码来看,自己还是遇到一个问题(不知道是代码问题,还是我自己的操作有问题),就是没有办法运行(后面会详说).正如上篇所说,构建一个JBehave的应用的5大步骤: Write story Map steps to Java Configure Stories Run Stories Vi

开发人员看测试之运行Github中的JBehave项目

本文要阐述的主要有两点,一是介绍自动化测试框架JBehave,二是介绍如何在Github上拉项目,编译成myeclipse环境中的项目,并最终导入Myeclipse中运行. JBehave是何物? JBehave是基于BDD框架的开源自动化测试框架.提供Web集成的BDD层扩展. JBehave特征: JBehave是纯Java实现,可以利用Java丰富的API为己所用: 具有基于文本的story,可以对其进行定义并执行,比较灵活和易扩展: 基于注解(Annotation)的运行配置信息,指定s

写给Android App开发人员看的Android底层知识(6)

(十一)BroadcastReceiver BroadcastReceiver,也就是广播,简称Receiver. 很多App开发人员表示,从来没用过Receiver.其实吧,对于音乐播放类App,用Service和Receiver还是蛮多的,如果你用过QQ音乐,App退到后台,音乐照样播放不会停止,这就是你写的Service在后台起作用. 在前台的Activity,点击停止按钮,就会给后台Service发送一个Receiver,通知它停止播放音乐:点击播放按钮,仍然是发送这个Receiver,

写给Android App开发人员看的Android底层知识(2)

(五)AMS 如果站在四大组件的角度来看,AMS就是Binder中的Server. AMS全称是ActivityManagerService,看字面意思是管理Activity的,但其实四大组件都归它管.估计是Android底层开发人员先写了ActivityManagerService用来管理Activity,后来写Service.Receiver.CP的时候发现代码都差不多,于是就全都用ActivityManagerService,但是却忘记改名字了——我也是猜的,纯属八卦. 由此而说到了插件化

推荐开发人员看的较有影响力的书籍

转载:http://blog.csdn.net/crzy_sparrow/article/details/7422962 对于一个程序员而言,在学校里学不到多少工作中真正需要的知识,只有在工作中实践积累并且看一些优秀的书籍,把实践和理论结合起来才能够更好的工作.尤其是在技术日益发展和变化的今天,每个开发者更应该主动的看书去学习编程技巧并且改变编程方法,才能应付工作中各种复杂的项目.同时也可以在程序设计中更高效.弹性和准确的解决问题.下面列出了 11 本对开发人员很有益的书籍,大家可以从中选取感兴

写给Android App开发人员看的Android底层知识(8)

(十)PMS及App安装过程 PMS,全称PackageManagerService,是用来获取Apk包的信息的. 在前面分析四大组件与AMS通信的时候,我们介绍过,AMS总是会使用PMS加载包的信息,将其封装在LoadedApk这个类对象中,然后我们就可以从中取出在manifest声明的四大组件信息了. (一) 在下载并安装App的过程,会把Apk存放在data/app目录下. Apk是一个zip压缩包,在文件头会记录压缩包的大小,所以后续在文件尾巴就算是追加一部小电影,也不会对解压造成影响—

《写给Web开发人员看的HTML5教程》

周末了!在家里敲作业,主要是html表格的练习. 我发现当有人问你问题时,我会很有动力学习. 为了很好回答他人的问题,我想我要学得更多,比如预习复习. 同时,被人问题也是一件很开心的事儿,这表示别人认同你,觉得你有这个能力. 为了不让人失望,你就会想方设法去学得更多. 第三章中,作者给我们介绍了许多HTML5中关于表单的新扩展功能. WEB开发者的美好时代来了,因为在使用日期和时间之类的常规输入元素时,他们不再需要用到JavaScipt库,尤其是对于手机输入来说.鉴于通常用手机输入比用计算机要难

如何有效地与开发人员一起工作(三)

合作可能会失败 紧密的合作关系是对时间的投资.有时候投资免不了得不到回报: 你的程序员是如此的固执以致你尖叫起来 – 只可惜很可能你的尖叫声还没他尖叫着说你固执来得响亮. 程序员可能会看起来故意阻碍或令人误解.(他也许在尝试通过使用公正的手段或不正当的手段来指示你从而节省他的时间.但是有时候他就是不可避免地粗心大意,或尝试隐藏他的无能,或其他什么原因.) 你的期望值没有达到.程序员对你做的事情不高兴. 我个人倾向于向糟糕的投资倾注更多的精力,更多的时间.那是错误的.有时候你必须承认计划失败并转向

软件测试之单元测试:开发人员的测试

说到单元测试,几乎所有人都知道,由开发人员完成.可是为什么要进行单元测试呢? 开发人员写单元测试的时间几乎和他写产品代码的时间相当,因此,当做项目计划的时候,把单元测试考虑进去是合理的.尽管单元测试增加了相当大的开发工作量,看上去开发时间延长了,但实际上对于一个长期不断改进和维护的项目而言,我们不能忽视级联效应,要从项目整体来看. 单元测试可以保证最基本的缺陷尽早的发现并解决,因此,用来解决被流转到后期的测试阶段的缺陷时间实际上就会缩短. 而如果问开发人员是否进行了单元测试,他们通常也会说,是的