如何簡單的理解TDD與DDT

TDD：TEST-DRIVEN Development

測試驅動開發到底是什麼意思？如何理解測試驅動開發？

舉個紅綠條簡單的例子：

1.編寫測試代碼

2.編譯運行測試代碼，確定會失敗，由於實現代碼尚未寫

3.編寫實現代碼

4.運行測試觀察測試結果，多是紅色的。

5.開發修改代碼使得測試經過

6.運行測試，觀察測試結果，直到變綠

7.可進行重構，進行代碼優化，刪除冗餘，繼續運行測試直到變綠

 

DDT：DATA-DRIVEN TEST

數據驅動測試是什麼意思？如何理解數據驅動測試？

數據驅動的自動化測試是針對上述開發與測試之間緊密耦合問題提出的測試方法。經過創建測試與開發定義的軟件元數據的關聯——元數據映射表，在測試與開發之間創建鬆耦合關係。不論測試人員修改測試腳本，仍是開發人員修改軟件，只須要修改元數據映射表，既能夠知足測試與開發同步進行。這樣，能夠減小測試腳本調試的工做量，更好的實現自動化測試

 

什麼是數據驅動的自動化測試框架？

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

 

KDT：KEYWORD-DRIVEN TEST

關鍵字驅動測試是什麼意思？如何理解關鍵字驅動測試？

關鍵字驅動的來源很是天然，從面向對象的思路出發，一樣的業務邏輯會天然的編寫成一個類或者函數做爲關鍵字來被不一樣的測試腳本所調用。當測試框架發展到全部的測試過程都已經能夠被寫好的函數和類所組合完成時，就進化到了關鍵字驅動的一個高級階段，這個時候測試用例的開發就變成了測試數據和關鍵字的組合，並把這種組合工做簡化爲全部人都很熟悉的表格填寫任務，從而最終達到一個由數據和關鍵字驅動整個測試的效果。

 

==============

初次接觸自動化測試時，對數據驅動和關鍵字驅動不甚理解，以爲有點故弄玄須，不就是參數和函數其嘛！其實其也體現了測試所不一樣與開發的一些特色（主要指系統測試），以及和對技術發展的脈絡的展示。

 

1.錄製/回放的神話

      實際上能夠理解爲一種自動測試腳本和測試用例的緊耦合，既有測試腳本維護的難度，也與系統測試中面向用戶的思路相抵制

　　每一家自動化測試工具廠商都會宣傳，他們的工具很是容易使用，沒有技術背景的測試人員只要簡單錄製測試的操做過程，而後播放錄製好的測試腳本，就能夠輕鬆自動化全部的測試。這樣的說法是很是不負責的。

　　如今咱們來分析一下自動化測試不能單單隻依靠錄製/回放來完成的緣由。

　　經過錄制創建的腳本，基本上都是用腳本語言以硬編碼的方式編寫的，當應用程序變更時，這些硬編碼也隨之須要更改。所以，維護這些錄製好的腳本，成本是很是高的，高到幾乎不能接受。

　　全部的測試腳本都必須是在應用程序能夠正確執行時才能錄製，若是在錄製過程當中發現缺陷.測試人員必須向缺陷管理機制報告，等到該缺陷修正了，整個錄製腳本的動做才能繼續下去。在這樣的狀況下，若是僅僅依靠錄製腳原本進行測試，效率是十分低下的。

　　同時，這些錄製好的腳本不是很是可靠，甚至在應用程序徹底沒有變更的狀況下直接播放，也可能由於一些意外情況而沒法執行。若是錄製腳本時測試人員使用了錯誤的腳本語言，則腳本就必須從新錄製。

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

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

     「什麼是數據驅動呢？很大一部分人確定認爲數據驅動就是把須要參數化的東西寫在EXCEL裏，而後在跑腳本時調用。若是我告訴你，這其實不是數據驅動，而只是較高級的參數化，你確定會很驚訝！如今我來解釋一下：首先爲何叫數據驅動呢，那麼它確定有驅動的含義，好比你用EXCEL能夠控制測試的業務流嗎？回答是不能的。那又如何做到驅動呢？因此說咱們將測試數據放在獨立的文件裏只是高級的參數話。而數據驅動，你必須有數據來控制測試的業務流。好比你測一個WEB程序，有不少頁面，你能夠經過一個數據來控制每次是在哪一個頁面下工做的（即經過數據來導航到相應的頁面）。它是關鍵字驅動的低級版本，他控制的是函數級的，而關鍵字是控制動做級的。因此數據驅動應該是能夠控制整個測試的」。

         在一些複雜的測試用例中，同一個用例包含了不少的測試流程，其中不一樣的測試流程採用不一樣的測試輸入數據，這個時候測試數據的輸入不只僅是參數的輸入，還有業務流程的控制字段的輸入(能夠理解爲邏輯參數)，這種情形會更深刻的體現數據驅動的含義。

　　數據驅動的自動化測試是針對上述開發與測試之間緊密耦合問題提出的測試方法。經過創建測試與開發定義的軟件元數據的關聯——元數據映射表，在測試與開發之間創建鬆耦合關係。不論測試人員修改測試腳本，仍是開發人員修改軟件，只須要修改元數據映射表，既能夠知足測試與開發同步進行。這樣，能夠減小測試腳本調試的工做量，更好的實現自動化測試。

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

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

　　●數據驅動腳本

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

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

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

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

　　數據驅動腳本的另外一個共同特色就是，全部在測試設計上所做的努力最終都體如今自動化工具的腳本語言中，或者複製到手工和自動化測試腳本中。這意味着每一個和自動化測試開發或執行有關的人必須對測試環境和自動化工具的編程語言很是精通。

　　●優勢與缺點

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

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

3.關鍵字驅動的自動化測試
       關鍵字驅動的來源很是天然，從面向對象的思路出發，一樣的業務邏輯會天然的編寫成一個類或者函數做爲關鍵字來被不一樣的測試腳本所調用。當測試框架發展到全部的測試過程都已經能夠被寫好的函數和類所組合完成時，就進化到了關鍵字驅動的一個高級階段，這個時候測試用例的開發就變成了測試數據和關鍵字的組合，並把這種組合工做簡化爲全部人都很熟悉的表格填寫任務，從而最終達到一個由數據和關鍵字驅動整個測試的效果。

       在關鍵字驅動框架裏，你能夠建立一些關鍵字以及相關聯的一些方法和函數。而後你建立一個函數庫，它裏面包含一個讀取關鍵字的邏輯，而後調用相關的動做。

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

        這種自動化測試的模型主要由核心數據驅動引擎、組件函數、支持庫和應用映射表組成。自動化測試首先由初始腳本開始執行，這個腳本把高層測試表傳遞給高層驅動器，高層驅動器在處理這些表的過程當中，遇到中層測試表後就調用中層驅動器，中層驅動器處理中層表時也做相似的處理。當低層驅動器處理低層表時，它嘗試着使應用與測試保持同步。當低層驅動器遇到對某一個組件的低層關鍵字組件時，它判斷這個組件的類型並調用相應的組件函數模塊來處理這個指令操做。全部這些元素都要依靠映射表中的信息，它是自動化測試模型和被測應用程序的橋樑。支持庫主要完成一些文件處理，日誌記錄和郵件發送等等的功能。