一、摘要自動化測試可以快速自動完成大量測試用例，節(jié)約巨大的人工測試成本；同時它需要擁有專業(yè)開發(fā)技能的人才能完成開發(fā)，且需要大量時間進行維護（在需求經常變化的情況下），所以大部分具有很好開發(fā)技能的人員不是很愿意編寫自動化用例。但由于軟件規(guī)模的高速增長，人力資源的逐步稀缺，自動化測試已是勢在必行。 對于自動化測試首先需要保證其功能是對客戶有價值的和正確可用的。而這一切的基礎就是用例要能測試客戶的需求，期望，最好能讓客戶參與到測試用例的開發(fā)過程中來或讓客戶評審測試用例，因此出現(xiàn)了ATDD、BDD等各種理論方法來支撐這一行為?，F(xiàn)有很多自動化測試工具可支持ATDD、BDD等，比如Cucumber1、RobotFramework2、SpecFlow3、JBehave4、Fitness5、Concordion6等。其中Cucumber和RobotFramework是最流行的兩個框架，但許多人在第一次選擇測試框架時因缺乏實踐經驗而困惑，所以今天為大家分享這兩款框架在幾個項目上的經驗及對比，方便大家在以后的項目上能正確地選擇這兩款測試框架。 首先看一下這兩款工具的簡單對比。
二、案例Cucumber案例1：某社交網絡系統(tǒng)項目時間：4年前 項目背景：系統(tǒng)的主要功能是幫助用戶能通過一個手機應用同時與Facebook，Twitter，F(xiàn)lickr等社交網絡更新信息，并能一次性把自己更新的信息同步到這些社交網絡。其中它有一個服務器端，用于和各個社交網絡通信，一個Web應用和一個手機應用提供給最終客戶使用。它的技術棧主要是Java Spring，Android，iOS，MySQL等。 被測系統(tǒng)構架圖：
由于這個項目是中國團隊和法國團隊一起合作開發(fā)，當時法國團隊的架構師提出選用Cucumber作為自動化測試框架來測試這個系統(tǒng)，項目需要支持多國語言，且需要同時做服務器和手機端的功能測試，甚至在一個測試場景中既包含服務器測試部分，又含手機端測試部分，而使用基于Cucumber的測試系統(tǒng)很好的滿足了我們的需求，其中手機端的功能測試用的是Calabash8。Calabash是一個手機功能測試系統(tǒng)，它使用Cucumber將Android的測試框架Robotium9和iOS的測試框架Frank10封裝了起來，使得Cucumber的Step可以調用Robotium和Frank進行測試。這樣就可以實現(xiàn)一個測試場景里面既包含手機端測試，又包含服務器端測試，比如：
實現(xiàn)方式是在Calabash中使用Ruby實現(xiàn)一層膠水代碼，和服務器測試功能測試代碼連結起來，并根據不同的Step調用不同的測試驅動層代碼從而實現(xiàn)同一個測試用例同時包含服務器端和手機端測試。雖然這樣的測試用例不會很多，但它卻有效的表達了端到端的系統(tǒng)集成測試，讓測試集合更加豐滿。 如果重新選擇測試工具，我還是會選擇Cucumber和Calabash，主要原因是它們可以方便的統(tǒng)一做手機和服務器的功能測試。雖然RobotFramework配合Selenium也能實現(xiàn)類似的功能，但是需要使用RobotFramework對Selenium重新進行封裝，沒有Calabash方便易用。 Cucumber案例2：某大型養(yǎng)老保險系統(tǒng)項目時間：2年前 項目背景，主要功能是提供一個Web系統(tǒng)讓用戶可以購買養(yǎng)老保險，管理養(yǎng)老保險賬戶里面的資金等業(yè)務。主要的技術棧Java Spring, JSP, AngularJS, Oracle DB等。 被測系統(tǒng)構架圖：
基于安全和開發(fā)成本原因，比如重用已有的服務器和容器環(huán)境，重用開發(fā)資源，所以公司絕大部分項目只用Java語言進行后臺服務器端開發(fā)，導致公司大部分人員只熟悉Java語言，因此測試框架選擇了Cucumber Java版11。 如果重新選擇工具，由于技術棧和成本的原因，我仍然會選擇Cucumber Java版，不會考慮RobotFramework。因為對于這種Java Spring商業(yè)應用項目，我不想引入一個Jython去加深項目的技術棧，只要能充分利用當前團隊已有的技術棧就可以了，并且還更容易說服開發(fā)人員幫忙實現(xiàn)和維護自動化測試，從而促使整個團隊都能對自動化測試負責。 RobotFramework案例1：某AC項目項目時間：3年前 項目背景：該項目是WIFI系統(tǒng)的AC（Access Controller 接入控制器）部分，包含WIFI接入的認證、計費等功能。它也提供了配置界面，包括Web和命令行兩種。AP（Access Point接入點）是與該系統(tǒng)交互的外部系統(tǒng)。通常來說AP會有很多個，放置在不同的空間區(qū)域，提供WIFI接入服務，AP和AC之間使用有線鏈路連接。 被測系統(tǒng)構架圖：
該系統(tǒng)作為一個嵌入式設備，從用戶的角度來看主要包括兩部分功能。第一部分是操作管理員在命令行或者Web界面上進行功能配置，第二部分是AP與系統(tǒng)進行交互，完成網絡接入等功能。 明確了被測對象和場景后，就需要尋找相應的測試庫來完成這些用戶（即包括人，也包AP）與系統(tǒng)之間的交互。對于Web來說，有成熟的Selenium可以使用，Selenium提供了多種語言的API，從這個角度來看RobotFramework和Cucumber都可以選擇。對于命令行操作而言，可以選用RoboFramework的SSH庫來完成，當然在這一點上其他的語言也有相應的類庫。要想完成上述這個系統(tǒng)的測試，還需要完成報文的收發(fā)及編解碼工作，Python的類庫Scapy12能夠很好地完成這部分工作，只需要在此之上做少量定制化開發(fā)，并將其封裝成為RobotFramework關鍵字即可。經過上面的分析可以看到，使用基于Python的RobotFramework能夠很好地處理報文相關的邏輯，加上團隊在Python上有比較好的技術儲備，因此RobotFramework成了最終的選擇。 如果重新選擇，我還是會選擇RobotFramework，原因是其他平臺上找不到類似Scapy這樣好用的測試庫。 RobotFramework案例2：某移動廣告管理平臺項目時間：1年前 項目背景：該項目是一個Web系統(tǒng)，用于廣告投放、查詢、顯示等功能。 測試思路是做端到端的測試，覆蓋從廣告投放、廣告查詢及廣告顯示等一系列功能。其中涉及到的測試庫主要是Selenium，這點上與案例1類似。不同之處在于這個項目中參與自動化用例編寫的主要是從不編寫代碼的測試人員，而RobotFramework有一個專用的用例編寫環(huán)境—RIDE，其中用例編輯窗口如下圖：
雖然它只是簡單地把使用TAB符號隔開的一系列純文本變成了可視的表格，但對于這些測試人員來說，他們以前工作的平臺就是Excel中，所以很容易切換過來。再加上它提供的一些高亮、抽取關鍵字等特性，使得測試人員可以比較專注于測試用例的設計、編寫和優(yōu)化，而不用關心格式等細節(jié)問題。 在RIDE中導入相關測試庫之后，可以通過F5快捷鍵查看所有關鍵字的文檔，如下圖所示：
關鍵字的概念很有趣，它們本質上就是一堆自由函數，或者是類的成員函數13，所以使用它們來編寫用例事實上就是在編寫代碼，本質上和Cucumber的Step Definition是一樣的。但由于RIDE以表格的形式呈現(xiàn)，并且有良好可視化的文檔，在這種環(huán)境下寫測試會給人一種“我不需要編寫代碼”或“我沒在寫代碼”的感覺。在我們經歷過的幾個項目中，測試人員對這種形式都比較接受。當然從另一個角度看，用例的編寫者失去了對測試代碼的直接掌控權，這對于很多開發(fā)人員來說還是有些別扭，所以如果你不喜歡RIDE這種形式，可以嘗試使用Pycharm來開發(fā)RobotFramework用例。 在這個項目中有不止一套測試運行環(huán)境，比如開發(fā)集成環(huán)境、CI環(huán)境、系統(tǒng)測試環(huán)境等。該項目包含了多個Web Portal，每套環(huán)境中Web Portal的IP地址都是不同的。如何保證一套測試代碼能夠在不同的環(huán)境中無差別的運行呢？簡單的答案是配置文件或者環(huán)境變量，在RobotFramework中，解決方案是變量文件。比如我希望測試代碼能夠在開發(fā)集成環(huán)境和CI環(huán)境中運行，則可以按照下面的方式操作。 首先定義兩個變量文件： ci-env.py: portal_ip = “192.168.1.1" …… dev-share-env.py: portal_ip = “192.168.1.4" …… 在用例文件中可以按照下面的方式引用上述變量文件中的變量： ……
open browser ${portal_ip}
……
然后在運行測試時加入如下的命令行參數即可針對CI環(huán)境運行測試： pybot -V ci-env.py tests/ 開發(fā)人員在自己編寫調試測試或者定位問題時，在命令行中使用dev-share-env.py的配置即可針對另一套環(huán)境進行測試。 在這個項目中遇到的另一個問題是中文問題。客戶非常在意用例是否能很好地處理中文，一方面是因為可讀性，另一方面是要適配一些使用中文編寫的Java代碼。RobotFramework和Cucumber這些工具都有考慮國際化的問題，比如Cucumber Java版就支持使用類似于“給定”、“當”等中文關鍵字及中文的Step Definition，而RobotFramework對中文的支持也很好。但是如果從可用性的角度考慮，RobotFramework會比Cucumber好一些。原因是Cucumber本身并沒有專用的IDE，只能求助于其它IDE插件，這些插件可以完成高亮、自動補全和Step Definition跳轉等功能，但一旦使用了中文，有些功能就不好用了。而在RIDE中就不存在這個問題。所以如果你的團隊因為某種原因對于中文用例的需求很旺盛，可以考慮RobotFramework。 如果重新選擇，我還是會選擇RobotFramework，主要從兩個方面進行考慮：一方面是因為其“不用寫代碼”的方式更容易被測試人員接受，另一方面是對中文的支持更好。 通過上面四個案例，展示了在不同的項目中實際使用Cucumber和RobotFramework時的一些經驗和選擇它們的理由。但對于Cucumber和RobotFramework更多的知識點，下面有一個更為詳細的對比表。
三、測試工具選擇的一般性原則在上述的實戰(zhàn)案例中，針對項目的具體情況我們對Cucumber和RobotFramework這兩種工具進行了取舍。本節(jié)就來總結一下這些取舍的考慮因素。 首先來看一下自動化驗收測試的層次：
然后對每層進行分析：
以上這些點是從RobotFramework和Cucumber的對比中總結出來的，但如果你想要選擇這兩者之外的其他框架，同樣可以考慮上述這些原則。 四、總結我們在銀行、保險、社交、電信、物流、互聯(lián)網等項目上實施過自動化功能以及驗收測試。對于Cucumber和RobotFramework到底屬于ATDD還是BDD，這里不做過多的討論，因為當前在業(yè)界對于ATDD和BDD怎么區(qū)分還有一些爭議，而對于我們來講，它們只不過是兩個名詞而已。對于這兩個工具本身來講，只需要清楚它們各自的特點，根據項目本身的情況和需求選擇就可以了，簡單地說就是：知行合一。
作者簡介
給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.。也歡迎大家通過新浪微博（@InfoQ）或者騰訊微博（@InfoQ）關注我們，并與我們的編輯和其他讀者朋友交流。 高危漏洞頻發(fā)，隱私泄露，普通開發(fā)者該如何避免和防范；開發(fā)者如何從邏輯上避免風險？在【QCon北京2015】“新時代的安全”專題中，在Pwn2Own 2015上奪冠的Keen Team安全研究員Peter Hlavaty將解讀內核安全精髓；阿里巴巴安全專家祝建躍將分享互聯(lián)網全球最大DDoS攻擊防御實戰(zhàn)。查看詳情。
相關內容 社區(qū)評論
Watch Thread
hmm...
2015年3月16日 12:34
by
如果說 Robot Framework（RF） 只支持 Python 和 Java 這不太公平，第一： RF 的網站上已經有 C 語言的例子，其實支持 C/C++ 都很容易；第二其實RF也可以透過 XML RPC去聯(lián)接被測系統(tǒng)，那麼你想用什麼語言來提供接口都可以。
相反，Cucumber 雖有不同語言版本，但不是每個語言版所支持的功能都一樣，這是需要注意的事情。 文中最搞笑的地方是 RF "不支持類似于Cucumber中的表格參數"，在 RF 裡面所有東西都是表格，而RF 亦支持 Template 的使用方法。我說這是搞笑不是因為作者認識不夠深入，而是因為這功能是 Cucumber 作者看到 RF 之後覺得很好而添加在 Cucumber 中，沒想到今天會被說成是 RF 沒這功能 :D 還有... 這篇文最多只是討論 RF / Cucumber 用作自動測試工具，根本和 ATDD, BDD 扯不上關係。 當然，ATDD, BDD 重要的從來都不是用什麼自動化測試工具。
Re: hmm...
2015年3月17日 05:12
by
1，RF對于C的支持其實使用的是Python's standard ctypes module，只是擴展，并不是使用C語言實現(xiàn)的，所以還需要安裝RF原始的所有環(huán)境，而且我們也沒有使用過，并不知道其穩(wěn)定性和易用性，所以并沒有寫。對于這個我們沒有寫，屬于我們的錯誤，我們更改。不過如果算上這種模型，理論上可以讓RF支持任何語言，比如使用Thrift（thrift./docs/features），這樣就可以讓RF支持所有語言...
更改： 編程語言支持：Cucumber:Java,Ruby,JavaScript etc.7 RF:Python, Java, C 2，對于Cucumber的多種語言，并不是所有語言功能都一樣，這個是對的，不過對于基本功能都是一樣的。對于普通的使用者可以不需要關心，高級用戶需要自己看文檔。 3.對于 "不支持類似于Cucumber中的表格參數"，如果你笑了只能說明你可能還沒有搞清楚cucumber的datatable，請詳細參見引用14. 4.我只是想闡明一下我對ATDD和BDD的看法，以及引出ATDD和BDD，文章并沒有詳細討論ATDD和BDD。如果你說扯不上關系，其實還是有一點點關系，那請參見在RF的官網上有這句話：“Generic test automation framework for acceptance testing and ATDD” 來自 /，而在cucumber的官方文檔中也寫道“While Cucumber can be thought of as a “testing” tool, the intent of the tool is to support BDD” 來自github.com/cucumber/cucumber/wiki。我只是想盡量解決讀者的疑惑... 5.就中立而言，我們已經盡量追求了。我們并沒有想偏向某一方，兩邊都有其優(yōu)缺點，根據你的需要自己選擇就可以了。這個也是為什么這篇文章是兩個人寫的原因。
Re: hmm...
2015年3月31日 02:05
by
非常同意。
RF設計目的是測試框架，或者說用來構建測試框架的框架。Cucumber是工具。層次不一樣。 一個優(yōu)秀的自動化團隊，肯定要構建自己自動化測試體系。 基礎很重要，RF提供的架構方式非常合適。 可以自定義adapter，parser，driver... 其他任何你覺得有用的東西，只要能被python調起來，加個wrapper都可以拿來用。 除了下劃線和空格會被忽略以外，真沒啥不好的 :-)
Re: hmm...
2015年3月31日 04:41
by
首先我覺得說Cucumber是工具只是一個狹義的理解，難道Cucumber就不能加個wrapper來用嗎？（Ruby的強大人所共知，討論這些就涉及到Ruby和Python的比較，我覺得是沒有什么意義的）如果一定要區(qū)分框架和工具，就要首先定義框架和工具。什么是框架，什么是工具？我覺得說一句“Cucumber是工具”無法讓我同意。
對于“一個優(yōu)秀的自動化團隊，肯定要構建自己自動化測試體系?！?，其實現(xiàn)在很多項目都不會有專門的自動化團隊，而是由開發(fā)團隊做。所以這個時候就需要根據每個團隊的特定選擇合適的自動化工具，框架，whatever，幫助他們建立自己的自動化測試系統(tǒng)就可以。所以應該是對于優(yōu)秀的開發(fā)團隊，都要構建自己自動化測試系統(tǒng)，所以才需要學習，比較和選擇適合自己的，而不是盲目的聽說某個好，就用某一個。 其次“基礎很重要，RF提供的架構方式非常合適?！边@個肯定是由前提條件的，并不是每一個團隊都適合的，因為每個團隊都有自己的限制條件，況且任何一個軟件項目最后都會有一個致命的問題：成本與收益（錢多得沒有地方花，不在乎錢的團隊除外）。 |
|
|
劉冉，現(xiàn)任ThoughtWorks高級軟件質量咨詢師, 超過10年軟件開發(fā)和測試工作工作經驗。最熟悉的領域是嵌入式系統(tǒng)開發(fā)、Linux系統(tǒng)開發(fā)、各種腳本、各種測試工具、各種自動化測試系統(tǒng)開發(fā)、以及Agile中的QA。其中對于服務器性能測試，Web功能測試，以及測試分層一體化解決方案有較深的理解。現(xiàn)在關注于全方位自動化QA的工作，以及對于Agile流程中怎么實現(xiàn)統(tǒng)一的流程、故事、功能、測試和文檔管理，以及質量控制度量。
崔力強，現(xiàn)任ThoughtWorks公司高級咨詢師。具有多年Java與Ruby的開發(fā)經驗，最近兩年的主要工作是在客戶現(xiàn)場指導客戶團隊的開發(fā)與改進。在遺留代碼重構、領域驅動設計、自動化測試的引入與推進方面有著豐富的經驗。
