自動化測試的7個步驟

領測軟件測試網

　　當然，不同的情況下，有的自動化測試目標比較容易達到，有的則比較難以達到。測試自動化往往對測試人員的技術水平要求很高，測試人員必須能理解充分的理解自動化測試，從而通過自動化測試不斷發現軟件的缺陷。不過，自動化測試不利于測試人員不斷的積累測試經驗。不管怎么樣，在開始自動化測試之前應該確定自動化測試成功的標準。  

　　手工測試人員在測試執行過程中的一些操作能夠發現不引人注意的問題。他們計劃并獲取必要的測試資源，建立測試環境，執行測試用例。測試過程中，如果有什么異常的情況發生，手工測試人員立刻可以關注到。他們對比實際測試結果和預期測試結果，記錄測試結果，復位被測試的軟件系統，準備下一個軟件測試用例的環境。他們分析各種測試用例執行失敗的情況，研究測試過程可疑的現象，尋找測試用例執行失敗的過程，設計并執行其他的測試用例幫助定位軟件缺陷。接下來，他們寫作缺陷報告單，保證缺陷被修改，并且總結所有的缺陷報告單，以便其他人能夠了解測試的執行情況。  

　　千萬不要強行在測試的每個部分都采用自動化方式。尋找能夠帶來最大回報的部分，部分的采用自動化測試是最好的方法�；蛟S你可能發現采用自動化執行和手動確認測試執行結果的方式是個很好的選擇，或許你可以采用自動化確認測試結果和手工測試執行相結合和方式。我聽到有人講，除非測試的各個環節都采用自動化方式，否則不是真正意義上的自動化測試，這真是胡言亂語。如果僅僅是為了尋找挑戰，可以嘗試在測試的每個環節都采用自動化方法。但是，如果尋找成功測試的方法，請關注那些可以快速建立的，可以反復利用的自動化測試。  

　　定義自動化測試項目的需求要求我們全面地、清楚地考慮各種情況，然后給出權衡后的需求，并且可以使測試相關人員更加合理的提出自己對自動化測試的期望。通過定義自動化測試需求，距離成功的自動化測試近了一步。  

　　步驟三：驗證概念  

　　在前面的故事當中，那個自動化測試人員在對測試方向一片茫然的情況下一頭扎進了自動化測試項目中。不過，在項目的進行中，他得到了來自各個方面的支持。  

　　你可能還沒有認識到這一點，不過，你必須驗證自動化測試項目的可行性。驗證過程花費的時間往往比人們預期的要長，并且需要來自你身邊的各種人的幫助。  

　　很多年前，我從事一個測試自動化項目的工作，參加項目的人員有各種各樣的好點子。我們設計了一個復雜的自動化測試系統，并且非常努力工作去實現系統的每個模塊。我們定期的介紹測試自動化的設計思路和工作進度，甚至演示已經完成的部分功能。但是，我們沒有演示如何利用該套測試自動化系統如何開展實際的測試工作。最后，整個項目被取消了，此后，我再也沒有犯這個錯誤。  

　　你需要盡可能快地驗證你采用的測試工具和測試方法的可行性，站在產品的角度驗證你所測試的產品采用自動化測試的可行性。這通常是很困難的，需要盡快地找出可行性問題的答案，需要確定你的測試工具和測試方法對于被測試的產品和測試人員是否合適。你需要做是驗證概念 —— 一個快速、有說服力的測試套可以證明你選在測試工具和測試方法的正確性，從而驗證了你的測試概念。你選擇的用來驗證概念的測試套是評估測試工具的最好的方式。  

　　對于很多人來說，自動化測試意味著 GUI 自動化測試，我不同意這種觀點。我曾經做過 GUI 和非 GUI 自動化測試，并驚奇的發現這兩類測試的測試計劃有很大的互補性。不過， GUI 測試工具很昂貴、并且過分講究。選擇合適的 GUI 測試工具是很重要的，因為，如果沒有選擇合適的測試工具，你會遇到很多不可預測的困難。 Elisabeth Hendrickson 曾經寫過一篇關于選擇測試的工具的指導性文章 [Hendrickson 1999] 。我建議在評估測試工具中，找出能夠驗證你的想法的證據是很重要的環節。這需要測試工具至少有一個月試用期，你可能打算現在購買一份測試工具，然后直到評估完成后再購買更多份。你需要在付出大筆金錢購買測試工具的之前，找出工具存在的問題。這樣，你可以從測試工具供應商得到更好的幫助，當你打算更換工具的時候，你不會感覺很為難。  

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

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

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

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

　　非 GUI 測試：實現命令行和 API 的測試自動化比 GUI 自動化測試容易的多。  

　　無論采用什么測試方法，定義一個看得見的目標，然后集中在這個目標上。驗證你自動化測試概念可以使自動化更進一步邁向成功之路。  

　　步驟四：支持產品的可測試性  

　　軟件產品一般會用到下面三種不同類別的接口：命令行接口（ command line interfaces ，縮寫 CLIs) 、應用程序接口（ API ）、圖形用戶接口（ GUI ）。有些產品會用到所有三類接口，有些產品只用到一類或者兩類接口，這些是測試中所需要的接口。從本質上看， API 接口和命令行接口比 GUI 接口容易實現自動化，去找一找你的被測產品是否包括 API 接口或者命令行接口。有些時候，這兩類接口隱藏在產品的內部，如果確實沒有，需要鼓勵開發人員在產品中提供命令行接口或者 API 接口，從而支持產品的可測試性。  

　　下面，更多多的講解 GUI 自動化測試相關內容。這里有幾個原因導致 GUI 自動化測試比預期的要困難。第一個原因是需要手工完成部分腳本。絕大多數自動化測試工具都有 “ 錄制回放 ” 或者 “ 捕捉回放 ” 功能，這確實是個很好的方法�？梢允止�執行測試用例，測試工具在后臺記住你的所有操作，然后產生可以用來重復執行的測試用例腳本。這是一個很好的方法，但是很多時候卻不能奏效。很多軟件測試文章的作者得出結論 “ 錄制回放 ” 雖然可以生成部分測試腳本，但是有很多問題導致 “ 錄制回放 ” 不能應用到整個測試執行過程中。 [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 自動化測試是不會有任何進展的，你只能花費大量的時間修改測試腳本，以適應圖形界面的變更。不管怎樣，即便界面的修改會導致測試修改腳本，你也不應該反對開發人員改進圖形界面。一旦原始的設計完成后，圖形界面接口下面的編程接口就固定下來了。  

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 自動測試