一、關鍵字驅動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) 缺點： ①對自動化測試工具裡的指令碼語言必須非常精通;②每個指令碼都會對應多個資料檔案，這些資料檔案需要根據指令碼的功能類別存放在各自的目錄中，增加了使用的複雜性;③測試人員除了需要根據具體測試資料維護相應的測試計畫，還要將這些資料寫入各個需求不同的資料檔案中;④在編輯資料檔案時，必須注意測試指令碼所要求的傳輸格式，否則會在處理指令碼時產生錯誤。如由專門的技術人員對其進行維護，依賴於資料驅動指令碼的自動化測試框架實現起來更簡單、快捷。但是，維護工作困難，而且還需要保持這種資料驅動的模式，這樣，即便長時間的維持也會導致失敗。
自動化測試中，測試資料如何管理？
今晚在某個測試群，看到有人問了乙個問題 把測試資料放配置檔案讀取和放檔案通過函式呼叫讀取有什麼區別？當時我下意識的這麼回答 資料量越大，配置檔案越臃腫，放在專門的資料檔案 比如excel，csv 方便針對性的維護。乍看沒毛病，但回頭和人討論這個問題的時候，就認真思考了一下這個問題，下面是我的一些思考...
ios自動化測試資料
官方文件 ios助手開發資料 命令列啟動instruments 使用命令安裝 for xcode 4.5 instruments t automationinstrument.bundle contents resources automation.tracetemplate e uiaresult...
資料驅動自動化測試
傳統測試認為功能測試 黑盒測試 就是資料驅動測試，而在自動化測試體系中，資料驅動測試則有了新的詮釋。以乙個基礎的自動化框架為例，它可以分為三層設計，資料層 邏輯層 業務層，假設資料層的設計足夠抽象，即可實現多套測試資料執行同樣的測試 邏輯 另一方面從功能測試的角度理解，這種設計同樣可以完成多角度測試...