所謂自動化測試框架，是由一些假設，概念和為自動化測試提供支持的實踐組成的集合。接下來將描述一下幾種比較常用的自動化測試框架：

　　1.錄制/回放的神話

　　每一家自動化測試工具廠商都會宣傳，他們的工具非常容易使用，沒有技術背景的測試人員只要簡單錄制測試的操作過程，然后播放錄制好的測試腳本，就可以輕松自動化所有的測試。這樣的說法是非常不負責的。

　　現在我們來分析一下自動化測試不能單單只依靠錄制/回放來完成的原因。

　　通過錄制建立的腳本，基本上都是用腳本語言以硬編碼的方式編寫的，當應用程序變動時，這些硬編碼也隨之需要更改。因此，維護這些錄制好的腳本，成本是非常高的，高到幾乎不能接受。

　　所有的測試腳本都必須是在應用程序可以正確執行時才能錄制，如果在錄制過程中發現缺陷.測試人員必須向缺陷管理機制報告，等到該缺陷修正了，整個錄制腳本的動作才能繼續下去。在這樣的情況下，如果僅僅依靠錄制腳本來進行測試，效率是十分低下的。

　　同時，這些錄制好的腳本不是非常可靠，甚至在應用程序完全沒有變動的情況下直接播放，也可能因為一些意外狀況而無法執行。如果錄制腳本時測試人員使用了錯誤的腳本語言，則腳本就必須重新錄制。

　　綜上所述，通過錄制的方式來建立自動化測試腳本的方式看似容易，但實際上會遇到下列問題:①測試人員大多不具備技術背景，難以完全掌握測試工具;②應用程序必須達到一定的穩定性，才能開始錄制測試腳本;③錄制的測試腳本與測試數據耦合得太緊密;④維護自動化測試腳本的成本非常高。

　　因此，僅僅依靠錄制/回放來完成自動化測試是遠遠不夠的，我們應找到一種能解決上述問題并能很好地執行自動化測試的方法。

　　2.數據驅動的自動化測試框架

　　數據驅動的自動化測試是針對上述開發與測試之間緊密耦合問題提出的測試方法。通過建立測試與開發定義的軟件元數據的關聯——元數據映射表，在測試與開發之間建立松耦合關系。不論測試人員修改測試腳本，還是開發人員修改軟件，只需要修改元數據映射表，既可以滿足測試與開發同步進行。這樣，可以減少測試腳本調試的工作量，更好的實現自動化測試。

　　●什么是數據驅動的自動化測試框架

　　數據驅動的自動化測試框架是這樣的一個框架，從某個數據文件(例如ODBC源文件、Excel文件、Csv文件、ADO對象文件等)中讀取輸入、輸出的測試數據，然后通過變量傳入事先錄制好的或手工編寫的測試腳本中。其中，這些變量被用作傳遞(輸入/輸出)用來驗證應用程序的測試數據。在這個過程中，數據文件的讀取、測試狀態和所有測試信息都被編寫進測試腳本里;測試數據只包含在數據文件中，而不是腳本里，測試腳本只是一個“驅動”，或者說是一個傳送數據的機制。

　　●數據驅動腳本

　　數據驅動腳本就是那些和應用程序相關聯的腳本。這些腳本通過錄制或手工編寫寫進自動化工具私有的語言，然后對其中的變量賦予合適的數值，作為測試數據的輸入。這些變量作為一些關鍵應用程序輸入的媒介，使腳本能通過外部的數據來驅動應用程序。

　　1) 可變數據，硬編碼組件標志

　　這些數據驅動的腳本經常包含硬編碼的數據，有時是一些窗口組件中非常脆弱的識別字符串。出現這種情況時，腳本很容易由于程序的更改而失去作用。

　　2) 高度技術化的、重復的測試設計

　　數據驅動腳本的另一個共同特點就是，所有在測試設計上所作的努力最終都體現在自動化工具的腳本語言中，或者復制到手工和自動化測試腳本中。這意味著每個和自動化測試開發或執行有關的人必須對測試環境和自動化工具的編程語言非常精通。

　　●優點與缺點

