自動化功能測試的基本原則

介紹

　　每個實行持續傳遞的項目，都有生産流水線的元素，如持續內建和自動化測試。這些測試是在不同層面進行的，從單元測試到冒煙測試再到功能測試。自動化功能測試的優點之一是可重複性和可預測的執行時間。出于這個原因，它應該作為軟體品質的每一個建構之後的名額。功能測試自動化往往會成為一個瓶頸，是以你應該熟悉一下如何建立這樣的測試的基本原則。

　　首先設計你的測試

　　測試集合可以比作盆景樹。

　　最初的時候，我們照顧樹根和樹幹。我們選擇會成長的主要分支，我們每天都細心照料這棵樹并等待它長出健康的葉子。

　　我們可以以類似的方式繼續測試。

　　我們建一個将負責應用程式主要功能（例如：開啟）的基類。

　　根據說明，我們先明确将被測試覆寫的應用程式的主要功能，然後每天我們在執行測試的時候都添加更多平行測試。

　　每一個支援測試（例如建立一個新的使用者）的方法都需要與測試分離——讓我們在單獨的類裡面來實作。

　　你應該在包括了應用程式主要功能的目錄裡保持類。

　　去建一個規定很多功能共有方法的抽象類是很好的做法。

　　如果你正在測試web應用程式，就用頁面對象設計模式。該模式裡，一個類及其方法對應了單個頁面的功能或一個大型網頁裡單個頁面上的一個元素。

　　無需事事自動化

　　自動化花費很多，是以你應該主要測試應用程式的主要功能。

　　某些測試可以快速輕松地手動完成，且潛在腳本可能難以實作。

　　值得用到自動化的是那些繁瑣的需要被重複很多次的，和那些需要大量資料驗證的測試工作。

　　寫短測試

　　在一個或多個測試失敗的情況下，開發團隊的任何成員都應該能夠輕松地找到錯誤的原因。

　　出于這個原因，每個測試方法裡應該最多有5個斷言，并且每個方法都必須提供的測試操作的完整記錄。

　　明智的做法是使用bdd（行為驅動開發）技術，但是當你沒有用一個特定的測試架構時，你應該把接下來的測試步驟放在comments //given //when //then下。

　　建立獨立測試

　　在測試類中的每個方法應該是一個獨立的實體，而不是依賴于其他測試。我們應該能夠在任何時間運作單個測試。否則，這樣的測試用例集将來維護起來就會很貴——必須定期跟蹤和更新測試之間的聯系。

　　很多時候，測試需要一定的前提條件來滿足。這些條件不應該用外部方法，應該在試驗開始時運作。如果這些條件和測試類的所有方法一樣，它們就可以被放在一開始進行的方法裡（例如：在junit中被标記為@ beforeclass）。

　　關注可讀性

　　源代碼應該是自我記錄的，而寫下以下幾行代碼的每個利益相關者應該明白測試在做什麼，為什麼它被這麼寫。盡量避免在源代碼注釋，因為它也必須被更新。這值得花比平常多一點的時間來命名方法，進而使你的代碼更易讀。

　　再看看行為驅動開發技術，每個測試方法都應以單詞“應該”開始，而不是“測試”。

　　根據這一慣例，我們馬上就可以明白一個特定的方法測試什麼内容了，它在分析測試報告時特别有用。

　測試必須要快

　　正如在本文開頭所提到的，自動化功能測試應該是應用程式品質的一個名額。連續傳遞過程中的每一步都應指明最長持續時間；并且根據這個概念，開發團隊應該盡快獲得有關軟體品質的回報。自動化功能測試的持續時間應不超過幾分鐘。

　　對一個非常全面的測試集來說，有必要并行運作測試（經常在不同的機器上）。虛拟化在這裡可能是非常有幫助的。

　　建立抗變測試

　　最常提及自動化功能測試的缺點是其對應用程式中變化的低抵抗性，尤其是在gui中。

　　在web應用程式中，測試應該能抵抗網站的内容的變化。測試應該隻驗證功能，這就使得它可以在不同的位置運作測試。這并不意味着我們不應該編寫自動化測試來檢查網頁的内容。

　　如果你已經想建立這樣的測試，你應該遵循ddt（資料驅動測試）技術。這意味着，檢查内容是與源代碼分離開的。

　　web應用程式的頁面布局變化非常頻繁，這已經影響到了使用者界面。

　　當你設計一個界面時，每個區段和每個頁面你都應該有一個你可以用來測試的唯一辨別符，即使一個網站的層次結構發生了變化。

　　自動化測試無法取代人類

　　功能自動化測試可以是項目中的主要測試技術，但絕不是唯一的一個。

　　自動化測試是可重複再生的，他們的覆寫範圍總是相同的。

　　另一方面，雖然探索性測試是低再生的，但是它們能夠覆寫自動化測試未觸及的區域。

　　你還應該記住，自動化測試的“綠色”狀态并不意味着你的應用程式是沒有錯誤的。

　　這種情況往往會讓測試員分心，而且有可能會影響測試的準确性。