一、摘要自动化测试可以快速自动完成大量测试用例，节约巨大的人工测试成本；同时它需要拥有专业开发技能的人才能完成开发，且需要大量时间进行维护（在需求经常变化的情况下），所以大部分具有很好开发技能的人员不是很愿意编写自动化用例。但由于软件规模的高速增长，人力资源的逐步稀缺，自动化测试已是势在必行。 对于自动化测试首先需要保证其功能是对客户有价值的和正确可用的。而这一切的基础就是用例要能测试客户的需求，期望，最好能让客户参与到测试用例的开发过程中来或让客户评审测试用例，因此出现了ATDD、BDD等各种理论方法来支撑这一行为。现有很多自动化测试工具可支持ATDD、BDD等，比如Cucumber1、RobotFramework2、SpecFlow3、JBehave4、Fitness5、Concordion6等。其中Cucumber和RobotFramework是最流行的两个框架，但许多人在第一次选择测试框架时因缺乏实践经验而困惑，所以今天为大家分享这两款框架在几个项目上的经验及对比，方便大家在以后的项目上能正确地选择这两款测试框架。 首先看一下这两款工具的简单对比。
二、案例Cucumber案例1：某社交网络系统项目时间：4年前 项目背景：系统的主要功能是帮助用户能通过一个手机应用同时与Facebook，Twitter，Flickr等社交网络更新信息，并能一次性把自己更新的信息同步到这些社交网络。其中它有一个服务器端，用于和各个社交网络通信，一个Web应用和一个手机应用提供给最终客户使用。它的技术栈主要是Java Spring，Android，iOS，MySQL等。 被测系统构架图：
由于这个项目是中国团队和法国团队一起合作开发，当时法国团队的架构师提出选用Cucumber作为自动化测试框架来测试这个系统，项目需要支持多国语言，且需要同时做服务器和手机端的功能测试，甚至在一个测试场景中既包含服务器测试部分，又含手机端测试部分，而使用基于Cucumber的测试系统很好的满足了我们的需求，其中手机端的功能测试用的是Calabash8。Calabash是一个手机功能测试系统，它使用Cucumber将Android的测试框架Robotium9和iOS的测试框架Frank10封装了起来，使得Cucumber的Step可以调用Robotium和Frank进行测试。这样就可以实现一个测试场景里面既包含手机端测试，又包含服务器端测试，比如：
实现方式是在Calabash中使用Ruby实现一层胶水代码，和服务器测试功能测试代码连结起来，并根据不同的Step调用不同的测试驱动层代码从而实现同一个测试用例同时包含服务器端和手机端测试。虽然这样的测试用例不会很多，但它却有效的表达了端到端的系统集成测试，让测试集合更加丰满。 如果重新选择测试工具，我还是会选择Cucumber和Calabash，主要原因是它们可以方便的统一做手机和服务器的功能测试。虽然RobotFramework配合Selenium也能实现类似的功能，但是需要使用RobotFramework对Selenium重新进行封装，没有Calabash方便易用。 Cucumber案例2：某大型养老保险系统项目时间：2年前 项目背景，主要功能是提供一个Web系统让用户可以购买养老保险，管理养老保险账户里面的资金等业务。主要的技术栈Java Spring, JSP, AngularJS, Oracle DB等。 被测系统构架图：
基于安全和开发成本原因，比如重用已有的服务器和容器环境，重用开发资源，所以公司绝大部分项目只用Java语言进行后台服务器端开发，导致公司大部分人员只熟悉Java语言，因此测试框架选择了Cucumber Java版11。 如果重新选择工具，由于技术栈和成本的原因，我仍然会选择Cucumber Java版，不会考虑RobotFramework。因为对于这种Java Spring商业应用项目，我不想引入一个Jython去加深项目的技术栈，只要能充分利用当前团队已有的技术栈就可以了，并且还更容易说服开发人员帮忙实现和维护自动化测试，从而促使整个团队都能对自动化测试负责。 RobotFramework案例1：某AC项目项目时间：3年前 项目背景：该项目是WIFI系统的AC（Access Controller 接入控制器）部分，包含WIFI接入的认证、计费等功能。它也提供了配置界面，包括Web和命令行两种。AP（Access Point接入点）是与该系统交互的外部系统。通常来说AP会有很多个，放置在不同的空间区域，提供WIFI接入服务，AP和AC之间使用有线链路连接。 被测系统构架图：
该系统作为一个嵌入式设备，从用户的角度来看主要包括两部分功能。第一部分是操作管理员在命令行或者Web界面上进行功能配置，第二部分是AP与系统进行交互，完成网络接入等功能。 明确了被测对象和场景后，就需要寻找相应的测试库来完成这些用户（即包括人，也包AP）与系统之间的交互。对于Web来说，有成熟的Selenium可以使用，Selenium提供了多种语言的API，从这个角度来看RobotFramework和Cucumber都可以选择。对于命令行操作而言，可以选用RoboFramework的SSH库来完成，当然在这一点上其他的语言也有相应的类库。要想完成上述这个系统的测试，还需要完成报文的收发及编解码工作，Python的类库Scapy12能够很好地完成这部分工作，只需要在此之上做少量定制化开发，并将其封装成为RobotFramework关键字即可。经过上面的分析可以看到，使用基于Python的RobotFramework能够很好地处理报文相关的逻辑，加上团队在Python上有比较好的技术储备，因此RobotFramework成了最终的选择。 如果重新选择，我还是会选择RobotFramework，原因是其他平台上找不到类似Scapy这样好用的测试库。 RobotFramework案例2：某移动广告管理平台项目时间：1年前 项目背景：该项目是一个Web系统，用于广告投放、查询、显示等功能。 测试思路是做端到端的测试，覆盖从广告投放、广告查询及广告显示等一系列功能。其中涉及到的测试库主要是Selenium，这点上与案例1类似。不同之处在于这个项目中参与自动化用例编写的主要是从不编写代码的测试人员，而RobotFramework有一个专用的用例编写环境—RIDE，其中用例编辑窗口如下图：
虽然它只是简单地把使用TAB符号隔开的一系列纯文本变成了可视的表格，但对于这些测试人员来说，他们以前工作的平台就是Excel中，所以很容易切换过来。再加上它提供的一些高亮、抽取关键字等特性，使得测试人员可以比较专注于测试用例的设计、编写和优化，而不用关心格式等细节问题。 在RIDE中导入相关测试库之后，可以通过F5快捷键查看所有关键字的文档，如下图所示：
关键字的概念很有趣，它们本质上就是一堆自由函数，或者是类的成员函数13，所以使用它们来编写用例事实上就是在编写代码，本质上和Cucumber的Step Definition是一样的。但由于RIDE以表格的形式呈现，并且有良好可视化的文档，在这种环境下写测试会给人一种“我不需要编写代码”或“我没在写代码”的感觉。在我们经历过的几个项目中，测试人员对这种形式都比较接受。当然从另一个角度看，用例的编写者失去了对测试代码的直接掌控权，这对于很多开发人员来说还是有些别扭，所以如果你不喜欢RIDE这种形式，可以尝试使用Pycharm来开发RobotFramework用例。 在这个项目中有不止一套测试运行环境，比如开发集成环境、CI环境、系统测试环境等。该项目包含了多个Web Portal，每套环境中Web Portal的IP地址都是不同的。如何保证一套测试代码能够在不同的环境中无差别的运行呢？简单的答案是配置文件或者环境变量，在RobotFramework中，解决方案是变量文件。比如我希望测试代码能够在开发集成环境和CI环境中运行，则可以按照下面的方式操作。 首先定义两个变量文件： ci-env.py: portal_ip = “192.168.1.1" …… dev-share-env.py: portal_ip = “192.168.1.4" …… 在用例文件中可以按照下面的方式引用上述变量文件中的变量： ……
open browser ${portal_ip}
……
然后在运行测试时加入如下的命令行参数即可针对CI环境运行测试： pybot -V ci-env.py tests/ 开发人员在自己编写调试测试或者定位问题时，在命令行中使用dev-share-env.py的配置即可针对另一套环境进行测试。 在这个项目中遇到的另一个问题是中文问题。客户非常在意用例是否能很好地处理中文，一方面是因为可读性，另一方面是要适配一些使用中文编写的Java代码。RobotFramework和Cucumber这些工具都有考虑国际化的问题，比如Cucumber Java版就支持使用类似于“给定”、“当”等中文关键字及中文的Step Definition，而RobotFramework对中文的支持也很好。但是如果从可用性的角度考虑，RobotFramework会比Cucumber好一些。原因是Cucumber本身并没有专用的IDE，只能求助于其它IDE插件，这些插件可以完成高亮、自动补全和Step Definition跳转等功能，但一旦使用了中文，有些功能就不好用了。而在RIDE中就不存在这个问题。所以如果你的团队因为某种原因对于中文用例的需求很旺盛，可以考虑RobotFramework。 如果重新选择，我还是会选择RobotFramework，主要从两个方面进行考虑：一方面是因为其“不用写代码”的方式更容易被测试人员接受，另一方面是对中文的支持更好。 通过上面四个案例，展示了在不同的项目中实际使用Cucumber和RobotFramework时的一些经验和选择它们的理由。但对于Cucumber和RobotFramework更多的知识点，下面有一个更为详细的对比表。
三、测试工具选择的一般性原则在上述的实战案例中，针对项目的具体情况我们对Cucumber和RobotFramework这两种工具进行了取舍。本节就来总结一下这些取舍的考虑因素。 首先来看一下自动化验收测试的层次：
然后对每层进行分析：
以上这些点是从RobotFramework和Cucumber的对比中总结出来的，但如果你想要选择这两者之外的其他框架，同样可以考虑上述这些原则。 四、总结我们在银行、保险、社交、电信、物流、互联网等项目上实施过自动化功能以及验收测试。对于Cucumber和RobotFramework到底属于ATDD还是BDD，这里不做过多的讨论，因为当前在业界对于ATDD和BDD怎么区分还有一些争议，而对于我们来讲，它们只不过是两个名词而已。对于这两个工具本身来讲，只需要清楚它们各自的特点，根据项目本身的情况和需求选择就可以了，简单地说就是：知行合一。
作者简介
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。 高危漏洞频发，隐私泄露，普通开发者该如何避免和防范；开发者如何从逻辑上避免风险？在【QCon北京2015】“新时代的安全”专题中，在Pwn2Own 2015上夺冠的Keen Team安全研究员Peter Hlavaty将解读内核安全精髓；阿里巴巴安全专家祝建跃将分享互联网全球最大DDoS攻击防御实战。查看详情。
相关内容 社区评论
Watch Thread
hmm...
2015年3月16日 12:34
by
如果說 Robot Framework（RF） 只支持 Python 和 Java 這不太公平，第一： RF 的網站上已經有 C 語言的例子，其實支持 C/C++ 都很容易；第二其實RF也可以透過 XML RPC去聯接被測系統，那麼你想用什麼語言來提供接口都可以。
相反，Cucumber 雖有不同語言版本，但不是每個語言版所支持的功能都一樣，這是需要注意的事情。 文中最搞笑的地方是 RF "不支持类似于Cucumber中的表格参数"，在 RF 裡面所有東西都是表格，而RF 亦支持 Template 的使用方法。我說這是搞笑不是因為作者認識不夠深入，而是因為這功能是 Cucumber 作者看到 RF 之後覺得很好而添加在 Cucumber 中，沒想到今天會被說成是 RF 沒這功能 :D 還有... 這篇文最多只是討論 RF / Cucumber 用作自動測試工具，根本和 ATDD, BDD 扯不上關係。 當然，ATDD, BDD 重要的從來都不是用什麼自動化測試工具。
Re: hmm...
2015年3月17日 05:12
by
1，RF对于C的支持其实使用的是Python's standard ctypes module，只是扩展，并不是使用C语言实现的，所以还需要安装RF原始的所有环境，而且我们也没有使用过，并不知道其稳定性和易用性，所以并没有写。对于这个我们没有写，属于我们的错误，我们更改。不过如果算上这种模型，理论上可以让RF支持任何语言，比如使用Thrift（thrift./docs/features），这样就可以让RF支持所有语言...
更改： 编程语言支持：Cucumber:Java,Ruby,JavaScript etc.7 RF:Python, Java, C 2，对于Cucumber的多种语言，并不是所有语言功能都一样，这个是对的，不过对于基本功能都是一样的。对于普通的使用者可以不需要关心，高级用户需要自己看文档。 3.对于 "不支持类似于Cucumber中的表格参数"，如果你笑了只能说明你可能还没有搞清楚cucumber的datatable，请详细参见引用14. 4.我只是想阐明一下我对ATDD和BDD的看法，以及引出ATDD和BDD，文章并没有详细讨论ATDD和BDD。如果你说扯不上关系，其实还是有一点点关系，那请参见在RF的官网上有这句话：“Generic test automation framework for acceptance testing and ATDD” 来自 /，而在cucumber的官方文档中也写道“While Cucumber can be thought of as a “testing” tool, the intent of the tool is to support BDD” 来自github.com/cucumber/cucumber/wiki。我只是想尽量解决读者的疑惑... 5.就中立而言，我们已经尽量追求了。我们并没有想偏向某一方，两边都有其优缺点，根据你的需要自己选择就可以了。这个也是为什么这篇文章是两个人写的原因。
Re: hmm...
2015年3月31日 02:05
by
非常同意。
RF设计目的是测试框架，或者说用来构建测试框架的框架。Cucumber是工具。层次不一样。 一个优秀的自动化团队，肯定要构建自己自动化测试体系。 基础很重要，RF提供的架构方式非常合适。 可以自定义adapter，parser，driver... 其他任何你觉得有用的东西，只要能被python调起来，加个wrapper都可以拿来用。 除了下划线和空格会被忽略以外，真没啥不好的 :-)
Re: hmm...
2015年3月31日 04:41
by
首先我觉得说Cucumber是工具只是一个狭义的理解，难道Cucumber就不能加个wrapper来用吗？（Ruby的强大人所共知，讨论这些就涉及到Ruby和Python的比较，我觉得是没有什么意义的）如果一定要区分框架和工具，就要首先定义框架和工具。什么是框架，什么是工具？我觉得说一句“Cucumber是工具”无法让我同意。
对于“一个优秀的自动化团队，肯定要构建自己自动化测试体系。”，其实现在很多项目都不会有专门的自动化团队，而是由开发团队做。所以这个时候就需要根据每个团队的特定选择合适的自动化工具，框架，whatever，帮助他们建立自己的自动化测试系统就可以。所以应该是对于优秀的开发团队，都要构建自己自动化测试系统，所以才需要学习，比较和选择适合自己的，而不是盲目的听说某个好，就用某一个。 其次“基础很重要，RF提供的架构方式非常合适。”这个肯定是由前提条件的，并不是每一个团队都适合的，因为每个团队都有自己的限制条件，况且任何一个软件项目最后都会有一个致命的问题：成本与收益（钱多得没有地方花，不在乎钱的团队除外）。 |
|
|
刘冉，现任ThoughtWorks高级软件质量咨询师, 超过10年软件开发和测试工作工作经验。最熟悉的领域是嵌入式系统开发、Linux系统开发、各种脚本、各种测试工具、各种自动化测试系统开发、以及Agile中的QA。其中对于服务器性能测试，Web功能测试，以及测试分层一体化解决方案有较深的理解。现在关注于全方位自动化QA的工作，以及对于Agile流程中怎么实现统一的流程、故事、功能、测试和文档管理，以及质量控制度量。
崔力强，现任ThoughtWorks公司高级咨询师。具有多年Java与Ruby的开发经验，最近两年的主要工作是在客户现场指导客户团队的开发与改进。在遗留代码重构、领域驱动设计、自动化测试的引入与推进方面有着丰富的经验。
