對于很多人來說,自動化測試意味著 GUI 自動化測試,我不同意這種觀點。我曾經做過 GUI 和非 GUI 自動化測試,并驚奇的發現這兩類測試的測試計劃有很大的互補性。不過, GUI 測試工具很昂貴、并且過分講究。選擇合適的 GUI 測試工具是很重要的,因為,如果沒有選擇合適的測試工具,你會遇到很多不可預測的困難。 Elisabeth Hendrickson 曾經寫過一篇關于選擇測試的工具的指導性文章 [Hendrickson 1999] 。我建議在評估測試工具中,找出能夠驗證你的想法的證據是很重要的環節。這需要測試工具至少有一個月試用期,你可能打算現在購買一份測試工具,然后直到評估完成后再購買更多份。你需要在付出大筆金錢購買測試工具的之前,找出工具存在的問題。這樣,你可以從測試工具供應商得到更好的幫助,當你打算更換工具的時候,你不會感覺很為難。
下面是一些候選的驗證概念的試驗:
回歸測試:你準備在每個版本運行同樣的測試用例嗎?回歸測試是最宜采用自動化測試的環節。
配置測試:你的軟件支持多少種不同的平臺?你打算在所有支持的平臺上測試執行所有的測試用例嗎?如果是的,那么采用自動化測試是有幫助的。
測試環境建立:對于大量不同的測試用例,可能需要相同的測試環境搭建過程。在開展自動化測試執行之前,先把測試環境搭建實現自動化。
非 GUI 測試:實現命令行和 API 的測試自動化比 GUI 自動化測試容易的多。
步驟四:支持產品的可測試性
軟件產品一般會用到下面三種不同類別的接口:命令行接口( command line interfaces ,縮寫 CLIs) 、應用程序接口( API )、圖形用戶接口( GUI )。有些產品會用到所有三類接口,有些產品只用到一類或者兩類接口,這些是測試中所需要的接口。從本質上看, API 接口和命令行接口比 GUI 接口容易實現自動化,去找一找你的被測產品是否包括 API 接口或者命令行接口。有些時候,這兩類接口隱藏在產品的內部,如果確實沒有,需要鼓勵開發人員在產品中提供命令行接口或者 API 接口,從而支持產品的可測試性。
下面,更多多的講解 GUI 自動化測試相關內容。這里有幾個原因導致 GUI 自動化測試比預期的要困難。第一個原因是需要手工完成部分腳本。絕大多數自動化測試工具都有 “ 錄制回放 ” 或者 “ 捕捉回放 ” 功能,這確實是個很好的方法??梢允止绦袦y試用例,測試工具在后臺記住你的所有操作,然后產生可以用來重復執行的測試用例腳本。這是一個很好的方法,但是很多時候卻不能奏效。很多軟件測試文章的作者得出結論 “ 錄制回放 ” 雖然可以生成部分測試腳本,但是有很多問題導致 “ 錄制回放 ” 不能應用到整個測試執行過程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 結果, GUI 測試還是主要由手工完成。
第二個原因,把 GUI 自動化測試工和被測試的產品有機的結合在一起需要面臨技術上的挑戰。經常要在采用眾多專家意見和最新的 GUI 接口技術才能使 GUI 測試工具正常工作。這個主要的困難也是 GUI 自動化測試工具價格昂貴的主要原因之一。非標準的、定制的控件會增加測試的困難,解決方法總是有的,可以采用修改產品源代碼的方式,也可以從測試工具供應商處升級測試工具。另外,還需要分析測試工具中的 BUG ,并且給工具打補丁。也可能測試工具需要做相當的定制,以便能有效地測試產品界面上的定制控件。 GUI 測試中,困難總是意外出現,讓人驚奇。你也可能需要重新設計你的測試以規避那些存在問題的界面控件。
第三個原因, GUI 設計方案的變動會直接帶來 GUI 自動化測試復雜度的提高。在開發的整個過程中,圖形界面經常被修改或者完全重設計,這是出了名的事情。一般來講,第一個版本的圖形界面都是很糟糕。如果處在圖形界面方案不停變動的時候,就開展 GUI 自動化測試是不會有任何進展的,你只能花費大量的時間修改測試腳本,以適應圖形界面的變更。不管怎樣,即便界面的修改會導致測試修改腳本,你也不應該反對開發人員改進圖形界面。一旦原始的設計完成后,圖形界面接口下面的編程接口就固定下來了。
上面提到的這些原因都是基于采用 GUI 自動化測試的方法完成產品的功能測試。圖形界面接口當然需要測試,可以考慮實現 GUI 測試自動化。不過,你也應該考慮采用其他方法測試產品的核心功能,并且這些測試不會因為圖形界面發生變化而被中斷,這類測試應該采用命令行接口或者 API 接口。我曾經看到有人選擇 GUI 自動化測試,因為,他們不打算修改被測試產品,但是,最終他們認識到必須對產品做修改,以保證 GUI 測試自動化可以正常工作。無論你選擇哪種方法,自動化都需要對被測試的產品做修改。因此,采用可編程的接口是最可靠的。
原文轉自:http://www.uml.org.cn/Test/201312093.asp