步驟六:有計劃的部署
在前面的故事中,當自動化工程師沒有提供打包后的自動化測試程序給測試執行人員,會影響到測試執行,測試執行人員不得不反過來求助自動化工程師指出如何使用自動化測試程序。
作為自動化工程師,你知道如何利用自動化方法執行測試和分析執行失敗的結果。不過,測試執行人員卻未必知道如何使用自動化測試。因此,需要提供自動化測試 程序的安裝文檔和使用文檔,保證自動化測試程序容易安裝和配置。當安裝的環境與安裝的要求不匹配,出現安裝錯誤的時候,能夠給出有價值的提示信息,便于定 位安裝問題。
能夠把自動化測試程序和測試套作為產品對待,那真是太好了。你應該對自動化測試程序和測試套開展測試,保證它們不依賴于任何專用的庫或者是設備上的任何其他程序。
保證其他測試人員能夠隨時利用已經提供的自動化測試程序和測試套開展測試工作;保證自動化測試是符合一般測試執行人員的思維習慣的;保證測試執行人員能夠理解測試結果,并能夠正確分析失敗的測試執行結果;這需要自動化工程師提供自動動化測試相關的指導性文檔和培訓。
作為測試管理者,你希望在自動化工程師離開前,能夠識別并修改測試套中的所有問題。自動化工程師遲早會離開的,如果你沒有及時的把測試套中的問題提出來,就會面臨廢棄已有的測試套的決定。
良好的測試套有多方面的用處。良好的測試套支持對產品新版本的測試;良好的測試套在新的軟件平臺上可以很方便的驗證產品的功能;良好的測試套支持每天晚上開始的軟件每日構造過程;甚至開發人員在代碼 check in 之前,用良好的測試套驗證代碼的正確性。
測試套的共享也很重要。很難預見以后什么人會繼續使用你開發的測試套。因此,盡量讓產品開發測試團隊中的成員都很容易獲得你的測試套??梢园褱y試套放在公 司的內部網絡上,這是個很好的辦法。這樣,大家就不必為了獲取一份需要的測試套而四處打聽。有些人總是感覺自己的測試套還沒有最終完工或者不夠完美,而沒 有拿出來與人分享,這種做法一定要改變,共享出來的測試套不一定非常完美,共享才是關鍵。
步驟七:面對成功的挑戰
當你完成了所有的事情,測試套已經文檔化了,并且文檔已經交付了。測試執行人員能夠理解要開展的測試,并知道如何完成測試執行。隨著你所負責產品的進一步 開發和維護,測試被反復重用。雖然,在自動化使測試變簡單的同時,也總是使測試過程復雜化。測試人員需要學習如何診斷自動化測試執行失敗的情況,如果不這 樣做,測試執行人員會認為執行失敗的情況是由自動化引起,然后,自動化工程師被叫過來幫助診斷每一個執行失敗的情況,開發人員往往也會認為執行失敗是由于 自動化測試自身引起的問題,這樣,測試執行人員就不得不學習通過手工的方式,或者通過采用少量腳本的方式重現自動化測試發現的問題,以證明他們確實發現了 產品當中的 BUG 。
測試套的相關工作還沒有結束,為了提高測試覆蓋率或者測試新的產品特性,需要增加更多的測試。如果已有的測試不能正常工作,那么需要對之修改;如果已有的測試是冗余的,那么需要刪除這部分測試。
隨著時間的推移,開發人員也會研究你設計的測試,改進產品的設計并且通過模擬你的測試過程對產品做初步測試,研究如何使產品在第一次測試就通過,這樣,你 設計的測試很可能無法繼續發現新的問題,這種現象被稱為一種殺蟲劑悖論。這時候,會有人對你的測試有效性提出質疑,那么,你必須考慮是否應該挖掘更嚴格的 測試,以便能夠發現開發人員優化之后的產品中的缺陷。
以前,我提到過一個基本上無法實現的設想,設想通過按下一個按鈕就完成了所有的測試工作。自動化測試是不是全能的,手工測試是永遠無法完全替代的。
有些測試受測試環境的影響很大,往往需要采用人工方法獲取測試結果,分析測試結果。因此,很難在預先知道設計的測試用例有多大的重用性。自動化測試還需要考慮成本問題,因此,千萬不要陷入到一切測試都采用自動化方法的錯誤觀念中。
原文轉自:http://www.uml.org.cn/Test/201312093.asp