　　1) 優點： ①在應用程序開發的同時就可以同步建立測試腳本，而且當應用功能變動時，只需要修改業務功能部分的腳本;②利用模型化的設計，避免重復的腳本，減少建立或維護腳本的成本;③測試輸入數據，驗證數據和預期的測試結果與腳本分開，存放在另外的數據文件里，利于測試人員修改和維護;④透過判斷功能回傳值是“True”或“False”，可作錯誤處理，增加了測試腳本的健壯性;⑤自動化測試開發人員創建數據驅動的測試過程，測試員創建測試數據;⑥在測試的過程中收集測試結果，并在輸入數據的語境中表示測試結果，這樣可以簡化手工結果分析。

　　2) 缺點： ①對自動化測試工具里的腳本語言必須非常精通;②每個腳本都會對應多個數據文件，這些數據文件需要根據腳本的功能類別存放在各自的目錄中，增加了使用的復雜性;③測試人員除了需要根據具體測試數據維護相應的測試計劃，還要將這些數據寫入各個需求不同的數據文件中;④在編輯數據文件時，必須注意測試腳本所要求的傳輸格式，否則會在處理腳本時產生錯誤。如由專門的技術人員對其進行維護，依賴于數據驅動腳本的自動化測試框架實現起來更簡單、快捷。但是，維護工作困難，而且還需要保持這種數據驅動的模式，這樣，即便長時間的維持也會導致失敗。3.關鍵字驅動的自動化測試

　　關鍵字驅動的自動化測試(也稱為表驅動測試自動化)，是數據驅動自動化測試的變種，可支持由不同序列或多個不同路徑組成的測試。它是一種獨立于應用程序的自動化框架，在處理自動化測試的同時也要適合手工測試。關鍵字驅動的自動化測試框架建立在數據驅動手段之上，表中包含指令(關鍵詞)，而不只是數據。這些測試被開發成使用關鍵字的數據表，它們獨立于執行測試的自動化工具。關鍵字驅動的自動化測試是對數據驅動的自動化測試的有效改進和補充。

　　關鍵字驅動的自動化測試的整個過程所包含的功能都是由關鍵字驅動的，關鍵字控制了整個測試過程。下面以“Post a Payment”為例，說明這種自動化測試方法是如何運作的(表1)。

　　優劣分析

　　關鍵字驅動的自動化測試框架是一種截然不同的思想，它把傳統測試腳本中變化的與不變的東西進行了分離，這種分離使得分工更明確，并且避免了它們相互之間的影響。 這種模型的開發和實現與傳統的測試流程相比可能是困難的，最耗時的，因為，我們正在努力地將我們的測試和自動化工具以及應用程序本身的變化完全隔離開來。為了實現這個目標，最重要的是要增強自動化工具所提供的組件功能，例如，錯誤糾正、避免和數據同步。但是這樣的投資是一次性的，一旦開發結束并投入使用，它給我們帶來的效益是巨大的，是自動化測試框架中最容易維護和使用的，而且可以反復運用于各種應用中，長期發揮作用。

　　另外，現在已經有一些符合需求的商業化產品可供使用，減少了實現這種框架的困難。利用關鍵字驅動的自動化測試框架，測試人員不需要錄制測試腳本，而是設計測試腳本。

　　4.混合的自動化測試框架

　　結合以上幾種自動化測試框架的比較，目前最為成功的自動化測試框架應是綜合使用數據驅動和關鍵字驅動的自動化測試框架：以數據驅動的腳本作為輸入，通過關鍵字驅動框架的處理得到測試結果，完成自動化測試過程。這樣可以使數據驅動的腳本利用關鍵字驅動框架通常所提供的庫和工具。這些框架工具可以使數據驅動的腳本更為緊湊，而且也不容易失敗。

　　關鍵字驅動的自動化測試框架模型

　　下面將介紹一種以關鍵字驅動自動化測試框架思想為指導的自動化測試實現方案——關鍵字驅動的自動化測試模型,它是由SAS Institute的Carl Nagle開發的。圖2描述了該測試模型的結構。

　　這個模型主要由核心數據驅動引擎、組件函數、支持庫和應用映射表組成。自動化測試首先由初始腳本開始執行，這個腳本把高層測試表傳遞給高層驅動器，高層驅動器在處理這些表的過程中，遇到中層測試表后就調用中層驅動器，中層驅動器處理中層表時也作類似的處理。當低層驅動器處理低層表時，它嘗試著使應用與測試保持同步。當低層驅動器遇到對某一個組件的低層關鍵字組件時，它判斷這個組件的類型并調用相應的組件函數模塊來處理這個指令操作。所有這些元素都要依靠映射表中的信息，它是自動化測試模型和被測應用程序的橋梁。

