如何理解自動化測試資料驅動與關鍵字驅動的區別?

　　初學者應該如何理解自動化測試資料驅動與關鍵字驅動的區別?本文將由千鋒給大家分享一下。

　　一、關鍵字驅動KDT(Keyword-driven testing)

　　1、自動化測試框架發展的第三個階段是關鍵字驅動測試框架階段，它是當前比較流行的一種框架之一，並且現在的自動化測試工具已經將關鍵字驅動框架融入到工具中。在錄製過程中自動化測試工具會將物件及操作屬性儲存到物件庫中。

　　2、關鍵字驅動測試是資料驅動測試的一種改進型別， 用關鍵字的形式將測試邏輯封裝在資料檔案中，測試工具只要能夠解釋這些關鍵字即可對其應用自動化。

​

　　以某工具自帶的飛機訂票系統為例，錄製完成後的每個測試步驟主要有三個元素組成：

　　Item：指物件名，可以是一個視窗、按鈕等;

　　Operation：指要執行的動作，如Select、Click等;

　　Value：操作動作所輸入的資料值;

　　錄製其登入過程，生成的程式碼如下：

　　Dialog("Login").WinEdit("Agent Name:").Set "test"

　　Dialog("Login").WinEdit("Password:").SetSecure

　　Dialog("Login").WinButton("OK").Click

　　這是以關鍵驅動的方式生成的程式碼，關鍵字驅動測試最核心的是關鍵字表格。以飛機訂票系統的登入為例，其關鍵字表格見表：

　　關鍵字驅動的思路是將關鍵字表中的物件及資料提取出來並構造成每個測試步驟，如步驟：Dialog("Login").WinEdit("Agent Name:").Set "test"。需要將關鍵字表中的物件、屬性及輸入的資料讀取出來，將它們構造同以上格式的程式碼步驟，通過這種方式來實現關鍵字驅動的功能。

　　下面是除錯好的一個的關鍵字驅動的框架，程式碼如下：

　　—————————————————————————————————

　　''

　　' 工程名：關鍵字驅動

　　'

　　' 方法：

　　' GetExcelCells —————讀取單元格中的值

　　' GetExcleSheetRowsCount—————獲取關鍵字驅動表中的行數

　　' oParentObject—————構造父物件

　　' oChildObject—————構造子物件

　　' oEventObject —————對物件屬性賦值

　　'

　　'———————————————————————————————————

　　''

　　' 函式名：GetExcelCells

　　'

　　' 引數：

　　' ExcelPath —————關鍵字驅動表的路徑

　　' SheetName—————關鍵字驅動表的sheet名

　　' SheetRow—————單元格中的行

　　' SheetColumn—————單元格中的列

　　3、 在關鍵字驅動框架裡，你可以建立一些關鍵字以及相關聯的一些方法和函式。然後你建立一個函式庫，它裡面包含一個讀取關鍵字的邏輯，然後呼叫相關的動作。

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

　　這種自動化測試的模型主要由核心資料驅動引擎、元件函式、支援庫和應用對映表組成。自動化測試首先由初始指令碼開始執行，這個指令碼把高層測試表傳遞給高層驅動器，高層驅動器在處理這些表的過程中，遇到中層測試表後就呼叫中層驅動器，中層驅動器處理中層表時也作類似的處理。當低層驅動器處理低層表時，它嘗試著使應用與測試保持同步。當低層驅動器遇到對某一個元件的低層關鍵字元件時，它判斷這個元件的型別並呼叫相應的元件函式模組來處理這個指令操作。所有這些元素都要依靠對映表中的資訊，它是自動化測試模型和被測應用程式的橋樑。支援庫主要完成一些檔案處理，日誌記錄和郵件傳送等等的功能。

　　二、資料驅動的自動化測試框架

　　什麼是資料驅動的自動化測試框架

　　資料驅動的自動化測試框架是這樣的一個框架，從某個資料檔案(例如ODBC原始檔、Excel檔案、Csv檔案、ADO物件檔案等)中讀取輸入、輸出的測試資料，然後通過變數傳入事先錄製好的或手工編寫的測試指令碼中。其中，這些變數被用作傳遞(輸入/輸出)用來驗證應用程式的測試資料。在這個過程中，資料檔案的讀取、測試狀態和所有測試資訊都被編寫進測試指令碼里;測試資料只包含在資料檔案中，而不是指令碼里，測試指令碼只是一個“驅動”，或者說是一個傳送資料的機制。

　　資料驅動指令碼

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

　　可變資料，硬編碼元件標誌

　　這些資料驅動的指令碼經常包含硬編碼的資料，有時是一些視窗元件中非常脆弱的識別字串。出現這種情況時，指令碼很容易由於程式的更改而失去作用。

　　高度技術化的、重複的測試設計

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

　　優點與缺點

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

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