自動化測試的7個步驟

領測軟件測試網

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

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

　　完整性： 當自動化測試執行后，報告測試執行通過，可以斷定這是真的嗎？這就是我稱之為測試套的完整性。在前面的故事中，當沒有對自動化測試完整性給予應有的關注的時候，發生了富有喜劇性的情況。我們應該在多大程度上相信自動化化測試執行結果？自動化測試執行中的誤報告警是很大的問題。測試人員特別討厭由于測試腳本自身的問題或者是測試環境的問題導致測試執行失敗，但是，對于自動化測試誤報告警的情況，大家往往無能為力。你期望自己設計的測試對 BUG 很敏感、有效，當測試發現異常的時候，能夠報告測試執行失敗。有的測試框架支持對特殊測試結果的分類方法，分類包括 PASS ， FAIL 和第三種測試結果 NOTRUN 或者 UNRESOLVED 。無論你怎么稱呼第三種測試結果，它很好的說明了由于某些測試失敗導致其他測試用例無法執行而并非執行失敗的情況。得到正確的測試結果是自動化測試完整性定義的一部分，另一部分是能夠確認執行成功的測試確確實實已經執行過了。我曾經在一個測試隊列中發現一個 BUG ，這個 BUG 引起測試隊列中部分測試用例被跳過，沒有執行。當測試隊列運行完畢后，沒有上報任何錯誤，我不得不通過走讀代碼的方式發現了這個 BUG 。如果，我沒有關注到這個 BUG ，那么可能在認識到自動化測試已經出現問題之前，還在長時間運行部分測試用例。  

　　獨立性： 采用自動化方法不可能達到和手工測試同樣的效果。當寫手工測試執行的規程時候，通常假定測試執行將會由一個有頭腦、善于思考、具有觀察力的測試人員完成的。如果采用自動化，測試執行是由一臺不會說話的計算機完成的，你必須告訴計算機什么樣的情況下測試執行是失敗的，并且需要告訴計算機如何恢復測試場景才能保證測試套可以順利執行。自動化測試可以作為測試套的一部分或者作為獨立的測試執行。測試都需要建立自己所需要的測試執行環境，因此，保證測試執行的獨立性是唯一的好方法。手工回歸測試通常都相關的指導文檔，以便一個接著一個有序地完成測試執行，每個測試執行可以利用前一個測試執行創建的對象或數據記錄。手工測試人員可以清楚地把握整個測試過程。在自動化測試中采用上述方法是經常犯的錯誤，這個錯誤源于 “ 多米諾骨牌 ” 測試套，當一個測試執行失敗，會導致后續一系列測試失敗。更糟糕的是，所有的測試關聯緊密，無法獨立的運行。并且，這使得在自動化測試中分析合法的執行失敗結果也困難重重。當出現這種情況后，人們首先開始懷疑自動化測試的價值。自動化測試的獨立性要求在自動化測試中增加重復和冗余設計。具有獨立性的測試對發現的缺陷的分析有很好的支持。以這種方式設計自動化測試好像是一種低效率的方式，不過，重要的是在不犧牲測試的可靠性的前提下保證測試的獨立性，如果測試可以在無需人看守情況下運行，那么測試的執行效率就不是大問題了。  

　　可重復性： 自動化測試有時能夠發現問題，有時候又無法發現問題，對這種情況實在沒有什么好的的處理辦法。因此，需要保證每次測試執行的時候，測試是以同樣的方式工作。這意味著不要采用隨機數據，在通用語言庫中構造的隨機數據經常隱藏初始化過程，使用這些數據會導致測試每次都以不同的方式執行，這樣，對測試執行的失敗結果分析是很讓人沮喪的。這里有兩個使用隨機數據發生器的的方法可以避免上述情況。一種方法是使用常量初始化隨機數據發生器。如果你打算生成不同種類的測試，需要在可預測，并且可控制的情況下建立不同類型的隨機數據發生器。另外一個辦法是提前在文件中或數據庫中建立生成隨機測試數據，然后在測試過程中使用這些數據。這樣做看起來似乎很好，但是我卻曾經看到過太多違反規則的做法。下面我來解釋到底看到了什么。當手動執行測試的時候，往往匆匆忙忙整理文件名和測試數據記錄。當對這些測試采用自動化測試方法，該做哪些工作呢？辦法之一是，可以為測試中使用的數據記錄給固定的命名。如果這些數據記錄在測試完成后還要繼續使用，那么就需要制定命名規則，避免在不同的測試中命名沖突，采用命名規則是一種很好的方法。然而，我曾經看到有些測試只是隨機的命名數據記錄，很不幸，事實證明采用這種隨機命名的方式不可避免的導致命名沖突，并且影響測試的可重復性。很顯然，自動化工程師低估了命名沖突的可能性。下面的情況我遇到過兩次，測試數據記錄的名字中包含四個隨機產生的數字，經過簡單的推算如果我們采用這種命名方式的時候，如果測試使用了 46 條記錄，會存在 10% 沖突的可能性，如果使用 118 條記錄，沖突的幾率會達到 50% 。我認為測試當中使用這種隨機命名是出于偷懶的想法 —— 避免再次測試之前寫代碼清除老的數據記錄，這樣引入了問題，損害了測試的可靠性和測試的完整性。  

