自動化測試框架Cucumber和Robot Framework的實戰對比

自動化測試框架Cucumber和RobotFramework的實戰對比                             

 

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怎麼區分還有一些爭議，而對於咱們來說，它們只不過是兩個名詞而已。對於這兩個工具自己來說，只須要清楚它們各自的特色，根據項目自己的狀況和需求選擇就能夠了，簡單地說就是：知行合一。