文章出處：www.51testing.com 作者：Bret Pettichord 譯者：王威 發(fā)布時(shí)間：2005-10-19
【摘要】 我們對自動(dòng)化測試充滿(mǎn)了希望，然而，自動(dòng)化測試卻經(jīng)常帶給我們沮喪和失望。雖然，自動(dòng)化測試可以把我們從困難的環(huán)境中解放出來(lái)，在實(shí)施自動(dòng)化測試解決問(wèn)題的同時(shí)，又帶來(lái)同樣多的問(wèn)題。在開(kāi)展自動(dòng)化測試的工作中，關(guān)鍵問(wèn)題是遵循軟件開(kāi)發(fā)的基本規則。本文介紹自動(dòng)化測試的 7 個(gè)步驟：改進(jìn)自動(dòng)化測試過(guò)程，定義需求，驗證概念，支持產(chǎn)品的可測試性，具有可延續性的設計（ design for sustainability ），有計劃的部署和面對成功的挑戰。按照以上 7 個(gè)步驟，安排你的人員、工具和制定你的自動(dòng)化測試項目計劃，你將會(huì )通往一條成功之路。
一個(gè)故事 :
我在很多軟件公司工作過(guò)，公司規模有大有小，也和來(lái)自其他公司的人員交流，因此經(jīng)歷過(guò)或者聽(tīng)說(shuō)過(guò)影響自動(dòng)化測試效果的各種各樣的的問(wèn)題。本文將提供若干方法規避可能在自動(dòng)化測試中出現的問(wèn)題。我先給大家講一個(gè)故事，以便各位了解自動(dòng)化測試會(huì )出現哪些問(wèn)題。
以前，我們有一個(gè)軟件項目，開(kāi)發(fā)小組內所有的人都認為應該在項目中采用自動(dòng)化測試。軟件項目的經(jīng)理是 Anita Delegate 。她評估了所有可能采用的自動(dòng)化測試工具，最后選擇了一種，并且購買(mǎi)了幾份拷貝。她委派一位員工 ——Jerry Overworked 負責自動(dòng)化測試工作。 Jerry 除了負責自動(dòng)化測試工作，還有其他的很多任務(wù)。他嘗試使用剛剛購買(mǎi)的自動(dòng)化測試工具。當把測試工具應用到軟件產(chǎn)品測試中的時(shí)候，遇到了問(wèn)題。這個(gè)測試工具太復雜，難于配置。他不得不給測試工具的客戶(hù)支持熱線(xiàn)打了幾個(gè)電話(huà)。最后， Jerry 認識到，他需要測試工具的技術(shù)支持人員到現場(chǎng)幫助安裝測試工具，并找出其中的問(wèn)題。在打過(guò)幾個(gè)電話(huà)后，測試工具廠(chǎng)商派過(guò)來(lái)一位技術(shù)專(zhuān)家。技術(shù)專(zhuān)家到達后，找出問(wèn)題所在，測試工具可以正常工作了。這還算是順利了。但是，幾個(gè)月后，他們還是沒(méi)有真正實(shí)現測試自動(dòng)化， Jerry 拒絕繼續從事這個(gè)項目的工作，他害怕自動(dòng)化測試會(huì )一事無(wú)成，只是浪費時(shí)間而已。
項目經(jīng)理 Anita 把項目重新指派給 Kevin Shorttimer ，一位剛剛被雇傭來(lái)做軟件測試的人員。 Kevin 剛剛獲得計算機科學(xué)的學(xué)位，希望通過(guò)這份工作邁向更有挑戰性的、值得去做的工作。 Anita 送 Kevin 參加工具培訓，避免 Kevin 步 Jerry 的后塵 —— 由于使用測試工具遇到困難而變得沮喪，導致放棄負責的項目。 Kevin 非常興奮。這個(gè)項目的測試需要重復測試，有點(diǎn)令人討厭，因此，他非常愿意采用自動(dòng)化測試。一個(gè)主要的版本發(fā)布后， Kevin 準備開(kāi)始全天的自動(dòng)化測試，他非?？释玫揭粋€(gè)機會(huì )證明自己可以寫(xiě)非常復雜的，有難度的代碼。他建立了一個(gè)測試庫，使用了一些技巧的方法，可以支持大部分的測試，這比原計劃多花費了很多時(shí)間，不過(guò)， Kevin 使整個(gè)測試工作開(kāi)展的很順利。他用已有的測試套測試新的產(chǎn)品版本，并且確實(shí)發(fā)現了 bug 。接下來(lái)， Kevin 得到一個(gè)從事軟件開(kāi)發(fā)職位的機會(huì )，離開(kāi)了自動(dòng)化的崗位。
Ahmed Hardluck 接手 Kevin 的工作，從事自動(dòng)化測試執行工作。他發(fā)現 Kevin 留下的文檔不僅少，并且沒(méi)有太多的價(jià)值。 Ahmed 花費不少時(shí)間去弄清楚已有的測試設計和研究如何開(kāi)展測試執行工作。這個(gè)過(guò)程中， Ahmed 經(jīng)歷了很多失敗，并且不能確信測試執行的方法是否正確。測試執行中，執行失敗后的錯誤的提示信息也沒(méi)有太多的參考價(jià)值，他不得不更深的鉆研。一些測試執行看起來(lái)仿佛永遠沒(méi)有結束。另外一些測試執行需要一些特定的測試環(huán)境搭建要求，他更新測試環(huán)境搭建文檔，堅持不懈地工作。后來(lái)，在自動(dòng)化測試執行中，它發(fā)現幾個(gè)執行失敗的結果，經(jīng)過(guò)分析，是回歸測試的軟件版本中有 BUG ，導致測試執行失敗，發(fā)現產(chǎn)品的 BUG 后，每個(gè)人都很高興。接下來(lái)，他仔細分析測試套中的內容，希望通過(guò)優(yōu)化測試套使測試變得更可靠，但是，這個(gè)工作一直沒(méi)有完成，預期的優(yōu)化結果也沒(méi)有達到。按照計劃，產(chǎn)品的下一個(gè)發(fā)布版本有幾個(gè)主要的改動(dòng)， Ahmed 立刻意識到產(chǎn)品的改動(dòng)會(huì )破壞已有的自動(dòng)化測試設計。接下來(lái)，在測試產(chǎn)品的新版本中，絕大多數測試用例執行失敗了， Ahmed 對執行失敗的測試研究了很長(cháng)時(shí)間，然后，從其他人那里尋求幫助。經(jīng)過(guò)商討，自動(dòng)化測試應該根據產(chǎn)品的新接口做修改，自動(dòng)化測試才能運轉起來(lái)。最后，大家根據新接口修改自動(dòng)化測試，測試都通過(guò)了。產(chǎn)品發(fā)布到了市場(chǎng)上。接下來(lái)，用戶(hù)立刻打來(lái)投訴電話(huà)，投訴軟件無(wú)法工作。大家才發(fā)現自己改寫(xiě)了一些自動(dòng)化測試腳本，導致一些錯誤提示信息被忽略了。雖然，實(shí)際上測試執行是失敗的，但是，由于改寫(xiě)腳本時(shí)的一個(gè)編程錯誤導致失敗的測試執行結果被忽略了。這個(gè)產(chǎn)品終于失敗了。
這是我的故事?；蛟S您曾經(jīng)親身經(jīng)歷了故事當中某些情節。不過(guò)，我希望你沒(méi)有這樣的相似結局。本文將給出一些建議，避免出現這樣的結局。
問(wèn)題
這個(gè)故事闡明了幾個(gè)使自動(dòng)化測試項目陷入困境的原因：
自動(dòng)化測試時(shí)間不充足：根據項目計劃的安排，測試人員往往被安排利用自己的個(gè)人時(shí)間或者項目后期介入自動(dòng)化測試。這使得自動(dòng)化測試無(wú)法得到充分的時(shí)間，無(wú)法得到真正的關(guān)注。
缺乏清晰的目標：有很多好的理由去開(kāi)展自動(dòng)化測試工作，諸如自動(dòng)化測試可以節省時(shí)間，使測試更加簡(jiǎn)單，提高測試的覆蓋率，可以讓測試人員保持更好的測試主動(dòng)性。但是，自動(dòng)化測試不可能同時(shí)滿(mǎn)足上述的目標。不同的人員對自動(dòng)化測試有不同的希望，這些希望應該提出來(lái)，否則很可能面對的是失望。
缺乏經(jīng)驗：嘗試測試自己的程序的初級的程序員經(jīng)常采用自動(dòng)化自動(dòng)化測試。由于缺乏經(jīng)驗，很難保證自動(dòng)化測試的順利開(kāi)展。
更新?lián)Q代頻繁（ High turnover ）：測試自動(dòng)化往往需要花費很多時(shí)間學(xué)習的，當自動(dòng)化測試更新?lián)Q代頻繁的時(shí)候，你就喪失了剛剛學(xué)習到的自動(dòng)化測試經(jīng)驗。
對于絕望的反應：在測試還遠沒(méi)有開(kāi)始的時(shí)候，問(wèn)題就已經(jīng)潛伏在軟件中了。軟件測試不過(guò)是發(fā)現了這些潛伏的問(wèn)題而已。就測試本身而言，測試是一件很困難的工作。當在修改過(guò)的軟件上一遍接一遍的測試時(shí)，測試人員變得疲勞起來(lái)。測試什么時(shí)候后結束？當按照計劃的安排，軟件應該交付的時(shí)候，測試人員的絕望變得尤其強烈。如果不需要測試，那該有多好呀！在這種環(huán)境中，自動(dòng)化測試可能是個(gè)可以選擇的解決方法。但是，自動(dòng)化測試卻未必是最好的選擇，他不是一個(gè)現實(shí)的解決方法，更像是一個(gè)希望。
不愿思考軟件測試：很多人發(fā)現實(shí)現產(chǎn)品的自動(dòng)化測試比測試本身更有趣。在很多軟件項目發(fā)生這樣的情況，自動(dòng)化工程師不參與到軟件測試的具體活動(dòng)中。由于測試的自動(dòng)化與測試的人為割裂，導致很多自動(dòng)化對軟件測試并沒(méi)有太大的幫助。
關(guān)注于技術(shù)：如何實(shí)現軟件的自動(dòng)化測試是一個(gè)很吸引人的技術(shù)問(wèn)題。不過(guò)，過(guò)多的關(guān)注如何實(shí)現自動(dòng)化測試，導致忽略了自動(dòng)化測試方案是否符合測試需要。
遵守軟件開(kāi)發(fā)的規則
你可能了解 SEI （軟件工程研究所）提出的 CMM （能力成熟度模型）。 CMM 分為 5 個(gè)界別，該模型用來(lái)對軟件開(kāi)發(fā)組織劃分等級。 Jerry Weinberg （美國著(zhù)名軟件工程專(zhuān)家）也創(chuàng )建了自己的一套軟件組織模型，在他的組織模型中增加了一個(gè)額外的級別，他稱(chēng)之為零級別。很顯然，一個(gè)零模式的組織實(shí)際上也是開(kāi)發(fā)軟件；零模式組織中，在開(kāi)發(fā)人員和用戶(hù)之間沒(méi)有差別 [Weinberg 1992] 。恰恰在這類(lèi)組織環(huán)境中，經(jīng)常采用自動(dòng)化測試方法。因此，把資源用于自動(dòng)化測試，并且把自動(dòng)化測試當作一個(gè)軟件開(kāi)發(fā)活動(dòng)對待，把軟件測試自動(dòng)化提升到一級。這是解決測試自動(dòng)化的核心的方案。我們應該像運作其他的開(kāi)發(fā)項目一樣來(lái)運作軟件自動(dòng)化測試項目。
像其他軟件開(kāi)發(fā)項目一樣，我們需要軟件開(kāi)發(fā)人員專(zhuān)注于測試自動(dòng)化的開(kāi)發(fā)任務(wù)；像其他軟件開(kāi)發(fā)項目一樣，自動(dòng)化測試可以自動(dòng)完成具體的測試任務(wù)，對于具體的測試任務(wù)來(lái)說(shuō)，自動(dòng)化開(kāi)發(fā)人員可能不是這方面的專(zhuān)家，因此，軟件測試專(zhuān)家應該提供具體測試任務(wù)相關(guān)的咨詢(xún)，并且提供測試自動(dòng)化的需求；像其他軟件開(kāi)發(fā)項目一樣，如果在開(kāi)發(fā)編碼之前，對測試自動(dòng)化作了整體設計有助于測試自動(dòng)化開(kāi)發(fā)的順利開(kāi)展。像其他軟件開(kāi)發(fā)項目一樣，自動(dòng)化測試代碼需要跟蹤和維護，因此，需要采用源代碼管理。像其他軟件開(kāi)發(fā)項目一樣，測試自動(dòng)化也會(huì )出現 BUG ，因此，需要有計劃的跟蹤 BUG ，并且對修改后的 BUG 進(jìn)行測試。像其他軟件開(kāi)發(fā)項目一樣，用戶(hù)需要知道如何使用軟件，因此，需要提供用戶(hù)使用手冊。
本文中不對軟件開(kāi)發(fā)做過(guò)多講述。我假定您屬于某個(gè)軟件組織，該組織已經(jīng)知道采用何種合理的、有效的方法開(kāi)發(fā)軟件。我僅僅是推動(dòng)您在自動(dòng)化測試開(kāi)發(fā)過(guò)程中遵守已經(jīng)建立的軟件開(kāi)發(fā)規則而已。本文按照在軟件開(kāi)發(fā)項目中采用的標準步驟組織的，重點(diǎn)關(guān)注測試自動(dòng)化相關(guān)的事宜和挑戰。
• 改進(jìn)軟件測試過(guò)程
• 定義需求
• 驗證概念
• 支持產(chǎn)品的可測試性
• 可延續性的設計（ design for sustainability ）
• 有計劃的部署
• 面對成功的挑戰
步驟一：改進(jìn)軟件測試過(guò)程
如果你負責提高一個(gè)商業(yè)交易操作的效率，首先，你應該確認已經(jīng)很好的定義了這個(gè)操作的具體過(guò)程。然后，在你投入時(shí)間和金錢(qián)采用計算機提供一套自動(dòng)化的商業(yè)交易操作系統之前，你想知道是否可以采用更簡(jiǎn)單、成本更低的的方法。同樣的，上述過(guò)程也是用于自動(dòng)化測試。我更愿意把 “ 測試自動(dòng)化 ” 這個(gè)詞解釋成能夠使測試過(guò)程簡(jiǎn)單并有效率，使測試過(guò)程更為快捷，沒(méi)有延誤。運行在計算機上的自動(dòng)化測試腳本只是自動(dòng)化測試的一個(gè)方面而已。
例如，很多測試小組都是在回歸測試環(huán)節開(kāi)始采用測試自動(dòng)化的方法?；貧w測試需要頻繁的執行，再執行，去檢查曾經(jīng)執行過(guò)的有效的測試用例沒(méi)有因為軟件的變動(dòng)而執行失敗?；貧w測試需要反復執行，并且單調乏味。怎樣才能做好回歸測試文檔化的工作呢？通常的做法是采用列有產(chǎn)品特性的列表，然后對照列表檢查。這是個(gè)很好的開(kāi)始，回歸測試檢查列表可以告訴你應該測試哪些方面。不過(guò)，回歸測試檢查列表只是合于那些了解產(chǎn)品，并且知道需要采用哪種測試方法的人。
在你開(kāi)始測試自動(dòng)化之前，你需要完善上面提到的回歸測試檢查表，并且，確保你已經(jīng)采用了確定的的測試方法，指明測試中需要什么樣的數據，并給出設計數據的完整方法。如果測試掌握了基本的產(chǎn)品知識，這會(huì )更好。確認可以提供上面提到的文檔后，需要明確測試設計的細節描述，還應該描述測試的預期結果，這些通常被忽略，建議測試人員知道。太多的測試人員沒(méi)有意識到他們缺少什么，并且由于害怕尷尬而不敢去求助。這樣一份詳細的文檔給測試小組帶來(lái)立竿見(jiàn)影的效果，因為，現在任何一個(gè)具有基本產(chǎn)品知識的人根據文檔可以開(kāi)展測試執行工作了。在開(kāi)始更為完全意義上的測試自動(dòng)化之前，必須已經(jīng)完成了測試設計文檔。測試設計是測試自動(dòng)化最主要的測試需求說(shuō)明。不過(guò)，這時(shí)候千萬(wàn)不要走極端去過(guò)分細致地說(shuō)明測試執行的每一個(gè)步驟，只要確保那些有軟件基本操作常識的人員可以根據文檔完成測試執行工作既可。但是，不要假定他們理解那些存留在你頭腦中的軟件測試執行的想法，把這些測試設計的思路描述清楚就可以了。
我以前負責過(guò)一個(gè)軟件模塊的自動(dòng)化測試工作。這個(gè)模塊的一些特性導致實(shí)現自動(dòng)化非常困難。當我了解到這項工作無(wú)需在很短的時(shí)間內完成后，決定制定一個(gè)詳細回歸測試設計方案。我仔細地檢查了缺陷跟蹤庫中與該模塊相關(guān)的每個(gè)已經(jīng)關(guān)閉的缺陷，針對每個(gè)缺陷，我寫(xiě)了一個(gè)能夠發(fā)現該問(wèn)題的測試執行操作。我計劃采用這種方法提供一個(gè)詳細的自動(dòng)化需求列表，這可以告訴我模塊的那一部分最適合自動(dòng)化測試。在完成上述工作后，我沒(méi)有機會(huì )完成測試自動(dòng)化的實(shí)現工作。不過(guò)，當我們需要對這個(gè)模塊做完整回歸測試的時(shí)候，我將上面提到的文檔提供給若干只了解被測試產(chǎn)品但是沒(méi)有測試經(jīng)驗的測試人員。依照文檔的指導，幾乎不需要任何指導的情況下，各自完成了回歸測試，并且發(fā)現了 BUG 。從某種角度看，這實(shí)際上是一次很成功的自動(dòng)化測試。在這個(gè)項目中，我們與其開(kāi)發(fā)自動(dòng)化測試腳本，還不如把測試執行步驟文檔化。后來(lái)，在其它項目中，我們開(kāi)發(fā)了自動(dòng)化測試腳本，發(fā)現相關(guān)人員只有接受相關(guān)培訓才能理解并執行自動(dòng)化測試腳本，如果測試自動(dòng)化設計的很好，可能會(huì )好一些。不過(guò)，經(jīng)過(guò)實(shí)踐我們總結出完成一份設計的比較好的測試文檔，比完成一份設計良好的測試腳本簡(jiǎn)單的多。
另外一個(gè)提高測試效率的簡(jiǎn)單方法是采用更多的計算機。很多測試人員動(dòng)輒動(dòng)用幾臺計算機，這一點(diǎn)顯而易見(jiàn)。我之所以強調采用更多的計算機是因為，我曾經(jīng)看到一些測試人員被誤導在單機上努力的完成某些大容量的自動(dòng)化測試執行工作，這種情況下由于錯誤的使用了測試設備、測試環(huán)境，導致測試沒(méi)有效果。因此，自動(dòng)化測試需要集中考慮所需要的支撐設備。
針對改進(jìn)軟件測試過(guò)程，我的最后一個(gè)建議是改進(jìn)被測試的產(chǎn)品，使它更容易被測試，有很多改進(jìn)措施既可以幫助用戶(hù)更好的使用產(chǎn)品，也可以幫助測試人員更好的測試產(chǎn)品。稍后，我將討論自動(dòng)化測試的可測試需求。這里，我只是建議給出產(chǎn)品的改進(jìn)點(diǎn)，這樣對手工測試大有幫助。
一些產(chǎn)品非常難安裝，測試人員在安裝和卸載軟件上花費大量的時(shí)間。這種情況下，與其實(shí)現產(chǎn)品安裝的自動(dòng)化測試，還不如改進(jìn)產(chǎn)品的安裝功能。采用這種解決辦法，最終的用戶(hù)會(huì )受益的。另外的一個(gè)處理方法是考慮開(kāi)發(fā)一套自動(dòng)安裝程序，該程序可以和產(chǎn)品一同發(fā)布。事實(shí)上，現在有很多專(zhuān)門(mén)制作安裝程序的商用工具。
另一些產(chǎn)品改進(jìn)需要利用工具在測試執行的日志中查找錯誤。采用人工方法，在日志中一頁(yè)一頁(yè)的查詢(xún)報錯信息很容易會(huì )讓人感到乏味。那么，趕快采用自動(dòng)化方法吧。如果你了解日志中記錄的錯誤信息格式，寫(xiě)出一個(gè)錯誤掃描程序是很容易的事情。如果，你不能確定日志中的錯誤信息格式，就開(kāi)始動(dòng)手寫(xiě)錯誤掃描程序，很可能面臨的是一場(chǎng)災難。不要忘記本文開(kāi)篇講的那個(gè)故事中提到的測試套無(wú)法判斷測試用例是否執行失敗的例子。最終用戶(hù)也不愿意采用通過(guò)搜索日志的方法查找錯誤信息。修改錯誤信息的格式，使其適合日志掃描程序，便于掃描工具能夠準確的掃描到所有的錯誤信息。這樣，在測試中就可以使用掃描工具了。
通過(guò)改進(jìn)產(chǎn)品的性能對測試也是大有幫助的。很顯然的，如果產(chǎn)品的性能影響了測試速度，鑒別出性能比較差的產(chǎn)品功能，并度量該產(chǎn)品功能的性能，把它作為影響測試進(jìn)度的缺陷，提交缺陷報告。
上面所述的幾個(gè)方面可以在無(wú)需構建自動(dòng)化測試系統的情況下，大幅度的提高測試效率。改進(jìn)軟件測試過(guò)程會(huì )花費你構建自動(dòng)化測試系統的時(shí)間，不過(guò)改進(jìn)測試過(guò)程無(wú)疑可以使你的自動(dòng)化測試項目更為順利開(kāi)展起來(lái)。
步驟二：定義需求
在前面的故事中，自動(dòng)化工程師和自動(dòng)化測試的發(fā)起者的目標存在偏差。為了避免這種情況，需要在自動(dòng)化測試需求上保持一致。應該有一份自動(dòng)化測試需求，用來(lái)描述需要測試什么。測試需求應該在測試設計階段詳細描述出來(lái)，自動(dòng)化測試需求描述了自動(dòng)化測試的目標。很多人認為自動(dòng)化測試顯然是一件好事情，但是，他們不愿意對自動(dòng)化測試的目標給出清晰的描述。下面是人們選用自動(dòng)化測試的幾個(gè)原因：
• 加快測試進(jìn)度從而加快產(chǎn)品發(fā)布進(jìn)度
• 更多的測試
• 通過(guò)減少手工測試降低測試成本
• 提高測試覆蓋率
• 保證一致性
• 提高測試的可靠性
• 測試工作可以由技術(shù)能力不強測試人員完成
• 定義測試過(guò)程，避免過(guò)分依賴(lài)個(gè)人
• 測試變得更加有趣
• 提高了編程技能
開(kāi)發(fā)管理、測試管理和測試人員實(shí)現自動(dòng)化測試的目標常常是有差別的。除非三者之間達成一致，否則很難定義什么是成功的自動(dòng)化測試。
當然，不同的情況下，有的自動(dòng)化測試目標比較容易達到，有的則比較難以達到。測試自動(dòng)化往往對測試人員的技術(shù)水平要求很高，測試人員必須能理解充分的理解自動(dòng)化測試，從而通過(guò)自動(dòng)化測試不斷發(fā)現軟件的缺陷。不過(guò)，自動(dòng)化測試不利于測試人員不斷的積累測試經(jīng)驗。不管怎么樣，在開(kāi)始自動(dòng)化測試之前應該確定自動(dòng)化測試成功的標準。
手工測試人員在測試執行過(guò)程中的一些操作能夠發(fā)現不引人注意的問(wèn)題。他們計劃并獲取必要的測試資源，建立測試環(huán)境，執行測試用例。測試過(guò)程中，如果有什么異常的情況發(fā)生，手工測試人員立刻可以關(guān)注到。他們對比實(shí)際測試結果和預期測試結果，記錄測試結果，復位被測試的軟件系統，準備下一個(gè)軟件測試用例的環(huán)境。他們分析各種測試用例執行失敗的情況，研究測試過(guò)程可疑的現象，尋找測試用例執行失敗的過(guò)程，設計并執行其他的測試用例幫助定位軟件缺陷。接下來(lái)，他們寫(xiě)作缺陷報告單，保證缺陷被修改，并且總結所有的缺陷報告單，以便其他人能夠了解測試的執行情況。
千萬(wàn)不要強行在測試的每個(gè)部分都采用自動(dòng)化方式。尋找能夠帶來(lái)最大回報的部分，部分的采用自動(dòng)化測試是最好的方法?；蛟S你可能發(fā)現采用自動(dòng)化執行和手動(dòng)確認測試執行結果的方式是個(gè)很好的選擇，或許你可以采用自動(dòng)化確認測試結果和手工測試執行相結合和方式。我聽(tīng)到有人講，除非測試的各個(gè)環(huán)節都采用自動(dòng)化方式，否則不是真正意義上的自動(dòng)化測試，這真是胡言亂語(yǔ)。如果僅僅是為了尋找挑戰，可以嘗試在測試的每個(gè)環(huán)節都采用自動(dòng)化方法。但是，如果尋找成功測試的方法，請關(guān)注那些可以快速建立的，可以反復利用的自動(dòng)化測試。
定義自動(dòng)化測試項目的需求要求我們全面地、清楚地考慮各種情況，然后給出權衡后的需求，并且可以使測試相關(guān)人員更加合理的提出自己對自動(dòng)化測試的期望。通過(guò)定義自動(dòng)化測試需求，距離成功的自動(dòng)化測試近了一步。
步驟三：驗證概念
在前面的故事當中，那個(gè)自動(dòng)化測試人員在對測試方向一片茫然的情況下一頭扎進(jìn)了自動(dòng)化測試項目中。不過(guò)，在項目的進(jìn)行中，他得到了來(lái)自各個(gè)方面的支持。
你可能還沒(méi)有認識到這一點(diǎn)，不過(guò)，你必須驗證自動(dòng)化測試項目的可行性。驗證過(guò)程花費的時(shí)間往往比人們預期的要長(cháng)，并且需要來(lái)自你身邊的各種人的幫助。
很多年前，我從事一個(gè)測試自動(dòng)化項目的工作，參加項目的人員有各種各樣的好點(diǎn)子。我們設計了一個(gè)復雜的自動(dòng)化測試系統，并且非常努力工作去實(shí)現系統的每個(gè)模塊。我們定期的介紹測試自動(dòng)化的設計思路和工作進(jìn)度，甚至演示已經(jīng)完成的部分功能。但是，我們沒(méi)有演示如何利用該套測試自動(dòng)化系統如何開(kāi)展實(shí)際的測試工作。最后，整個(gè)項目被取消了，此后，我再也沒(méi)有犯這個(gè)錯誤。
你需要盡可能快地驗證你采用的測試工具和測試方法的可行性，站在產(chǎn)品的角度驗證你所測試的產(chǎn)品采用自動(dòng)化測試的可行性。這通常是很困難的，需要盡快地找出可行性問(wèn)題的答案，需要確定你的測試工具和測試方法對于被測試的產(chǎn)品和測試人員是否合適。你需要做是驗證概念 —— 一個(gè)快速、有說(shuō)服力的測試套可以證明你選在測試工具和測試方法的正確性，從而驗證了你的測試概念。你選擇的用來(lái)驗證概念的測試套是評估測試工具的最好的方式。
對于很多人來(lái)說(shuō)，自動(dòng)化測試意味著(zhù) GUI 自動(dòng)化測試，我不同意這種觀(guān)點(diǎn)。我曾經(jīng)做過(guò) GUI 和非 GUI 自動(dòng)化測試，并驚奇的發(fā)現這兩類(lèi)測試的測試計劃有很大的互補性。不過(guò)， GUI 測試工具很昂貴、并且過(guò)分講究。選擇合適的 GUI 測試工具是很重要的，因為，如果沒(méi)有選擇合適的測試工具，你會(huì )遇到很多不可預測的困難。 Elisabeth Hendrickson 曾經(jīng)寫(xiě)過(guò)一篇關(guān)于選擇測試的工具的指導性文章 [Hendrickson 1999] 。我建議在評估測試工具中，找出能夠驗證你的想法的證據是很重要的環(huán)節。這需要測試工具至少有一個(gè)月試用期，你可能打算現在購買(mǎi)一份測試工具，然后直到評估完成后再購買(mǎi)更多份。你需要在付出大筆金錢(qián)購買(mǎi)測試工具的之前，找出工具存在的問(wèn)題。這樣，你可以從測試工具供應商得到更好的幫助，當你打算更換工具的時(shí)候，你不會(huì )感覺(jué)很為難。
下面是一些候選的驗證概念的試驗：
回歸測試：你準備在每個(gè)版本運行同樣的測試用例嗎？回歸測試是最宜采用自動(dòng)化測試的環(huán)節。
配置測試：你的軟件支持多少種不同的平臺？你打算在所有支持的平臺上測試執行所有的測試用例嗎？如果是的，那么采用自動(dòng)化測試是有幫助的。
測試環(huán)境建立：對于大量不同的測試用例，可能需要相同的測試環(huán)境搭建過(guò)程。在開(kāi)展自動(dòng)化測試執行之前，先把測試環(huán)境搭建實(shí)現自動(dòng)化。
非 GUI 測試：實(shí)現命令行和 API 的測試自動(dòng)化比 GUI 自動(dòng)化測試容易的多。
無(wú)論采用什么測試方法，定義一個(gè)看得見(jiàn)的目標，然后集中在這個(gè)目標上。驗證你自動(dòng)化測試概念可以使自動(dòng)化更進(jìn)一步邁向成功之路。
步驟四：支持產(chǎn)品的可測試性
軟件產(chǎn)品一般會(huì )用到下面三種不同類(lèi)別的接口：命令行接口（ command line interfaces ，縮寫(xiě) CLIs) 、應用程序接口（ API ）、圖形用戶(hù)接口（ GUI ）。有些產(chǎn)品會(huì )用到所有三類(lèi)接口，有些產(chǎn)品只用到一類(lèi)或者兩類(lèi)接口，這些是測試中所需要的接口。從本質(zhì)上看， API 接口和命令行接口比 GUI 接口容易實(shí)現自動(dòng)化，去找一找你的被測產(chǎn)品是否包括 API 接口或者命令行接口。有些時(shí)候，這兩類(lèi)接口隱藏在產(chǎn)品的內部，如果確實(shí)沒(méi)有，需要鼓勵開(kāi)發(fā)人員在產(chǎn)品中提供命令行接口或者 API 接口，從而支持產(chǎn)品的可測試性。
下面，更多多的講解 GUI 自動(dòng)化測試相關(guān)內容。這里有幾個(gè)原因導致 GUI 自動(dòng)化測試比預期的要困難。第一個(gè)原因是需要手工完成部分腳本。絕大多數自動(dòng)化測試工具都有 “ 錄制回放 ” 或者 “ 捕捉回放 ” 功能，這確實(shí)是個(gè)很好的方法?？梢允止绦袦y試用例，測試工具在后臺記住你的所有操作，然后產(chǎn)生可以用來(lái)重復執行的測試用例腳本。這是一個(gè)很好的方法，但是很多時(shí)候卻不能奏效。很多軟件測試文章的作者得出結論 “ 錄制回放 ” 雖然可以生成部分測試腳本，但是有很多問(wèn)題導致 “ 錄制回放 ” 不能應用到整個(gè)測試執行過(guò)程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 結果， GUI 測試還是主要由手工完成。
第二個(gè)原因，把 GUI 自動(dòng)化測試工和被測試的產(chǎn)品有機的結合在一起需要面臨技術(shù)上的挑戰。經(jīng)常要在采用眾多專(zhuān)家意見(jiàn)和最新的 GUI 接口技術(shù)才能使 GUI 測試工具正常工作。這個(gè)主要的困難也是 GUI 自動(dòng)化測試工具價(jià)格昂貴的主要原因之一。非標準的、定制的控件會(huì )增加測試的困難，解決方法總是有的，可以采用修改產(chǎn)品源代碼的方式，也可以從測試工具供應商處升級測試工具。另外，還需要分析測試工具中的 BUG ，并且給工具打補丁。也可能測試工具需要做相當的定制，以便能有效地測試產(chǎn)品界面上的定制控件。 GUI 測試中，困難總是意外出現，讓人驚奇。你也可能需要重新設計你的測試以規避那些存在問(wèn)題的界面控件。
第三個(gè)原因， GUI 設計方案的變動(dòng)會(huì )直接帶來(lái) GUI 自動(dòng)化測試復雜度的提高。在開(kāi)發(fā)的整個(gè)過(guò)程中，圖形界面經(jīng)常被修改或者完全重設計，這是出了名的事情。一般來(lái)講，第一個(gè)版本的圖形界面都是很糟糕。如果處在圖形界面方案不停變動(dòng)的時(shí)候，就開(kāi)展 GUI 自動(dòng)化測試是不會(huì )有任何進(jìn)展的，你只能花費大量的時(shí)間修改測試腳本，以適應圖形界面的變更。不管怎樣，即便界面的修改會(huì )導致測試修改腳本，你也不應該反對開(kāi)發(fā)人員改進(jìn)圖形界面。一旦原始的設計完成后，圖形界面接口下面的編程接口就固定下來(lái)了。
上面提到的這些原因都是基于采用 GUI 自動(dòng)化測試的方法完成產(chǎn)品的功能測試。圖形界面接口當然需要測試，可以考慮實(shí)現 GUI 測試自動(dòng)化。不過(guò)，你也應該考慮采用其他方法測試產(chǎn)品的核心功能，并且這些測試不會(huì )因為圖形界面發(fā)生變化而被中斷，這類(lèi)測試應該采用命令行接口或者 API 接口。我曾經(jīng)看到有人選擇 GUI 自動(dòng)化測試，因為，他們不打算修改被測試產(chǎn)品，但是，最終他們認識到必須對產(chǎn)品做修改，以保證 GUI 測試自動(dòng)化可以正常工作。無(wú)論你選擇哪種方法，自動(dòng)化都需要對被測試的產(chǎn)品做修改。因此，采用可編程的接口是最可靠的。
為了讓 API 接口測試更為容易，應該把接口與某種解釋程序，例如 Tcl 、 Perl 或者 Python 綁定在一起。這使交互式測試成為可能，并且可以縮短自動(dòng)化測試的開(kāi)發(fā)周期。采用 API 接口的方式，還可以實(shí)現獨立的產(chǎn)品模塊的單元測試自動(dòng)化。
一個(gè)關(guān)于隱藏可編程接口的例子是關(guān)于 InstallShield—— 非常流行的制作安裝盤(pán)的工具。 InstallShield 有命令行選項，采用這種選項可以實(shí)現非 GUI 方式的安裝盤(pán)，采用這種方式，從提前創(chuàng )建好的文件中讀取安裝選項。這種方式可能比采用 GUI 的安裝方式更簡(jiǎn)單更可靠。
另一個(gè)例子是關(guān)于如何避免基于 WEB 軟件的 GUI 自動(dòng)化測試。采用 GUI 測試工具可以通過(guò)瀏覽器操作 WEB 界面。 WEB 瀏覽器是通過(guò) HTTP 協(xié)議與 WEB 服務(wù)器交互的，所以直接測試 HTTP 協(xié)議更為簡(jiǎn)單。 Perl 可以直接連接 TCP/IP 端口，完成這類(lèi)的自動(dòng)化測試。采用高級接口技術(shù)，譬如客戶(hù)端 JAVA 或者 ActiveX 不可能利用這種方法。但是，如果在合適的環(huán)境中采用這種方式，你將發(fā)現這種方式的自動(dòng)化測試比 GUI 自動(dòng)化測試更加便宜更加簡(jiǎn)單。
我曾經(jīng)受雇在一家公司負責某個(gè)產(chǎn)品 GUI 相關(guān)的自動(dòng)化測試，該產(chǎn)品也提供命令行接口，不過(guò)，他們已經(jīng)實(shí)現了 GUI 的自動(dòng)化測試。經(jīng)過(guò)一段時(shí)間的研究，我發(fā)現找到圖形界面中的 BUG 并不困難，不過(guò)，用戶(hù)并不關(guān)注圖形界面，他們更喜歡使用命令行。我還發(fā)現我們還沒(méi)有針對最新的產(chǎn)品功能（這些功能即可通過(guò) GUI 的方式，也可以通過(guò)命令行的方式使用）實(shí)現自動(dòng)化測試。我決定推遲 GUI 自動(dòng)化測試，擴展命令行測試套，測試新增的產(chǎn)品功能?，F在回過(guò)頭看這個(gè)決定，我沒(méi)有選擇 GUI 自動(dòng)化測試是最大的成功之處，如果采用了 GUI 自動(dòng)化測試所有的時(shí)間和努力都會(huì )浪費在其中。他們已經(jīng)準備好做 GUI 自動(dòng)化測試了，并且已經(jīng)購買(mǎi)了一套測試工具和其他需要的東西，但我知道在開(kāi)展具體的 GUI 自動(dòng)化測試活動(dòng)中，會(huì )遇到各種各樣的困難和障礙。
無(wú)論你需要支持圖形界面接口、命令行接口還是 API 接口，如果你盡可能早的在產(chǎn)品設計階段提出產(chǎn)品的可測試性設計需求，未來(lái)的測試工作中，你很可能成功。盡可能早的啟動(dòng)自動(dòng)化測試項目，提出可測試性需求，會(huì )使您走向自動(dòng)化測試成功之路。
步驟五：具有可延續性的設計
在開(kāi)篇的故事中，我們看到由于自動(dòng)化工程師把注意力僅僅集中在如何使自動(dòng)化運轉起來(lái)，導致測試自動(dòng)化達不到預期的效果。自動(dòng)化測試是一個(gè)長(cháng)期的過(guò)程，為了與產(chǎn)品新版本的功能和其他相關(guān)修改保持一致，自動(dòng)化測試需要不停的維護和擴充。自動(dòng)化測試設計中考慮自動(dòng)化在未來(lái)的可擴充性是很關(guān)鍵的，不過(guò)，自動(dòng)化測試的完整性也是很重要的。如果自動(dòng)化測試程序報告測試用例執行通過(guò)，測試人員應該相信得到的結果，測試執行的實(shí)際結果也應該是通過(guò)了。其實(shí)，有很多存在問(wèn)題的測試用例表面上執行通過(guò)了，實(shí)際上卻執行失敗了，并且沒(méi)有記錄任何錯誤日志，這就是失敗的自動(dòng)化。這種失敗的自動(dòng)化會(huì )給整個(gè)項目帶來(lái)災難性的后果，而當測試人員構建的測試自動(dòng)化采用了很糟糕的設計方案或者由于后來(lái)的修改引入了錯誤，都會(huì )導致這種失敗的測試自動(dòng)化。失敗的自動(dòng)化通常是由于沒(méi)有關(guān)注自動(dòng)化測試的性能或者沒(méi)有充分的自動(dòng)化設計導致的。
性能： 提高代碼的性能往往增加了代碼的復雜性，因此，會(huì )威脅到代碼的可靠性。很少有人關(guān)心如何對自動(dòng)化本身加以測試。通過(guò)我對測試套性能的分析，很多測試套都是花費大量的時(shí)間等候產(chǎn)品的運行。因此，在不提高產(chǎn)品運行性能的前提下，無(wú)法更有效的提高自動(dòng)化測試執行效率。我懷疑測試自動(dòng)化工程師只是從計算機課程了解到應該關(guān)注軟件的性能，而并沒(méi)有實(shí)際的操作經(jīng)驗。如果測試套的性能問(wèn)題無(wú)法改變，那么應該考慮提高硬件的性能；測試套中經(jīng)常會(huì )出現冗余，也可以考慮取出測試套中的冗余或者減少一個(gè)測試套中完成的測試任務(wù)，都是很好的辦法。
便于分析： 測試自動(dòng)化執行失敗后應該分析失敗的結果，這是一個(gè)棘手的問(wèn)題。分析執行失敗的自動(dòng)化測試結果是件困難的事情，需要從多方面著(zhù)手，測試上報的告警信息是真的還是假的？是不是因為測試套中存在缺陷導致測試執行失??？是不是在搭建測試環(huán)境中出現了錯誤導致測試執行失??？是不是產(chǎn)品中確實(shí)存在缺陷導致測試執行失??？有幾個(gè)方法可以幫助測試執行失敗的結果分析，某些方法可以找到問(wèn)題所在。通過(guò)在測試執行之前檢查常見(jiàn)的測試環(huán)境搭建問(wèn)題，從而提高測試套的可靠性；通過(guò)改進(jìn)錯誤輸出報告，從而提高測試自動(dòng)化的錯誤輸出的可分析性；此外，還可以改進(jìn)自動(dòng)化測試框架中存在的問(wèn)題。訓練測試人員如何分析測試執行失敗結果。甚至可以找到那些不可靠的、冗余的或者功能比較獨立的測試，然后安全地將之刪除。上面這些都是減少自動(dòng)化測試誤報告警、提高測試可分析性的積極有效的方法。另外，有一種錯誤的測試結果分析方法，那就是采用測試結果后處理程序對測試結果自動(dòng)分析和過(guò)濾，盡管也可以采用這種測試結果分析方法，不過(guò)這種方法會(huì )使自動(dòng)化測試系統復雜化，更重要的是，后處理程序中的 BUG 會(huì )嚴重損害自動(dòng)化測試的完整性。如果由于自動(dòng)化測試本身存在的缺陷誤把產(chǎn)品中的正常功能視為異常，那該怎么辦？我曾經(jīng)看到測試小組花費開(kāi)發(fā)測試自動(dòng)化兩倍的時(shí)間來(lái)修改測試腳本，并且不愿意開(kāi)展培訓過(guò)程。那些僅僅關(guān)注很淺層次測試技術(shù)的測試管理者對這種方法很感興趣，他們排斥采用隱藏測試復雜度的方法。
綜上所述，應該集中精力關(guān)注可以延續使用的測試套，從以下幾方面考慮，測試的可檢視性、測試的可維護性、測試的完整性、測試的獨立性、測試的可重復性。
可讀性： 很多情況下，在測試人員開(kāi)始測試項目之前，公司已經(jīng)有了一套測試腳本，并且已經(jīng)存在很多年了。我們可以稱(chēng)之為 “ 聰明的橡樹(shù) ”(wise oak tree)[Bach 1996] 。大家很依賴(lài)它，但是并不知道它是什么。由于 “ 聰明的橡樹(shù) ” 類(lèi)型的測試腳本缺乏可讀性，在具體應用中，那些腳本常常沒(méi)有多大的實(shí)用價(jià)值，越來(lái)越讓人迷惑。因此，測試人員很難確定他們實(shí)際在測試什么，反而會(huì )導致測試人員對自身的測試能力有過(guò)高的估計。測試人員能夠檢視測試腳本，并且理解測試腳本究竟測試了什么，這是很關(guān)鍵的。好的文檔是解決問(wèn)題的手段之一，對測試腳本全面分析是另外一個(gè)手段。由上面兩種方法可以引申出其它的相關(guān)方法，我曾經(jīng)在一個(gè)項目中使用過(guò)引申之后的方法。在測試腳本中插樁，把所有執行的產(chǎn)品相關(guān)的命令記錄到日志里。這樣，當分析日志確定執行了哪些產(chǎn)品命令，命令采用了何種參數配置時(shí)，可以提供一個(gè)非常好的測試記錄，里面記錄了自動(dòng)化測試執行了什么，沒(méi)有執行什么。如果測試腳本可讀性不好，很容易變得過(guò)分依賴(lài)并沒(méi)有完全理解的測試腳本，很容易認為測試腳本實(shí)際上做的工作比你想象中的還要多。測試套的可讀性提高后，可以更容易的開(kāi)展同行評審活動(dòng)。
可維護性： 在工作中，我曾經(jīng)使用過(guò)一個(gè)測試套，它把所有的程序輸出保存到文件中。然后，通過(guò)對比輸出文件內容和一個(gè)已有的輸出文件內容的差別，可以稱(chēng)已有的輸出文件為 “ 標準文件 ” （ “gold file” ）。在回歸測試中，用這個(gè)方法查找 BUG 是不是明智之舉。這種方法太過(guò)于敏感了，它會(huì )產(chǎn)生很多錯誤的警告。隨著(zhù)時(shí)間的推移，軟件開(kāi)發(fā)人員會(huì )根據需要修改產(chǎn)品的很多輸出信息，這會(huì )導致很多自動(dòng)化測試失敗。很明顯，為了保證自動(dòng)化測試的順利進(jìn)行，應該在對 “ 標準文件 ” 仔細分析的基礎上，根據開(kāi)發(fā)人員修改的產(chǎn)品輸出信息對之做相應的修改。比較好的可維護性方法是，每次只檢查選定的產(chǎn)品的某些特定輸出，而不是對比所有的結果輸出。產(chǎn)品的接口變動(dòng)也會(huì )導致原來(lái)的測試無(wú)法執行或者執行失敗。對于 GUI 測試，這是一個(gè)更大的挑戰。研究由于產(chǎn)品接口變化引起的相關(guān)測試修改，并研究使測試修改量最小的方法，測試中采用庫是解決問(wèn)題的方法。當產(chǎn)品發(fā)生變化的時(shí)候，只需要修改相關(guān)的庫，保證測試與產(chǎn)品的變動(dòng)同步修改即可。
完整性： 當自動(dòng)化測試執行后，報告測試執行通過(guò)，可以斷定這是真的嗎？這就是我稱(chēng)之為測試套的完整性。在前面的故事中，當沒(méi)有對自動(dòng)化測試完整性給予應有的關(guān)注的時(shí)候，發(fā)生了富有喜劇性的情況。我們應該在多大程度上相信自動(dòng)化化測試執行結果？自動(dòng)化測試執行中的誤報告警是很大的問(wèn)題。測試人員特別討厭由于測試腳本自身的問(wèn)題或者是測試環(huán)境的問(wèn)題導致測試執行失敗，但是，對于自動(dòng)化測試誤報告警的情況，大家往往無(wú)能為力。你期望自己設計的測試對 BUG 很敏感、有效，當測試發(fā)現異常的時(shí)候，能夠報告測試執行失敗。有的測試框架支持對特殊測試結果的分類(lèi)方法，分類(lèi)包括 PASS ， FAIL 和第三種測試結果 NOTRUN 或者 UNRESOLVED 。無(wú)論你怎么稱(chēng)呼第三種測試結果，它很好的說(shuō)明了由于某些測試失敗導致其他測試用例無(wú)法執行而并非執行失敗的情況。得到正確的測試結果是自動(dòng)化測試完整性定義的一部分，另一部分是能夠確認執行成功的測試確確實(shí)實(shí)已經(jīng)執行過(guò)了。我曾經(jīng)在一個(gè)測試隊列中發(fā)現一個(gè) BUG ，這個(gè) BUG 引起測試隊列中部分測試用例被跳過(guò)，沒(méi)有執行。當測試隊列運行完畢后，沒(méi)有上報任何錯誤，我不得不通過(guò)走讀代碼的方式發(fā)現了這個(gè) BUG 。如果，我沒(méi)有關(guān)注到這個(gè) BUG ，那么可能在認識到自動(dòng)化測試已經(jīng)出現問(wèn)題之前，還在長(cháng)時(shí)間運行部分測試用例。
獨立性： 采用自動(dòng)化方法不可能達到和手工測試同樣的效果。當寫(xiě)手工測試執行的規程時(shí)候，通常假定測試執行將會(huì )由一個(gè)有頭腦、善于思考、具有觀(guān)察力的測試人員完成的。如果采用自動(dòng)化，測試執行是由一臺不會(huì )說(shuō)話(huà)的計算機完成的，你必須告訴計算機什么樣的情況下測試執行是失敗的，并且需要告訴計算機如何恢復測試場(chǎng)景才能保證測試套可以順利執行。自動(dòng)化測試可以作為測試套的一部分或者作為獨立的測試執行。測試都需要建立自己所需要的測試執行環(huán)境，因此，保證測試執行的獨立性是唯一的好方法。手工回歸測試通常都相關(guān)的指導文檔，以便一個(gè)接著(zhù)一個(gè)有序地完成測試執行，每個(gè)測試執行可以利用前一個(gè)測試執行創(chuàng )建的對象或數據記錄。手工測試人員可以清楚地把握整個(gè)測試過(guò)程。在自動(dòng)化測試中采用上述方法是經(jīng)常犯的錯誤，這個(gè)錯誤源于 “ 多米諾骨牌 ” 測試套，當一個(gè)測試執行失敗，會(huì )導致后續一系列測試失敗。更糟糕的是，所有的測試關(guān)聯(lián)緊密，無(wú)法獨立的運行。并且，這使得在自動(dòng)化測試中分析合法的執行失敗結果也困難重重。當出現這種情況后，人們首先開(kāi)始懷疑自動(dòng)化測試的價(jià)值。自動(dòng)化測試的獨立性要求在自動(dòng)化測試中增加重復和冗余設計。具有獨立性的測試對發(fā)現的缺陷的分析有很好的支持。以這種方式設計自動(dòng)化測試好像是一種低效率的方式，不過(guò)，重要的是在不犧牲測試的可靠性的前提下保證測試的獨立性，如果測試可以在無(wú)需人看守情況下運行，那么測試的執行效率就不是大問(wèn)題了。
可重復性： 自動(dòng)化測試有時(shí)能夠發(fā)現問(wèn)題，有時(shí)候又無(wú)法發(fā)現問(wèn)題，對這種情況實(shí)在沒(méi)有什么好的的處理辦法。因此，需要保證每次測試執行的時(shí)候，測試是以同樣的方式工作。這意味著(zhù)不要采用隨機數據，在通用語(yǔ)言庫中構造的隨機數據經(jīng)常隱藏初始化過(guò)程，使用這些數據會(huì )導致測試每次都以不同的方式執行，這樣，對測試執行的失敗結果分析是很讓人沮喪的。這里有兩個(gè)使用隨機數據發(fā)生器的的方法可以避免上述情況。一種方法是使用常量初始化隨機數據發(fā)生器。如果你打算生成不同種類(lèi)的測試，需要在可預測，并且可控制的情況下建立不同類(lèi)型的隨機數據發(fā)生器。另外一個(gè)辦法是提前在文件中或數據庫中建立生成隨機測試數據，然后在測試過(guò)程中使用這些數據。這樣做看起來(lái)似乎很好，但是我卻曾經(jīng)看到過(guò)太多違反規則的做法。下面我來(lái)解釋到底看到了什么。當手動(dòng)執行測試的時(shí)候，往往匆匆忙忙整理文件名和測試數據記錄。當對這些測試采用自動(dòng)化測試方法，該做哪些工作呢？辦法之一是，可以為測試中使用的數據記錄給固定的命名。如果這些數據記錄在測試完成后還要繼續使用，那么就需要制定命名規則，避免在不同的測試中命名沖突，采用命名規則是一種很好的方法。然而，我曾經(jīng)看到有些測試只是隨機的命名數據記錄，很不幸，事實(shí)證明采用這種隨機命名的方式不可避免的導致命名沖突，并且影響測試的可重復性。很顯然，自動(dòng)化工程師低估了命名沖突的可能性。下面的情況我遇到過(guò)兩次，測試數據記錄的名字中包含四個(gè)隨機產(chǎn)生的數字，經(jīng)過(guò)簡(jiǎn)單的推算如果我們采用這種命名方式的時(shí)候，如果測試使用了 46 條記錄，會(huì )存在 10% 沖突的可能性，如果使用 118 條記錄，沖突的幾率會(huì )達到 50% 。我認為測試當中使用這種隨機命名是出于偷懶的想法 —— 避免再次測試之前寫(xiě)代碼清除老的數據記錄，這樣引入了問(wèn)題，損害了測試的可靠性和測試的完整性。
測試庫： 自動(dòng)化測試的一個(gè)通用策略是開(kāi)發(fā)可以在不同測試中應用的測試函數庫。我曾經(jīng)看到過(guò)很多測試函數庫，自己也寫(xiě)了一些。當要求測試不受被測試產(chǎn)品接口變動(dòng)影響的時(shí)候，采用測試庫方法是非常有效的。不過(guò)，根據我的觀(guān)察測試庫已經(jīng)使用的太多了，已經(jīng)被濫用了，并且測試庫往往設計的不好，沒(méi)有相關(guān)的文檔支撐，因此，使用測試庫的測試往往很難開(kāi)展。當發(fā)現問(wèn)題的時(shí)候，往往不知道是測試庫自身的問(wèn)題，還是測試庫的使用問(wèn)題。由于測試庫往往很復雜，即便在發(fā)現測試庫存在問(wèn)題，相關(guān)的維護人員也很不愿意去修改問(wèn)題。通過(guò)前文中的論述，可以得出結論，在一開(kāi)始就應該保證測試庫設計良好。但是，實(shí)際情況是測試自動(dòng)化往往沒(méi)有花費更多的精力去保證一個(gè)優(yōu)良設計的測試庫。我曾經(jīng)看到有些測試庫中的功能根本不再使用了或僅僅使用一次。這與極限編程原則保持一致，即 " 你將不需要它 " 。這會(huì )導致在測試用例之間的代碼出現一些重復，我發(fā)現微小的變化可能仍然存在，很難與測試庫功能協(xié)調。你可能打算對測試用例作修改，采用源代碼的方式比采用庫的方式更容易修改。如果有幾個(gè)測試，他們有某些共同的操作，我使用剪切和粘貼的方式去復制代碼，有的人認為我采用的方法不可理喻。這允許我根據需要修改通用代碼，我不必一開(kāi)始嘗試和猜測如何重用代碼。我認為我的測試是很容易讀懂的，因為閱讀者不必關(guān)心任何測試庫的語(yǔ)法。這種辦法的優(yōu)勢是很容易理解測試，并且很方便擴展測試套。在開(kāi)發(fā)軟件測試項目的時(shí)候，大多數程序員找到與他們打算實(shí)現功能類(lèi)似的源代碼，并對源代碼做修改，而不是從頭開(kāi)始寫(xiě)代碼。同樣，在寫(xiě)測試套的過(guò)程中可以采用上述方法，這也是代碼開(kāi)發(fā)方式所鼓勵的方法。我比較喜歡寫(xiě)一些規模比較小的測試庫，這些庫可以被反復的使用。測試庫的開(kāi)發(fā)需要在概念階段充分定義，并且文檔化，從始至終都應該保持。我會(huì )對測試庫作充分的測試后，才在測試中使用這些測試庫。采用測試庫是對所有面臨的情況作權衡的。千萬(wàn)不要打算寫(xiě)一個(gè)大而全的測試庫，不要希望有朝一日測試人員會(huì )利用你的測試庫完成大量的測試，這一天恐怕永遠不會(huì )到來(lái)。
數據驅動(dòng)測試： 把測試數據寫(xiě)入到簡(jiǎn)單表格中，這種測試技術(shù)得到了越來(lái)越廣泛的應用，這種方法被稱(chēng)為表驅動(dòng)（ table-driven ），數據驅動(dòng) (data-driven) 或者 “ 第三代 ” 自動(dòng)化測試（ "third generation" automation ）。這需要寫(xiě)一個(gè)解析器，用來(lái)解釋表格中的數據，并執行測試。該測試架構的最主要的好處是，它允許把測試內容寫(xiě)在具有一定格式的表格中，這樣方便數據設計和數據的檢視。如果測試組中有缺少編程經(jīng)驗的業(yè)務(wù)專(zhuān)家參與測試，采用數據驅動(dòng)測試方法是很合適的。數據驅動(dòng)測試的解析器主要是由測試庫和上層的少量開(kāi)發(fā)語(yǔ)言寫(xiě)成的代碼組成的，所以，上面關(guān)于測試庫的說(shuō)明放在這里是同樣合適的。在針對上面提到的少量代碼的設計、開(kāi)發(fā)、測試的工作，還存在各種困難。代碼所采用的編程語(yǔ)言是不斷發(fā)展的。也許，測試人員認為他們需要把第一部分測試的輸出作為第二部分測試的輸入，這樣，加入了新的變量。接下來(lái)，也許有人需要讓測試中的某個(gè)環(huán)節運行一百次，這樣加入一個(gè)循環(huán)。你可以采用其他語(yǔ)言，不過(guò)，如果你預料到會(huì )面臨上述情況的時(shí)候，那么做好采用一些能夠通過(guò)公開(kāi)的渠道獲取的編程語(yǔ)言，比如 Perl,Python 或者 TCL ，這樣比設計你自己的語(yǔ)言要快的多。
啟發(fā)式確認： 我曾經(jīng)看到很多測試自動(dòng)化沒(méi)有真正意義上的結果校驗，其原因有兩個(gè)，一個(gè)原因是做完全意義上的自動(dòng)化測試結果確認從技術(shù)上講是很困難的，另外一個(gè)原因是通過(guò)測試設計規格很難找出自動(dòng)化測試的預期結果。這很不幸。不過(guò)，采用手工校驗測試結果的方法是真正意義上的測試校驗。標準文件（ Gold file ）是另外一中校驗測試結果的方法。首先，捕獲被測試程序的輸出，并檢視程序的輸出，然后，把輸出信息文檔化，并歸檔，作為標準文件。以后，自動(dòng)化測試結果與標準文件作比較，從而達到結果校驗的目的。采用標準文件的方法，也有弊端。當產(chǎn)品發(fā)生變化，自動(dòng)化測試的環(huán)境配置發(fā)生變化，產(chǎn)品的輸出發(fā)生變化的時(shí)候，采用標準文方法，會(huì )上報大量的誤報告警。做好的測試結果校驗方法是，對輸出結果的特定內容作分析，并作合理的比較。有時(shí)候，很難知道正確的輸出結果是什么樣的，但是你應該知道錯誤的輸出結果是什么樣的。開(kāi)展啟發(fā)式的結果校驗是很有幫助的。我猜想一些人在自動(dòng)化測試中設計了大而全的測試結果校驗方法，是因為擔心如果結果校驗漏掉了任何信息，可能導致自動(dòng)化測試自身出現錯誤。不過(guò)，我們在測試過(guò)程中往往采用折衷的做法，沒(méi)有采用大而全的測試結果校驗方法，這樣就不得不面對少量漏測情況的出現的風(fēng)險。自動(dòng)化測試不能改變這種情況的出現。如果自動(dòng)化工程師不習慣采用這種折衷的方法，那么他必須找相關(guān)人員咨詢(xún)，尋找一種合適的測試結果校驗策略，這需要有很大的創(chuàng )造性。目前有很多技術(shù)可以保證在不產(chǎn)生誤報告警的情況下，找到被測試產(chǎn)品的缺陷。
把注意力放在通過(guò)設計保證測試的可延續性上，選擇一個(gè)合適的測試體系架構，你將進(jìn)一步邁向成功的自動(dòng)化測試。
步驟六：有計劃的部署
在前面的故事中，當自動(dòng)化工程師沒(méi)有提供打包后的自動(dòng)化測試程序給測試執行人員，會(huì )影響到測試執行，測試執行人員不得不反過(guò)來(lái)求助自動(dòng)化工程師指出如何使用自動(dòng)化測試程序。
作為自動(dòng)化工程師，你知道如何利用自動(dòng)化方法執行測試和分析執行失敗的結果。不過(guò)，測試執行人員卻未必知道如何使用自動(dòng)化測試。因此，需要提供自動(dòng)化測試程序的安裝文檔和使用文檔，保證自動(dòng)化測試程序容易安裝和配置。當安裝的環(huán)境與安裝的要求不匹配，出現安裝錯誤的時(shí)候，能夠給出有價(jià)值的提示信息，便于定位安裝問(wèn)題。
能夠把自動(dòng)化測試程序和測試套作為產(chǎn)品對待，那真是太好了。你應該對自動(dòng)化測試程序和測試套開(kāi)展測試，保證它們不依賴(lài)于任何專(zhuān)用的庫或者是設備上的任何其他程序。
保證其他測試人員能夠隨時(shí)利用已經(jīng)提供的自動(dòng)化測試程序和測試套開(kāi)展測試工作；保證自動(dòng)化測試是符合一般測試執行人員的思維習慣的；保證測試執行人員能夠理解測試結果，并能夠正確分析失敗的測試執行結果；這需要自動(dòng)化工程師提供自動(dòng)動(dòng)化測試相關(guān)的指導性文檔和培訓。
作為測試管理者，你希望在自動(dòng)化工程師離開(kāi)前，能夠識別并修改測試套中的所有問(wèn)題。自動(dòng)化工程師遲早會(huì )離開(kāi)的，如果你沒(méi)有及時(shí)的把測試套中的問(wèn)題提出來(lái)，就會(huì )面臨廢棄已有的測試套的決定。
良好的測試套有多方面的用處。良好的測試套支持對產(chǎn)品新版本的測試；良好的測試套在新的軟件平臺上可以很方便的驗證產(chǎn)品的功能；良好的測試套支持每天晚上開(kāi)始的軟件每日構造過(guò)程；甚至開(kāi)發(fā)人員在代碼 check in 之前，用良好的測試套驗證代碼的正確性。
測試套的共享也很重要。很難預見(jiàn)以后什么人會(huì )繼續使用你開(kāi)發(fā)的測試套。因此，盡量讓產(chǎn)品開(kāi)發(fā)測試團隊中的成員都很容易獲得你的測試套?？梢园褱y試套放在公司的內部網(wǎng)絡(luò )上，這是個(gè)很好的辦法。這樣，大家就不必為了獲取一份需要的測試套而四處打聽(tīng)。有些人總是感覺(jué)自己的測試套還沒(méi)有最終完工或者不夠完美，而沒(méi)有拿出來(lái)與人分享，這種做法一定要改變，共享出來(lái)的測試套不一定非常完美，共享才是關(guān)鍵。
有計劃的自動(dòng)化測試部署，保證你的測試套能夠被產(chǎn)品相關(guān)人員獲取到，你就向成功的自動(dòng)化測試又邁進(jìn)了一步。并且你的自動(dòng)化測試會(huì )被一次又一次的重用。
步驟七：面對成功的挑戰
當你完成了所有的事情，測試套已經(jīng)文檔化了，并且文檔已經(jīng)交付了。測試執行人員能夠理解要開(kāi)展的測試，并知道如何完成測試執行。隨著(zhù)你所負責產(chǎn)品的進(jìn)一步開(kāi)發(fā)和維護，測試被反復重用。雖然，在自動(dòng)化使測試變簡(jiǎn)單的同時(shí)，也總是使測試過(guò)程復雜化。測試人員需要學(xué)習如何診斷自動(dòng)化測試執行失敗的情況，如果不這樣做，測試執行人員會(huì )認為執行失敗的情況是由自動(dòng)化引起，然后，自動(dòng)化工程師被叫過(guò)來(lái)幫助診斷每一個(gè)執行失敗的情況，開(kāi)發(fā)人員往往也會(huì )認為執行失敗是由于自動(dòng)化測試自身引起的問(wèn)題，這樣，測試執行人員就不得不學(xué)習通過(guò)手工的方式，或者通過(guò)采用少量腳本的方式重現自動(dòng)化測試發(fā)現的問(wèn)題，以證明他們確實(shí)發(fā)現了產(chǎn)品當中的 BUG 。
測試套的相關(guān)工作還沒(méi)有結束，為了提高測試覆蓋率或者測試新的產(chǎn)品特性，需要增加更多的測試。如果已有的測試不能正常工作，那么需要對之修改；如果已有的測試是冗余的，那么需要刪除這部分測試。
隨著(zhù)時(shí)間的推移，開(kāi)發(fā)人員也會(huì )研究你設計的測試，改進(jìn)產(chǎn)品的設計并且通過(guò)模擬你的測試過(guò)程對產(chǎn)品做初步測試，研究如何使產(chǎn)品在第一次測試就通過(guò)，這樣，你設計的測試很可能無(wú)法繼續發(fā)現新的問(wèn)題，這種現象被稱(chēng)為一種殺蟲(chóng)劑悖論。這時(shí)候，會(huì )有人對你的測試有效性提出質(zhì)疑，那么，你必須考慮是否應該挖掘更嚴格的測試，以便能夠發(fā)現開(kāi)發(fā)人員優(yōu)化之后的產(chǎn)品中的缺陷。
以前，我提到過(guò)一個(gè)基本上無(wú)法實(shí)現的設想，設想通過(guò)按下一個(gè)按鈕就完成了所有的測試工作。自動(dòng)化測試是不是全能的，手工測試是永遠無(wú)法完全替代的。
有些測試受測試環(huán)境的影響很大，往往需要采用人工方法獲取測試結果，分析測試結果。因此，很難在預先知道設計的測試用例有多大的重用性。自動(dòng)化測試還需要考慮成本問(wèn)題，因此，千萬(wàn)不要陷入到一切測試都采用自動(dòng)化方法的錯誤觀(guān)念中。
我曾經(jīng)主張保證給與測試自動(dòng)化持續不斷的投入。但是，在開(kāi)展自動(dòng)化測試的時(shí)候，一個(gè)問(wèn)題擺在面前，測試自動(dòng)化應該及時(shí)的提供給測試執行人員，這個(gè)不成問(wèn)題，但是如何保證需求變更后，能夠及時(shí)提供更新后的自動(dòng)化測試就是個(gè)大問(wèn)題了。如果自動(dòng)化測試與需求變更無(wú)法同步，那么自動(dòng)化測試的效果就無(wú)法保證了，測試人員就不愿意花費時(shí)間學(xué)習如何使用新的測試工具和如何診斷測試工具上報的錯誤。識別項目計劃中的軟件發(fā)布日期，然后把這個(gè)日期作為里程碑，并計劃達到這個(gè)里程碑。當達到這個(gè)里程碑后，自動(dòng)化工程師應該做什么呢？如果自動(dòng)化工程師關(guān)注當前產(chǎn)品版本的發(fā)布，他需要為測試執行人員提供幫助和咨詢(xún)，但是，一旦測試執行人員知道如何使用自動(dòng)化測試，自動(dòng)化測試工程師可以考慮下一個(gè)版本的測試自動(dòng)化工作，包括改進(jìn)測試工具和相關(guān)的庫。當開(kāi)發(fā)人員開(kāi)始設計產(chǎn)品下一個(gè)版本中的新特性的時(shí)候，如果考慮了自動(dòng)化測試需求，那么自動(dòng)化測試師的設計工作就很好開(kāi)展了，采用這種方法，自動(dòng)化測試工程師可以保持與開(kāi)發(fā)周期同步，而不是與測試周期同步。如果不采用這種方式，在產(chǎn)品版本升級的過(guò)程中，自動(dòng)化測試無(wú)法得到進(jìn)一步的改進(jìn)。
持續在在自動(dòng)化投入，你會(huì )面臨成功的挑戰，當自動(dòng)化測試成為測試過(guò)程可靠的基礎后，自動(dòng)化測試的道路將會(huì )越來(lái)越平坦。
參考文獻：
Bach, James. 1996. “Test Automation Snake Oil.” Windows Technical Journal , (October): 40-44.
http://www.satisfice.com/articles/test_automation_snake_oil.pdf Dustin, Elfriede. 1999. “Lessons in Test Automation.” Software Testing and Quality Engineering (September): 16-22.
http://www.stickyminds.com/sitewide.asp?ObjectId=1802&ObjectType=ART&Function=edetail Fewster, Mark and Dorothy Graham. 1999. Software Test Automation , Addison-Wesley.
Groder, Chip. “Building Maintainable GUI Tests” in [Fewster 1999].
Kit, Edward. 1999. “Integrated, Effective Test Design and Automation.” Software Development (February).
http://www.sdmagazine.com/articles/1999/9902/9902b/9902b.htm Hancock, Jim. 1997 “When to Automate Testing.” Testers Network (June).
http://www.data-dimensions.com/Testers‘Network/jimauto1.htm Hendrickson, Elisabeth. 1999. “Making the Right Choice: The Features you Need in a GUI Test Automation Tool.” Software Testing and Quality Engineering Magazine (May): 21-25.
http://www.qualitytree.com/feature/mtrc.pdf Hoffman, Douglas. 1999. “Heuristic Test Oracles: The Balance Between Exhaustive Comparison and No Comparison at All.” Software Testing and Quality Engineering Magazine (March): 29-32.
Kaner, Cem. 1997. “Improving the Maintainability of Automated Test Suites.” Presented at Quality Week.
http://www.kaner.com/lawst1.htm Linz , Tilo and Matthias Daigl. 1998. “How to Automate Testing of Graphical User Interfaces.” European Systems and Software Initiative Project No. 24306 (June).
http://www.imbus.de/html/GUI/AQUIS-full_paper-1.3.html Jeffries, Ronald E., 1997, “XPractices,”
http://www.XProgramming.com/Practices/xpractices.htm Marick, Brian. 1998. “When Should a Test Be Automated?” Presented at Quality Week.
http://www.testing.com/writings/automate.pdf Marick, Brian. 1997. “Classic Testing Mistakes.” Presented at STAR.
http://www.testing.com/writings/classic/mistakes.html Pettichord, Bret. 1996. “Success with Test Automation.” Presented at Quality Week (May).
http://www.io.com/~wazmo/succpap.htm Thomson, Jim. “A Test Automation Journey” in [Fewster 1999]
Weinberg, Gerald M. 1992. Quality Software Management: Systems Thinking . Vol 1. Dorset House.
