自动化测试框架Cucumber和RobotFramework的实战对比

转自: http://www.infoq.com/cn/articles/cucumber-robotframework-comparison

 

1、摘要

自动化测试能够快速自动完成大量测试用例，节约巨大的人工测试成本；同时它须要拥有专业开发技能的人才能完成开发，且须要大量时间进行维护（在需求常常变化的状况下），因此大部分具备很好开发技能的人员不是很愿意编写自动化用例。但因为软件规模的高速增加，人力资源的逐步稀缺，自动化测试已经是势在必行。

对于自动化测试首先须要保证其功能是对客户有价值的和正确可用的。而这一切的基础就是用例要能测试客户的需求，指望，最好能让客户参与到测试用例的开发过程当中来或让客户评审测试用例，所以出现了ATDD、BDD等各类理论方法来支撑这一行为。现有不少自动化测试工具可支持ATDD、BDD等，好比Cucumber¹、RobotFramework²、SpecFlow³、JBehave⁴、Fitness⁵、Concordion⁶等。其中Cucumber和RobotFramework是最流行的两个框架，但许多人在第一次选择测试框架时因缺少实践经验而困惑，因此今天为你们分享这两款框架在几个项目上的经验及对比，方便你们在之后的项目上能正确地选择这两款测试框架。

首先看一下这两款工具的简单对比。

	Cucumber	RobotFramework
编程语言支持	Java,Ruby,JavaScript etc.7	Python, Java, C
支持的系统	全部主流系统	全部主流系统
主要的IDE	IntelliJ,RubyMine, Eclipse	RIDE, IntelliJ, PyCharm, Eclipse
费用	免费	免费
多国语言支持	UTF-8	用户关键字及用例层面支持UTF-8

 

2、案例

Cucumber案例1：某社交网络系统

项目时间：4年前

项目背景：系统的主要功能是帮助用户能经过一个手机应用同时与Facebook，Twitter，Flickr等社交网络更新信息，并能一次性把本身更新的信息同步到这些社交网络。其中它有一个服务器端，用于和各个社交网络通讯，一个Web应用和一个手机应用提供给最终客户使用。它的技术栈主要是Java Spring，Android，iOS，MySQL等。

被测系统构架图：

因为这个项目是中国团队和法国团队一块儿合做开发，当时法国团队的架构师提出选用Cucumber做为自动化测试框架来测试这个系统，项目须要支持多国语言，且须要同时作服务器和手机端的功能测试，甚至在一个测试场景中既包含服务器测试部分，又含手机端测试部分，而使用基于Cucumber的测试系统很好的知足了咱们的需求，其中手机端的功能测试用的是Calabash⁸。Calabash是一个手机功能测试系统，它使用Cucumber将Android的测试框架Robotium⁹和iOS的测试框架Frank¹⁰封装了起来，使得Cucumber的Step能够调用Robotium和Frank进行测试。这样就能够实现一个测试场景里面既包含手机端测试，又包含服务器端测试，好比：

I "submit" update to "Facebook" with "I am happy today" on "Android"

I "get" update on "Facebook” with "I am happy today" on "Server"

实现方式是在Calabash中使用Ruby实现一层胶水代码，和服务器测试功能测试代码连结起来，并根据不一样的Step调用不一样的测试驱动层代码从而实现同一个测试用例同时包含服务器端和手机端测试。虽然这样的测试用例不会不少，但它却有效的表达了端到端的系统集成测试，让测试集合更加丰满。

若是从新选择测试工具，我仍是会选择Cucumber和Calabash，主要缘由是它们能够方便的统一作手机和服务器的功能测试。虽然RobotFramework配合Selenium也能实现相似的功能，可是须要使用RobotFramework对Selenium从新进行封装，没有Calabash方便易用。

Cucumber案例2：某大型养老保险系统

项目时间：2年前

项目背景，主要功能是提供一个Web系统让用户能够购买养老保险，管理养老保险帐户里面的资金等业务。主要的技术栈Java Spring, JSP, AngularJS, Oracle DB等。

被测系统构架图：

基于安全和开发成本缘由，好比重用已有的服务器和容器环境，重用开发资源，因此公司绝大部分项目只用Java语言进行后台服务器端开发，致使公司大部分人员只熟悉Java语言，所以测试框架选择了Cucumber Java版¹¹。

