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