　　測試庫： 自動化測試的一個通用策略是開發可以在不同測試中應用的測試函數庫。我曾經看到過很多測試函數庫，自己也寫了一些。當要求測試不受被測試產品接口變動影響的時候，采用測試庫方法是非常有效的。不過，根據我的觀察測試庫已經使用的太多了，已經被濫用了，并且測試庫往往設計的不好，沒有相關的文檔支撐，因此，使用測試庫的測試往往很難開展。當發現問題的時候，往往不知道是測試庫自身的問題，還是測試庫的使用問題。由于測試庫往往很復雜，即便在發現測試庫存在問題，相關的維護人員也很不愿意去修改問題。通過前文中的論述，可以得出結論，在一開始就應該保證測試庫設計良好。但是，實際情況是測試自動化往往沒有花費更多的精力去保證一個優良設計的測試庫。我曾經看到有些測試庫中的功能根本不再使用了或僅僅使用一次。這與極限編程原則保持一致，即 " 你將不需要它 " 。這會導致在測試用例之間的代碼出現一些重復，我發現微小的變化可能仍然存在，很難與測試庫功能協調。你可能打算對測試用例作修改，采用源代碼的方式比采用庫的方式更容易修改。如果有幾個測試，他們有某些共同的操作，我使用剪切和粘貼的方式去復制代碼，有的人認為我采用的方法不可理喻。這允許我根據需要修改通用代碼，我不必一開始嘗試和猜測如何重用代碼。我認為我的測試是很容易讀懂的，因為閱讀者不必關心任何測試庫的語法。這種辦法的優勢是很容易理解測試，并且很方便擴展測試套。在開發軟件測試項目的時候，大多數程序員找到與他們打算實現功能類似的源代碼，并對源代碼做修改，而不是從頭開始寫代碼。同樣，在寫測試套的過程中可以采用上述方法，這也是代碼開發方式所鼓勵的方法。我比較喜歡寫一些規模比較小的測試庫，這些庫可以被反復的使用。測試庫的開發需要在概念階段充分定義，并且文檔化，從始至終都應該保持。我會對測試庫作充分的測試后，才在測試中使用這些測試庫。采用測試庫是對所有面臨的情況作權衡的。千萬不要打算寫一個大而全的測試庫，不要希望有朝一日測試人員會利用你的測試庫完成大量的測試，這一天恐怕永遠不會到來。  

　　數據驅動測試： 把測試數據寫入到簡單表格中，這種測試技術得到了越來越廣泛的應用，這種方法被稱為表驅動（ table-driven ），數據驅動 (data-driven) 或者 “ 第三代 ” 自動化測試（ "third generation" automation ）。這需要寫一個解析器，用來解釋表格中的數據，并執行測試。該測試架構的最主要的好處是，它允許把測試內容寫在具有一定格式的表格中，這樣方便數據設計和數據的檢視。如果測試組中有缺少編程經驗的業務專家參與測試，采用數據驅動測試方法是很合適的。數據驅動測試的解析器主要是由測試庫和上層的少量開發語言寫成的代碼組成的，所以，上面關于測試庫的說明放在這里是同樣合適的。在針對上面提到的少量代碼的設計、開發、測試的工作，還存在各種困難。代碼所采用的編程語言是不斷發展的。也許，測試人員認為他們需要把第一部分測試的輸出作為第二部分測試的輸入，這樣，加入了新的變量。接下來，也許有人需要讓測試中的某個環節運行一百次，這樣加入一個循環。你可以采用其他語言，不過，如果你預料到會面臨上述情況的時候，那么做好采用一些能夠通過公開的渠道獲取的編程語言，比如 Perl,Python 或者 TCL ，這樣比設計你自己的語言要快的多。  

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 自動測試