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

性能： 提高代碼的性能往往增加了代碼的復雜性，因此，會威脅到代碼的可靠性。很少有人關心如何對自動化本身加以測試。通過我對測試套性能的分析，很多測試套都是 花費大量的時間等候產品的運行。因此，在不提高產品運行性能的前提下，無法更有效的提高自動化測試執行效率。我懷疑測試自動化工程師只是從計算機課程了解 到應該關注軟件的性能，而并沒有實際的操作經驗。如果測試套的性能問題無法改變，那么應該考慮提高硬件的性能；測試套中經常會出現冗余，也可以考慮取出測 試套中的冗余或者減少一個測試套中完成的測試任務，都是很好的辦法。

便于分析： 測試自動化執行失敗后應該分析失敗的結果，這是一個棘手的問題。分析執行失敗的自動化測試結果是件困難的事情，需要從多方面著手，測試上報的告警信息是真 的還是假的？是不是因為測試套中存在缺陷導致測試執行失??？是不是在搭建測試環境中出現了錯誤導致測試執行失??？是不是產品中確實存在缺陷導致測試執行失 ??？有幾個方法可以幫助測試執行失敗的結果分析，某些方法可以找到問題所在。通過在測試執行之前檢查常見的測試環境搭建問題，從而提高測試套的可靠性；通 過改進錯誤輸出報告，從而提高測試自動化的錯誤輸出的可分析性；此外，還可以改進自動化測試框架中存在的問題。訓練測試人員如何分析測試執行失敗結果。甚 至可以找到那些不可靠的、冗余的或者功能比較獨立的測試，然后安全地將之刪除。上面這些都是減少自動化測試誤報告警、提高測試可分析性的積極有效的方法。 另外，有一種錯誤的測試結果分析方法，那就是采用測試結果后處理程序對測試結果自動分析和過濾，盡管也可以采用這種測試結果分析方法，不過這種方法會使自 動化測試系統復雜化，更重要的是，后處理程序中的 BUG 會嚴重損害自動化測試的完整性。如果由于自動化測試本身存在的缺陷誤把產品中的正常功能視為異常，那該怎么辦？我曾經看到測試小組花費開發測試自動化兩倍 的時間來修改測試腳本，并且不愿意開展培訓過程。那些僅僅關注很淺層次測試技術的測試管理者對這種方法很感興趣，他們排斥采用隱藏測試復雜度的方法。

綜上所述，應該集中精力關注可以延續使用的測試套，從以下幾方面考慮，測試的可檢視性、測試的可維護性、測試的完整性、測試的獨立性、測試的可重復性。

可讀性： 很多情況下，在測試人員開始測試項目之前，公司已經有了一套測試腳本，并且已經存在很多年了。我們可以稱之為 “ 聰明的橡樹 ”(wise oak tree)[Bach 1996] 。大家很依賴它，但是并不知道它是什么。由于 “ 聰明的橡樹 ” 類型的測試腳本缺乏可讀性，在具體應用中，那些腳本常常沒有多大的實用價值，越來越讓人迷惑。因此，測試人員很難確定他們實際在測試什么，反而會導致測試 人員對自身的測試能力有過高的估計。測試人員能夠檢視測試腳本，并且理解測試腳本究竟測試了什么，這是很關鍵的。好的文檔是解決問題的手段之一，對測試腳 本全面分析是另外一個手段。由上面兩種方法可以引申出其它的相關方法，我曾經在一個項目中使用過引申之后的方法。在測試腳本中插樁，把所有執行的產品相關 的命令記錄到日志里。這樣，當分析日志確定執行了哪些產品命令，命令采用了何種參數配置時，可以提供一個非常好的測試記錄，里面記錄了自動化測試執行了什 么，沒有執行什么。如果測試腳本可讀性不好，很容易變得過分依賴并沒有完全理解的測試腳本，很容易認為測試腳本實際上做的工作比你想象中的還要多。測試套 的可讀性提高后，可以更容易的開展同行評審活動。

可維護性： 在工作中，我曾經使用過一個測試套，它把所有的程序輸出保存到文件中。然后，通過對比輸出文件內容和一個已有的輸出文件內容的差別，可以稱已有的輸出文件 為 “ 標準文件 ” （ “gold file” ）。在回歸測試中，用這個方法查找 BUG 是不是明智之舉。這種方法太過于敏感了，它會產生很多錯誤的警告。隨著時間的推移，軟件開發人員會根據需要修改產品的很多輸出信息，這會導致很多自動化測 試失敗。很明顯，為了保證自動化測試的順利進行，應該在對 “ 標準文件 ” 仔細分析的基礎上，根據開發人員修改的產品輸出信息對之做相應的修改。比較好的可維護性方法是，每次只檢查選定的產品的某些特定輸出，而不是對比所有的結 果輸出。產品的接口變動也會導致原來的測試無法執行或者執行失敗。對于 GUI 測試，這是一個更大的挑戰。研究由于產品接口變化引起的相關測試修改，并研究使測試修改量最小的方法，測試中采用庫是解決問題的方法。當產品發生變化的時 候，只需要修改相關的庫，保證測試與產品的變動同步修改即可。

原文轉自：http://www.uml.org.cn/Test/201312093.asp