自動(dòng)化測試可以快速自動(dòng)完成大量測試用例，節約巨大的人工測試成本；同時(shí)它需要擁有專(zhuān)業(yè)開(kāi)發(fā)技能的人才能完成開(kāi)發(fā)，且需要大量時(shí)間進(jìn)行維護（在需求經(jīng)常變化的情況下），所以大部分具有很好開(kāi)發(fā)技能的人員不是很愿意編寫(xiě)自動(dòng)化用例。但由于軟件規模的高速增長(cháng)，人力資源的逐步稀缺，自動(dòng)化測試已是勢在必行。
對于自動(dòng)化測試首先需要保證其功能是對客戶(hù)有價(jià)值的和正確可用的。而這一切的基礎就是用例要能測試客戶(hù)的需求，期望，最好能讓客戶(hù)參與到測試用例的開(kāi)發(fā)過(guò)程中來(lái)或讓客戶(hù)評審測試用例，因此出現了ATDD、BDD等各種理論方法來(lái)支撐這一行為?，F有很多自動(dòng)化測試工具可支持ATDD、BDD等，比如Cucumber1、RobotFramework2、SpecFlow3、JBehave4、Fitness5、Concordion6等。其中Cucumber和RobotFramework是最流行的兩個(gè)框架，但許多人在第一次選擇測試框架時(shí)因缺乏實(shí)踐經(jīng)驗而困惑，所以今天為大家分享這兩款框架在幾個(gè)項目上的經(jīng)驗及對比，方便大家在以后的項目上能正確地選擇這兩款測試框架。
首先看一下這兩款工具的簡(jiǎn)單對比。
|
| Cucumber | RobotFramework |
| 編程語(yǔ)言支持 | Java,Ruby,JavaScript etc.7 | Python, Java, C |
| 支持的系統 | 所有主流系統 | 所有主流系統 |
| 主要的IDE | IntelliJ,RubyMine, Eclipse | RIDE, IntelliJ, PyCharm, Eclipse |
| 費用 | 免費 | 免費 |
| 多國語(yǔ)言支持 | UTF-8 | 用戶(hù)關(guān)鍵字及用例層面支持UTF-8 |
項目時(shí)間：4年前
項目背景：系統的主要功能是幫助用戶(hù)能通過(guò)一個(gè)手機應用同時(shí)與Facebook，Twitter，Flickr等社交網(wǎng)絡(luò )更新信息，并能一次性把自己更新的信息同步到這些社交網(wǎng)絡(luò )。其中它有一個(gè)服務(wù)器端，用于和各個(gè)社交網(wǎng)絡(luò )通信，一個(gè)Web應用和一個(gè)手機應用提供給最終客戶(hù)使用。它的技術(shù)棧主要是Java Spring，Android，iOS，MySQL等。
被測系統構架圖：
由于這個(gè)項目是中國團隊和法國團隊一起合作開(kāi)發(fā)，當時(shí)法國團隊的架構師提出選用Cucumber作為自動(dòng)化測試框架來(lái)測試這個(gè)系統，項目需要支持多國語(yǔ)言，且需要同時(shí)做服務(wù)器和手機端的功能測試，甚至在一個(gè)測試場(chǎng)景中既包含服務(wù)器測試部分，又含手機端測試部分，而使用基于Cucumber的測試系統很好的滿(mǎn)足了我們的需求，其中手機端的功能測試用的是Calabash8。Calabash是一個(gè)手機功能測試系統，它使用Cucumber將Android的測試框架Robotium9和iOS的測試框架Frank10封裝了起來(lái)，使得Cucumber的Step可以調用Robotium和Frank進(jìn)行測試。這樣就可以實(shí)現一個(gè)測試場(chǎng)景里面既包含手機端測試，又包含服務(wù)器端測試，比如：
I "submit" update to "Facebook" with "I am happy today" on "Android"
I "get" update on "Facebook” with "I am happy today" on "Server"
實(shí)現方式是在Calabash中使用Ruby實(shí)現一層膠水代碼，和服務(wù)器測試功能測試代碼連結起來(lái)，并根據不同的Step調用不同的測試驅動(dòng)層代碼從而實(shí)現同一個(gè)測試用例同時(shí)包含服務(wù)器端和手機端測試。雖然這樣的測試用例不會(huì )很多，但它卻有效的表達了端到端的系統集成測試，讓測試集合更加豐滿(mǎn)。
如果重新選擇測試工具，我還是會(huì )選擇Cucumber和Calabash，主要原因是它們可以方便的統一做手機和服務(wù)器的功能測試。雖然RobotFramework配合Selenium也能實(shí)現類(lèi)似的功能，但是需要使用RobotFramework對Selenium重新進(jìn)行封裝，沒(méi)有Calabash方便易用。
項目時(shí)間：2年前
項目背景，主要功能是提供一個(gè)Web系統讓用戶(hù)可以購買(mǎi)養老保險，管理養老保險賬戶(hù)里面的資金等業(yè)務(wù)。主要的技術(shù)棧Java Spring, JSP, AngularJS, Oracle DB等。
被測系統構架圖：
基于安全和開(kāi)發(fā)成本原因，比如重用已有的服務(wù)器和容器環(huán)境，重用開(kāi)發(fā)資源，所以公司絕大部分項目只用Java語(yǔ)言進(jìn)行后臺服務(wù)器端開(kāi)發(fā)，導致公司大部分人員只熟悉Java語(yǔ)言，因此測試框架選擇了Cucumber Java版11。
如果重新選擇工具，由于技術(shù)棧和成本的原因，我仍然會(huì )選擇Cucumber Java版，不會(huì )考慮RobotFramework。因為對于這種Java Spring商業(yè)應用項目，我不想引入一個(gè)Jython去加深項目的技術(shù)棧，只要能充分利用當前團隊已有的技術(shù)棧就可以了，并且還更容易說(shuō)服開(kāi)發(fā)人員幫忙實(shí)現和維護自動(dòng)化測試，從而促使整個(gè)團隊都能對自動(dòng)化測試負責。
項目時(shí)間：3年前
項目背景：該項目是WIFI系統的AC（Access Controller 接入控制器）部分，包含WIFI接入的認證、計費等功能。它也提供了配置界面，包括Web和命令行兩種。AP（Access Point接入點(diǎn)）是與該系統交互的外部系統。通常來(lái)說(shuō)AP會(huì )有很多個(gè)，放置在不同的空間區域，提供WIFI接入服務(wù)，AP和AC之間使用有線(xiàn)鏈路連接。
被測系統構架圖：
該系統作為一個(gè)嵌入式設備，從用戶(hù)的角度來(lái)看主要包括兩部分功能。第一部分是操作管理員在命令行或者Web界面上進(jìn)行功能配置，第二部分是AP與系統進(jìn)行交互，完成網(wǎng)絡(luò )接入等功能。
明確了被測對象和場(chǎng)景后，就需要尋找相應的測試庫來(lái)完成這些用戶(hù)（即包括人，也包AP）與系統之間的交互。對于Web來(lái)說(shuō)，有成熟的Selenium可以使用，Selenium提供了多種語(yǔ)言的API，從這個(gè)角度來(lái)看RobotFramework和Cucumber都可以選擇。對于命令行操作而言，可以選用RoboFramework的SSH庫來(lái)完成，當然在這一點(diǎn)上其他的語(yǔ)言也有相應的類(lèi)庫。要想完成上述這個(gè)系統的測試，還需要完成報文的收發(fā)及編解碼工作，Python的類(lèi)庫Scapy12能夠很好地完成這部分工作，只需要在此之上做少量定制化開(kāi)發(fā)，并將其封裝成為RobotFramework關(guān)鍵字即可。經(jīng)過(guò)上面的分析可以看到，使用基于Python的RobotFramework能夠很好地處理報文相關(guān)的邏輯，加上團隊在Python上有比較好的技術(shù)儲備，因此RobotFramework成了最終的選擇。
如果重新選擇，我還是會(huì )選擇RobotFramework，原因是其他平臺上找不到類(lèi)似Scapy這樣好用的測試庫。
項目時(shí)間：1年前
項目背景：該項目是一個(gè)Web系統，用于廣告投放、查詢(xún)、顯示等功能。
測試思路是做端到端的測試，覆蓋從廣告投放、廣告查詢(xún)及廣告顯示等一系列功能。其中涉及到的測試庫主要是Selenium，這點(diǎn)上與案例1類(lèi)似。不同之處在于這個(gè)項目中參與自動(dòng)化用例編寫(xiě)的主要是從不編寫(xiě)代碼的測試人員，而RobotFramework有一個(gè)專(zhuān)用的用例編寫(xiě)環(huán)境—RIDE，其中用例編輯窗口如下圖：
雖然它只是簡(jiǎn)單地把使用TAB符號隔開(kāi)的一系列純文本變成了可視的表格，但對于這些測試人員來(lái)說(shuō)，他們以前工作的平臺就是Excel中，所以很容易切換過(guò)來(lái)。再加上它提供的一些高亮、抽取關(guān)鍵字等特性，使得測試人員可以比較專(zhuān)注于測試用例的設計、編寫(xiě)和優(yōu)化，而不用關(guān)心格式等細節問(wèn)題。
在RIDE中導入相關(guān)測試庫之后，可以通過(guò)F5快捷鍵查看所有關(guān)鍵字的文檔，如下圖所示：
關(guān)鍵字的概念很有趣，它們本質(zhì)上就是一堆自由函數，或者是類(lèi)的成員函數13，所以使用它們來(lái)編寫(xiě)用例事實(shí)上就是在編寫(xiě)代碼，本質(zhì)上和Cucumber的Step Definition是一樣的。但由于RIDE以表格的形式呈現，并且有良好可視化的文檔，在這種環(huán)境下寫(xiě)測試會(huì )給人一種“我不需要編寫(xiě)代碼”或“我沒(méi)在寫(xiě)代碼”的感覺(jué)。在我們經(jīng)歷過(guò)的幾個(gè)項目中，測試人員對這種形式都比較接受。當然從另一個(gè)角度看，用例的編寫(xiě)者失去了對測試代碼的直接掌控權，這對于很多開(kāi)發(fā)人員來(lái)說(shuō)還是有些別扭，所以如果你不喜歡RIDE這種形式，可以嘗試使用Pycharm來(lái)開(kāi)發(fā)RobotFramework用例。
在這個(gè)項目中有不止一套測試運行環(huán)境，比如開(kāi)發(fā)集成環(huán)境、CI環(huán)境、系統測試環(huán)境等。該項目包含了多個(gè)Web Portal，每套環(huán)境中Web Portal的IP地址都是不同的。如何保證一套測試代碼能夠在不同的環(huán)境中無(wú)差別的運行呢？簡(jiǎn)單的答案是配置文件或者環(huán)境變量，在RobotFramework中，解決方案是變量文件。比如我希望測試代碼能夠在開(kāi)發(fā)集成環(huán)境和CI環(huán)境中運行，則可以按照下面的方式操作。
首先定義兩個(gè)變量文件：
ci-env.py:portal_ip = “192.168.1.1"……dev-share-env.py:portal_ip = “192.168.1.4"……
在用例文件中可以按照下面的方式引用上述變量文件中的變量：
……open browser ${portal_ip}……然后在運行測試時(shí)加入如下的命令行參數即可針對CI環(huán)境運行測試：
pybot -V ci-env.py tests/
開(kāi)發(fā)人員在自己編寫(xiě)調試測試或者定位問(wèn)題時(shí)，在命令行中使用dev-share-env.py的配置即可針對另一套環(huán)境進(jìn)行測試。
在這個(gè)項目中遇到的另一個(gè)問(wèn)題是中文問(wèn)題?？蛻?hù)非常在意用例是否能很好地處理中文，一方面是因為可讀性，另一方面是要適配一些使用中文編寫(xiě)的Java代碼。RobotFramework和Cucumber這些工具都有考慮國際化的問(wèn)題，比如Cucumber Java版就支持使用類(lèi)似于“給定”、“當”等中文關(guān)鍵字及中文的Step Definition，而RobotFramework對中文的支持也很好。但是如果從可用性的角度考慮，RobotFramework會(huì )比Cucumber好一些。原因是Cucumber本身并沒(méi)有專(zhuān)用的IDE，只能求助于其它IDE插件，這些插件可以完成高亮、自動(dòng)補全和Step Definition跳轉等功能，但一旦使用了中文，有些功能就不好用了。而在RIDE中就不存在這個(gè)問(wèn)題。所以如果你的團隊因為某種原因對于中文用例的需求很旺盛，可以考慮RobotFramework。
如果重新選擇，我還是會(huì )選擇RobotFramework，主要從兩個(gè)方面進(jìn)行考慮：一方面是因為其“不用寫(xiě)代碼”的方式更容易被測試人員接受，另一方面是對中文的支持更好。
通過(guò)上面四個(gè)案例，展示了在不同的項目中實(shí)際使用Cucumber和RobotFramework時(shí)的一些經(jīng)驗和選擇它們的理由。但對于Cucumber和RobotFramework更多的知識點(diǎn)，下面有一個(gè)更為詳細的對比表。
|
| Cucumber | RobotFramework |
| 亮點(diǎn) |
|
|
| 不足
|
|
|
| Jenkins支持 | 支持 | 支持 |
| Maven支持 | 支持 | 支持 |
| 開(kāi)發(fā)效率 | 高效-Jetbrains系列的IDE | 高效-RIDE和Jetbrains系列的IDE |
| 商業(yè)支持 | 支持18 | 無(wú) |
| 社區支持 | 廣泛 | 廣泛 |
在上述的實(shí)戰案例中，針對項目的具體情況我們對Cucumber和RobotFramework這兩種工具進(jìn)行了取舍。本節就來(lái)總結一下這些取舍的考慮因素。
首先來(lái)看一下自動(dòng)化驗收測試的層次：
然后對每層進(jìn)行分析：
以上這些點(diǎn)是從RobotFramework和Cucumber的對比中總結出來(lái)的，但如果你想要選擇這兩者之外的其他框架，同樣可以考慮上述這些原則。
我們在銀行、保險、社交、電信、物流、互聯(lián)網(wǎng)等項目上實(shí)施過(guò)自動(dòng)化功能以及驗收測試。對于Cucumber和RobotFramework到底屬于A(yíng)TDD還是BDD，這里不做過(guò)多的討論，因為當前在業(yè)界對于A(yíng)TDD和BDD怎么區分還有一些爭議，而對于我們來(lái)講，它們只不過(guò)是兩個(gè)名詞而已。對于這兩個(gè)工具本身來(lái)講，只需要清楚它們各自的特點(diǎn)，根據項目本身的情況和需求選擇就可以了，簡(jiǎn)單地說(shuō)就是：知行合一。
給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過(guò)新浪微博（@InfoQ）或者騰訊微博（@InfoQ）關(guān)注我們，并與我們的編輯和其他讀者朋友交流。
相關(guān)內容
hmm... 2015年3月16日 12:34 by Steven Mak
Re: hmm... 2015年3月17日 05:12 by Liu Ran
Re: hmm... 2015年3月31日 02:05 by Zeng Neil
Re: hmm... 2015年3月31日 04:41 by Liu Ran
聯(lián)系客服
