可讀性： 很多情況下，在測試人員開始測試項目之前，公司已經有了一套測試腳本，并且已經存在很多年了。我們可以稱之為 “ 聰明的橡樹 ”(wise oak tree)[Bach 1996] 。大家很依賴它，但是并不知道它是什么。由于 “ 聰明的橡樹 ” 類型的測試腳本缺乏可讀性，在具體應用中，那些腳本常常沒有多大的實用價值，越來越讓人迷惑。因此，測試人員很難確定他們實際在測試什么，反而會導致測試人員對自身的測試能力有過高的估計。測試人員能夠檢視測試腳本，并且理解測試腳本究竟測試了什么，這是很關鍵的。好的文檔是解決問題的手段之一，對測試腳本全面分析是另外一個手段。由上面兩種方法可以引申出其它的相關方法，我曾經在一個項目中使用過引申之后的方法。在測試腳本中插樁，把所有執行的產品相關的命令記錄到日志里。這樣，當分析日志確定執行了哪些產品命令，命令采用了何種參數配置時，可以提供一個非常好的測試記錄，里面記錄了自動化測試執行了什么，沒有執行什么。如果測試腳本可讀性不好，很容易變得過分依賴并沒有完全理解的測試腳本，很容易認為測試腳本實際上做的工作比你想象中的還要多。測試套的可讀性提高后，可以更容易的開展同行評審活動。
可維護性： 在工作中，我曾經使用過一個測試套，它把所有的程序輸出保存到文件中。然后，通過對比輸出文件內容和一個已有的輸出文件內容的差別，可以稱已有的輸出文件為 “ 標準文件 ” ( “gold file” )。在回歸測試中，用這個方法查找 BUG 是不是明智之舉。這種方法太過于敏感了，它會產生很多錯誤的警告。隨著時間的推移，軟件開發人員會根據需要修改產品的很多輸出信息，這會導致很多自動化測試失敗。很明顯，為了保證自動化測試的順利進行，應該在對 “ 標準文件 ” 仔細分析的基礎上，根據開發人員修改的產品輸出信息對之做相應的修改。比較好的可維護性方法是，每次只檢查選定的產品的某些特定輸出，而不是對比所有的結果輸出。產品的接口變動也會導致原來的測試無法執行或者執行失敗。對于 GUI 測試，這是一個更大的挑戰。研究由于產品接口變化引起的相關測試修改，并研究使測試修改量最小的方法，測試中采用庫是解決問題的方法。當產品發生變化的時候，只需要修改相關的庫，保證測試與產品的變動同步修改即可。
完整性： 當自動化測試執行后，報告測試執行通過，可以斷定這是真的嗎?這就是我稱之為測試套的完整性。在前面的故事中，當沒有對自動化測試完整性給予應有的關注的時候，發生了富有喜劇性的情況。我們應該在多大程度上相信自動化化測試執行結果?自動化測試執行中的誤報告警是很大的問題。測試人員特別討厭由于測試腳本自身的問題或者是測試環境的問題導致測試執行失敗，但是，對于自動化測試誤報告警的情況，大家往往無能為力。你期望自己設計的測試對 BUG 很敏感、有效，當測試發現異常的時候，能夠報告測試執行失敗。有的測試框架支持對特殊測試結果的分類方法，分類包括 PASS ， FAIL 和第三種測試結果 NOTRUN 或者 UNRESOLVED 。無論你怎么稱呼第三種測試結果，它很好的說明了由于某些測試失敗導致其他測試用例無法執行而并非執行失敗的情況。得到正確的測試結果是自動化測試完整性定義的一部分，另一部分是能夠確認執行成功的測試確確實實已經執行過了。我曾經在一個測試隊列中發現一個 BUG ，這個 BUG 引起測試隊列中部分測試用例被跳過，沒有執行。當測試隊列運行完畢后，沒有上報任何錯誤，我不得不通過走讀代碼的方式發現了這個 BUG 。如果，我沒有關注到這個 BUG ，那么可能在認識到自動化測試已經出現問題之前，還在長時間運行部分測試用例。
獨立性： 采用自動化方法不可能達到和手工測試同樣的效果。當寫手工測試執行的規程時候，通常假定測試執行將會由一個有頭腦、善于思考、具有觀察力的測試人員完成的。如果采用自動化，測試執行是由一臺不會說話的計算機完成的，你必須告訴計算機什么樣的情況下測試執行是失敗的，并且需要告訴計算機如何恢復測試場景才能保證測試套可以順利執行。自動化測試可以作為測試套的一部分或者作為獨立的測試執行。測試都需要建立自己所需要的測試執行環境，因此，保證測試執行的獨立性是唯一的好方法。手工回歸測試通常都相關的指導文檔，以便一個接著一個有序地完成測試執行，每個測試執行可以利用前一個測試執行創建的對象或數據記錄。手工測試人員可以清楚地把握整個測試過程。在自動化測試中采用上述方法是經常犯的錯誤，這個錯誤源于 “ 多米諾骨牌 ” 測試套，當一個測試執行失敗，會導致后續一系列測試失敗。更糟糕的是，所有的測試關聯緊密，無法獨立的運行。并且，這使得在自動化測試中分析合法的執行失敗結果也困難重重。當出現這種情況后，人們首先開始懷疑自動化測試的價值。自動化測試的獨立性要求在自動化測試中增加重復和冗余設計。具有獨立性的測試對發現的缺陷的分析有很好的支持。以這種方式設計自動化測試好像是一種低效率的方式，不過，重要的是在不犧牲測試的可靠性的前提下保證測試的獨立性，如果測試可以在無需人看守情況下運行，那么測試的執行效率就不是大問題了。
可重復性： 自動化測試有時能夠發現問題，有時候又無法發現問題，對這種情況實在沒有什么好的的處理辦法。因此，需要保證每次測試執行的時候，測試是以同樣的方式工作。這意味著不要采用隨機數據，在通用語言庫中構造的隨機數據經常隱藏初始化過程，使用這些數據會導致測試每次都以不同的方式執行，這樣，對測試執行的失敗結果分析是很讓人沮喪的。這里有兩個使用隨機數據發生器的的方法可以避免上述情況。一種方法是使用常量初始化隨機數據發生器。如果你打算生成不同種類的測試，需要在可預測，并且可控制的情況下建立不同類型的隨機數據發生器。另外一個辦法是提前在文件中或數據庫中建立生成隨機測試數據，然后在測試過程中使用這些數據。這樣做看起來似乎很好，但是我卻曾經看到過太多違反規則的做法。下面我來解釋到底看到了什么。當手動執行測試的時候，往往匆匆忙忙整理文件名和測試數據記錄。當對這些測試采用自動化測試方法，該做哪些工作呢?辦法之一是，可以為測試中使用的數據記錄給固定的命名。如果這些數據記錄在測試完成后還要繼續使用，那么就需要制定命名規則，避免在不同的測試中命名沖突，采用命名規則是一種很好的方法。然而，我曾經看到有些測試只是隨機的命名數據記錄，很不幸，事實證明采用這種隨機命名的方式不可避免的導致命名沖突，并且影響測試的可重復性。很顯然，自動化工程師低估了命名沖突的可能性。下面的情況我遇到過兩次，測試數據記錄的名字中包含四個隨機產生的數字，經過簡單的推算如果我們采用這種命名方式的時候，如果測試使用了 46 條記錄，會存在 10% 沖突的可能性，如果使用 118 條記錄，沖突的幾率會達到 50% 。我認為測試當中使用這種隨機命名是出于偷懶的想法 —— 避免再次測試之前寫代碼清除老的數據記錄，這樣引入了問題，損害了測試的可靠性和測試的完整性。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
