摘要：本文介紹自動(dòng)化測試的7個(gè)步驟：改進(jìn)自動(dòng)化測試過程，定義需求，驗(yàn)證概念，支持產(chǎn)品的可測試性，具有可延續(xù)性的設(shè)計(jì)，有計(jì)劃的部署和面對成功的挑戰(zhàn)。按照以上7個(gè)步驟，安排你的人員、工具和制定你的自動(dòng)化測試項(xiàng)目計(jì)劃，你將會(huì)通往一條成功之路。
　　
　　步驟一：改進(jìn)軟件測試過程
　　
　　如果你負(fù)責(zé)提高一個(gè)商業(yè)交易操作的效率，首先，你應(yīng)該確認(rèn)已經(jīng)很好的定義了這個(gè)操作的具體過程。然后，在你投入時(shí)間和金錢采用計(jì)算機(jī)提供一套自動(dòng)化的商業(yè)交易操作系統(tǒng)之前，你想知道是否可以采用更簡單、成本更低的的方法。同樣的，上述過程也是用于自動(dòng)化測試。我更愿意把“測試自動(dòng)化”這個(gè)詞解釋成能夠使測試過程簡單并有效率，使測試過程更為快捷，沒有延誤。運(yùn)行在計(jì)算機(jī)上的自動(dòng)化測試腳本只是自動(dòng)化測試的一個(gè)方面而已。
　　
　　例如，很多測試小組都是在回歸測試環(huán)節(jié)開始采用測試自動(dòng)化的方法。回歸測試需要頻繁的執(zhí)行，再執(zhí)行，去檢查曾經(jīng)執(zhí)行過的有效的測試用例沒有因?yàn)檐浖淖儎?dòng)而執(zhí)行失敗。回歸測試需要反復(fù)執(zhí)行，并且單調(diào)乏味。怎樣才能做好回歸測試文檔化的工作呢？通常的做法是采用列有產(chǎn)品特性的列表，然后對照列表檢查。這是個(gè)很好的開始，回歸測試檢查列表可以告訴你應(yīng)該測試哪些方面。不過，回歸測試檢查列表只是合于那些了解產(chǎn)品，并且知道需要采用哪種測試方法的人。
　　
　　在你開始測試自動(dòng)化之前，你需要完善上面提到的回歸測試檢查表，并且，確保你已經(jīng)采用了確定的的測試方法，指明測試中需要什么樣的數(shù)據(jù)，并給出設(shè)計(jì)數(shù)據(jù)的完整方法。如果測試掌握了基本的產(chǎn)品知識，這會(huì)更好。確認(rèn)可以提供上面提到的文檔后，需要明確測試設(shè)計(jì)的細(xì)節(jié)描述，還應(yīng)該描述測試的預(yù)期結(jié)果，這些通常被忽略，建議測試人員知道。太多的測試人員沒有意識到他們?nèi)鄙偈裁矗⑶矣捎诤ε聦擂味桓胰デ笾＿@樣一份詳細(xì)的文檔給測試小組帶來*的效果，因?yàn)椋F(xiàn)在任何一個(gè)具有基本產(chǎn)品知識的人根據(jù)文檔可以開展測試執(zhí)行工作了。在開始更為*意義上的測試自動(dòng)化之前，必須已經(jīng)完成了測試設(shè)計(jì)文檔。測試設(shè)計(jì)是測試自動(dòng)化zui主要的測試需求說明。不過，這時(shí)候千萬不要走去過分細(xì)致地說明測試執(zhí)行的每一個(gè)步驟，只要確保那些有軟件基本操作常識的人員可以根據(jù)文檔完成測試執(zhí)行工作既可。但是，不要假定他們理解那些存留在你頭腦中的軟件測試執(zhí)行的想法，把這些測試設(shè)計(jì)的思路描述清楚就可以了。
　　
　　我以前負(fù)責(zé)過一個(gè)軟件模塊的自動(dòng)化測試工作。這個(gè)模塊的一些特性導(dǎo)致實(shí)現(xiàn)自動(dòng)化非常困難。當(dāng)我了解到這項(xiàng)工作無需在很短的時(shí)間內(nèi)完成后，決定制定一個(gè)詳細(xì)回歸測試設(shè)計(jì)方案。我仔細(xì)地檢查了缺陷跟蹤庫中與該模塊相關(guān)的每個(gè)已經(jīng)關(guān)閉的缺陷，針對每個(gè)缺陷，我寫了一個(gè)能夠發(fā)現(xiàn)該問題的測試執(zhí)行操作。我計(jì)劃采用這種方法提供一個(gè)詳細(xì)的自動(dòng)化需求列表，這可以告訴我模塊的那一部分自動(dòng)化測試。在完成上述工作后，我沒有機(jī)會(huì)完成測試自動(dòng)化的實(shí)現(xiàn)工作。不過，當(dāng)我們需要對這個(gè)模塊做完整回歸測試的時(shí)候，我將上面提到的文檔提供給若干只了解被測試產(chǎn)品但是沒有測試經(jīng)驗(yàn)的測試人員。依照文檔的指導(dǎo)，幾乎不需要任何指導(dǎo)的情況下，各自完成了回歸測試，并且發(fā)現(xiàn)了BUG。從某種角度看，這實(shí)際上是一次很成功的自動(dòng)化測試。在這個(gè)項(xiàng)目中，我們與其開發(fā)自動(dòng)化測試腳本，還不如把測試執(zhí)行步驟文檔化。后來，在其它項(xiàng)目中，我們開發(fā)了自動(dòng)化測試腳本，發(fā)現(xiàn)相關(guān)人員只有接受相關(guān)培訓(xùn)才能理解并執(zhí)行自動(dòng)化測試腳本，如果測試自動(dòng)化設(shè)計(jì)的很好，可能會(huì)好一些。不過，經(jīng)過實(shí)踐我們總結(jié)出完成一份設(shè)計(jì)的比較好的測試文檔，比完成一份設(shè)計(jì)良好的測試腳本簡單的多。
　　
　　另外一個(gè)提高測試效率的簡單方法是采用更多的計(jì)算機(jī)。很多測試人員動(dòng)輒動(dòng)用幾臺計(jì)算機(jī)，這一點(diǎn)顯而易見。我之所以強(qiáng)調(diào)采用更多的計(jì)算機(jī)是因?yàn)椋以?jīng)看到一些測試人員被誤導(dǎo)在單機(jī)上努力的完成某些大容量的自動(dòng)化測試執(zhí)行工作，這種情況下由于錯(cuò)誤的使用了測試設(shè)備、測試環(huán)境，導(dǎo)致測試沒有效果。因此，自動(dòng)化測試需要集中考慮所需要的支撐設(shè)備。
　　
　　針對改進(jìn)軟件測試過程，我的zui后一個(gè)建議是改進(jìn)被測試的產(chǎn)品，使它更容易被測試，有很多改進(jìn)措施既可以幫助用戶更好的使用產(chǎn)品，也可以幫助測試人員更好的測試產(chǎn)品。稍后，我將討論自動(dòng)化測試的可測試需求。這里，我只是建議給出產(chǎn)品的改進(jìn)點(diǎn)，這樣對手工測試大有幫助。
　　
　　一些產(chǎn)品非常難安裝，測試人員在安裝和卸載軟件上花費(fèi)大量的時(shí)間。這種情況下，與其實(shí)現(xiàn)產(chǎn)品安裝的自動(dòng)化測試，還不如改進(jìn)產(chǎn)品的安裝功能。采用這種解決辦法，zui終的用戶會(huì)受益的。另外的一個(gè)處理方法是考慮開發(fā)一套自動(dòng)安裝程序，該程序可以和產(chǎn)品一同發(fā)布。事實(shí)上，現(xiàn)在有很多專門制作安裝程序的商用工具。
　　
　　另一些產(chǎn)品改進(jìn)需要利用工具在測試執(zhí)行的日志中查找錯(cuò)誤。采用人工方法，在日志中一頁一頁的查詢報(bào)錯(cuò)信息很容易會(huì)讓人感到乏味。那么，趕快采用自動(dòng)化方法吧。如果你了解日志中記錄的錯(cuò)誤信息格式，寫出一個(gè)錯(cuò)誤掃描程序是很容易的事情。如果，你不能確定日志中的錯(cuò)誤信息格式，就開始動(dòng)手寫錯(cuò)誤掃描程序，很可能面臨的是一場災(zāi)難。不要忘記本文開篇講的那個(gè)故事中提到的測試套無法判斷測試用例是否執(zhí)行失敗的例子。zui終用戶也不愿意采用通過搜索日志的方法查找錯(cuò)誤信息。修改錯(cuò)誤信息的格式，使其適合日志掃描程序，便于掃描工具能夠準(zhǔn)確的掃描到所有的錯(cuò)誤信息。這樣，在測試中就可以使用掃描工具了。
　　
　　通過改進(jìn)產(chǎn)品的性能對測試也是大有幫助的。很顯然的，如果產(chǎn)品的性能影響了測試速度，鑒別出性能比較差的產(chǎn)品功能，并度量該產(chǎn)品功能的性能，把它作為影響測試進(jìn)度的缺陷，提交缺陷報(bào)告。
　　
　　上面所述的幾個(gè)方面可以在無需構(gòu)建自動(dòng)化測試系統(tǒng)的情況下，大幅度的提高測試效率。改進(jìn)軟件測試過程會(huì)花費(fèi)你構(gòu)建自動(dòng)化測試系統(tǒng)的時(shí)間，不過改進(jìn)測試過程無疑可以使你的自動(dòng)化測試項(xiàng)目更為順利開展起來。
　　
　　步驟二：定義需求
　　
　　在前面的故事中，自動(dòng)化工程師和自動(dòng)化測試的發(fā)起者的目標(biāo)存在偏差。為了避免這種情況，需要在自動(dòng)化測試需求上保持一致。應(yīng)該有一份自動(dòng)化測試需求，用來描述需要測試什么。測試需求應(yīng)該在測試設(shè)計(jì)階段詳細(xì)描述出來，自動(dòng)化測試需求描述了自動(dòng)化測試的目標(biāo)。很多人認(rèn)為自動(dòng)化測試顯然是一件好事情，但是，他們不愿意對自動(dòng)化測試的目標(biāo)給出清晰的描述。下面是人們選用自動(dòng)化測試的幾個(gè)原因：
　　
　　加快測試進(jìn)度從而加快產(chǎn)品發(fā)布進(jìn)度
　　
　　更多的測試
　　
　　通過減少手工測試降低測試成本
　　
　　提高測試覆蓋率
　　
　　保證一致性
　　
　　提高測試的可靠性
　　
　　測試工作可以由技術(shù)能力不強(qiáng)測試人員完成
　　
　　定義測試過程，避免過分依賴個(gè)人
　　
　　測試變得更加有趣
　　
　　提高了編程技能
　　
　　開發(fā)管理、測試管理和測試人員實(shí)現(xiàn)自動(dòng)化測試的目標(biāo)常常是有差別的。除非三者之間達(dá)成一致，否則很難定義什么是成功的自動(dòng)化測試。
　　
　　當(dāng)然，不同的情況下，有的自動(dòng)化測試目標(biāo)比較容易達(dá)到，有的則比較難以達(dá)到。測試自動(dòng)化往往對測試人員的技術(shù)水平要求很高，測試人員必須能理解充分的理解自動(dòng)化測試，從而通過自動(dòng)化測試不斷發(fā)現(xiàn)軟件的缺陷。不過，自動(dòng)化測試不利于測試人員不斷的積累測試經(jīng)驗(yàn)。不管怎么樣，在開始自動(dòng)化測試之前應(yīng)該確定自動(dòng)化測試成功的標(biāo)準(zhǔn)。
　　
　　手工測試人員在測試執(zhí)行過程中的一些操作能夠發(fā)現(xiàn)不引人注意的問題。他們計(jì)劃并獲取必要的測試資源，建立測試環(huán)境，執(zhí)行測試用例。測試過程中，如果有什么異常的情況發(fā)生，手工測試人員立刻可以關(guān)注到。他們對比實(shí)際測試結(jié)果和預(yù)期測試結(jié)果，記錄測試結(jié)果，復(fù)位被測試的軟件系統(tǒng)，準(zhǔn)備下一個(gè)軟件測試用例的環(huán)境。他們分析各種測試用例執(zhí)行失敗的情況，研究測試過程可疑的現(xiàn)象，尋找測試用例執(zhí)行失敗的過程，設(shè)計(jì)并執(zhí)行其他的測試用例幫助定位軟件缺陷。接下來，他們寫作缺陷報(bào)告單，保證缺陷被修改，并且總結(jié)所有的缺陷報(bào)告單，以便其他人能夠了解測試的執(zhí)行情況。
　　
　　千萬不要強(qiáng)行在測試的每個(gè)部分都采用自動(dòng)化方式。尋找能夠帶來zui大回報(bào)的部分，部分的采用自動(dòng)化測試是的方法。或許你可能發(fā)現(xiàn)采用自動(dòng)化執(zhí)行和手動(dòng)確認(rèn)測試執(zhí)行結(jié)果的方式是個(gè)很好的選擇，或許你可以采用自動(dòng)化確認(rèn)測試結(jié)果和手工測試執(zhí)行相結(jié)合和方式。我聽到有人講，除非測試的各個(gè)環(huán)節(jié)都采用自動(dòng)化方式，否則不是真正意義上的自動(dòng)化測試，這真是胡言亂語。如果僅僅是為了尋找挑戰(zhàn)，可以嘗試在測試的每個(gè)環(huán)節(jié)都采用自動(dòng)化方法。但是，如果尋找成功測試的方法，請關(guān)注那些可以快速建立的，可以反復(fù)利用的自動(dòng)化測試。
　　
　　定義自動(dòng)化測試項(xiàng)目的需求要求我們?nèi)娴亍⑶宄乜紤]各種情況，然后給出權(quán)衡后的需求，并且可以使測試相關(guān)人員更加合理的提出自己對自動(dòng)化測試的期望。通過定義自動(dòng)化測試需求，距離成功的自動(dòng)化測試近了一步。
　　
　　步驟三：驗(yàn)證概念
　　
　　在前面的故事當(dāng)中，那個(gè)自動(dòng)化測試人員在對測試方向一片茫然的情況下一頭扎進(jìn)了自動(dòng)化測試項(xiàng)目中。不過，在項(xiàng)目的進(jìn)行中，他得到了來自各個(gè)方面的支持。
　　
　　你可能還沒有認(rèn)識到這一點(diǎn)，不過，你必須驗(yàn)證自動(dòng)化測試項(xiàng)目的可行性。驗(yàn)證過程花費(fèi)的時(shí)間往往比人們預(yù)期的要長，并且需要來自你身邊的各種人的幫助。
　　
　　很多年前，我從事一個(gè)測試自動(dòng)化項(xiàng)目的工作，參加項(xiàng)目的人員有各種各樣的好點(diǎn)子。我們設(shè)計(jì)了一個(gè)復(fù)雜的自動(dòng)化測試系統(tǒng)，并且非常努力工作去實(shí)現(xiàn)系統(tǒng)的每個(gè)模塊。我們定期的介紹測試自動(dòng)化的設(shè)計(jì)思路和工作進(jìn)度，甚至演示已經(jīng)完成的部分功能。但是，我們沒有演示如何利用該套測試自動(dòng)化系統(tǒng)如何開展實(shí)際的測試工作。zui后，整個(gè)項(xiàng)目被取消了，此后，我再也沒有犯這個(gè)錯(cuò)誤。
　　
　　你需要盡可能快地驗(yàn)證你采用的測試工具和測試方法的可行性，站在產(chǎn)品的角度驗(yàn)證你所測試的產(chǎn)品采用自動(dòng)化測試的可行性。這通常是很困難的，需要盡快地找出可行性問題的答案，需要確定你的測試工具和測試方法對于被測試的產(chǎn)品和測試人員是否合適。你需要做是驗(yàn)證概念——一個(gè)快速、有說服力的測試套可以證明你選在測試工具和測試方法的正確性，從而驗(yàn)證了你的測試概念。你選擇的用來驗(yàn)證概念的測試套是評估測試工具的的方式。
　　
　　對于很多人來說，自動(dòng)化測試意味著GUI自動(dòng)化測試，我不同意這種觀點(diǎn)。我曾經(jīng)做過GUI和非GUI自動(dòng)化測試，并驚奇的發(fā)現(xiàn)這兩類測試的測試計(jì)劃有很大的互補(bǔ)性。不過，GUI測試工具很昂貴、并且過分講究。選擇合適的GUI測試工具是很重要的，因?yàn)椋绻麤]有選擇合適的測試工具，你會(huì)遇到很多不可預(yù)測的困難。ElisabethHendrickson曾經(jīng)寫過一篇關(guān)于選擇測試的工具的指導(dǎo)性文章[Hendrickson1999]。我建議在評估測試工具中，找出能夠驗(yàn)證你的想法的證據(jù)是很重要的環(huán)節(jié)。這需要測試工具至少有一個(gè)月試用期，你可能打算現(xiàn)在購買一份測試工具，然后直到評估完成后再購買更多份。你需要在付出大筆金錢購買測試工具的之前，找出工具存在的問題。這樣，你可以從測試工具供應(yīng)商得到更好的幫助，當(dāng)你打算更換工具的時(shí)候，你不會(huì)感覺很為難。
　　
　　下面是一些候選的驗(yàn)證概念的試驗(yàn)：
　　
　　回歸測試：你準(zhǔn)備在每個(gè)版本運(yùn)行同樣的測試用例嗎？回歸測試是zui宜采用自動(dòng)化測試的環(huán)節(jié)。
　　
　　配置測試：你的軟件支持多少種不同的平臺？你打算在所有支持的平臺上測試執(zhí)行所有的測試用例嗎？如果是的，那么采用自動(dòng)化測試是有幫助的。
　　
　　測試環(huán)境建立：對于大量不同的測試用例，可能需要相同的測試環(huán)境搭建過程。在開展自動(dòng)化測試執(zhí)行之前，先把測試環(huán)境搭建實(shí)現(xiàn)自動(dòng)化。
　　
　　非GUI測試：實(shí)現(xiàn)命令行和API的測試自動(dòng)化比GUI自動(dòng)化測試容易的多。
　　
　　無論采用什么測試方法，定義一個(gè)看得見的目標(biāo)，然后集中在這個(gè)目標(biāo)上。驗(yàn)證你自動(dòng)化測試概念可以使自動(dòng)化更進(jìn)一步邁向成功之路。
　　
　　步驟四：支持產(chǎn)品的可測試性
　　
　　軟件產(chǎn)品一般會(huì)用到下面三種不同類別的接口：命令行接口（commandlineinterfaces，縮寫CLIs)、應(yīng)用程序接口（API）、圖形用戶接口（GUI）。有些產(chǎn)品會(huì)用到所有三類接口，有些產(chǎn)品只用到一類或者兩類接口，這些是測試中所需要的接口。從本質(zhì)上看，API接口和命令行接口比GUI接口容易實(shí)現(xiàn)自動(dòng)化，去找一找你的被測產(chǎn)品是否包括API接口或者命令行接口。有些時(shí)候，這兩類接口隱藏在產(chǎn)品的內(nèi)部，如果確實(shí)沒有，需要鼓勵(lì)開發(fā)人員在產(chǎn)品中提供命令行接口或者API接口，從而支持產(chǎn)品的可測試性。
　　
　　下面，更多多的講解GUI自動(dòng)化測試相關(guān)內(nèi)容。這里有幾個(gè)原因?qū)е翯UI自動(dòng)化測試比預(yù)期的要困難。*個(gè)原因是需要手工完成部分腳本。絕大多數(shù)自動(dòng)化測試工具都有“錄制回放”或者“捕捉回放”功能，這確實(shí)是個(gè)很好的方法。可以手工執(zhí)行測試用例，測試工具在后臺記住你的所有操作，然后產(chǎn)生可以用來重復(fù)執(zhí)行的測試用例腳本。這是一個(gè)很好的方法，但是很多時(shí)候卻不能奏效。很多軟件測試文章的作者得出結(jié)論“錄制回放”雖然可以生成部分測試腳本，但是有很多問題導(dǎo)致“錄制回放”不能應(yīng)用到整個(gè)測試執(zhí)行過程中。[Bach1996,Pettichord1996,Kaner1997,Linz1998,Hendrickson1999,Kit1999,Thomson1999,Groder1999].結(jié)果，GUI測試還是主要由手工完成。
　　
　　第二個(gè)原因，把GUI自動(dòng)化測試工和被測試的產(chǎn)品有機(jī)的結(jié)合在一起需要面臨技術(shù)上的挑戰(zhàn)。經(jīng)常要在采用眾多專家意見和的GUI接口技術(shù)才能使GUI測試工具正常工作。這個(gè)主要的困難也是GUI自動(dòng)化測試工具價(jià)格昂貴的主要原因之一。非標(biāo)準(zhǔn)的、定制的控件會(huì)增加測試的困難，解決方法總是有的，可以采用修改產(chǎn)品源代碼的方式，也可以從測試工具供應(yīng)商處升級測試工具。另外，還需要分析測試工具中的BUG，并且給工具打補(bǔ)丁。也可能測試工具需要做相當(dāng)?shù)亩ㄖ疲员隳苡行У販y試產(chǎn)品界面上的定制控件。GUI測試中，困難總是意外出現(xiàn)，讓人驚奇。你也可能需要重新設(shè)計(jì)你的測試以規(guī)避那些存在問題的界面控件。
　　
　　第三個(gè)原因，GUI設(shè)計(jì)方案的變動(dòng)會(huì)直接帶來GUI自動(dòng)化測試復(fù)雜度的提高。在開發(fā)的整個(gè)過程中，圖形界面經(jīng)常被修改或者*重設(shè)計(jì)，這是出了名的事情。一般來講，*個(gè)版本的圖形界面都是很糟糕。如果處在圖形界面方案不停變動(dòng)的時(shí)候，就開展GUI自動(dòng)化測試是不會(huì)有任何進(jìn)展的，你只能花費(fèi)大量的時(shí)間修改測試腳本，以適應(yīng)圖形界面的變更。不管怎樣，即便界面的修改會(huì)導(dǎo)致測試修改腳本，你也不應(yīng)該反對開發(fā)人員改進(jìn)圖形界面。一旦原始的設(shè)計(jì)完成后，圖形界面接口下面的編程接口就固定下來了。
　　
　　上面提到的這些原因都是基于采用GUI自動(dòng)化測試的方法完成產(chǎn)品的功能測試。圖形界面接口當(dāng)然需要測試，可以考慮實(shí)現(xiàn)GUI測試自動(dòng)化。不過，你也應(yīng)該考慮采用其他方法測試產(chǎn)品的核心功能，并且這些測試不會(huì)因?yàn)閳D形界面發(fā)生變化而被中斷，這類測試應(yīng)該采用命令行接口或者API接口。我曾經(jīng)看到有人選擇GUI自動(dòng)化測試，因?yàn)椋麄儾淮蛩阈薷谋粶y試產(chǎn)品，但是，zui終他們認(rèn)識到必須對產(chǎn)品做修改，以保證GUI測試自動(dòng)化可以正常工作。無論你選擇哪種方法，自動(dòng)化都需要對被測試的產(chǎn)品做修改。因此，采用可編程的接口是zui可靠的。
　　
　　為了讓API接口測試更為容易，應(yīng)該把接口與某種解釋程序，例如Tcl、Perl或者Python綁定在一起。這使交互式測試成為可能，并且可以縮短自動(dòng)化測試的開發(fā)周期。采用API接口的方式，還可以實(shí)現(xiàn)獨(dú)立的產(chǎn)品模塊的單元測試自動(dòng)化。
　　
　　一個(gè)關(guān)于隱藏可編程接口的例子是關(guān)于InstallShield——非常流行的制作安裝盤的工具。InstallShield有命令行選項(xiàng)，采用這種選項(xiàng)可以實(shí)現(xiàn)非GUI方式的安裝盤，采用這種方式，從提前創(chuàng)建好的文件中讀取安裝選項(xiàng)。這種方式可能比采用GUI的安裝方式更簡單更可靠。
　　
　　另一個(gè)例子是關(guān)于如何避免基于WEB軟件的GUI自動(dòng)化測試。采用GUI測試工具可以通過瀏覽器操作WEB界面。WEB瀏覽器是通過HTTP協(xié)議與WEB服務(wù)器交互的，所以直接測試HTTP協(xié)議更為簡單。Perl可以直接連接TCP/IP端口，完成這類的自動(dòng)化測試。采用接口技術(shù)，譬如客戶端JAVA或者ActiveX不可能利用這種方法。但是，如果在合適的環(huán)境中采用這種方式，你將發(fā)現(xiàn)這種方式的自動(dòng)化測試比GUI自動(dòng)化測試更加便宜更加簡單。
　　
　　我曾經(jīng)受雇在一家公司負(fù)責(zé)某個(gè)產(chǎn)品GUI相關(guān)的自動(dòng)化測試，該產(chǎn)品也提供命令行接口，不過，他們已經(jīng)實(shí)現(xiàn)了GUI的自動(dòng)化測試。經(jīng)過一段時(shí)間的研究，我發(fā)現(xiàn)找到圖形界面中的BUG并不困難，不過，用戶并不關(guān)注圖形界面，他們更喜歡使用命令行。我還發(fā)現(xiàn)我們還沒有針對的產(chǎn)品功能（這些功能即可通過GUI的方式，也可以通過命令行的方式使用）實(shí)現(xiàn)自動(dòng)化測試。我決定推遲GUI自動(dòng)化測試，擴(kuò)展命令行測試套，測試新增的產(chǎn)品功能。現(xiàn)在回過頭看這個(gè)決定，我沒有選擇GUI自動(dòng)化測試是zui大的成功之處，如果采用了GUI自動(dòng)化測試所有的時(shí)間和努力都會(huì)浪費(fèi)在其中。他們已經(jīng)準(zhǔn)備好做GUI自動(dòng)化測試了，并且已經(jīng)購買了一套測試工具和其他需要的東西，但我知道在開展具體的GUI自動(dòng)化測試活動(dòng)中，會(huì)遇到各種各樣的困難和障礙。
　　
　　無論你需要支持圖形界面接口、命令行接口還是API接口，如果你盡可能早的在產(chǎn)品設(shè)計(jì)階段提出產(chǎn)品的可測試性設(shè)計(jì)需求，未來的測試工作中，你很可能成功。盡可能早的啟動(dòng)自動(dòng)化測試項(xiàng)目，提出可測試性需求，會(huì)使您走向自動(dòng)化測試成功之路。
　　
　　步驟五：具有可延續(xù)性的設(shè)計(jì)
　　
　　在開篇的故事中，我們看到由于自動(dòng)化工程師把注意力僅僅集中在如何使自動(dòng)化運(yùn)轉(zhuǎn)起來，導(dǎo)致測試自動(dòng)化達(dá)不到預(yù)期的效果。自動(dòng)化測試是一個(gè)長期的過程，為了與產(chǎn)品新版本的功能和其他相關(guān)修改保持一致，自動(dòng)化測試需要不停的維護(hù)和擴(kuò)充。自動(dòng)化測試設(shè)計(jì)中考慮自動(dòng)化在未來的可擴(kuò)充性是很關(guān)鍵的，不過，自動(dòng)化測試的完整性也是很重要的。如果自動(dòng)化測試程序報(bào)告測試用例執(zhí)行通過，測試人員應(yīng)該相信得到的結(jié)果，測試執(zhí)行的實(shí)際結(jié)果也應(yīng)該是通過了。其實(shí)，有很多存在問題的測試用例表面上執(zhí)行通過了，實(shí)際上卻執(zhí)行失敗了，并且沒有記錄任何錯(cuò)誤日志，這就是失敗的自動(dòng)化。這種失敗的自動(dòng)化會(huì)給整個(gè)項(xiàng)目帶來災(zāi)難性的后果，而當(dāng)測試人員構(gòu)建的測試自動(dòng)化采用了很糟糕的設(shè)計(jì)方案或者由于后來的修改引入了錯(cuò)誤，都會(huì)導(dǎo)致這種失敗的測試自動(dòng)化。失敗的自動(dòng)化通常是由于沒有關(guān)注自動(dòng)化測試的性能或者沒有充分的自動(dòng)化設(shè)計(jì)導(dǎo)致的。
　　
　　性能：提高代碼的性能往往增加了代碼的復(fù)雜性，因此，會(huì)威脅到代碼的可靠性。很少有人關(guān)心如何對自動(dòng)化本身加以測試。通過我對測試套性能的分析，很多測試套都是花費(fèi)大量的時(shí)間等候產(chǎn)品的運(yùn)行。因此，在不提高產(chǎn)品運(yùn)行性能的前提下，無法更有效的提高自動(dòng)化測試執(zhí)行效率。我懷疑測試自動(dòng)化工程師只是從計(jì)算機(jī)課程了解到應(yīng)該關(guān)注軟件的性能，而并沒有實(shí)際的操作經(jīng)驗(yàn)。如果測試套的性能問題無法改變，那么應(yīng)該考慮提高硬件的性能；測試套中經(jīng)常會(huì)出現(xiàn)冗余，也可以考慮取出測試套中的冗余或者減少一個(gè)測試套中完成的測試任務(wù)，都是很好的辦法。
　　
　　便于分析：測試自動(dòng)化執(zhí)行失敗后應(yīng)該分析失敗的結(jié)果，這是一個(gè)棘手的問題。分析執(zhí)行失敗的自動(dòng)化測試結(jié)果是件困難的事情，需要從多方面著手，測試上報(bào)的告警信息是真的還是假的？是不是因?yàn)闇y試套中存在缺陷導(dǎo)致測試執(zhí)行失敗？是不是在搭建測試環(huán)境中出現(xiàn)了錯(cuò)誤導(dǎo)致測試執(zhí)行失敗？是不是產(chǎn)品中確實(shí)存在缺陷導(dǎo)致測試執(zhí)行失敗？有幾個(gè)方法可以幫助測試執(zhí)行失敗的結(jié)果分析，某些方法可以找到問題所在。通過在測試執(zhí)行之前檢查常見的測試環(huán)境搭建問題，從而提高測試套的可靠性；通過改進(jìn)錯(cuò)誤輸出報(bào)告，從而提高測試自動(dòng)化的錯(cuò)誤輸出的可分析性；此外，還可以改進(jìn)自動(dòng)化測試框架中存在的問題。訓(xùn)練測試人員如何分析測試執(zhí)行失敗結(jié)果。甚至可以找到那些不可靠的、冗余的或者功能比較獨(dú)立的測試，然后安全地將之刪除。上面這些都是減少自動(dòng)化測試誤報(bào)告警、提高測試可分析性的積極有效的方法。另外，有一種錯(cuò)誤的測試結(jié)果分析方法，那就是采用測試結(jié)果后處理程序?qū)y試結(jié)果自動(dòng)分析和過濾，盡管也可以采用這種測試結(jié)果分析方法，不過這種方法會(huì)使自動(dòng)化測試系統(tǒng)復(fù)雜化，更重要的是，后處理程序中的BUG會(huì)嚴(yán)重?fù)p害自動(dòng)化測試的完整性。如果由于自動(dòng)化測試本身存在的缺陷誤把產(chǎn)品中的正常功能視為異常，那該怎么辦？我曾經(jīng)看到測試小組花費(fèi)開發(fā)測試自動(dòng)化兩倍的時(shí)間來修改測試腳本，并且不愿意開展培訓(xùn)過程。那些僅僅關(guān)注很淺層次測試技術(shù)的測試管理者對這種方法很感興趣，他們排斥采用隱藏測試復(fù)雜度的方法。
　　
　　綜上所述，應(yīng)該集中精力關(guān)注可以延續(xù)使用的測試套，從以下幾方面考慮，測試的可檢視性、測試的可維護(hù)性、測試的完整性、測試的獨(dú)立性、測試的可重復(fù)性。
　　
　　可讀性：很多情況下，在測試人員開始測試項(xiàng)目之前，公司已經(jīng)有了一套測試腳本，并且已經(jīng)存在很多年了。我們可以稱之為“聰明的橡樹”(wiseoaktree)[Bach1996]。大家很依賴它，但是并不知道它是什么。由于“聰明的橡樹”類型的測試腳本缺乏可讀性，在具體應(yīng)用中，那些腳本常常沒有多大的實(shí)用價(jià)值，越來越讓人迷惑。因此，測試人員很難確定他們實(shí)際在測試什么，反而會(huì)導(dǎo)致測試人員對自身的測試能力有過高的估計(jì)。測試人員能夠檢視測試腳本，并且理解測試腳本究竟測試了什么，這是很關(guān)鍵的。好的文檔是解決問題的手段之一，對測試腳本全面分析是另外一個(gè)手段。由上面兩種方法可以引申出其它的相關(guān)方法，我曾經(jīng)在一個(gè)項(xiàng)目中使用過引申之后的方法。在測試腳本中插樁，把所有執(zhí)行的產(chǎn)品相關(guān)的命令記錄到日志里。這樣，當(dāng)分析日志確定執(zhí)行了哪些產(chǎn)品命令，命令采用了何種參數(shù)配置時(shí)，可以提供一個(gè)非常好的測試記錄，里面記錄了自動(dòng)化測試執(zhí)行了什么，沒有執(zhí)行什么。如果測試腳本可讀性不好，很容易變得過分依賴并沒有*理解的測試腳本，很容易認(rèn)為測試腳本實(shí)際上做的工作比你想象中的還要多。測試套的可讀性提高后，可以更容易的開展同行評審活動(dòng)。
　　
　　可維護(hù)性：在工作中，我曾經(jīng)使用過一個(gè)測試套，它把所有的程序輸出保存到文件中。然后，通過對比輸出文件內(nèi)容和一個(gè)已有的輸出文件內(nèi)容的差別，可以稱已有的輸出文件為“標(biāo)準(zhǔn)文件”（“goldfile”）。在回歸測試中，用這個(gè)方法查找BUG是不是明智之舉。這種方法太過于敏感了，它會(huì)產(chǎn)生很多錯(cuò)誤的警告。隨著時(shí)間的推移，軟件開發(fā)人員會(huì)根據(jù)需要修改產(chǎn)品的很多輸出信息，這會(huì)導(dǎo)致很多自動(dòng)化測試失敗。很明顯，為了保證自動(dòng)化測試的順利進(jìn)行，應(yīng)該在對“標(biāo)準(zhǔn)文件”仔細(xì)分析的基礎(chǔ)上，根據(jù)開發(fā)人員修改的產(chǎn)品輸出信息對之做相應(yīng)的修改。比較好的可維護(hù)性方法是，每次只檢查選定的產(chǎn)品的某些特定輸出，而不是對比所有的結(jié)果輸出。產(chǎn)品的接口變動(dòng)也會(huì)導(dǎo)致原來的測試無法執(zhí)行或者執(zhí)行失敗。對于GUI測試，這是一個(gè)更大的挑戰(zhàn)。研究由于產(chǎn)品接口變化引起的相關(guān)測試修改，并研究使測試修改量zui小的方法，測試中采用庫是解決問題的方法。當(dāng)產(chǎn)品發(fā)生變化的時(shí)候，只需要修改相關(guān)的庫，保證測試與產(chǎn)品的變動(dòng)同步修改即可。
　　
　　完整性：當(dāng)自動(dòng)化測試執(zhí)行后，報(bào)告測試執(zhí)行通過，可以斷定這是真的嗎？這就是我稱之為測試套的完整性。在前面的故事中，當(dāng)沒有對自動(dòng)化測試完整性給予應(yīng)有的關(guān)注的時(shí)候，發(fā)生了富有喜劇性的情況。我們應(yīng)該在多大程度上相信自動(dòng)化化測試執(zhí)行結(jié)果？自動(dòng)化測試執(zhí)行中的誤報(bào)告警是很大的問題。測試人員特別討厭由于測試腳本自身的問題或者是測試環(huán)境的問題導(dǎo)致測試執(zhí)行失敗，但是，對于自動(dòng)化測試誤報(bào)告警的情況，大家往往無能為力。你期望自己設(shè)計(jì)的測試對BUG很敏感、有效，當(dāng)測試發(fā)現(xiàn)異常的時(shí)候，能夠報(bào)告測試執(zhí)行失敗。有的測試框架支持對特殊測試結(jié)果的分類方法，分類包括PASS，F(xiàn)AIL和第三種測試結(jié)果NOTRUN或者UNRESOLVED。無論你怎么稱呼第三種測試結(jié)果，它很好的說明了由于某些測試失敗導(dǎo)致其他測試用例無法執(zhí)行而并非執(zhí)行失敗的情況。得到正確的測試結(jié)果是自動(dòng)化測試完整性定義的一部分，另一部分是能夠確認(rèn)執(zhí)行成功的測試確確實(shí)實(shí)已經(jīng)執(zhí)行過了。我曾經(jīng)在一個(gè)測試隊(duì)列中發(fā)現(xiàn)一個(gè)BUG，這個(gè)BUG引起測試隊(duì)列中部分測試用例被跳過，沒有執(zhí)行。當(dāng)測試隊(duì)列運(yùn)行完畢后，沒有上報(bào)任何錯(cuò)誤，我不得不通過走讀代碼的方式發(fā)現(xiàn)了這個(gè)BUG。如果，我沒有關(guān)注到這個(gè)BUG，那么可能在認(rèn)識到自動(dòng)化測試已經(jīng)出現(xiàn)問題之前，還在長時(shí)間運(yùn)行部分測試用例。
　　
　　獨(dú)立性：采用自動(dòng)化方法不可能達(dá)到和手工測試同樣的效果。當(dāng)寫手工測試執(zhí)行的規(guī)程時(shí)候，通常假定測試執(zhí)行將會(huì)由一個(gè)有頭腦、善于思考、具有觀察力的測試人員完成的。如果采用自動(dòng)化，測試執(zhí)行是由一臺不會(huì)說話的計(jì)算機(jī)完成的，你必須告訴計(jì)算機(jī)什么樣的情況下測試執(zhí)行是失敗的，并且需要告訴計(jì)算機(jī)如何恢復(fù)測試場景才能保證測試套可以順利執(zhí)行。自動(dòng)化測試可以作為測試套的一部分或者作為獨(dú)立的測試執(zhí)行。測試都需要建立自己所需要的測試執(zhí)行環(huán)境，因此，保證測試執(zhí)行的獨(dú)立性是*的好方法。手工回歸測試通常都相關(guān)的指導(dǎo)文檔，以便一個(gè)接著一個(gè)有序地完成測試執(zhí)行，每個(gè)測試執(zhí)行可以利用前一個(gè)測試執(zhí)行創(chuàng)建的對象或數(shù)據(jù)記錄。手工測試人員可以清楚地把握整個(gè)測試過程。在自動(dòng)化測試中采用上述方法是經(jīng)常犯的錯(cuò)誤，這個(gè)錯(cuò)誤源于“多米諾骨牌”測試套，當(dāng)一個(gè)測試執(zhí)行失敗，會(huì)導(dǎo)致后續(xù)一系列測試失敗。更糟糕的是，所有的測試關(guān)聯(lián)緊密，無法獨(dú)立的運(yùn)行。并且，這使得在自動(dòng)化測試中分析合法的執(zhí)行失敗結(jié)果也困難重重。當(dāng)出現(xiàn)這種情況后，人們首先開始懷疑自動(dòng)化測試的價(jià)值。自動(dòng)化測試的獨(dú)立性要求在自動(dòng)化測試中增加重復(fù)和冗余設(shè)計(jì)。具有獨(dú)立性的測試對發(fā)現(xiàn)的缺陷的分析有很好的支持。以這種方式設(shè)計(jì)自動(dòng)化測試好像是一種低效率的方式，不過，重要的是在不犧牲測試的可靠性的前提下保證測試的獨(dú)立性，如果測試可以在無需人看守情況下運(yùn)行，那么測試的執(zhí)行效率就不是大問題了。
　　
　　可重復(fù)性：自動(dòng)化測試有時(shí)能夠發(fā)現(xiàn)問題，有時(shí)候又無法發(fā)現(xiàn)問題，對這種情況實(shí)在沒有什么好的的處理辦法。因此，需要保證每次測試執(zhí)行的時(shí)候，測試是以同樣的方式工作。這意味著不要采用隨機(jī)數(shù)據(jù)，在通用語言庫中構(gòu)造的隨機(jī)數(shù)據(jù)經(jīng)常隱藏初始化過程，使用這些數(shù)據(jù)會(huì)導(dǎo)致測試每次都以不同的方式執(zhí)行，這樣，對測試執(zhí)行的失敗結(jié)果分析是很讓人沮喪的。這里有兩個(gè)使用隨機(jī)數(shù)據(jù)發(fā)生器的的方法可以避免上述情況。一種方法是使用常量初始化隨機(jī)數(shù)據(jù)發(fā)生器。如果你打算生成不同種類的測試，需要在可預(yù)測，并且可控制的情況下建立不同類型的隨機(jī)數(shù)據(jù)發(fā)生器。另外一個(gè)辦法是提前在文件中或數(shù)據(jù)庫中建立生成隨機(jī)測試數(shù)據(jù)，然后在測試過程中使用這些數(shù)據(jù)。這樣做看起來似乎很好，但是我卻曾經(jīng)看到過太多違反規(guī)則的做法。下面我來解釋到底看到了什么。當(dāng)手動(dòng)執(zhí)行測試的時(shí)候，往往匆匆忙忙整理文件名和測試數(shù)據(jù)記錄。當(dāng)對這些測試采用自動(dòng)化測試方法，該做哪些工作呢？辦法之一是，可以為測試中使用的數(shù)據(jù)記錄給固定的命名。如果這些數(shù)據(jù)記錄在測試完成后還要繼續(xù)使用，那么就需要制定命名規(guī)則，避免在不同的測試中命名沖突，采用命名規(guī)則是一種很好的方法。然而，我曾經(jīng)看到有些測試只是隨機(jī)的命名數(shù)據(jù)記錄，很不幸，事實(shí)證明采用這種隨機(jī)命名的方式不可避免的導(dǎo)致命名沖突，并且影響測試的可重復(fù)性。很顯然，自動(dòng)化工程師低估了命名沖突的可能性。下面的情況我遇到過兩次，測試數(shù)據(jù)記錄的名字中包含四個(gè)隨機(jī)產(chǎn)生的數(shù)字，經(jīng)過簡單的推算如果我們采用這種命名方式的時(shí)候，如果測試使用了46條記錄，會(huì)存在10%沖突的可能性，如果使用118條記錄，沖突的幾率會(huì)達(dá)到50%。我認(rèn)為測試當(dāng)中使用這種隨機(jī)命名是出于偷懶的想法——避免再次測試之前寫代碼清除老的數(shù)據(jù)記錄，這樣引入了問題，損害了測試的可靠性和測試的完整性。
　　
　　測試庫：自動(dòng)化測試的一個(gè)通用策略是開發(fā)可以在不同測試中應(yīng)用的測試函數(shù)庫。我曾經(jīng)看到過很多測試函數(shù)庫，自己也寫了一些。當(dāng)要求測試不受被測試產(chǎn)品接口變動(dòng)影響的時(shí)候，采用測試庫方法是非常有效的。不過，根據(jù)我的觀察測試庫已經(jīng)使用的太多了，已經(jīng)被濫用了，并且測試庫往往設(shè)計(jì)的不好，沒有相關(guān)的文檔支撐，因此，使用測試庫的測試往往很難開展。當(dāng)發(fā)現(xiàn)問題的時(shí)候，往往不知道是測試庫自身的問題，還是測試庫的使用問題。由于測試庫往往很復(fù)雜，即便在發(fā)現(xiàn)測試庫存在問題，相關(guān)的維護(hù)人員也很不愿意去修改問題。通過前文中的論述，可以得出結(jié)論，在一開始就應(yīng)該保證測試庫設(shè)計(jì)良好。但是，實(shí)際情況是測試自動(dòng)化往往沒有花費(fèi)更多的精力去保證一個(gè)優(yōu)良設(shè)計(jì)的測試庫。我曾經(jīng)看到有些測試庫中的功能根本不再使用了或僅僅使用一次。這與極限編程原則保持一致，即"你將不需要它"。這會(huì)導(dǎo)致在測試用例之間的代碼出現(xiàn)一些重復(fù)，我發(fā)現(xiàn)微小的變化可能仍然存在，很難與測試庫功能協(xié)調(diào)。你可能打算對測試用例作修改，采用源代碼的方式比采用庫的方式更容易修改。如果有幾個(gè)測試，他們有某些共同的操作，我使用剪切和粘貼的方式去復(fù)制代碼，有的人認(rèn)為我采用的方法不可理喻。這允許我根據(jù)需要修改通用代碼，我不必一開始嘗試和猜測如何重用代碼。我認(rèn)為我的測試是很容易讀懂的，因?yàn)殚喿x者不必關(guān)心任何測試庫的語法。這種辦法的優(yōu)勢是很容易理解測試，并且很方便擴(kuò)展測試套。在開發(fā)軟件測試項(xiàng)目的時(shí)候，大多數(shù)程序員找到與他們打算實(shí)現(xiàn)功能類似的源代碼，并對源代碼做修改，而不是從頭開始寫代碼。同樣，在寫測試套的過程中可以采用上述方法，這也是代碼開發(fā)方式所鼓勵(lì)的方法。我比較喜歡寫一些規(guī)模比較小的測試庫，這些庫可以被反復(fù)的使用。測試庫的開發(fā)需要在概念階段充分定義，并且文檔化，從始至終都應(yīng)該保持。我會(huì)對測試庫作充分的測試后，才在測試中使用這些測試庫。采用測試庫是對所有面臨的情況作權(quán)衡的。千萬不要打算寫一個(gè)大而全的測試庫，不要希望有朝一日測試人員會(huì)利用你的測試庫完成大量的測試，這一天恐怕永遠(yuǎn)不會(huì)到來。
　　
　　數(shù)據(jù)驅(qū)動(dòng)測試：把測試數(shù)據(jù)寫入到簡單表格中，這種測試技術(shù)得到了越來越廣泛的應(yīng)用，這種方法被稱為表驅(qū)動(dòng)（table-driven），數(shù)據(jù)驅(qū)動(dòng)(data-driven)或者“第三代”自動(dòng)化測試（"thirdgeneration"automation）。這需要寫一個(gè)解析器，用來解釋表格中的數(shù)據(jù)，并執(zhí)行測試。該測試架構(gòu)的zui主要的好處是，它允許把測試內(nèi)容寫在具有一定格式的表格中，這樣方便數(shù)據(jù)設(shè)計(jì)和數(shù)據(jù)的檢視。如果測試組中有缺少編程經(jīng)驗(yàn)的業(yè)務(wù)專家參與測試，采用數(shù)據(jù)驅(qū)動(dòng)測試方法是很合適的。數(shù)據(jù)驅(qū)動(dòng)測試的解析器主要是由測試庫和上層的少量開發(fā)語言寫成的代碼組成的，所以，上面關(guān)于測試庫的說明放在這里是同樣合適的。在針對上面提到的少量代碼的設(shè)計(jì)、開發(fā)、測試的工作，還存在各種困難。代碼所采用的編程語言是不斷發(fā)展的。也許，測試人員認(rèn)為他們需要把*部分測試的輸出作為第二部分測試的輸入，這樣，加入了新的變量。接下來，也許有人需要讓測試中的某個(gè)環(huán)節(jié)運(yùn)行一百次，這樣加入一個(gè)循環(huán)。你可以采用其他語言，不過，如果你預(yù)料到會(huì)面臨上述情況的時(shí)候，那么做好采用一些能夠通過公開的渠道獲取的編程語言，比如Perl,Python或者TCL，這樣比設(shè)計(jì)你自己的語言要快的多。
　　
　　啟發(fā)式確認(rèn)：我曾經(jīng)看到很多測試自動(dòng)化沒有真正意義上的結(jié)果校驗(yàn)，其原因有兩個(gè)，一個(gè)原因是做*意義上的自動(dòng)化測試結(jié)果確認(rèn)從技術(shù)上講是很困難的，另外一個(gè)原因是通過測試設(shè)計(jì)規(guī)格很難找出自動(dòng)化測試的預(yù)期結(jié)果。這很不幸。不過，采用手工校驗(yàn)測試結(jié)果的方法是真正意義上的測試校驗(yàn)。標(biāo)準(zhǔn)文件（Goldfile）是另外一中校驗(yàn)測試結(jié)果的方法。首先，捕獲被測試程序的輸出，并檢視程序的輸出，然后，把輸出信息文檔化，并歸檔，作為標(biāo)準(zhǔn)文件。以后，自動(dòng)化測試結(jié)果與標(biāo)準(zhǔn)文件作比較，從而達(dá)到結(jié)果校驗(yàn)的目的。采用標(biāo)準(zhǔn)文件的方法，也有弊端。當(dāng)產(chǎn)品發(fā)生變化，自動(dòng)化測試的環(huán)境配置發(fā)生變化，產(chǎn)品的輸出發(fā)生變化的時(shí)候，采用標(biāo)準(zhǔn)文方法，會(huì)上報(bào)大量的誤報(bào)告警。做好的測試結(jié)果校驗(yàn)方法是，對輸出結(jié)果的特定內(nèi)容作分析，并作合理的比較。有時(shí)候，很難知道正確的輸出結(jié)果是什么樣的，但是你應(yīng)該知道錯(cuò)誤的輸出結(jié)果是什么樣的。開展啟發(fā)式的結(jié)果校驗(yàn)是很有幫助的。我猜想一些人在自動(dòng)化測試中設(shè)計(jì)了大而全的測試結(jié)果校驗(yàn)方法，是因?yàn)閾?dān)心如果結(jié)果校驗(yàn)漏掉了任何信息，可能導(dǎo)致自動(dòng)化測試自身出現(xiàn)錯(cuò)誤。不過，我們在測試過程中往往采用折衷的做法，沒有采用大而全的測試結(jié)果校驗(yàn)方法，這樣就不得不面對少量漏測情況的出現(xiàn)的風(fēng)險(xiǎn)。自動(dòng)化測試不能改變這種情況的出現(xiàn)。如果自動(dòng)化工程師不習(xí)慣采用這種折衷的方法，那么他必須找相關(guān)人員咨詢，尋找一種合適的測試結(jié)果校驗(yàn)策略，這需要有很大的創(chuàng)造性。目前有很多技術(shù)可以保證在不產(chǎn)生誤報(bào)告警的情況下，找到被測試產(chǎn)品的缺陷。
　　
　　把注意力放在通過設(shè)計(jì)保證測試的可延續(xù)性上，選擇一個(gè)合適的測試體系架構(gòu)，你將進(jìn)一步邁向成功的自動(dòng)化測試。
　　
　　步驟六：有計(jì)劃的部署
　　
　　在前面的故事中，當(dāng)自動(dòng)化工程師沒有提供打包后的自動(dòng)化測試程序給測試執(zhí)行人員，會(huì)影響到測試執(zhí)行，測試執(zhí)行人員不得不反過來求助自動(dòng)化工程師指出如何使用自動(dòng)化測試程序。
　　
　　作為自動(dòng)化工程師，你知道如何利用自動(dòng)化方法執(zhí)行測試和分析執(zhí)行失敗的結(jié)果。不過，測試執(zhí)行人員卻未必知道如何使用自動(dòng)化測試。因此，需要提供自動(dòng)化測試程序的安裝文檔和使用文檔，保證自動(dòng)化測試程序容易安裝和配置。當(dāng)安裝的環(huán)境與安裝的要求不匹配，出現(xiàn)安裝錯(cuò)誤的時(shí)候，能夠給出有價(jià)值的提示信息，便于定位安裝問題。
　　
　　能夠把自動(dòng)化測試程序和測試套作為產(chǎn)品對待，那真是太好了。你應(yīng)該對自動(dòng)化測試程序和測試套開展測試，保證它們不依賴于任何的庫或者是設(shè)備上的任何其他程序。
　　
　　保證其他測試人員能夠隨時(shí)利用已經(jīng)提供的自動(dòng)化測試程序和測試套開展測試工作；保證自動(dòng)化測試是符合一般測試執(zhí)行人員的思維習(xí)慣的；保證測試執(zhí)行人員能夠理解測試結(jié)果，并能夠正確分析失敗的測試執(zhí)行結(jié)果；這需要自動(dòng)化工程師提供自動(dòng)動(dòng)化測試相關(guān)的指導(dǎo)性文檔和培訓(xùn)。
　　
　　作為測試管理者，你希望在自動(dòng)化工程師離開前，能夠識別并修改測試套中的所有問題。自動(dòng)化工程師遲早會(huì)離開的，如果你沒有及時(shí)的把測試套中的問題提出來，就會(huì)面臨廢棄已有的測試套的決定。
　　
　　良好的測試套有多方面的用處。良好的測試套支持對產(chǎn)品新版本的測試；良好的測試套在新的軟件平臺上可以很方便的驗(yàn)證產(chǎn)品的功能；良好的測試套支持每天晚上開始的軟件每日構(gòu)造過程；甚至開發(fā)人員在代碼checkin之前，用良好的測試套驗(yàn)證代碼的正確性。
　　
　　測試套的共享也很重要。很難預(yù)見以后什么人會(huì)繼續(xù)使用你開發(fā)的測試套。因此，盡量讓產(chǎn)品開發(fā)測試團(tuán)隊(duì)中的成員都很容易獲得你的測試套。可以把測試套放在公司的內(nèi)部網(wǎng)絡(luò)上，這是個(gè)很好的辦法。這樣，大家就不必為了獲取一份需要的測試套而四處打聽。有些人總是感覺自己的測試套還沒有zui終完工或者不夠，而沒有拿出來與人分享，這種做法一定要改變，共享出來的測試套不一定非常，共享才是關(guān)鍵。
　　
　　有計(jì)劃的自動(dòng)化測試部署，保證你的測試套能夠被產(chǎn)品相關(guān)人員獲取到，你就向成功的自動(dòng)化測試又邁進(jìn)了一步。并且你的自動(dòng)化測試會(huì)被一次又一次的重用。
　　
　　步驟七：面對成功的挑戰(zhàn)
　　
　　當(dāng)你完成了所有的事情，測試套已經(jīng)文檔化了，并且文檔已經(jīng)交付了。測試執(zhí)行人員能夠理解要開展的測試，并知道如何完成測試執(zhí)行。隨著你所負(fù)責(zé)產(chǎn)品的進(jìn)一步開發(fā)和維護(hù)，測試被反復(fù)重用。雖然，在自動(dòng)化使測試變簡單的同時(shí)，也總是使測試過程復(fù)雜化。測試人員需要學(xué)習(xí)如何診斷自動(dòng)化測試執(zhí)行失敗的情況，如果不這樣做，測試執(zhí)行人員會(huì)認(rèn)為執(zhí)行失敗的情況是由自動(dòng)化引起，然后，自動(dòng)化工程師被叫過來幫助診斷每一個(gè)執(zhí)行失敗的情況，開發(fā)人員往往也會(huì)認(rèn)為執(zhí)行失敗是由于自動(dòng)化測試自身引起的問題，這樣，測試執(zhí)行人員就不得不學(xué)習(xí)通過手工的方式，或者通過采用少量腳本的方式重現(xiàn)自動(dòng)化測試發(fā)現(xiàn)的問題，以證明他們確實(shí)發(fā)現(xiàn)了產(chǎn)品當(dāng)中的BUG。
　　
　　測試套的相關(guān)工作還沒有結(jié)束，為了提高測試覆蓋率或者測試新的產(chǎn)品特性，需要增加更多的測試。如果已有的測試不能正常工作，那么需要對之修改；如果已有的測試是冗余的，那么需要?jiǎng)h除這部分測試。
　　
　　隨著時(shí)間的推移，開發(fā)人員也會(huì)研究你設(shè)計(jì)的測試，改進(jìn)產(chǎn)品的設(shè)計(jì)并且通過模擬你的測試過程對產(chǎn)品做初步測試，研究如何使產(chǎn)品在*次測試就通過，這樣，你設(shè)計(jì)的測試很可能無法繼續(xù)發(fā)現(xiàn)新的問題，這種現(xiàn)象被稱為一種殺蟲劑悖論。這時(shí)候，會(huì)有人對你的測試有效性提出質(zhì)疑，那么，你必須考慮是否應(yīng)該挖掘更嚴(yán)格的測試，以便能夠發(fā)現(xiàn)開發(fā)人員優(yōu)化之后的產(chǎn)品中的缺陷。
　　
　　以前，我提到過一個(gè)基本上無法實(shí)現(xiàn)的設(shè)想，設(shè)想通過按下一個(gè)按鈕就完成了所有的測試工作。自動(dòng)化測試是不是的，手工測試是永遠(yuǎn)無法*替代的。
　　
　　有些測試受測試環(huán)境的影響很大，往往需要采用人工方法獲取測試結(jié)果，分析測試結(jié)果。因此，很難在預(yù)先知道設(shè)計(jì)的測試用例有多大的重用性。自動(dòng)化測試還需要考慮成本問題，因此，千萬不要陷入到一切測試都采用自動(dòng)化方法的錯(cuò)誤觀念中。
　　
　　我曾經(jīng)主張保證給與測試自動(dòng)化持續(xù)不斷的投入。但是，在開展自動(dòng)化測試的時(shí)候，一個(gè)問題擺在面前，測試自動(dòng)化應(yīng)該及時(shí)的提供給測試執(zhí)行人員，這個(gè)不成問題，但是如何保證需求變更后，能夠及時(shí)提供更新后的自動(dòng)化測試就是個(gè)大問題了。如果自動(dòng)化測試與需求變更無法同步，那么自動(dòng)化測試的效果就無法保證了，測試人員就不愿意花費(fèi)時(shí)間學(xué)習(xí)如何使用新的測試工具和如何診斷測試工具上報(bào)的錯(cuò)誤。識別項(xiàng)目計(jì)劃中的軟件發(fā)布日期，然后把這個(gè)日期作為里程碑，并計(jì)劃達(dá)到這個(gè)里程碑。當(dāng)達(dá)到這個(gè)里程碑后，自動(dòng)化工程師應(yīng)該做什么呢？如果自動(dòng)化工程師關(guān)注當(dāng)前產(chǎn)品版本的發(fā)布，他需要為測試執(zhí)行人員提供幫助和咨詢，但是，一旦測試執(zhí)行人員知道如何使用自動(dòng)化測試，自動(dòng)化測試工程師可以考慮下一個(gè)版本的測試自動(dòng)化工作，包括改進(jìn)測試工具和相關(guān)的庫。當(dāng)開發(fā)人員開始設(shè)計(jì)產(chǎn)品下一個(gè)版本中的新特性的時(shí)候，如果考慮了自動(dòng)化測試需求，那么自動(dòng)化測試師的設(shè)計(jì)工作就很好開展了，采用這種方法，自動(dòng)化測試工程師可以保持與開發(fā)周期同步，而不是與測試周期同步。如果不采用這種方式，在產(chǎn)品版本升級的過程中，自動(dòng)化測試無法得到進(jìn)一步的改進(jìn)。
　　
　　持續(xù)在在自動(dòng)化投入，你會(huì)面臨成功的挑戰(zhàn)，當(dāng)自動(dòng)化測試成為測試過程可靠的基礎(chǔ)后，自動(dòng)化測試的道路將會(huì)越來越平坦。