對于某個特定程序，為其開發自動化
功能測試解決方案的過程，與創建該程序的過程，二者相較并沒有很懸殊的差別。
自動化測試是一個非常年輕的領域，它正在不斷經歷大量的進步、提升和標準化進程。在這個領域中，涌現了許多與“被測系統”（SUT，System Under
Test）互動的新工具。
現在，
軟件開發方面有大量可供選擇的方法論和途徑，例如：面向對象編程、函數式編程、領域驅動設計、測試驅動設計、行為驅動設計等等。它們擁有明確的聲明性概念和理論，并簡化了對初始系統架構的定義過程、對系統的理解以及開發者之間的知識交換等方面的
工作。
本文將主要針對GUI（圖形用戶界面）應用的測試自動化進行討論——從自動化開發人員的角度看，在這種情況下被測系統（SUT）表現為一個黑箱（被測系統，是指一個正在測試是否能夠正確操作的系統。對于桌面應用來說，它就是應用本身，而對瀏覽器系統來說——則代表了網站/Web項目等含義）。在公司的遺留系統占很高比例的環境里，或是在新開發的系統沒有考慮可檢測質量屬性時，這一現象非常常見。
對最佳實踐的準備和定義，是開發自動化的測試的關鍵部分。下圖展示了被測系統和測試者之間的傳統交互：
測試者與SUT之間的交互
位于該系統中心的，是一個扮演測試者角色的人類個體。測試者使用手動交互和應用的視覺化分析，以及特定的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狀態。
測試分組模式
每個測試類封裝一個測試方法
在該模式下，每個獨立的測試方法，都封裝在一個獨立的測試類中。
測試類中的分組測試方法
在該模式下，多個測試方法被放置于一個獨立的測試類中。
總結
測試解決方案的設計背后的驅動力，是對特定測試實現模式的選擇。它扮演了未來所有測試解決方案開發的起點，將在可讀性、可維護性和其他諸多特性方面產生影響。而且它也設置了這些實驗，使其在能夠產生幫助的時候更好地復用項目之間的資源，并減少新項目自動啟動的時間。
這篇文章拋出了有關如何參考設計模式，來構建測試解決方案的想法。