源於http://www.cnblogs.com/jarodzz/archive/2012/07/26/2610617.html

但凡專案，傳統的開發流程W模型，如圖：

在W模型中，每一份專案文件，都對應著一份測試文件，如：使用者需求文件與使用者驗收測試文件。每一份測試文件，又可能對應著一份自動化測試程式碼，如：使用者驗收測試文件與自動化使用者驗收測試程式碼。

說完了傳統流程，再回到BDD。2.1的例子中，BDD整合了使用者需求、測試用例、自動化測試用例。針對複雜專案，BDD的解決辦法依舊是：整合！整合！整合！如圖：

在BDD的流程中，行為這一概念，整合了多種文件與程式碼：

• 使用者行為描述使用者與系統互動的場景，作為使用者需求，驗收測試，和自動化驗收測試
• 系統行為描述系統提供的功能場景，作為系統功能文件，系統測試，和自動化系統測試
• 模組行為描述模組間互動的場景，作為模組功能文件，模組測試，和自動化模組測試

對比W模型與BDD模型，最主要的區別：

• W模型的每個橫向階段，都需要儲存三份拷貝：功能文件+測試文件+自動化測試用例
• BDD模型只需要一份拷貝，行為

採用BDD流程進行開發，由外而內，持續地描述當前系統或模組的行為，併為之實現自動化（即步驟定義）。當產品程式碼部分完成後，右側的一系列測試活動都已經自動化了。(至於如何迭代開發，如何持續整合，如何劃分使用者故事以保證可持續釋出可交付的產品，這裡就不做過多講述。有興趣的，可以看看敏捷的書。)

維基百科上對BDD的定義，原文為：
BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

我用中文複述下：

BDD是一個第二代的敏捷開發方法。它有如下特點：

• 由外而內：使用者 -> 系統 -> 模組
• 以拉力驅動：先設定目標，即行為，而後編寫產品程式碼去實現目標
• 多利益人：使用者、開發人員、測試人員共同維護行為
• 多擴充套件性：可以描述使用者級、系統級、模組級行為
• 高度自動化：只要提供步驟定義，所有行為都可以作為自動化測試執行

它定義了一個可持續的週期，在週期中人們先設定目標，再為了達到預期目標而進行編碼，只有程式碼通過驗證才可提交。持續交付可工作、經過測試的軟體。

理想中的BDD開發，是這樣的：週一早晨上班時，團隊成員一起書寫一個或幾個使用者行為，併為每個行為估算工作量。從中選出可以在一週內完成的部分，以作為本週目標開始工作。工作中，通過對使用者行為的深入理解，書寫系統行為以及可能需要的模組行為。在開發人員編寫產品程式碼時，由測試人員編寫步驟定義。週五，開發人員陸續將程式碼提交，並使用測試人員自動化過的行為進行測試。當所有行為都通過時，本週任務完成。如圖：

BDD流程中，包含的敏捷思想有：

• 個人交流勝過流程與工具：一週內，開發人員和測試人員都要肩並肩一起工作
• 可交付的軟體勝過繁複的文件：一週內，幾乎沒有任何文件產生，所有行為都以程式碼方式存在

回顧

• BDD是一個由外而內、以拉力驅動、高度自動化的敏捷方法
• BDD的實踐，需要使用者、開發人員和測試人員共同努力
• BDD中的行為，可以整合傳統流程中的諸多文件與程式碼；可以減少為維護文件而造成的浪費；
• 在Cucumber中，行為（behavior）是用功能（feature）檔案來描述的
• Cucumber只是BDD中的一個工具，還有其他工具如Jbehave等

說完正事兒，我得表個態。BDD是好東西，一如TDD，一如AATDD。它夠快，夠直接，夠節約，因此，夠敏捷。

可BDD並非適用於所有產品、所有團隊。開發Cucumber的人們，有著良好的編碼技能與質量意識。Cucumber自己的原始碼中，就包含Cucumber自己的功能（feature）檔案。因此，他們難免會對使用者，有期許，期許他們與自己一樣，有著良好的編碼技能與質量意識。但大部分我所交流過的團隊，測試人員並不具備如此優秀的編碼技能，而開發人員又具備如此優秀的質量意識。然後，還要考慮因為忽然接觸新事物、新知識導致的短期的效率降低。長遠來看，也可能由於人為因素導致其他問題。

因此，我喜歡BDD，但不推薦它、不試圖推廣。但是，如果拋開BDD，只是把Cucumber當做一個自動化測試工具，在不改變現有流程的情況下，去用，去體會，去思考。漸漸地，一個組或一個專案便可以慢慢地減少浪費，增加自動化，在更短時間提供更多的可交付的產品。甚至於，不知不覺地轉型成BDD。這就是我喜歡cucumber，推薦、也試圖推廣它的原因。