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

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

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

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

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

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