目前比較常見的自動化測試框架主要有3種：資料驅動框架、關鍵字驅動框架和混合型框架。

1、資料驅動框架（Data Driven Framework）

   資料驅動最適合測試的業務邏輯固定不變的應用程式，只有測試資料會變化。通常測試資料會被配置在外部檔案或資料庫中。

2、關鍵字驅動框架（Keyword Driven Framework）

   關鍵字驅動顧名思義，它提供了一系列通用的關鍵字，使用者通過呼叫這些關鍵字並輸入一些引數可以實現單個操作，比如，開啟瀏覽器、開啟某個網頁、點選某個連結等等，然後通過組織這些關鍵字形成一個完整的測試流程。

3、混合型框架（Hybrid Framework）

   混合型框架就是把資料驅動和關鍵字驅動整合起來，同時具備了兩者的優點。與關鍵字框架不同的是，這種框架通常會提供一些針對於特定應用程式的關鍵字，比如登入、登出等。然後在完整測試流程的基礎上，再應用一層資料驅動，這樣就能使測試邏輯和測試資料更加靈活和可配置。

一、自動化測試管理

   自動化測試用例的執行機制一般包括管理端和執行端，由管理端發出訊號通知執行端開始執行相應的測試任務，從而執行相應的指令碼進行測試，並將測試結果報告管理端。

1．管理端

   管理端主要完成以下任務：執行控制的決策系統，負責建立並維護執行佇列，控制執行策略和訊號燈；在管理端還必須維護一個測試任務的佇列，每個測試任務的開始執行的時間可能不同，狀態也不一樣，管理端根據這些標誌對其進行控制。

2．執行端

   執行端根據管理端的決策系統，來執行執行佇列中的測試指令碼，其中執行控制的執行系統，負責分配測試指令碼，並按照指定策略啟動指令碼等也是執行端的功能。

二、自動化測試指令碼開發

1．測試驅動

測試驅動是一個自動化測試框架的核心，其決定整個自動化指令碼設計。當前比較流行的測試驅動有資料驅動和關鍵字驅動，使用不同的測試驅動，關係到指令碼重用率，以及後期的可維護性。

（１）資料驅動

基於資料驅動的自動化測試框架是指測試驅動引擎從資料來源獲取測試資料，然後將將資料以引數的形式傳遞給測試指令碼，最後通過執行測試指令碼，驗證測試結果，並將測試結果輸出。一般資料來源與測試結果儲存在、Excel檔案、Csv檔案等。資料驅動主要優點是：測試指令碼與測試資料的分離，當應用功能變更時，只需要修改該功能部分的指令碼；執行測試用例的人員不需要了解測試指令碼的實現，只關注測試資料表與測試報告表。而且測試指令碼的執行是離散的，即非線性的，測試人員可以有選擇的執行測試用例。

（２）關鍵字驅動

關鍵字驅動的自動化測試框架是在資料驅動的基礎上進行改進，資料來源裡包含的不只是資料，還有關鍵字，一個測試用例由一個或若干個關鍵字組成。每個關鍵字對應個不同的業務邏輯，例如，登入、登出等。資料表通過關鍵字，查詢對映表，執行相關的指令碼。

（３）驅動引擎

驅動引擎是對資料表的資料進行分析，根據不同的測試資料或關鍵字呼叫相應測試指令碼。驅動引擎還需完成一些測試環境初始化、全域性引數設定、測試用例是否執行的判斷，以及測試報告的處理等。

2．測試指令碼開發

　　測試指令碼開發必須通過詳細、合理的設計，要對指令碼程式碼進行劃分，指令碼檔案或資料檔案分層管理。這樣有利於自動化指令碼的開發與維護，從而節省自動化測試的投入成本，也使得不同測試人員或開發人員可以協調開發指令碼。

（１）指令碼規範

　　測試指令碼的開發也要遵循程式設計的規則與標準，應該統一規劃，所有開發指令碼的人員按照統一的規定進行編碼。除了程式設計本身規範，還考慮測試用例與庫函式名的命名，測試用例需要加上專案名稱，但公共的庫函式卻不需要，因為公共的庫函式是獨立於專案的。例如，專案M4.1客戶端登入測試用例可命名為：TC_M4.1_client_login；讀取excel表的函式可命名為：read_excel。

（２）指令碼劃分

測試指令碼的劃分，如何定義公共的指令碼庫，不同模組特有的指令碼庫，以及直接構建測試用例的指令碼。為了方便以後指令碼的維護問題，必須對指令碼進行有效的分層，同時，提高了指令碼的複用率。

① 公共類庫

公共類庫包括所有模組都可能使用者的操作方法，其抽象了不同模組同性，比如操作excel表的方法、讀寫測試報告、驅動引擎等。

② 模組特定類庫

在模組內部將可以為該模組共享使用的方法抽象出來，作為一個公共類。它可以是一個單的邏輯操作，也比較獨立。比如客戶端登入操作、控制檯登入操作、控制檯更新操作等。

③ 測試用例指令碼

測試用例腳在最上層，它根據測試點進行設計，面向具體的應用。它可直接呼叫公共類庫或模組特定類庫的方法，即調單個邏輯操作。它是單個或多個邏輯操作的集合，即一個測試使用者指令碼。比如，在客戶端訪問資源的測試用例，它呼叫了客戶端登入方法和訪問資源方法。

（３）測試用例

① 測試用例粒度

測試用例的粒度決定了用例模型級的複雜度，也決定了每一個用例內部的複雜度。應該根據每個系統的具體情況來把握各個層次的複雜度，在儘可能保證整個用例模型的易理解性前提下決定用例的大小和數目。用例不能太大，這樣一旦出執行測試用例出錯，不利於定位問題；但也不能太細化，太小則不方便執行。

② 測試用例與測試套件

一個大型的專案有許功能模組，必然會產生大量的測試用例，怎樣才能有效的管理這些測試用例呢？這就需要建立測試套件，通過測試套件將測試某一個模組或功能點的測試用例集合起來，方便執行與管理。例如，只驗證“使用者管理”模組功能，則只需要執行“使用者管理”模組套件即可。

（４）指令碼與html標記分離

指令碼與html標記分離使得在一定程度上指令碼獨立於WEB頁面，指令碼沒有直接的處理html標記，指令碼程式碼通過html對映表獲取賦有WEB頁面標記值的變數。WEB頁面標記包括html標記和頁面內容（文字或圖片等，這些都可能是判斷用例是否成功能的檢查點），當WEB頁面標記變更後，不需要在範圍的修改指令碼。

（5）選擇適合自動化測試的用例

在編寫自動化測試指令碼前，首先要確定哪些用例適合做自動化測試，因為自化測試不像手工測試，它不能那麼智慧，也沒有發發散思維。

通常適合自動化測試的用例有：

產品型專案。產品型的專案，新版本是在舊版本的基礎上進行改進，功能變不大的專案，但專案的新老功能都必須重複的測試。

迴歸測試。迴歸測試是自動化測試的強項，它能夠很好的驗證你是否引入了新的缺陷，老的缺陷是否修改過來了。在某種程度上可以把自動化測試工具叫做迴歸測試工具。

機械並頻繁的測試。每次需要輸入相同、大量的一些資料，並且在一個專案中執行的週期比較長。

有一些互動性比較強，需要人工干預的操作，就不要指望通過自動化測試來完成了。例如，使用者使用DKEY登入