軟件自動化測試,作為手工測試的替代,越來越受到關注。Pekka Klärck,作為Robot Framework的創建者和核心開發者,按照系統級別,介紹了幾種不同的自動化測試方法的區別。
一、記錄回放的方式流行于商業工具之中,無需編程技能即可快速上手。然而這種方法相對脆弱,一旦UI變化測試就會受到影響,分散的腳本不可重用且難以維護,而且系統在測試前必須可用(也就意味著無法使用A-TDD方法)。因此這種方法并不適合大型自動化測試。
二、線性腳本允許使用各種語言來編寫非結構化腳本,腳本直接與被測系統交互。能夠快速上手,靈活性強。但是編寫腳本需要編程技能,系統中一個改動會影響所有腳本,沒有經過模塊化或重用的大量腳本難以維護。因此這種方法適合簡單任務,不適合大型自動化。
三、模塊化腳本由兩部分組成:驅動腳本執行測試,測試庫函數完成與被測系統交互。驅動腳本編寫起來非常簡單,這樣可以更快地建立新測試,容易維護。然而需要花時間和編程技能建立測試庫,并將測試數據嵌入腳本,建立新測試就需要新的測試腳本。因此,只要擁有編程技能,這種方法還是適合大型項目,但不適合非編程人員。
四、數據驅動方法,將數據與測試腳本分離,基于模塊化的測試庫,一個驅動腳本可以執行多個相似測試,這樣非常容易建立新測試。維護工作可以分離,測試人員負責數據,程序員負責寫測試庫。然而,不同類型測試仍需要新的驅動腳本,初始建立數據解析器和重用組件需要花人力。這種方法適合大型項目,只需要較少的編程技能。
五、關鍵字驅動,將數據與關鍵字結合來描述如何使用數據執行測試。這種方法具備數據驅動的優勢,同時非編程人員也能建立新類型測試。所有測試由同一個框架來執行,無需不同的驅動腳本。然而初始成本很大,但是可以使用開源方案!因此非常適合大型項目。
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