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