【文章內容簡介】 系統(tǒng)的情況下，大幅度的提高測試效率。改進軟件測試過程會花費你構建自動化測試系統(tǒng)的時間，不過改進測試過程無疑可以使你的自動化測試項目更為順利開展起來。 步驟二：定義需求 在前面的故事中，自動化工程師和自動化測試的發(fā)起者的目標存在偏差。為了避免這種情況，需要在自動化測試需求上保持一致。應該有一份自動化測試需求，用來描述需要測試什么。測試需求應該在測試設計階段詳細描述出來，自動化測試需求描述了自動化測試的目標。很多人認為自動化測試顯然是一件好事情，但是，他們不愿意對自動化測試的目標給出清晰的描述。下面是人們選用自動化測試的幾個原因： ? 加快測試進度從而加快產(chǎn)品發(fā)布進度 ? 更多的測試 ? 通過減少手工測試降低測試成本 ? 提高測試覆蓋率 ? 保證一致性 ? 提高測試的可靠性 ? 測試工作可以由技術能力不強測試人員完成 ? 定義測試過程，避免過分依賴個人 ? 測試變得更加有趣 ? 提高了編程技能 開發(fā)管理、測試管理和測試人員實現(xiàn)自動化測試的目標常常是有差別的。除非三者之間達成一致，否則很難定義什么是成功的自動化測試。 當然，不同的情況下，有的自動化測試目標比較容易達到，有的則比較難以達到。測試自動化往往對測試人員的技術水平要求很高，測試人員必須能理解充分的理解自動化測試，從而通過自動化測試不斷發(fā)現(xiàn)軟件的缺陷。不過，自動化測試不利于測試人員不斷的積累測試經(jīng)驗。不管怎么樣，在開始自動化測試之前應該確定自動化測試成功的標準。 手工測試人員在測試執(zhí)行過程中的一些操作能夠發(fā)現(xiàn)不引人注意的問題。他們計劃并獲取必要的測試資源，建立測試環(huán)境，執(zhí)行測試用例。測試過程中，如果有什么異常的情況發(fā)生，手工測試人員立刻可以關注到。他們對比實際測試結果和預期測試結果，記錄測試結果，復位被測試的軟件系統(tǒng)，準備下一個軟件測試用例的環(huán)境。他們分析各種測試用例執(zhí)行失敗的情況，研究測試過程可疑的現(xiàn)象，尋找測試用例執(zhí)行失敗的過程，設計并執(zhí)行其他的測試用例幫助定位軟件缺陷。接下來，他們寫作缺陷報告單，保證缺陷被修改，并且總結所有的缺陷報告單，以便其他人能夠了解測試的執(zhí)行情況。 千萬不要強行在測試的每個部分都采用自動化方式。尋找能夠帶來最大回報的部分，部分的采用自動化測試是最好的方法。或許你可能發(fā)現(xiàn)采用自動化執(zhí)行和手動確認測試執(zhí)行結果的方式是個很好的選擇，或許你可以采用自動化確認測試結果和手工測試執(zhí)行相結合和方式。我聽到有人講，除非測試的各個環(huán)節(jié)都采用自動化方式，否則不是真正意義上的自動化測試，這真是胡言亂語。如果僅僅是為了尋找挑戰(zhàn)，可以嘗試在測試的每個環(huán)節(jié)都采用自動化方法。但是，如果尋找成功測試的方法，請關注那些可以快速建立的，可以反復利用的自動化測試。 定義自動化測試項目的需求要求我們全面地、清楚地考慮各種情況，然后給出權衡后的需求，并且可以使測試相關人員更加合理的提出自己對自動化測試的期望。通過定義自動化測試需求，距離成功的自動化測試近了一步。 步驟三：驗證概念 在前面的故事當中，那個自動化測試人員在對測試方向一片茫然的情況下一頭扎進了自動化測試項目中。不過，在項目的進行中，他得到了來自各個方面的支持。 你可能還沒有認識到這一點，不過，你必須驗證自動化測試項目的可行性。驗證過程花費的時間往往比人們預期的要長，并且需要來自你身邊的各種人的幫助。 很多年前，我從事一個測試自動化項目的工作，參加項目的人員有各種各樣的好點子。我們設計了一個復雜的自動化測試系統(tǒng)，并且非常努力工作去實現(xiàn)系統(tǒng)的每個模塊。我們定期的介紹測試自動化的設計思路和工作進度，甚至演示已經(jīng)完成的部分功能。但是，我們沒有演示如何利用該套測試自動化系統(tǒng)如何開展實際的測試工作。最后，整個項目被取消了，此后，我再也沒有犯這個錯誤。 你需要盡可能快地驗證你采用的測試工具和測試方法的可行性，站在產(chǎn)品的角度驗證你所測試的產(chǎn)品采用自動化測試的可行性。這通常是很困難的，需要盡快地找出可行性問題的答案，需要確定你的測試工具和測試方法對于被測試的產(chǎn)品和測試人員是否合適。你需要做是驗證概念 —— 一個快速、有說服力的測試套可以證明你選在測試工具和測試方法的正確性，從而驗證了你的測試概念。你選擇的用來驗證概念的測試套是評估測試工具的最好的方式。 對于很多人來說，自動化測試意味著 GUI 自動化測試，我不同意這種觀點。我曾經(jīng)做過 GUI 和非 GUI 自動化測試，并驚奇的發(fā)現(xiàn)這兩類測試的測試計劃有很大的互補性。不過， GUI 測試工具很昂貴、并且過分講究。選擇合適的 GUI 測試工具是很重要的，因為，如果沒有選擇合適的測試工具，你會遇到很多不可預測的困難。 Elisabeth Hendrickson 曾經(jīng)寫過一篇關于選擇測試的工具的指導性文章 [Hendrickson 1999] 。我建議在評估測試工具中，找出能夠驗證你的想法的證據(jù)是很重要的環(huán)節(jié)。這需要測試工具至少有一個月試用期，你可能打算現(xiàn)在購買一份測試工具，然后直到評估完成后再購買更多份。你需要在付出大筆金錢購買測試工具的之前，找出工具存在的問題。這樣，你可以從測試工具供應商得到更好的幫助，當你打算更換工具的時候，你不會感覺很為難。 下面是一些候選的驗證概念的試驗： 回歸測試：你準備在每個版本運行同樣的測試用例嗎？回歸測試是最宜采用自動化測試的環(huán)節(jié)。 配置測試：你的軟件支持多少種不同的平臺？你打算在所有支持的平臺上測試執(zhí)行所有的測試用例嗎？如果是的，那么采用自動化測試是有幫助的。 測試環(huán)境建立：對于大量不同的測試用例，可能需要相同的測試環(huán)境搭建過程。在開展自動化測試執(zhí)行之前，先把測試環(huán)境搭建實現(xiàn)自動化。 非 GUI 測試：實現(xiàn)命令行和 API 的測試自動化比 GUI 自動化測試容易的多。 無論采用什么測試方法，定義一個看得見的目標，然后集中在這個目標上。驗證你自動化測試概念可以使自動化更進一步邁向成功之路。 步驟四：支持產(chǎn)品的可測試性 軟件產(chǎn)品一般會用到下面三種不同類別的接口：命令行接口（ mand line interfaces ，縮寫 CLIs) 、應用程序接口（ API ）、圖形用戶接口（ GUI ）。有些產(chǎn)品會用到所有三類接口，有些產(chǎn)品只用到一類或者兩類接口，這些是測試中所需要的接口。從本質上看， API 接口和命令行接口比 GUI 接口容易實現(xiàn)自動化，去找一找你的被測產(chǎn)品是否包括 API 接口或者命令行接口。有些時候，這兩類接口隱藏在產(chǎn)品的內部，如果確實沒有，需要鼓勵開發(fā)人員在產(chǎn)品中提供命令行接口或者 API 接口，從而支持產(chǎn)品的可測試性。 下面，更多多的講解 GUI 自動化測試相關內容。這里有幾個原因導致 GUI 自動化測試比預期的要困難。第一個原因是需要手工完成部分腳本。絕大多數(shù)自動化測試工具都有 “ 錄制回放 ” 或者 “ 捕捉回放 ” 功能，這確實是個很好的方法。可以手工執(zhí)行測試用例，測試工具在后臺記住你的所有操作，然后產(chǎn)生可以用來重復執(zhí)行的測試用例腳本。這是一個很好的方法，但是很多時候卻不能奏效。很多軟件測試文章的作者得出結論 “ 錄制回放 ” 雖然可以生成部分測試腳本，但是有很多問題導致 “ 錄制回放 ” 不能應用到整個測試執(zhí)行過程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 結果， GUI 測試還是主要由手工完成。 第二個原因，把 GUI 自動化測試工和被測試的產(chǎn)品有機的結合在一起需要面臨技術上的挑戰(zhàn)。經(jīng)常要在采用眾多專家意見和最新的 GUI 接口技術才能使 GUI 測試工具正常工作。這個主要的困難也是 GUI 自動化測試工具價格昂貴的主要原因之一。非標準的、定制的控件會增加測試的困難，解決方法總是有的，可以采用修改產(chǎn)品源代碼的方式，也可以從測試工具供應商處升級測試工具。另外，還需要分析測試工具中的 BUG ，并且給工具打補丁。也可能測試工具需要做相當?shù)亩ㄖ?，以便能有效地測試產(chǎn)品界面上的定制控件。 GUI 測試中，困難總是意外出現(xiàn)，讓人驚奇。你也可能需要重新設計你的測試以規(guī)避那些存在問題的界面控件。 第三個原因， GUI 設計方案的變動會直接帶來 GUI 自動化測試復雜度的提高。在開發(fā)的整個過程中，圖形界面經(jīng)常被修改或者完全重設計，這是出了名的事情。一般來講，第一個版本的圖形界面都是很糟糕。如果處在圖形界面方案不停變動的時候，就開展 GUI 自動化測試是不會有任何進展的，你只能花費大量的時間修改測試腳本，以適應圖形界面的變更。不管怎樣，即便界面的修改會導致測試修改腳本，你也不應該反對開發(fā)人員改進圖形界面。一旦原始的設計完成后，圖形界面接口下面的編程接口就固定下來了。 上面提到的這些原因都是基于采用 GUI 自動化測試的方法完成產(chǎn)品的功能測試。圖形界面接口當然需要測試，可以考慮實現(xiàn) GUI 測試自動化。不過，你也應該考慮采用其他方法測試產(chǎn)品的核心功能，并且這些測試不會因為圖形界面發(fā)生變化而被中斷，這類測試應該采用命令行接口或者 API 接口。我曾經(jīng)看到有人選擇 GUI 自動化測試，因為，他們不打算修改被測試產(chǎn)品，但是，最終他們認識到必須對產(chǎn)品做修改，以保證 GUI 測試自動化可以正常工作。無論你選擇哪種方法，自動化都需要對被測試的產(chǎn)品做修改。因此，采用可編程的接口是最可靠的。 為了讓 API 接口測試更為容易，應該把接口與某種解釋程序，例如 Tcl 、 Perl 或者 Python 綁定在一起。這使交互式測試成為可能，并且可以縮短自動化測試的開發(fā)周期。采用 API 接口的方式，還可以實現(xiàn)獨立的產(chǎn)品模塊的單元測試自動化。 一個關于隱藏可編程接口的例子是關于 InstallShield—— 非常流行的制作安裝盤的工具。 InstallShield 有命令行選項，采用這種選項可以實現(xiàn)非 GUI 方式的安裝盤，采用這種方式，從提前創(chuàng)建好的文件中讀取安裝選項。這種方式可能比采用 GUI 的安裝方式更簡單更可靠。 另一個例子是關于如何避免基于 WEB 軟件的 GUI 自動化測試。采用 GUI 測試工具可以通過瀏覽器操作 WEB 界面。 WEB 瀏覽器是通過 HTTP 協(xié)議與 WEB 服務器交互的，所以直接測試 HTTP 協(xié)議更為簡單。 Perl 可以直接連接 TCP/IP 端口，完成這類的自動化測試。采用高級接口技術，譬如客戶端 JAVA 或者 ActiveX 不可能利用這種方法。但是，如果在合適的環(huán)境中采用這種方式，你將發(fā)現(xiàn)這種方式的自動化測試比 GUI 自動化測試更加便宜更加簡單。 我曾經(jīng)受雇在一家公司負責某個產(chǎn)品 GUI 相關的自動化測試，該產(chǎn)品也提供命令行接口，不過，他們已經(jīng)實現(xiàn)了 GUI 的自動化測試。經(jīng)過一段時間的研究，我發(fā)現(xiàn)找到圖形界面中的 BUG 并不困難，不過，用戶并不關注圖形界面，他們更喜歡使用命令行。我還發(fā)現(xiàn)我們還沒有針對最新的產(chǎn)品功能（這些功能即可通過 GUI 的方式，也可以通過命令行的方式使用）實現(xiàn)自動化測試。我決定推遲 GUI 自動化測試，擴展命令行測試套，測試新增的產(chǎn)品功能?，F(xiàn)在回過頭看這個決定，我沒有選擇 GUI 自動化測試是最大的成功之處，如果采用了 GUI 自動化測試所有的時間和努力都會浪費在其中。他們已經(jīng)準備好做 GUI 自動化測試了，并且已經(jīng)購買了一套測試工具和其他需要的東西，但我知道在開展具體的 GUI 自動化測試活動中，會遇到各種各樣的困難和障礙。 無論你需要支持圖形界面接口、命令行接口還是 API 接口，如果你盡可能早的在產(chǎn)品設計階段提出產(chǎn)品的可測試性設計需求，未來的測試工作中，你很可能成功。盡可能早的啟動自動化測試項目，提出可測試性需求，會使您走向自動化測試成功之路。 步驟五：具有可延續(xù)性的設計 在開篇的故事中，我們看到由于自動化工程師把注意力僅僅集中在如何使自動化運轉起來，導致測試自動化達不到預期的效果。自動化測試是一個長期的過程，為了與產(chǎn)品新版本的功能和其他相關修改保持一致，自動化測試需要不停的維護和擴充。自動化測試設計中考慮自動化在未來的可擴充性是很關鍵的，不過，自動化測試的完整性也是很重要的。如果自動化測試程序報告測試用例執(zhí)行通過，測試人員應該相信得到的結果，測試執(zhí)行的實際結果也應該是通過了。其實，有很多存在問題的測試用例表面上執(zhí)行通過了，實際上卻執(zhí)行失敗了，并且沒有記錄任何錯誤日志，這就是失敗的自動化。這種失敗的自動化會給整個項目帶來災難性的后果，而當測試人員構建的測試自動化采用了很糟糕的設計方案或者由于后來的修改引入了錯誤，都會導致這種失敗的測試自動化。失敗的自動化通常是由于沒有關注自動化測試的性能或者沒有充分的自動化設計導致的。 性能： 提高代碼的性能往往增加了代碼的復雜性，因此，會威脅到代碼的可靠性。很少有人關心如何對自動化本身加以測試。通過我對測試套性能的分析，很多測試套都是花費大量的時間等候產(chǎn)品的運行。因此，在不提高產(chǎn)品運行性能的前提下，無法更有效的提高自動化測試執(zhí)行效率。我懷疑測試自動化工程師只是從計算機課程了解到應該關注軟件的性能