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

一、摘要

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

对于自动化测试首先需要保证其功能是对客户有价值的和正确可用的。而这一切的基础就是用例要能测试客户的需求，期望，最好能让客户参与到测试用例的开发过程中来或让客户评审测试用例，因此出现了ATDD、BDD等各种理论方法来支撑这一行为。现有很多自动化测试工具可支持ATDD、BDD等，比如Cucumber1、RobotFramework2、SpecFlow3、JBehave4、Fitness5、Concordion6等。其中Cucumber和RobotFramework是最流行的两个框架，但许多人在第一次选择测试框架时因缺乏实践经验而困惑，所以今天为大家分享这两款框架在几个项目上的经验及对比，方便大家在以后的项目上能正确地选择这两款测试框架。

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

二、案例

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

项目时间：4年前

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

被测系统构架图：

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

I"submit"updateto"Facebook"with"Iamhappytoday"on"Android"

I"get"updateon"Facebook”with"Iamhappytoday"on"Server"

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

如果重新选择测试工具，我还是会选择Cucumber和Calabash，主要原因是它们可以方便的统一做手机和服务器的功能测试。虽然RobotFramework配合Selenium也能实现类似的功能，但是需要使用RobotFramework对Selenium重新进行封装，没有Calabash方便易用。

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

项目时间：2年前

项目背景，主要功能是提供一个Web系统让用户可以购买养老保险，管理养老保险账户里面的资金等业务。主要的技术栈JavaSpring,JSP,AngularJS,OracleDB等。

被测系统构架图：

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

如果重新选择工具，由于技术栈和成本的原因，我仍然会选择CucumberJava版，不会考虑RobotFramework。因为对于这种JavaSpring商业应用项目，我不想引入一个Jython去加深项目的技术栈，只要能充分利用当前团队已有的技术栈就可以了，并且还更容易说服开发人员帮忙实现和维护自动化测试，从而促使整个团队都能对自动化测试负责。

RobotFramework案例1：某AC项目

项目时间：3年前

项目背景：该项目是WIFI系统的AC（AccessController接入控制器）部分，包含WIFI接入的认证、计费等功能。它也提供了配置界面，包括Web和命令行两种。AP（AccessPoint接入点）是与该系统交互的外部系统。通常来说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快捷键查看所有关键字的文档，如下图所示：

查看测试工具，欢迎前往51Testing软件测试网。