聲明：此文作者是 劉冉 崔力強
一、摘要
自動化測試可以快速自動完成大量測試用例，節約巨大的人工測試成本；同時它需要擁有專業開發技能的人才能完成開發，且需要大量時間進行維護（在需求經常變化的情況下），所以大部分具有很好開發技能的人員不是很願意編寫自動化用例。但由於軟件規模的高速增長，人力資源的逐步稀缺，自動化測試已是勢在必行。
對於自動化測試首先需要保證其功能是對客戶有價值的和正確可用的。而這一切的基礎就是用例要能測試客戶的需求，期望，最好能讓客戶參與到測試用例的開發過程中來或讓客戶評審測試用例，因此出現了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 |
二、案例
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進行測試。這樣就可以實現一個測試場景裏面既包含手機端測試，又包含服務器端測試，比如：
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版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 |
|
亮點 |
|
|
|
不足
|
|
|
|
Jenkins支持 |
支持 |
支持 |
|
Maven支持 |
支持 |
支持 |
|
開發效率 |
高效-Jetbrains系列的IDE |
高效-RIDE和Jetbrains系列的IDE |
|
商業支持 |
支持18 |
無 |
|
社區支持 |
廣泛 |
廣泛 |
三、測試工具選擇的一般性原則
在上述的實戰案例中，針對項目的具體情況我們對Cucumber和RobotFramework這兩種工具進行了取捨。本節就來總結一下這些取捨的考慮因素。
首先來看一下自動化驗收測試的層次：
然後對每層進行分析：
- 最下面是被測系統，需要明確它的形態，比如是Web系統、REST系統或者特定協議系統。
- 中間是測試庫。比如Selenium、SSH、Scapy等，有了它們用例才能和被測系統進行交互，所以需要根據被測系統的形態來選擇相應地測試庫。該層的選擇需要考慮幾個因素：
- 測試庫的易用程度。
- 測試庫是否有良好的商業或者開源社區的支持。
- 團隊成員是否熟悉測試庫使用的編程語言。
- 最上層則是測試框架，也就是Cucumber和RobotFramework這一層。其作用包括用例管理、測試數據管理、測試運行、測試報告等。該層的選擇需要考慮幾個因素：
- 這一層會通過函數調用的方式和測試庫打交道，因此測試框架必須支持測試庫所使用的編程語言。
- 是否提供易用的測試用例開發環境，比如是否有如RIDE這樣的專用工具，或者Intellij的IDE的插件。
- 引入某個測試框架之後對現有工作模式的影響程度，比如讓不懂編程的測試人員寫代碼。
以上這些點是從RobotFramework和Cucumber的對比中總結出來的，但如果你想要選擇這兩者之外的其他框架，同樣可以考慮上述這些原則。
四、總結
我們在銀行、保險、社交、電信、物流、互聯網等項目上實施過自動化功能以及驗收測試。對於Cucumber和RobotFramework到底屬於ATDD還是BDD，這裏不做過多的討論，因爲當前在業界對於ATDD和BDD怎麼區分還有一些爭議，而對於我們來講，它們只不過是兩個名詞而已。對於這兩個工具本身來講，只需要清楚它們各自的特點，根據項目本身的情況和需求選擇就可以了，簡單地說就是：知行合一。