　　●應用映射表

　　應用映射表是自動化測試模型中最關鍵的組件之一。在進行測試設計之前，測試人員首先對應用中的每一個對象定義一套命名規范，并利用映射表把這些名字和自動化工具識別的對象名聯系起來，使工具能準確地定位和操縱對象。我們的測試腳本只需進行單點維護。在上面的例子中，如果按鈕的名字或顯示文字發生了變化，那么腳本中所有涉及這些名字的地方都要進行修改。如果我們建立這樣一個映射，用邏輯對象SavePushButton表示真實的確認保存的按鈕對象，那么這個例子就可以寫成“Click SavePushButton”。當按鈕的名字或顯示文字改變時，只需要快速修改一下映射表中對應的識別方法就可以了，而不用修改腳本(表2)

　　●組件函數

　　組件函數是實現用戶對界面對象操作指令的函數，一個組件對象的類型對應一個組件函數庫。例如對于一個文本框對象，測試人員可能會對它執行多種操作：輸入文本、驗證文本框的值、驗證文本框的某些屬性等，實現這些操作行為的函數就被放在文本框的組件函數庫中。一般的測試工具都提供了這樣的函數，而我們可以在其中加入額外的代碼來檢測錯誤、糾正錯誤和幫助同步，這類代碼是實現無人職守的自動化測試所必需的。

　　組件函數相當于在應用和自動化工具之間提供了一個隔離層，如果沒有這個隔離層，自動化工具本身的改變或提高就會影響已有的腳本，但是有了組件函數，我們可以增加一對修補代碼來適應這些變化，轉移對測試的破壞。組件函數關鍵字和它們的參數構成自動化模型最低層的詞庫，了解了低層詞庫和映射表，就可以建立在它們基礎之上的測試表。

　　●測試表和核心數據驅動引擎

　　測試表分低層、中層和高層。低層測試表指定了測試的每一步指令的細節，這些指令都是直接作用在界面對象上的，是無法再細分的指令。中層測試表把低層測試表組裝起來執行更多有用的任務。同一個低層表可以用于多個中層表，所以我們應該開發盡可能少的低層表，然后把它們按照不同的目的組裝起來，實現最大的重用性。同樣的，高層測試表把中層表組裝起來，形成一個測試循環，每個循環都是完整的，可以定制不同類型和數量的測試。

　　例如打開網頁、登錄、關閉網頁這3個動作可以用3個低層表來表示，每個表定義了實現相應動作的具體步驟，所以低層表又叫做步驟表。低層表中使用了映射表中定義的對象名，和由組件函數定義的低層關鍵字詞庫。表3是一個實現登錄動作的低層表。而這個表示“登錄”的低層表關鍵字很可能會出現在“驗證錯誤登錄”、“驗證正確登錄”、“驗證空白登錄”等中層表中，這些中層表合起來構成了“驗證權限”高層表。

　　對應于以上這3個測試表，核心數據驅動引擎相應地分成了高層驅動器、中層驅動器和低層驅動器。高層驅動器讀取高層表的每個記錄，如果遇到中間表關鍵字，就把這個表傳遞給中層驅動器，依此類推，直至到達低層表，低層驅動器調用關鍵字詞庫中的低層指令所對應的組件函數來完成最后的執行。最后要說明的是這樣一種層次結構并不是固定不變的，可以根據實際應用情況進行調整。

　　●支持庫

　　支持庫是一些程序和工具，例如文件處理、字符串處理、緩沖處理、數據庫訪問、日志記錄工具等，它們為自動化模型提供最基礎的支持。

　　結 語

　　自動化測試框架無疑是企業實施自動化測試的一個必然的發展方向，它對于產生成功的測試自動化的適當基礎是重要的。為了選擇一個合適的自動化測試框架，企業需要綜合考慮維護成本、測試數據、可測試性、測試人員的技能等諸多因素?；仡欁詣踊瘻y試發展的過程，以往的經驗告訴我們，無法依靠簡單的錄制/回放的測試方法或傳統的測試腳本工具來完成測試，因為錄制產生的腳本維護困難，而且生存期很短。