行為驅動開發（Behavior Driven Development）即BDD，是一種敏捷開發方法，通常應用在自動化測試中，或者也可稱為行為驅動測試。通過使用自然描述語言確定自動化腳本，通過這種方式，能夠大大促進團隊之間的溝通。實現BDD的工具有Cucumber、JBehave、RBehave，以及桌面客戶端CukeTest。 下面以自動化測試開發模式的發展過程來說明下行為驅動測試歷史發展與現狀。
自動化測試方法的現狀
隨著 Agile 開發模式在越來越多的項目組中推廣，持續集成 (CI) 作為 Agile 的重要組成部分，也被越來越多的項目組採納並實施，在這個部署實施過程中，自動化測試在軟體測試中佔有越來越重要的地位，如何讓我們的自動化測試能更快，更有效的運作，一直是我們探索的目標。在實際的項目中，我們可能隨時面對各種不同的需要，而這些也決定了我們採用什麼樣的開發模式。
TDD
測試驅動開發（Test Driven Development）。它的想法來自於極限編程（Extreme Programming）。TDD 是 Agile 開發中的一項核心實踐和技術，也是一種設計方法。引用 Wikipedia 上的關於 TDD 的介紹：
測試驅動開發（英語：Test-driven development，縮寫為TDD）是一種軟體開發過程中的應用方法，由極限編程中倡導，以其倡導先寫測試程序，然後編碼實現其功能得名。測試驅動開發始於20世紀90年代。測試驅動開發的目的是取得快速反饋並使用「illustrate the main line」方法來構建程序。
TDD 的基本思想是通過測試來推動整個開發的進行，但測試驅動開發並不只是單純的測試工作，而是把需求分析，設計和質量控制量化的過程。TDD 簡單的說就是：每寫一段代碼之前，先寫一個單元測試；根據單元測試的功能，開始編碼；待到代碼可以使之前的測試通過後，編碼完成；在保持測試通過情況下，重構代碼。
測試驅動開發是戴兩頂帽子思考的開發方式：先戴上實現功能的帽子，在測試的輔助下，快速實現其功能；再戴上重構的帽子，在測試的保護下，通過去除冗餘的代碼，提高代碼質量。測試驅動著整個開發過程：首先，驅動代碼的設計和功能的實現；其後，驅動代碼的再設計和重構。
優點
可以有效的避免過度設計帶來的浪費。但是也有人強調在開發前需要有完整的設計再實施可以有效的避免重構帶來的浪費。
缺點
開發者可能只完成滿足了測試的代碼，而忽略了對實際需求的實現。有實踐者認為用結對編程的方式可以有效的避免這個問題。
會放慢開發實際代碼的速度，特別對於要求開發速度的原型開發造成不利。這裡需要考慮開發速度需要包含功能和品質兩個方面，單純的代碼速度可能不能完全代表開發速度。
對於GUI,資料庫和Web應用而言。構造單元測試比較困難，如果強行構造單元測試，反而給維護帶來額外的工作量。有開發者認為這個是由於設計方法，而不是開發方法造成的困難。
使得開發更為關注用例和測試案例，而不是設計本身。目前，對於這個觀點有較多的爭議。
測試驅動開發會導致單元測試的覆蓋度不夠，比如可能缺乏邊界測試。在實際的操作中，和非測試驅動開發一樣，當代碼完成以後還是需要補充單元測試，提高測試的覆蓋度。
ATDD
驗收性測試驅動開發（Acceptance Test Driven Development）。這種開發模式是整個團隊在開發工作之前，一起討論、制定每個任務的驗收標準，並提取測試用例。ATDD 是從 TDD 發展過來的，ATDD 就是為了解決 TDD 的一些缺點而出現。
因為 TDD 只涉及到開發人員，測試人員及業務經理。如果開發人員可能只完成了滿足測試的代碼卻忽略實際需求的實現，那麼將會造成測試人員寫的測試用例是不夠的也有可能是錯誤的。所以在 ATDD 中首先要求團隊定義出期望的質量標準和驗收細則，以明確而且達成共識的驗收計劃（報告測試用例）來驅動開發人員 TDD 實踐和測試人員的測試腳本。
在明確而且達成共識的驗收計劃中，通常情況下，我們以如下的文檔格式來定義我們的文檔。
A specified state of a system
An action or event occurs
The state of the system has changed or an output has been produced
ATDD的這種文檔格式借鑒BDD的概念，並把它應用到驗收測試中。下面我們給大家介紹一下應用廣泛的BDD和相關的工具。
BDD
行為驅動開發（Behavior Driven Development）。它也是 Agile 開發的技術，引用 Wikipedia 上的關於 BDD 的介紹：
行為驅動開發（英語：Behavior-driven development，縮寫BDD）是一種敏捷軟體開發的技術，它鼓勵軟體項目中的開發者、QA和非技術人員或商業參與者之間的協作。
這種開發模式鼓勵軟體項目中的開發人員，測試人員和非技術人員或者客戶之間的協作，從用戶的需求出發，強調系統行為。在 TDD 中，我們並不能完全保證根據設計所編寫的測試就是用戶所期望的功能，用戶並一定能看懂測試用例。BDD 將這一部分用更接近自然語言的形式來描述，讓測試用例更自然化和簡單，使開發人員，測試人員和客戶能在這個基礎上達成一致。
TDD 與 BDD 的自動化測試比較
圖 1 顯示了在 TDD 技術下測試人員的測試過程，TDD 的測試用於單元測試，一般開發人員用什麼語言，單元測試就用什麼語言。在此其中，測試人員參與的機會不多，通常有了測試任務後，測試人員會將它分成測試計劃，然後再細分成測試點列表，每一份測試列表可能又對應著一份自動化測試用例，所以這個階段就需要保持三份文檔： 需求文檔 + 測試點文檔（計劃和測試點）+ 自動化測試用例，整個 TDD 的過程中，自動化測試用例的編寫是在測試點列表出來之後。
