說起BDD，你會想到什麽？

在剛接觸BDD（Behavior Driven Development，行為驅動開發）的時候，我以為就是用Cucumber這樣的工具來編寫場景用例，從而實現自動化測試，甚至很長時間分不清BDD和ATDD(Acceptance test driven development)到底有什麽區別。那麽，BDD真的就是用來做自動化測試的嗎？本文就來跟大家分享一下我理解的BDD。

為什麽要BDD？

“開發軟件系統最困難的部分就是準確說明開發什麽” (“The hardest single part of building a software system is deciding precisely what to build” — No Silver Bullet, Fred Brooks) 。

場景一：業務分析人員覺得自己分析的需求已經寫的很清晰了，並且跟技術人員進行了足夠的溝通，可是開發完做Desk check的時候，發現所開發的功能還是跟期望有差距。
場景二：開發團隊辛辛苦苦開發完一個功能，滿懷信心的去給產品經理/客戶展示的時候，才發現原來客戶需求的功能不是這樣的。

這些場景是不是似曾相識？為什麽會這樣？第一個場景是開發團隊內部技術人員跟需求分析人員的理解有偏差，導致大家理解的需求其實是不一樣的；第二個場景是開發團隊沒有真正理解產品經理／客戶所提出來的真實需求，導致開發的產品跟需求不一致。其實，產生這兩個不一致的真正原因是因為不同角色有著不同的領域知識，說著不同的語言，大家在溝通的時候，如果都用自己領域語言，必然會產生溝通代溝，導致理解的不一致性。

領域知識不同、語言不通導致溝通障礙，這個客觀存在的問題該如何解決呢？BDD正是為此而生。

BDD是什麽？

BDD的提出者Dan North強調BDD不是關於測試的，它是在應用程序存在之前，寫出用例與期望，從而描述應用程序的行為，並且促使在項目中的人們彼此互相溝通。

要給BDD下個清晰易懂的定義很難，包括大師們也這麽認為，這裏試著總結以下幾點：

1. 關註的是業務領域，而不是技術：BDD強調用領域特定語言（DSL, domain specific language）描述用戶行為，定義業務需求，而不會關心系統的技術實現。
2. 不是工具，強調的是一種協作方式：BDD要求各個角色共同參與系統行為的挖掘和定義，以實現對業務價值的一致理解。
3. 不是關於測試的：BDD源自TDD，又不同於TDD，重點不是關於測試的，但可以指導更好的做自動化測試。
4. 全棧敏捷方法：BDD促使團隊所有角色從需求到最後的測試驗證，進行高度的協作和溝通，以交付最有價值的功能。

BDD怎麽做？

用例場景的描述格式“GIVEN... WHEN... THEN... ”對大家都不陌生，但用這個格式寫出好的用例卻是非常的難，尤其是新手。這裏總結幾點供大家參考：

1.業務層抽取，業務語言描述

根據業務層的數據流，在每個數據停留點進行縱切，抽取出一個個用例場景。描述語言一定是業務領域可懂的，不要涉及任何實現相關的技術細節。所描述的場景一定是從業務層抽象出來，體現真實業務價值的。

2.技術人員可懂，自動化友好

所描述的用例場景要能驅動開發，必須要讓技術人員易於理解；要指導自動化測試，還得要求對於自動化的實現是友好的。這一點似乎是跟第一點有些矛盾，但我們嚴格遵守BDD的格式要求還是可以做到的。其中，GIVEN從句描述的是場景的前提條件、初始狀態，通常是一種現在完成時態；WHEN從句是采取某個動作或者是發生某個事件，一定是動詞，通常是一般現在時；THEN從句用“應該…(should be…)”來描述一種期望的結果，而不用斷言（assert），後者與測試關聯更緊密。

3.數據驅動，需求實例化

抽象的業務語言描述的需求，往往由於太抽象而缺失掉很多關鍵信息，導致不同人員對需求理解的不一致。想要既抽象又能包含細節信息，就需要采用需求實例來描述。簡單說來，就是給場景用例舉例說明。舉例就會需要列舉數據，如果在場景用例描述裏邊直接添加數據實例，那樣的用例將會很混亂，可讀性和可維護性都非常差。如果我們能夠在描述場景的用例裏邊用一些變量來代替，把變量對應的值（數據）提取出來存為一個表格或者獨立的文件，這樣將會使得用例的可讀性很好，而且也不會缺失細節信息（數據），後期的維護和修改也較為方便。這就是數據驅動的方法來描述實例化的需求。

下面舉幾個例子，大家體會一下：

場景一：檢查收件箱，可以看出第三個清晰明了且能體現業務價值，比較符合上面的要求。

場景二：限制非法用戶查看某些受限內容，BDD要強調什麽（What），而不是怎麽（How），第二個寫的比較好。

場景三：添加圖書到購物車並計算總額

BDD的工具有Cucumber、JBehave、Twist、Concordion等，工具的優缺點和使用方法，網上都有豐富的文檔可參考，在此不作介紹。

BDD有什麽好處？

BDD的作用是把利益關系人、交付團隊等不同方面的項目相關人員集中到一起，形成共同的理解，共同的價值觀以及共同的期望值。它可以幫助我們：

1. 關註用戶行為

2.交付最有用的功能

3. 在團隊內部維護一致的術語

4. 探究需求實例

5. 編寫和維護需求

6. 創建活的文檔

7. 消除協作與溝通障礙

什麽樣的項目適合BDD？

簡單的一次性項目，溝通交流成本都較低的情況下，沒有必要使用BDD；

業務比較輕量，重在技術方面的項目，可以使用簡單的白板上的BDD，不需要在BDD工具記錄需求用例文檔；

業務復雜、團隊成員較多的項目，溝通成本高，BDD很有必要。

常見疑惑

1.BDD與TDD/ATDD

TDD是測試驅動開發，ATDD是驗收測試驅動開發，都是關於測試的，是與所開發的系統緊密聯系的。而BDD則不同，前面提到過BDD不是關於測試的，著重關註需求、關註客戶的業務價值，所描述的需求用例是可以獨立於軟件系統存在的，因為客戶的業務是始終存在的，不取決於是否有軟件系統來支撐。

2. BDD與SBE

SBE(Specification By Example，實例化需求)是在BDD之後由Gojko提出來的，也是關於需求的，主要強調通過列舉實例發現需求中的缺失概念。BDD也是關註需求的，同樣會使用實例來描述行為。兩者的本質沒有區別，只是概念的差異

轉自簡書

https://www.jianshu.com/p/20a3af030b51

BDD本質及與ATDD區別