BDD课题研究-总结报告

这是淘测试平台上发布的一系列关于BDD的研究报告，我认真的看了看，对BDD认识有了更全面的认识，故转载过来，过段时间再看看。
第一篇

http://www.taobaotest.com/blogs/qa?bid=11778
第二篇

http://www.taobaotest.com/blogs/qa?bid=11763

这个博客也说的比较细，怕忘记，有时间再看看。 http://www.cnblogs.com/jarodzz/tag/bdd/
本次报告对BDD课题研究进行总结。欢迎大家拍砖。

非常感谢文朗，博一，自在，七修，宋缺，汐影和郭芙在本课题研究工作的过程中对我的支持、鼓励和帮助，使我获得进步与成长。
总述课题： 课题共分为两大部分：测试理念和技术框架。

测试理念方面，通过代码即文档，系统设计，合作等关键字剖析了BDD提倡的测试理念。

技术框架方面，开始选定了面向java语言的Jbehave框架，后因为运用BDD实践Freetest的需要，转向RSpec，其后深入解析了
RSpec和Jbehave的运行原理，最后介绍了Cucumber，easyb和JDave的运用，并比较器优缺点。

理论离不开实践，在实践方面，Freetest的测试用例编写情况完成issueStatus Controller的编写，另外对于每一种BDD框架的学习，都编写一个简单的demo实践其运用。

虽然到了总结阶段，但是必须承认，知识无止境，正如文朗所说：弄懂测试框架的原理只是刚刚开启了一扇门，门后还有无数有价值的东西，BDD理念和其框架中还有很多东西值得我们去挖掘。

在此过程中，我有很多的收获，首先是学习到了一种全新的软件测试及开发理念，开阔了眼界，其次是学习了Ruby语言和Rails开发框架，和多种BDD测试框架的运用及原理。

BDD课题研究工作是个不断遇到困难、解决困难的过程，网上鲜有人做BDD资料的分享，仅有的文章也大多内容雷同，可利用的资料少，技术框架的学习总是能碰到各种各样的错误，只能靠自己摸索，有时候很长时间没有丝毫进展，再加上时间上有限制，压力山大。

这种经历是宝贵的，可以获得很多东西：越是有压力，越是要承担起责任，努力把事情做
好，在这种情况下，要静下心来，分析遇到的困难，找到一个突破口，将其攻破，再开展其他工作。还有一个教训：当遇到问题的时候，要早点把困难报告出来，让
大家从总体上对进度有把握，并调整从短期到长期的进度安排，否则的话，很可能由于一个问题卡着，带来整个进度的拖延。
BDD ：测试思想

测试先行：这个概念取自TDD,编码之前先写测试用例，然后以测试驱动开发工作。

系统设计： 测试代码不再是单纯的数据输入输出的验证工作，而是要给出系统的行为的定义。
技术框架

BDD的技术框架很多，主要研究如下几个：

JBehave：由BDD的命名者Dan North开发，作为第一个BDD的框架面世，全面支持BDD理念，以story文本，story配置，step映射的方式管理测试用例。

RSpec：大名鼎鼎，尤其是支持Rails，使之应用很广，使用describe()，it()方法来组织测试用例。

Cucumber：类似于JBehave，story文本和step映射的方式，但是配置较少，使用较易。

easyb：JBehave和Rspec的结合体，不过正如其名，easyb很easy，其采用Groovy动态语言来编写测试用例。

JDave：所介绍的框架中最独特的一个，利用类名方法名的方式来定义测试用例，和前四者比较，其可读性较差。
BDD优点

代码即文档：以一种接近自然语言的方式编写测试代码。描述系统的行为，测试用例可以担当文档的角色。

测试驱动开发：以测试用例驱动开发编码工作，使开发人员的目标统一，即使测试用例通过。

代码精简化：编写足够的代码就足够了，不要花费功夫到冗余代码上面。

增进合作：项目共利益者通过紧密合作，完成系统行为的定义。并且，我觉得测试用例的编
写应该有测试人员和开发人员共同完成，测试人员要提供测试人员专业的敏感性，开发人员要为编码工作做好准备，即定义接口。也可以这样分：测试人员完成
story文本的编写，开发人员负责step映射的实现，增进测试和开发人员的合作。

Writing Software That
Matters：编写用户真正需要的软件。这是代码即文档和测试驱动开发两个概念结合后的效果，也是BDD的核心，把系统的行为写在测试用例中，然后用测
试用例驱动实现的过程，可以保证实现的系统的我们定义好了的系统。

成就感：满足测试用例，即意味着系统部分的实现，成果容易看得见。

大胆重构：有测试用例在那里保证着系统的质量，可以大胆重构至最优。
BDD缺点

项目初期投入多：系统需求分析和行为的定义，测试用例的编写，要投入很大精力，这一步决定项目的要做成什么样子和怎么实现，需要定义大量接口。对于此，我觉得对于一个大的项目来说采用迭代的方法，先部分，再其他部分，后整体这样来完成。

定义系统行为方式单一：只有文字表述，不能采用图形化的方式，这是BDD描述系统行为的硬伤。图形有着文字无法比拟的直观性，可以为人们理解系统时的思维做很好的引导，这也是BDD测试代码不能全面取代文档的原因。
BDD的其他价值

特性注入：在定义系统行为时，所有的项目相关人员以自己的角度提出系统应该完成的目标，为完成该目标定义一些该角度下的特性集合，通过该目标将利益最大化。

由外及内： 从用户界面开始，为完成此界面上的功能，需要位于里层的系统模块提供接口，里向外提供服务，可以把服务的概念引入软件开发，使整个系统得到更好的模块化。

商业价值：从最接近用户的一端开始实现系统，尽早的让用户看到系统的模样，以获得客户和最终用户的肯定。
我们可以借鉴的地方

BDD涉及的是整个软件开发过程，在淘宝没有实际推行应用，所以测试先行这个概念暂时摒弃。

在测试用例中描述系统的行为，倒是值得一试的，我初接手我的测试工作时，觉得要了解我
所测试的系统很难，因为没有文档说明，只有一页纸的逻辑，而且内容陈旧，没有及时更新过。所以若是可以把系统行为定义在测试用例中，就是相当于我们不但在
维护系统的稳定，而且在维护系统是什么。如果有工作的交接，可以直接阅读测试用例理解系统，可以节约步入测试正轨工作的时间成本。

最后一句话共勉：我不做软件，但我使软件变得更好！