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

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

　　為了讓 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 自動化測試活動中，會遇到各種各樣的困難和障礙。

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