便于分析： 測試自動(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)存在很多年了。我們可以稱之為 “ 聰明的橡樹 ”(wise oak tree)[Bach 1996] 。大家很依賴它，但是并不知道它是什么。由于 “ 聰明的橡樹 ” 類型的測試腳本缺乏可讀性，在具體應(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í)際上做的工作比你想象中的還要多。測試套的可讀性提高后，可以更容易的開展同行評(píng)審活動(dòng)。
可維護(hù)性： 在工作中，我曾經(jīng)使用過一個(gè)測試套，它把所有的程序輸出保存到文件中。然后，通過對比輸出文件內(nèi)容和一個(gè)已有的輸出文件內(nèi)容的差別，可以稱已有的輸出文件為 “ 標(biāo)準(zhǔn)文件 ” （ “gold file” ）。在回歸測試中，用這個(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)測試修改，并研究使測試修改量小的方法，測試中采用庫是解決問題的方法。當(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 ， FAIL 和第三種測試結(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)識(shí)到自動(dòng)化測試已經(jīng)出現(xiàn)問題之前，還在長時(shí)間運(yùn)行部分測試用例。
獨(dú)立性： 采用自動(dòng)化方法不可能達(dá)到和手工測試同樣的效果。當(dāng)寫手工測試執(zhí)行的規(guī)程時(shí)候，通常假定測試執(zhí)行將會(huì)由一個(gè)有頭腦、善于思考、具有觀察力的測試人員完成的。如果采用自動(dòng)化，測試執(zhí)行是由一臺(tái)不會(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í)行效率就不是大問題了。
綜上所述，應(yīng)該集中精力關(guān)注可以延續(xù)使用的測試套，從以下幾方面考慮，測試的可檢視性、測試的可維護(hù)性、測試的完整性、測試的獨(dú)立性、測試的可重復(fù)性。
可讀性： 很多情況下，在測試人員開始測試項(xiàng)目之前，公司已經(jīng)有了一套測試腳本，并且已經(jīng)存在很多年了。我們可以稱之為 “ 聰明的橡樹 ”(wise oak tree)[Bach 1996] 。大家很依賴它，但是并不知道它是什么。由于 “ 聰明的橡樹 ” 類型的測試腳本缺乏可讀性，在具體應(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í)際上做的工作比你想象中的還要多。測試套的可讀性提高后，可以更容易的開展同行評(píng)審活動(dòng)。
可維護(hù)性： 在工作中，我曾經(jīng)使用過一個(gè)測試套，它把所有的程序輸出保存到文件中。然后，通過對比輸出文件內(nèi)容和一個(gè)已有的輸出文件內(nèi)容的差別，可以稱已有的輸出文件為 “ 標(biāo)準(zhǔn)文件 ” （ “gold file” ）。在回歸測試中，用這個(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)測試修改，并研究使測試修改量小的方法，測試中采用庫是解決問題的方法。當(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 ， FAIL 和第三種測試結(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)識(shí)到自動(dòng)化測試已經(jīng)出現(xiàn)問題之前，還在長時(shí)間運(yùn)行部分測試用例。
獨(dú)立性： 采用自動(dòng)化方法不可能達(dá)到和手工測試同樣的效果。當(dāng)寫手工測試執(zhí)行的規(guī)程時(shí)候，通常假定測試執(zhí)行將會(huì)由一個(gè)有頭腦、善于思考、具有觀察力的測試人員完成的。如果采用自動(dòng)化，測試執(zhí)行是由一臺(tái)不會(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í)行效率就不是大問題了。