【轉】Robot Framework做者建議如何選擇自動化測試框架

原文：http://www.infoq.com/cn/news/2012/06/robot-author-suggest-autotest 

 

軟件自動化測試，做爲手工測試的替代，愈來愈受到關注。Pekka Klärck，做爲Robot Framework的建立者和核心開發者，按照系統級別，介紹了幾種不一樣的自動化測試方法的區別。

1、記錄回放的方式流行於商業工具之中，無需編程技能便可快速上手。然而這種方法相對脆弱，一旦UI變化測試就會受到影響，分散的腳本不可重用且難以維護，並且系統在測試前必須可用（也就意味着沒法使用A-TDD方法）。所以這種方法並不適合大型自動化測試。

2、線性腳本容許使用各類語言來編寫非結構化腳本，腳本直接與被測系統交互。可以快速上手，靈活性強。可是編寫腳本須要編程技能，系統中一個改動會影響全部腳本，沒有通過模塊化或重用的大量腳本難以維護。所以這種方法適合簡單任務，不適合大型自動化。

3、模塊化腳本由兩部分組成：驅動腳本執行測試，測試庫函數完成與被測系統交互。驅動腳本編寫起來很是簡單，這樣能夠更快地創建新測試，容易維護。然而須要花時間和編程技能創建測試庫，並將測試數據嵌入腳本，創建新測試就須要新的測試腳本。所以，只要擁有編程技能，這種方法仍是適合大型項目，但不適合非編程人員。

4、數據驅動方法，將數據與測試腳本分離，基於模塊化的測試庫，一個驅動腳本能夠執行多個類似測試，這樣很是容易創建新測試。維護工做能夠分離，測試人員負責數據，程序員負責寫測試庫。然而，不一樣類型測試仍須要新的驅動腳本，初始創建數據解析器和重用組件須要花人力。這種方法適合大型項目，只須要較少的編程技能。

5、關鍵字驅動，將數據與關鍵字結合來描述如何使用數據執行測試。這種方法具有數據驅動的優點，同時非編程人員也能創建新類型測試。全部測試由同一個框架來執行，無需不一樣的驅動腳本。然而初始成本很大，可是可使用開源方案！所以很是適合大型項目。

Pekka對以上五種方法的介紹其實也是對自動化測試發展史的介紹，同時也體現了RobotFramework背後的設計思想。

除了測試框架的選擇，要想作好自動化測試，還要關注其餘方面。

自動化測試須要關注可測性。自動化最難的部分是與被測系統交互，特別是GUI層。確保系統容易被測試，好比給GUI元素增長標識、輸出易於解析的文本、提供自動化接口等。

系統通常能夠分爲GUI層以及GUI之下的業務層。GUI層測試須要調用與普通用戶一樣的接口，可是某些GUI技術缺少好的工具支持，會使測試變得脆弱，並且執行相對較慢。從業務層開始測試相對容易，執行快。但GUI層仍然須要被測試，以保證GUI正確鏈接到了業務層，甚至有時GUI層也具備業務功能。Pekka建議考慮對業務層進行徹底測試，而部分地對GUI層實行端到端測試。 不是全部系統都具備GUI層，卻可能具備API、數據庫、服務器、命令行等。自動化測試框架能夠調用不一樣驅動來進行測試。這些非GUI層相對容易測試，只要把測試用例看做另外一個客戶端而已。

那麼自動化測試應該在什麼階段進行？若是開發完成後單獨作自動化，這是典型的瀑布式過程，不一樣團隊之間存在溝通障礙，反饋週期慢，產品在後期難以得到可測性，從而致使複雜和脆弱的測試方案。相反，典型敏捷式過程當中，程序員和測試人員協同完成自動化。把自動化看做團隊開發的一部分，可測性再也不是問題，團隊作技術決定時就能夠考慮可測性和工具選擇，程序員能夠提早加入提供可測性的鉤子特性。

自動化測試須要版本控制和持續集成來支持。將測試和代碼放在一塊兒，像管理代碼同樣管理測試腳本，那麼多可用工具，SVN、GIT、Mercurial，沒道理不用。持續集成是全方位自動化的關鍵，當測試或代碼有所改動當即執行測試。若是測試運行時間比較長，也能夠按期運行。使用Jenkins、Hudson、Cruise Control、 BuildBot吧，本身寫定時腳本或Cron Job能夠休矣。

選擇商業自動化工具仍是開源工具？好東西確定貴，可是貴的不見得好，再便宜的許可證也會阻止整個團隊的協做。並且商業化工具難以和其餘自動化工具（特別是其餘廠商的）或版本控制、持續集成進行整合和定製化。另外，產品終止或公司關門是潛在的風險。開源工具可供選擇餘地很大，固然也是參差不齊。開源工具一般容易與其餘工具整合，關鍵是免費，誰均可以隨意使用和定製化，還永遠不會消失。至於免費軟件，愈來愈少了，不少自由軟件都已經開源。免費軟件一樣不能定製化，且存在停止的風險。

作自動化須要哪些技能？通常來講，包括Python、Ruby、Perl、JavaScript、正則表達式、XPath和CSS定位、SQL語句、版本控制等。

有了自動化，手工測試還須要嗎？固然須要！！ 不過，要避免手工執行腳原本測試，仍是將其徹底自動化吧，測試人員能夠更多關注於探索性測試。 記住，機器擅長迴歸測試，人類善於尋找Bug。