軟件自動化測試的7個步驟(7)

　　啟發式確認： 我曾經看到很多測試自動化沒有真正意義上的結果校驗，其原因有兩個，一個原因是做完全意義上的自動化測試結果確認從技術上講是很困難的，另外一個原因是通過測試設計規格很難找出自動化測試的預期結果。這很不幸。不過，采用手工校驗測試結果的方法是真正意義上的測試校驗。標準文件( Gold file )是另外一中校驗測試結果的方法。首先，捕獲被測試程序的輸出，并檢視程序的輸出，然后，把輸出信息文檔化，并歸檔，作為標準文件。以后，自動化測試結果與標準文件作比較，從而達到結果校驗的目的。采用標準文件的方法，也有弊端。當產品發生變化，自動化測試的環境配置發生變化，產品的輸出發生變化的時候，采用標準文方法，會上報大量的誤報告警。做好的測試結果校驗方法是，對輸出結果的特定內容作分析，并作合理的比較。有時候，很難知道正確的輸出結果是什么樣的，但是你應該知道錯誤的輸出結果是什么樣的。開展啟發式的結果校驗是很有幫助的。我猜想一些人在自動化測試中設計了大而全的測試結果校驗方法，是因為擔心如果結果校驗漏掉了任何信息，可能導致自動化測試自身出現錯誤。不過，我們在測試過程中往往采用折衷的做法，沒有采用大而全的測試結果校驗方法，這樣就不得不面對少量漏測情況的出現的風險。自動化測試不能改變這種情況的出現。如果自動化工程師不習慣采用這種折衷的方法，那么他必須找相關人員咨詢，尋找一種合適的測試結果校驗策略，這需要有很大的創造性。目前有很多技術可以保證在不產生誤報告警的情況下，找到被測試產品的缺陷。

　　把注意力放在通過設計保證測試的可延續性上，選擇一個合適的測試體系架構，你將進一步邁向成功的自動化測試。

　　步驟六：有計劃的部署

　　在前面的故事中，當自動化工程師沒有提供打包后的自動化測試程序給測試執行人員，會影響到測試執行，測試執行人員不得不反過來求助自動化工程師指出如何使用自動化測試程序。

　　作為自動化工程師，你知道如何利用自動化方法執行測試和分析執行失敗的結果。不過，測試執行人員卻未必知道如何使用自動化測試。因此，需要提供自動化測試程序的安裝文檔和使用文檔，保證自動化測試程序容易安裝和配置。當安裝的環境與安裝的要求不匹配，出現安裝錯誤的時候，能夠給出有價值的提示信息，便于定位安裝問題。

　　能夠把自動化測試程序和測試套作為產品對待，那真是太好了。你應該對自動化測試程序和測試套開展測試，保證它們不依賴于任何專用的庫或者是設備上的任何其他程序。

　　保證其他測試人員能夠隨時利用已經提供的自動化測試程序和測試套開展測試工作;保證自動化測試是符合一般測試執行人員的思維習慣的;保證測試執行人員能夠理解測試結果，并能夠正確分析失敗的測試執行結果;這需要自動化工程師提供自動動化測試相關的指導性文檔和培訓。

　　作為測試管理者，你希望在自動化工程師離開前，能夠識別并修改測試套中的所有問題。自動化工程師遲早會離開的，如果你沒有及時的把測試套中的問題提出來，就會面臨廢棄已有的測試套的決定。

　　良好的測試套有多方面的用處。良好的測試套支持對產品新版本的測試;良好的測試套在新的軟件平臺上可以很方便的驗證產品的功能;良好的測試套支持每天晚上開始的軟件每日構造過程;甚至開發人員在代碼 check in 之前，用良好的測試套驗證代碼的正確性。

