本文将主要針對gui（圖形使用者界面）應用的測試自動化進行讨論——從自動化開發人員的角度看，在這種情況下被測系統（sut）表現為一個黑箱（被測系統，是指一個正在測試是否能夠正确操作的系統。對于桌面應用來說，它就是應用本身，而對浏覽器系統來說——則代表了網站/web項目等含義）。在公司的遺留系統占很高比例的環境裡，或是在新開發的系統沒有考慮可檢測品質屬性時，這一現象非常常見。
對最佳實踐的準備和定義，是開發自動化的測試的關鍵部分。下圖展示了被測系統和測試者之間的傳統互動：
測試者與sut之間的互動
自動化測試的主要目的，是消除（或者至少最小化）人類與sut之間的互動。在持續傳遞産品開發周期中，這是非常常見的問題。一份文獻來源的研究表明，現在自動化測試系統的數量非常多。商業産品一般會公布一系列詳細的要求和推薦，特别适用于其産品。但是這些廠家往往不會公布适合與任何自動工具一起使用的一系列工具診斷實踐。
此外，這些自動工具軟體提供商往往還會運用營銷手段，基于小量功能測試來描繪其系統的優勢。但是随着自動化測試數量的增長，維護現有測試将成為系統工作流程中最昂貴的部分。
自動化測試架構旨在幫忙解決這些問題。他們定義了基本的系統可複用元件，公布了最佳實踐和統一自動方法——為了正确地開發自動化測試架構，我們需要得到獨立最佳實踐的指導。
自動化功能測試的模式
讓我們檢查以下web應用程式自動化方面的問題（圖1），這是一個自動化解決方案裝置的例子。該應用包含了一幅登入頁面，而每項測試都必須經過該頁面，才能進行更進一步的測試。
圖1：示例——擁有最少頁面和功能集的簡單web應用
分類體系（圖2）為我們帶來了全部功能測試模式的整體視角，本文稍後會對各個模式展開描述。
圖2：自動化功能測試模式的分類
測試實作的模式
記錄
通過自動化測試工具來執行此模式的測試實作。該工具記錄并回放手工測試者的操作。某種程度上，考慮到昂貴的維護成本，這種方式被認為是一個糟糕的實踐。
腳本化
由程式員使用自動化工具的api來執行測試實作（例如selenium webdriver api）。
實作基礎模闆（測試模闆）
該模式将實作基礎測試模闆類。要實作各種測試的變體，可以通過繼承和擴充模闆類的功能來建立。
資料驅動實作
通過測試用例來定義一個基礎測試的實作。可以通過一系列不同的輸入資料組合，來建立各種測試的變體。
在大部分單元測試架構中都實作了這一方法，例如：mstest以datacontext（鍵值集合）的方式，提供對測試内部的屬性的通路權限。于是，相同的測試方法主體會運作很多次，但datacontext屬性所提供的資料各不相同。
關鍵字驅動實作
這一測試實作借助了關鍵字（例如：點選、回車）。測試實作通過特殊的ide完成，這類ide可以鈎挂到應用的ui上。
目前已有數款軟體工具，支援借助關鍵字來實作測試。測試的步驟，以關鍵字、螢幕上的控制名和輸入參數的結合的形式出現。hp qtp和monkeytalk是這類ide中的典型例子
模型驅動實作
對任何應用來說，在特定的時刻接受特定的輸入，都隻會有一個特定的狀态。根據這樣的定義，我們可以将軟體程式描繪為有限狀态機（有限自動機）。考慮到這一事實，以及狀态可用性和轉換模型（例如圖1），我們可以定義一套特定的頁面間轉換（工作流）的集合，它将能夠覆寫程式的大部分功能。
架構模式
多層的測試解決方案
該模式從邏輯次元将正在測試的系統劃分為獨立的邏輯層級。
将軟體系統以架構性方式分為獨立的層級是一個廣為流傳的實踐。第一層封裝了表述邏輯，第二層則是業務邏輯層，而第三層負責資料存儲。使用這一範式，有助于降低應用維護成本，因為更換每層内部的元件對其他層級的影響将被最小化。而同樣的方法也可以運用到測試系統中。
測試代碼同樣可以分為三層：用來向sut提供通路的ui自動化工具界面層、功能邏輯層和測試用例層。每一層都肩負特定的責任，而它們都在追求共同的目标——降低測試維護成本，提升建立新測試的便利性。
圖 3: 架構性原型——測試系統的多層架構
元架構
該模式定義了一組基礎的獨立工具類。對任何自動化工具來說，它們都是通用的，而且可以在不同自動化項目之間複用。
當需要在一個組織機構中測試不同的項目，而且企業标準要求測試結果采用統一的界面時，或許就需要這樣的解決方案。此外，元架構改進了項目間代碼複用的度量标準，因為它可能會包含有用的工具方法。有關功能和測試對象的基礎類，簡化了項目之間知識的轉移。元架構展現在圖3的右側。
功能組合模式
功能方法
針對特定于應用的業務功能，從其ui實作、api或其他層面進行了抽象。
用于自動化測試的許多工具，都支援建立被稱之為“場景記錄”的功能。當一位測試開發者針對特定應用執行特定操作時，這些工具将自動建立一份測試腳本。它可以在稍後進行回放，并檢查在程式發生變化後，該腳本是否得到了正确的執行。
例子：改變登入界面的外觀，将要求在全部預計的測試場景中的對應部分都進行變更。如果我們将登入方法提取為application.login(username,password)，并在全部測試中使用這一方法，那麼當登陸頁面發生任何變更的時候，我們将隻需要修改僅僅這一個功能方法，随後變更就會被自動分發到所有使用該方法的測試中。
圖4：測試腳本與(a)缺乏功能方法的過渡層的使用者界面之間的互動；(b) 帶有功能方法層的使用者界面。當應用發生變更時，陰影部分對象将會被改變。
頁面對象
這一模式将某個頁面的功能方法組合在一起。
由于圖1中展現的用于應用的功能方法數量不多，是以它們可以移入一個單獨的類。但是為了提升代碼可維護性，此模式建議依據這些方法所代表頁面，對其進行分組。例如，這些對應關系可以包括：頁面：pagelogin——方法：login()；頁面pagehome——方法：logout()、createuser()。
功能庫
它将某個特定應用的功能對象或（和）功能方法分組打包，成為一個适合複用的子產品。
sut的啟動和拆卸對象（sut運作者）
該模式支援被測系統的初始啟動，即它的初始化。在此之後，測試對象釋放與該系統相關的資源。
在功能方法之中，我們可以區分出與功能測試無關的方法集合：例如啟動某個web浏覽器，并通路sut的登入頁面。而在測試之後，web浏覽器應該被關閉。sut運作者負責以上這些通用活動。
對象源（對象之母、對象精靈、對象工程）
該模式按測試執行所要求的形式，建立并初始化的對象。
運輸者（導航器）
根據測試要求，它将被測試系統中的導航控制集中在一起。
該對象封裝了與被測試系統内部的導航實作有關的完整邏輯。是以業務邏輯的問題不會影響系統内的導航。
對于圖1所描述的情況，我們将擁有一個transporter類（運輸者），它擁有以下方法：navigatetologin()、navigatetohomepage()和navigatetocreateuser()等等。或者，每個獨立的頁面（page）對象或許都會擁有自己的運輸（transport）方法。在這種情況下，這些方法就作為該對象自身的運輸者。
複合頁面對象
該模式将複用的頁面（page）對象聚合在一個外部對象中。
這一模式支援用更加“面向對象”的方式來組織頁面對象——把可以在不同頁面上複用的子對象分離，并将其包含到父對象中。
圖5：通過在首頁和建立使用者頁面對象中聚集，來使用導航頁面（navigation page）對象
擴充的頁面對象
該模式通過繼承來擴充基礎的頁面對象，成為複合頁面對象的替代選擇。
過程模式
給定條件/時機/結果
此模式将測試執行過程分為三個階段：
給定條件（定義先決條件）
時機（設定與上下文協同工作的特定操作）
結果（檢查結果）
四階段測試
此模式将測試執行過程分為四個階段：
定義先決條件
調用業務功能
checking results;
拆卸系統
流測試
該模式支援在一個測試内執行業務操作并進行檢查。兩項内容可以交替進行，直到實作測試的最終目标。
多次失敗
該模式定義了一套機制，能夠在非緻命錯誤出現之後繼續進行測試。
測試依賴模式
獨立測試
該模式令被測試的系統回到測試前的狀态。
鍊式測試
在該模式中，初步測試樹立起了測試需要跟蹤的sut狀态。
測試分組模式
每個測試類封裝一個測試方法
在該模式下，每個獨立的測試方法，都封裝在一個獨立的測試類中。
測試類中的分組測試方法
在該模式下，多個測試方法被放置于一個獨立的測試類中。
總結
測試解決方案的設計背後的驅動力，是對特定測試實作模式的選擇。它扮演了未來所有測試解決方案開發的起點，将在可讀性、可維護性和其他諸多特性方面産生影響。而且它也設定了這些實驗，使其在能夠産生幫助的時候更好地複用項目之間的資源，并減少新項目自動啟動的時間。
這篇文章抛出了有關如何參考設計模式，來建構測試解決方案的想法。
最新内容請見作者的github頁：http://qaseven.github.io/