若是从新选择工具，因为技术栈和成本的缘由，我仍然会选择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的类库Scapy¹²可以很好地完成这部分工做，只须要在此之上作少许定制化开发，并将其封装成为RobotFramework关键字便可。通过上面的分析能够看到，使用基于Python的RobotFramework可以很好地处理报文相关的逻辑，加上团队在Python上有比较好的技术储备，所以RobotFramework成了最终的选择。

若是从新选择，我仍是会选择RobotFramework，缘由是其余平台上找不到相似Scapy这样好用的测试库。

RobotFramework案例2：某移动广告管理平台

项目时间：1年前

项目背景：该项目是一个Web系统，用于广告投放、查询、显示等功能。

测试思路是作端到端的测试，覆盖从广告投放、广告查询及广告显示等一系列功能。其中涉及到的测试库主要是Selenium，这点上与案例1相似。不一样之处在于这个项目中参与自动化用例编写的主要是从不编写代码的测试人员，而RobotFramework有一个专用的用例编写环境—RIDE，其中用例编辑窗口以下图：

虽然它只是简单地把使用TAB符号隔开的一系列纯文本变成了可视的表格，但对于这些测试人员来讲，他们之前工做的平台就是Excel中，因此很容易切换过来。再加上它提供的一些高亮、抽取关键字等特性，使得测试人员能够比较专一于测试用例的设计、编写和优化，而不用关心格式等细节问题。

在RIDE中导入相关测试库以后，能够经过F5快捷键查看全部关键字的文档，以下图所示：

关键字的概念颇有趣，它们本质上就是一堆自由函数，或者是类的成员函数¹³，因此使用它们来编写用例事实上就是在编写代码，本质上和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
亮点	· 使用天然语言，更易读 · 支持表格参数14 · 支持多种格式的Report：html、junit etc. · 支持多种语言 · 支持四种状态的测试步骤15：Passed、Failed、Skipped、Pending · 支持使用变形器消除重复16 · 一个商用的在线Cucumber系统：Cucumber Pro17	· 使用关键字的机制，更容易上手 · 提供了RIDE，对于不熟悉编码的人来讲比较友好 · 可以精细的控制关键字的scope19 · Log和Report很是好20 · 使用变量文件的机制来描述不一样的环境21 · 丰富的关键字库22 · 内置变量23
不足	· 缺少相似RIDE对纯测试人员友好的专用工具	· 不支持相似于Cucumber中的表格参数14 · 使用Jython版本测试运行启动慢
Jenkins支持	支持	支持
Maven支持	支持	支持
开发效率	高效-Jetbrains系列的IDE	高效-RIDE和Jetbrains系列的IDE
商业支持	支持18	无
社区支持	普遍	普遍

3、测试工具选择的通常性原则

在上述的实战案例中，针对项目的具体状况咱们对Cucumber和RobotFramework这两种工具进行了取舍。本节就来总结一下这些取舍的考虑因素。

首先来看一下自动化验收测试的层次：

而后对每层进行分析：

1. 最下面是被测系统，须要明确它的形态，好比是Web系统、REST系统或者特定协议系统。
2. 中间是测试库。好比Selenium、SSH、Scapy等，有了它们用例才能和被测系统进行交互，因此须要根据被测系统的形态来选择相应地测试库。该层的选择须要考虑几个因素：
   • 测试库的易用程度。
   • 测试库是否有良好的商业或者开源社区的支持。
   • 团队成员是否熟悉测试库使用的编程语言。
3. 最上层则是测试框架，也就是Cucumber和RobotFramework这一层。其做用包括用例管理、测试数据管理、测试运行、测试报告等。该层的选择须要考虑几个因素：
   • 这一层会经过函数调用的方式和测试库打交道，所以测试框架必须支持测试库所使用的编程语言。
   • 是否提供易用的测试用例开发环境，好比是否有如RIDE这样的专用工具，或者Intellij的IDE的插件。
   • 引入某个测试框架以后对现有工做模式的影响程度，好比让不懂编程的测试人员写代码。

以上这些点是从RobotFramework和Cucumber的对比中总结出来的，但若是你想要选择这二者以外的其余框架，一样能够考虑上述这些原则。

4、总结

咱们在银行、保险、社交、电信、物流、互联网等项目上实施过自动化功能以及验收测试。对于Cucumber和RobotFramework到底属于ATDD仍是BDD，这里不作过多的讨论，由于当前在业界对于ATDD和BDD怎么区分还有一些争议，而对于咱们来说，它们只不过是两个名词而已。对于这两个工具自己来说，只须要清楚它们各自的特色，根据项目自己的状况和需求选择就能够了，简单地说就是：知行合一。