　　測試套的共享也很重要。很難預見以后什么人會繼續使用你開發的測試套。因此，盡量讓產品開發測試團隊中的成員都很容易獲得你的測試套?？梢园褱y試套放在公司的內部網絡上，這是個很好的辦法。這樣，大家就不必為了獲取一份需要的測試套而四處打聽。有些人總是感覺自己的測試套還沒有最終完工或者不夠完美，而沒有拿出來與人分享，這種做法一定要改變，共享出來的測試套不一定非常完美，共享才是關鍵。

　　有計劃的自動化測試部署，保證你的測試套能夠被產品相關人員獲取到，你就向成功的自動化測試又邁進了一步。并且你的自動化測試會被一次又一次的重用。

　　步驟七：面對成功的挑戰

　　當你完成了所有的事情，測試套已經文檔化了，并且文檔已經交付了。測試執行人員能夠理解要開展的測試，并知道如何完成測試執行。隨著你所負責產品的進一步開發和維護，測試被反復重用。雖然，在自動化使測試變簡單的同時，也總是使測試過程復雜化。測試人員需要學習如何診斷自動化測試執行失敗的情況，如果不這樣做，測試執行人員會認為執行失敗的情況是由自動化引起，然后，自動化工程師被叫過來幫助診斷每一個執行失敗的情況，開發人員往往也會認為執行失敗是由于自動化測試自身引起的問題，這樣，測試執行人員就不得不學習通過手工的方式，或者通過采用少量腳本的方式重現自動化測試發現的問題，以證明他們確實發現了產品當中的 BUG 。

　　測試套的相關工作還沒有結束，為了提高測試覆蓋率或者測試新的產品特性，需要增加更多的測試。如果已有的測試不能正常工作，那么需要對之修改;如果已有的測試是冗余的，那么需要刪除這部分測試。

　　隨著時間的推移，開發人員也會研究你設計的測試，改進產品的設計并且通過模擬你的測試過程對產品做初步測試，研究如何使產品在第一次測試就通過，這樣，你設計的測試很可能無法繼續發現新的問題，這種現象被稱為一種殺蟲劑悖論。這時候，會有人對你的測試有效性提出質疑，那么，你必須考慮是否應該挖掘更嚴格的測試，以便能夠發現開發人員優化之后的產品中的缺陷。

　　以前，我提到過一個基本上無法實現的設想，設想通過按下一個按鈕就完成了所有的測試工作。自動化測試是不是全能的，手工測試是永遠無法完全替代的。

　　有些測試受測試環境的影響很大，往往需要采用人工方法獲取測試結果，分析測試結果。因此，很難在預先知道設計的測試用例有多大的重用性。自動化測試還需要考慮成本問題，因此，千萬不要陷入到一切測試都采用自動化方法的錯誤觀念中。

　　我曾經主張保證給與測試自動化持續不斷的投入。但是，在開展自動化測試的時候，一個問題擺在面前，測試自動化應該及時的提供給測試執行人員，這個不成問題，但是如何保證需求變更后，能夠及時提供更新后的自動化測試就是個大問題了。如果自動化測試與需求變更無法同步，那么自動化測試的效果就無法保證了，測試人員就不愿意花費時間學習如何使用新的測試工具和如何診斷測試工具上報的錯誤。識別項目計劃中的軟件發布日期，然后把這個日期作為里程碑，并計劃達到這個里程碑。當達到這個里程碑后，自動化工程師應該做什么呢?如果自動化工程師關注當前產品版本的發布，他需要為測試執行人員提供幫助和咨詢，但是，一旦測試執行人員知道如何使用自動化測試，自動化測試工程師可以考慮下一個版本的測試自動化工作，包括改進測試工具和相關的庫。當開發人員開始設計產品下一個版本中的新特性的時候，如果考慮了自動化測試需求，那么自動化測試師的設計工作就很好開展了，采用這種方法，自動化測試工程師可以保持與開發周期同步，而不是與測試周期同步。如果不采用這種方式，在產品版本升級的過程中，自動化測試無法得到進一步的改進。

原文轉自：http://www.anti-gravitydesign.com