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