通過自動化測試工具來執(zhí)行此模式的測試實現(xiàn)。該工具記錄并回放手工測試者的操作。某種程度上，考慮到昂貴的維護成本，這種方式被認為是一個糟糕的實踐。
在大部分單元測試框架中都實現(xiàn)了這一方法，例如：MSTest以DataContext（鍵值集合）的方式，提供對測試內(nèi)部的屬性的訪問權(quán)限。于是，相同的測試方法主體會運行很多次，但DataContext屬性所提供的數(shù)據(jù)各不相同。
這一測試實現(xiàn)借助了關(guān)鍵字（例如：點擊、回車）。測試實現(xiàn)通過特殊的IDE完成，這類IDE可以鉤掛到應(yīng)用的UI上。
目前已有數(shù)款軟件工具，支持借助關(guān)鍵字來實現(xiàn)測試。測試的步驟，以關(guān)鍵字、屏幕上的控制名和輸入?yún)?shù)的結(jié)合的形式出現(xiàn)。HP QTP和MonkeyTalk是這類IDE中的典型例子
對任何應(yīng)用來說，在特定的時刻接受特定的輸入，都只會有一個特定的狀態(tài)。根據(jù)這樣的定義，我們可以將軟件程序描繪為有限狀態(tài)機（有限自動機）。考慮到這一事實，以及狀態(tài)可用性和轉(zhuǎn)換模型（例如圖1），我們可以定義一套特定的頁面間轉(zhuǎn)換（工作流）的集合，它將能夠覆蓋程序的大部分功能。
將軟件系統(tǒng)以架構(gòu)性方式分為獨立的層級是一個廣為流傳的實踐。第一層封裝了表述邏輯，第二層則是業(yè)務(wù)邏輯層，而第三層負責數(shù)據(jù)存儲。使用這一范式，有助于降低應(yīng)用維護成本，因為更換每層內(nèi)部的組件對其他層級的影響將被最小化。而同樣的方法也可以運用到測試系統(tǒng)中。
測試代碼同樣可以分為三層：用來向SUT提供訪問的UI自動化工具界面層、功能邏輯層和測試用例層。每一層都肩負特定的責任，而它們都在追求共同的目標——降低測試維護成本，提升創(chuàng)建新測試的便利性。
圖 3: 架構(gòu)性原型——測試系統(tǒng)的多層架構(gòu)
元框架
該模式定義了一組基礎(chǔ)的獨立工具類。對任何自動化工具來說，它們都是通用的，而且可以在不同自動化項目之間復(fù)用。
當需要在一個組織機構(gòu)中測試不同的項目，而且企業(yè)標準要求測試結(jié)果采用統(tǒng)一的界面時，或許就需要這樣的解決方案。此外，元框架改進了項目間代碼復(fù)用的度量標準，因為它可能會包含有用的工具方法。有關(guān)功能和測試對象的基礎(chǔ)類，簡化了項目之間知識的轉(zhuǎn)移。元框架展現(xiàn)在圖3的右側(cè)。
功能組合模式
功能方法
針對特定于應(yīng)用的業(yè)務(wù)功能，從其UI實現(xiàn)、API或其他層面進行了抽象。
用于自動化測試的許多工具，都支持創(chuàng)建被稱之為“場景記錄”的功能。當一位測試開發(fā)者針對特定應(yīng)用執(zhí)行特定操作時，這些工具將自動創(chuàng)建一份測試腳本。它可以在稍后進行回放，并檢查在程序發(fā)生變化后，該腳本是否得到了正確的執(zhí)行。
例子：改變登錄界面的外觀，將要求在全部預(yù)計的測試場景中的對應(yīng)部分都進行變更。如果我們將登錄方法提取為Application.Login(username,password)，并在全部測試中使用這一方法，那么當?shù)顷戫撁姘l(fā)生任何變更的時候，我們將只需要修改僅僅這一個功能方法，隨后變更就會被自動分發(fā)到所有使用該方法的測試中。
圖4：測試腳本與(a)缺乏功能方法的過渡層的用戶界面之間的交互；(b) 帶有功能方法層的用戶界面。當應(yīng)用發(fā)生變更時，陰影部分對象將會被改變。
頁面對象
這一模式將某個頁面的功能方法組合在一起。
由于圖1中展現(xiàn)的用于應(yīng)用的功能方法數(shù)量不多，因此它們可以移入一個單獨的類。但是為了提升代碼可維護性，此模式建議依據(jù)這些方法所代表頁面，對其進行分組。例如，這些對應(yīng)關(guān)系可以包括：頁面：PageLogin——方法：Login()；頁面PageHome——方法：Logout()、CreateUser()。
功能庫
它將某個特定應(yīng)用的功能對象或（和）功能方法分組打包，成為一個適合復(fù)用的模塊。
SUT的啟動和拆卸對象（SUT運行者）
該模式支持被測系統(tǒng)的初始啟動，即它的初始化。在此之后，測試對象釋放與該系統(tǒng)相關(guān)的資源。
在功能方法之中，我們可以區(qū)分出與功能測試無關(guān)的方法集合：例如啟動某個Web瀏覽器，并訪問SUT的登錄頁面。而在測試之后，Web瀏覽器應(yīng)該被關(guān)閉。SUT運行者負責以上這些通用活動。
對象源（對象之母、對象精靈、對象工程）
該模式按測試執(zhí)行所要求的形式，創(chuàng)建并初始化的對象。
運輸者（導(dǎo)航器）
根據(jù)測試要求，它將被測試系統(tǒng)中的導(dǎo)航控制集中在一起。
該對象封裝了與被測試系統(tǒng)內(nèi)部的導(dǎo)航實現(xiàn)有關(guān)的完整邏輯。因此業(yè)務(wù)邏輯的問題不會影響系統(tǒng)內(nèi)的導(dǎo)航。
對于圖1所描述的情況，我們將擁有一個Transporter類（運輸者），它擁有以下方法：NavigateToLogin()、NavigateToHomePage()和NavigateToCreateuser()等等。或者，每個獨立的頁面（page）對象或許都會擁有自己的運輸（transport）方法。在這種情況下，這些方法就作為該對象自身的運輸者。
復(fù)合頁面對象
該模式將復(fù)用的頁面（page）對象聚合在一個外部對象中。
這一模式支持用更加“面向?qū)ο?#8221;的方式來組織頁面對象——把可以在不同頁面上復(fù)用的子對象分離，并將其包含到父對象中。
圖5：通過在主頁和創(chuàng)建用戶頁面對象中聚集，來使用導(dǎo)航頁面（Navigation Page）對象
擴展的頁面對象
該模式通過繼承來擴展基礎(chǔ)的頁面對象，成為復(fù)合頁面對象的替代選擇。
過程模式
給定條件/時機/結(jié)果
此模式將測試執(zhí)行過程分為三個階段：
給定條件（定義先決條件）
時機（設(shè)定與上下文協(xié)同工作的特定操作）
結(jié)果（檢查結(jié)果）
四階段測試
此模式將測試執(zhí)行過程分為四個階段：
定義先決條件
調(diào)用業(yè)務(wù)功能
Checking results;
拆卸系統(tǒng)
流測試
該模式支持在一個測試內(nèi)執(zhí)行業(yè)務(wù)操作并進行檢查。兩項內(nèi)容可以交替進行，直到實現(xiàn)測試的最終目標。
多次失敗
該模式定義了一套機制，能夠在非致命錯誤出現(xiàn)之后繼續(xù)進行測試。
測試依賴模式
獨立測試
該模式令被測試的系統(tǒng)回到測試前的狀態(tài)。
鏈式測試
在該模式中，初步測試樹立起了測試需要跟蹤的SUT狀態(tài)。
測試分組模式
每個測試類封裝一個測試方法
在該模式下，每個獨立的測試方法，都封裝在一個獨立的測試類中。
測試類中的分組測試方法
在該模式下，多個測試方法被放置于一個獨立的測試類中。
總結(jié)
測試解決方案的設(shè)計背后的驅(qū)動力，是對特定測試實現(xiàn)模式的選擇。它扮演了未來所有測試解決方案開發(fā)的起點，將在可讀性、可維護性和其他諸多特性方面產(chǎn)生影響。而且它也設(shè)置了這些實驗，使其在能夠產(chǎn)生幫助的時候更好地復(fù)用項目之間的資源，并減少新項目自動啟動的時間。
這篇文章拋出了有關(guān)如何參考設(shè)計模式，來構(gòu)建測試解決方案的想法。