初次接觸自動化測試時，對資料驅動和關鍵字驅動不甚理解，覺得有點故弄玄須，不就是引數和函式其嘛！其實其也體現了測試所不同與開發的一些特點（主要指系統測試），以及和對技術發展的脈絡的展現。
1.錄製/回放的神話
實際上可以理解為一種自動測試指令碼和測試用例的緊耦合，既有測試指令碼維護的難度，也與系統測試中面向使用者的思路相抵制
現在我們來分析一下自動化測試不能單單只依靠錄製/回放來完成的原因。
通過錄製建立的指令碼，基本上都是用指令碼語言以硬編碼的方式編寫的，當應用程式變動時，這些硬編碼也隨之需要更改。因此，維護這些錄製好的指令碼，成本是非常高的，高到幾乎不能接受。
所有的測試指令碼都必須是在應用程式可以正確執行時才能錄製，如果在錄製過程中發現缺陷.測試人員必須向缺陷管理機制報告，等到該缺陷修正了，整個錄製指令碼的動作才能繼續下去。在這樣的情況下，如果僅僅依靠錄製指令碼來進行測試，效率是十分低下的。
綜上所述，通過錄製的方式來建立自動化測試指令碼的方式看似容易，但實際上會遇到下列問題:①測試人員大多不具備技術背景，難以完全掌握測試工具;②應用程式必須達到一定的穩定性，才能開始錄製測試指令碼;③錄製的測試指令碼與測試資料耦合得太緊密;④維護自動化測試指令碼的成本非常高。
2.資料驅動的自動化測試框架
「什麼是資料驅動呢？很大一部分人肯定認為資料驅動就是把需要引數化的東西寫在excel裡，然後在跑指令碼時呼叫。如果我告訴你，這其實不是資料驅動，而只是較高階的引數化，你肯定會很驚訝！現在我來解釋一下：首先為什麼叫資料驅動呢，那麼它肯定有驅動的含義，比如你用excel可以控制測試的業務流嗎？回答是不能的。那又如何作到驅動呢？所以說我們將測試資料放在獨立的檔案裡只是高階的引數話。而資料驅動，你必須有資料來控制測試的業務流。比如你測乙個web程式，有很多頁面，你可以通過乙個資料來控制每次是在哪個頁面下工作的（即通過資料來導航到相應的頁面）。它是關鍵字驅動的低階版本，他控制的是函式級的，而關鍵字是控制動作級的。所以資料驅動應該是可以控制整個測試的」。
在一些複雜的測試用例中，同乙個用例包含了很多的測試流程，其中不同的測試流程採用不同的測試輸入資料，這個時候測試資料的輸入不僅僅是引數的輸入，還有業務流程的控制欄位的輸入(可以理解為邏輯引數)，這種情形會更深入的體現資料驅動的含義。
資料驅動的自動化測試是針對上述開發與測試之間緊密耦合問題提出的測試方法。通過建立測試與開發定義的軟體元資料的關聯——元資料對映表，在測試與開發之間建立松耦合關係。不論測試人員修改測試指令碼，還是開發人員修改軟體，只需要修改元資料對映表，既可以滿足測試與開發同步進行。這樣，可以減少測試指令碼除錯的工作量，更好的實現自動化測試。
●什麼是資料驅動的自動化測試框架
資料驅動的自動化測試框架是這樣的乙個框架，從某個資料檔案(例如odbc原始檔、excel檔案、csv檔案、ado物件檔案等)中讀取輸入、輸出的測試資料，然後通過變數傳入事先錄製好的或手工編寫的測試指令碼中。其中，這些變數被用作傳遞(輸入/輸出)用來驗證應用程式的測試資料。在這個過程中，資料檔案的讀取、測試狀態和所有測試資訊都被編寫進測試指令碼裡;測試資料只包含在資料檔案中，而不是指令碼裡，測試指令碼只是乙個「驅動」，或者說是乙個傳送資料的機制。
●資料驅動指令碼
資料驅動指令碼就是那些和應用程式相關聯的指令碼。這些指令碼通過錄製或手工編寫寫進自動化工具私有的語言，然後對其中的變數賦予合適的數值，作為測試資料的輸入。這些變數作為一些關鍵應用程式輸入的媒介，使指令碼能通過外部的資料來驅動應用程式。
1) 可變資料，硬編碼元件標誌
這些資料驅動的指令碼經常包含硬編碼的資料，有時是一些視窗元件中非常脆弱的識別字串。出現這種情況時，指令碼很容易由於程式的更改而失去作用。
2) 高度技術化的、重複的測試設計
資料驅動指令碼的另乙個共同特點就是，所有在測試設計上所作的努力最終都體現在自動化工具的指令碼語言中，或者複製到手工和自動化測試指令碼中。這意味著每個和自動化測試開發或執行有關的人必須對測試環境和自動化工具的程式語言非常精通。
●優點與缺點
1) 優點： ①在應用程式開發的同時就可以同步建立測試指令碼，而且當應用功能變動時，只需要修改業務功能部分的指令碼;②利用模型化的設計，避免重複的指令碼，減少建立或維護指令碼的成本;③測試輸入資料，驗證資料和預期的測試結果與指令碼分開，存放在另外的資料檔案裡，利於測試人員修改和維護;④透過判斷功能回傳值是「true」或「false」，可作錯誤處理，增加了測試指令碼的健壯性;⑤自動化測試開發人員建立資料驅動的測試過程，測試員建立測試資料;⑥在測試的過程中收集測試結果，並在輸入資料的語境中表示測試結果，這樣可以簡化手工結果分析。
2) 缺點： ①對自動化測試工具裡的指令碼語言必須非常精通;②每個指令碼都會對應多個資料檔案，這些資料檔案需要根據指令碼的功能類別存放在各自的目錄中，增加了使用的複雜性;③測試人員除了需要根據具體測試資料維護相應的測試計畫，還要將這些資料寫入各個需求不同的資料檔案中;④在編輯資料檔案時，必須注意測試指令碼所要求的傳輸格式，否則會在處理指令碼時產生錯誤。如由專門的技術人員對其進行維護，依賴於資料驅動指令碼的自動化測試框架實現起來更簡單、快捷。但是，維護工作困難，而且還需要保持這種資料驅動的模式，這樣，即便長時間的維持也會導致失敗。
3.關鍵字驅動的自動化測試
關鍵字驅動的**非常自然，從物件導向的思路出發，同樣的業務邏輯會自然的編寫成乙個類或者函式作為關鍵字來被不同的測試指令碼所呼叫。當測試框架發展到所有的測試過程都已經可以被寫好的函式和類所組合完成時，就進化到了關鍵字驅動的乙個高階階段，這個時候測試用例的開發就變成了測試資料和關鍵字的組合，並把這種組合工作簡化為所有人都很熟悉的**填寫任務，從而最終達到乙個由資料和關鍵字驅動整個測試的效果。
在關鍵字驅動框架裡，你可以建立一些關鍵字以及相關聯的一些方法和函式。然後你建立乙個函式庫，它裡面包含乙個讀取關鍵字的邏輯，然後呼叫相關的動作。
這種自動化測試的模型主要由核心資料驅動引擎、元件函式、支援庫和應用對映表組成。自動化測試首先由初始指令碼開始執行，這個指令碼把高層測試表傳遞給高層驅動器，高層驅動器在處理這些表的過程中，遇到中層測試表後就呼叫中層驅動器，中層驅動器處理中層表時也作類似的處理。當低層驅動器處理低層表時，它嘗試著使應用與測試保持同步。當低層驅動器遇到對某乙個元件的低層關鍵字元件時，它判斷這個元件的型別並呼叫相應的元件函式模組來處理這個指令操作。所有這些元素都要依靠對映表中的資訊，它是自動化測試模型和被測應用程式的橋梁。支援庫主要完成一些檔案處理，日誌記錄和郵件傳送等等的功能。
關鍵字驅動測試框架搭建（1）
1 小練習 定義三個方法 加法 減法 斷言 通過使用關鍵字驅動測試這個三個方法 compute.py encoding utf 8 defadd a,b print a b return a b defsub a,b print a b return a b defassert value a,b ...
自動化測試裡的資料驅動和關鍵字驅動思路的理解
原文 初次接觸自動化測試時，對資料驅動和關鍵字驅動不甚理解，覺得有點故弄玄須，不就是引數和函式其嘛！其實其也體現了測試所不同與開發的一些特點 主要指系統測試 以及和對技術發展的脈絡的展現。1.錄製 回放的神話 實際上可以理解為一種自動測試指令碼和測試用例的緊耦合，既有測試指令碼維護的難度，也與系統測...
關鍵字提取 從字典中提取資料後，如何實現多欄位排序
例項，下面資料中a列是城市的名稱，後面是三列資料，我們要實現每個城市的新的3個資料計算，回填到指定區域。並實現按 序列6 序列5 序列4 名稱 的四個欄位的先後排序。如何實現呢？思路分析 在提取資料時候，我們用將類賦值給鍵值的方案，沒有熟悉這方面內容的朋友要看看我之前的文章再學習一下有關將類作為鍵值...