軟件測試自動化成功的7個步驟(4)

　　下面是一些候選的驗證概念的試驗：

　　回歸測試：你準備在每個版本運行同樣的測試用例嗎?回歸測試是最宜采用自動化測試的環節。

　　配置測試：你的軟件支持多少種不同的平臺?你打算在所有支持的平臺上測試執行所有的測試用例嗎?如果是的，那么采用自動化測試是有幫助的。

　　測試環境建立：對于大量不同的測試用例，可能需要相同的測試環境搭建過程。在開展自動化測試執行之前，先把測試環境搭建實現自動化。

　　非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測試自動化可以正常工作。無論你選擇哪種方法，自動化都需要對被測試的產品做修改。因此，采用可編程的接口是最可靠的。

　　為了讓API接口測試更為容易，應該把接口與某種解釋程序，例如Tcl、Perl或者Python綁定在一起。這使交互式測試成為可能，并且可以縮短自動化測試的開發周期。采用API接口的方式，還可以實現獨立的產品模塊的單元測試自動化。

　　一個關于隱藏可編程接口的例子是關于InstallShield——非常流行的制作安裝盤的工具。InstallShield有命令行選項，采用這種選項可以實現非GUI方式的安裝盤，采用這種方式，從提前創建好的文件中讀取安裝選項。這種方式可能比采用GUI的安裝方式更簡單更可靠。

　　另一個例子是關于如何避免基于WEB軟件的GUI自動化測試。采用GUI測試工具可以通過瀏覽器操作WEB界面。WEB瀏覽器是通過HTTP協議與WEB服務器交互的，所以直接測試HTTP協議更為簡單。Perl可以直接連接TCP/IP端口，完成這類的自動化測試。采用高級接口技術，譬如客戶端JAVA或者ActiveX不可能利用這種方法。但是，如果在合適的環境中采用這種方式，你將發現這種方式的自動化測試比GUI自動化測試更加便宜更加簡單。

　　我曾經受雇在一家公司負責某個產品GUI相關的自動化測試，該產品也提供命令行接口，不過，他們已經實現了GUI的自動化測試。經過一段時間的研究，我發現找到圖形界面中的BUG并不困難，不過，用戶并不關注圖形界面，他們更喜歡使用命令行。我還發現我們還沒有針對最新的產品功能(這些功能即可通過GUI的方式，也可以通過命令行的方式使用)實現自動化測試。我決定推遲GUI自動化測試，擴展命令行測試套，測試新增的產品功能?，F在回過頭看這個決定，我沒有選擇GUI自動化測試是最大的成功之處，如果采用了GUI自動化測試所有的時間和努力都會浪費在其中。他們已經準備好做GUI自動化測試了，并且已經購買了一套測試工具和其他需要的東西，但我知道在開展具體的GUI自動化測試活動中，會遇到各種各樣的困難和障礙。

　　無論你需要支持圖形界面接口、命令行接口還是API接口，如果你盡可能早的在產品設計階段提出產品的可測試性設計需求，未來的測試工作中，你很可能成功。盡可能早的啟動自動化測試項目，提出可測試性需求，會使您走向自動化測試成功之路。

原文轉自：http://www.anti-gravitydesign.com