一、摘要
自動化測試可以快速自動完成大量測試用例，節約巨大的人工測試成本；同時它需要擁有專業開發技能的人才能完成開發，且需要大量時間進行維護（在需求經常變化的情況下），所以大部分具有很好開發技能的人員不是很願意編寫自動化用例。但由於軟件規模的高速增長，人力資源的逐步稀缺，自動化測試已是勢在必行。
對於自動化測試首先需要保證其功能是對客戶有價值的和正確可用的。而這一切的基礎就是用例要能測試客戶的需求，期望，最好能讓客戶參與到測試用例的開發過程中來或讓客戶評審測試用例，因此出現了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