一、摘要
自动化测试可以快速自动完成大量测试用例，节约巨大的人工测试成本；同时它需要拥有专业开发技能的人才能完成开发，且需要大量时间进行维护（在需求经常变化的情况下），所以大部分具有很好开发技能的人员不是很愿意编写自动化用例。但由于软件规模的高速增长，人力资源的逐步稀缺，自动化测试已是势在必行。
对于自动化测试首先需要保证其功能是对客户有价值的和正确可用的。而这一切的基础就是用例要能测试客户的需求，期望，最好能让客户参与到测试用例的开发过程中来或让客户评审测试用例，因此出现了ATDD、BDD等各种理论方法来支撑这一行为。现有很多自动化测试工具可支持ATDD、BDD等，比如Cucumber1、RobotFramework2、SpecFlow3、JBehave4、Fitness5、Concordion6等。其中Cucumber和RobotFramework是最流行的两个框架，但许多人在第一次选择测试框架时因缺乏实践经验而困惑，所以今天为大家分享这两款框架在几个项目上的经验及对比，方便大家在以后的项目上能正确地选择这两款测试框架。
首先看一下这两款工具的简单对比。
|
Cucumber |
RobotFramework |
|
|
编程语言支持 |
Java,Ruby,JavaScript etc.7 |
Python, Java, C |
|
支持的系统 |
所有主流系统 |
所有主流系统 |
|
主要的IDE |
IntelliJ,RubyMine, Eclipse |
RIDE, IntelliJ, PyCharm, Eclipse |
|
费用 |
免费 |
免费 |
|
多国语言支持 |
UTF-8 |
用户关键字及用例层面支持UTF-8 |
二、案例
----案例省略
案例1：
当时法国团队的架构师提出选用Cucumber作为自动化测试框架来测试这个系统，项目需要支持多国语言，且需要同时做服务器和手机端的功能测试，甚至在一个测试场景中既包含服务器测试部分，又含手机端测试部分，而使用基于Cucumber的测试系统很好的满足了我们的需求，其中手机端的功能测试用的是Calabash8。Calabash是一个手机功能测试系统，它使用Cucumber将Android的测试框架Robotium9和iOS的测试框架Frank10封装了起来，使得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和RobotFramework时的一些经验和选择它们的理由。但对于Cucumber和RobotFramework更多的知识点，下面有一个更为详细的对比表。
|
Cucumber |
RobotFramework |
|
|
亮点 |
|
|
|
不足
|
|
|
|
Jenkins支持 |
支持 |
支持 |
|
Maven支持 |
支持 |
支持 |
|
开发效率 |
高效-Jetbrains系列的IDE |
高效-RIDE和Jetbrains系列的IDE |
|
商业支持 |
支持18 |
无 |
|
社区支持 |
广泛 |
广泛 |
三、测试工具选择的一般性原则
在上述的实战案例中，针对项目的具体情况我们对Cucumber和RobotFramework这两种工具进行了取舍。本节就来总结一下这些取舍的考虑因素。
首先来看一下自动化验收测试的层次：
然后对每层进行分析：
- 最下面是被测系统，需要明确它的形态，比如是Web系统、REST系统或者特定协议系统。
- 中间是测试库。比如Selenium、SSH、Scapy等，有了它们用例才能和被测系统进行交互，所以需要根据被测系统的形态来选择相应地测试库。该层的选择需要考虑几个因素：
- 测试库的易用程度。
- 测试库是否有良好的商业或者开源社区的支持。
- 团队成员是否熟悉测试库使用的编程语言。
- 最上层则是测试框架，也就是Cucumber和RobotFramework这一层。其作用包括用例管理、测试数据管理、测试运行、测试报告等。该层的选择需要考虑几个因素：
- 这一层会通过函数调用的方式和测试库打交道，因此测试框架必须支持测试库所使用的编程语言。
- 是否提供易用的测试用例开发环境，比如是否有如RIDE这样的专用工具，或者Intellij的IDE的插件。
- 引入某个测试框架之后对现有工作模式的影响程度，比如让不懂编程的测试人员写代码。
以上这些点是从RobotFramework和Cucumber的对比中总结出来的，但如果你想要选择这两者之外的其他框架，同样可以考虑上述这些原则。
四、总结
对于这两个工具本身来讲，只需要清楚它们各自的特点，根据项目本身的情况和需求选择就可以了，简单地说就是：知行合一。
- http://cukes.info/
- http://robotframework.org/
- http://www.specflow.org/
- http://jbehave.org/
- http://www.fitnesse.org/
- http://concordion.org/
- https://cukes.info/docs#cucumber-implementations
- https://github.com/calabash
- https://code.google.com/p/robotium/
- http://www.testingwithfrank.com/
- https://github.com/cucumber/cucumber-jvm
- http://secdev.org/projects/scapy/
- http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#creating-test-libraries
- https://cukes.info/docs/reference#data-tables
- https://github.com/cucumber/cucumber/wiki/Step-Definitions
- https://github.com/cucumber/cucumber/wiki/Step-Argument-Transforms
- https://cucumber.pro/
- http://cukes.info/support
- http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#test-library-scope
- http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#report-file
- http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#variable-files
- http://robotframework.org/#test-libraries
- http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#built-in-variables
摘自：http://www.infoq.com/cn/articles/cucumber-robotframework-comparison