軟件行業中，軟件研發項目的產品交付經常被推遲、研發費用經常超出預算、經常遺漏客戶所需的軟件功能、有將近20%的項目最終無法交付，或者取消。這些軟件研發往往花費了大量的資金、人力和時間，但所交付給用戶的產品功能卻有很大部分用戶不會用到，或者沒有能夠幫助用戶解決問題。
導致軟件研發項目失敗的原因是多種多樣的，但最終結果可以分爲兩類：
- 沒能正確的研發軟件。
- 沒能研發正確的軟件。
沒能正確的研發軟件，主要是交付滿足質量要求的軟件，軟件缺陷多且難以維護。沒能研發正確的軟件，主要表現在費用超出預算、軟件產品延期交付、軟件功能遺漏、產品功能錯誤或交付了客戶根本不用的產品功能。
有鑑於此，行爲驅動開發（Behavior Driven Development，BDD）借鑑了敏捷和精益實踐，讓敏捷研發團隊儘可能理解產品經理或業務人員的產品需求，並在軟件研發過程中及時反饋和演示軟件產品的研發狀態，讓產品經理或業務人員根據獲得的產品研發信息及時對軟件產品特性進行調整。BDD 幫助敏捷研發團隊把精力集中在識別、理解和構建跟業務目標有關的產品特性上面，並讓敏捷研發團隊能夠確保識別出的產品特性能夠被正確設計和實現出來。
圖1 BDD 增進研發團隊與業務人員的交流水平
引入 BDD 的軟件研發團隊通過充分的交流溝通和待實現的產品功能的使用場景舉例，來幫助研發團隊理解產品特性對業務的價值。BDD 採用更容易測試的軟件需求描述方式鼓勵需求分析人員、軟件開發人員、測試人員密切協同開展軟件產品研發工作。同時 BDD 工具可以幫助把用 BDD 風格描述的業務需求轉換成自動化測試腳本，讓軟件開發人員同步驗證自己編寫的代碼是否滿足業務需求描述的產品特性，並在驗證軟件產品特性的同時形成軟件產品特性文檔，從而實現了產品研發文檔與軟件產品代碼編寫的同步更新。
BDD 並不是一種軟件研發方法，也不是用來替代 Scrum、XP、看板等現有的敏捷理論和方法，而是把現有的工作方法融合起來，讓軟件研發團隊更加高效的工作，從而減輕因軟件產品計劃延誤或功能缺失帶來的壓力。
使用 BDD 的軟件研發過程與傳統軟件研發過程有什麼區別呢？
傳統軟件研發過程
傳統軟件研發過程是這樣的：
業務人員把想要的軟件產品需求講述給軟件需求分析人員。
軟件需求分析人員把從業務人員那裏獲得的軟件需求記錄下來，並根據業務需求編寫軟件產品需求說明書。
軟件開發人員根據軟件產品需求說明書編寫軟件代碼和單元測試代碼。
軟件測試人員根據軟件產品需求說明書進行測試需求分析，編寫測試案例（用例），並使用測試案例對軟件產品進行測試。
最後軟件開發團隊根據穩定的軟件版本編寫軟件產品的功能說明和技術說明文檔。
圖2 傳統軟件開發過程
傳統軟件研發模式的問題在於，在業務人員把業務需求描述給軟件需求分析人員之後，軟件需求分析人員按照自己的理解編寫軟件需求規格說明書，然後由研發人員根據軟件需求規格說明進行軟件架構設計和編寫軟件代碼，最後由測試人員根據軟件需求規格說明書編寫測試案例進行測試。由業務需求到軟件編碼，再到軟件測試的過程中，有不同角色和不同人員在不同時段對軟件開發所需的信息進行處理，這中間有太多機會可能會導致丟失、弄錯、甚至直接忽視業務人員的原始需求。軟件研發的衆多環節中，只要一個環節出錯，軟件研發團隊就很難按時交付出符合業務人員要求的軟件產品。
Behavior Driven Development（BDD），行爲驅動開發是一種敏捷軟件開發的技術，它鼓勵軟件項目中的開發者、QA 和非技術人員或商業參與者之間的協作。行爲驅動開發特別適用於敏捷項目。行爲驅動開發由一系列軟件工程實踐組成，這些軟件工程實踐可以用來幫組研發團隊提高交付效率、交付質量和交付價值。 BDD 引入了敏捷管理、精益研發等思想，尤其包括測試驅動開發（TDD）和領域驅動設計（DDD）等軟件研發方法。行爲驅動開發（BDD）利用簡單的格式化自然語言（包括英語、中文等語言）來提升敏捷研發團隊和產品經理或業務人員之間的溝通水平，使得敏捷研發團隊能夠更好的理解業務目標，從而更好的滿足產品經理或業務人員的產品需求。
BDD 的軟件研發過程
BDD 的軟件研發過程是這樣的：
產品經理（業務人員）通過具體的用戶故事使用場景來告訴軟件需求分析人員他（她）想要什麼樣的軟件產品。使用軟件產品的使用場景來描述軟件需求可以儘可能的避免相關人員錯誤理解軟件需求或增加自己的主觀想象的需求。
軟件需求分析人員（BA）和研發團隊（研發人員、測試人員）一起對產品經理（業務人員）的用戶故事進行分析，並梳理出具體的軟件產品使用場景舉例，這些場景舉例使用結構化的關鍵字自然語言進行描述，例如中文、英文等。
研發團隊使用 BDD 工具把用戶故事場景文件轉化爲可執行的自動化測試代碼，研發人員運行自動化測試用例來驗證開發出來的軟件產品是否符合用戶故事場景的驗收要求。
測試人員可以根據自動化測試結果開展手工測試和探索性測試。
產品經理（業務人員）可以實時查看軟件研發團隊的自動化測試結果和 BDD 工具生成的測試報告，確保軟件實現符合產品經理（業務人員）的軟件期望。
圖3 BDD 軟件研發過程
如何實施行爲驅動開發（BDD）呢？其實本課程之前章節的主線就是 BDD 的過程。我們把小明同學的機票銷售系統的研發過程進行梳理，就是 BDD 的實踐過程。
總結小明同學使用 BDD 研發機票銷售系統的過程如下。
第一步：老闆提出戰略目標。（產品願景）
同學們，市場競爭越來越激烈，飛機票代訂業務也越來越難做。董事會要求我們今年的營業額要比去年增加20%，成本要降低10%。今天召集大家開會的目的就是請市場部、銷售部和研發的童鞋一起獻計獻策，羣策羣力完成今年的業務目標。
第二步： 業務部門提出具體業務目標和軟件需求。
- 增加常旅客積分積累和使用功能，通過我們公司電子商務網站或相關渠道購買機票的旅客可以積累里程積分。這些積分可以在下次購買機票時使用積分購買機票，也可以設置積分共享，讓他（她）的親友使用自己的積分購買機票。
- 增加電子商務網站訪問渠道，例如可以通過微信或支付寶平臺查詢機票，購買機票，查看和共享里程積分。
- 爲了增加客戶的黏着度，新增用戶登錄積分和信息共享積分，用戶登錄使用我們電子商務網站越多，積分也越多。用戶在我們電子商務網站發表旅行心得或爲他人提供幫助信息也可以獲取積分。使用積分可以這換成里程積分兌換機票。
第三步：產品經理（需求分析人員）與研發團隊一起梳理用戶故事，並實例化用戶故事驗收條件。
用戶故事場景：新會員註冊後初始狀態爲銅牌會員
# language: zh-CN
場景：新會員註冊後初始狀態爲銅牌會員。
假如：小明同學還不是一位常旅客會員。
當：小明同學註冊常旅客會員，註冊時輸入信息：
用戶名 密碼 xiaoming 12345678 [email protected] 那麼：註冊成功後，小明同學的初始會員級別爲“銅牌會員”。
第四步： 研發人員（測試人員）使用 BDD 工具，例如 Cucumber，轉化爲可以運行的驗收測試說明文檔，也是自動化驗收測試案例
@假如("^小明童鞋還不是一位常旅客會員$")
public void 小明童鞋還不是一位常旅客會員() throws Throwable {
//TODO： 註冊前小明童鞋還不是常旅客會員
throw new PendingException();
}
@當("^小明童鞋註冊常旅客會員:$")
public void 小明童鞋註冊常旅客會員(DataTable arg1) throws Throwable {
///TODO：小明童鞋註冊爲會員
throw new PendingException();
}
@那麼("^註冊成功後，小明童鞋的初始會員級別爲'銅牌會員'$")
public void 註冊成功後_小明童鞋的初始會員級別爲_銅牌會員() throws Throwable {
//TODO： 註冊成功後檢查小明童鞋的會員狀態
throw new PendingException();
}
第五步：研發人員根據用戶故事設計軟件功能，編寫單元測試和實現代碼，當軟件功能通過單元測試時，表示軟件功能滿足了設計需求。
public class WhenCheckingMinimumStatusPoints {
FrequentFlyer member;
@Before
public void newFrequentFlyer() {
member = FrequentFlyer.newMemberWithUsername("xiaoming").password("12345678").email("[email protected]");
}
@Test
public void should_have_bronze_status_initially() {
assertThat(member.getStatus()).isEqualTo(FrequentFlyerStatus.BRONZE);
}
enter code here
}
第六步：研發人員運行第四步中生成的驗收測試代碼，驗收測試可以是 UI 層端到端測試也可以是接口測試。
public class UserRegisterPage extends PageObject {
@FindBy(name="username")
private WebElement username;
@FindBy(name="password")
private WebElement password;
@FindBy(name="email")
private WebElement email;
@FindBy(css = ".btn[value='Sign up']")
private WebElement signup;
public void signupAs(String username, String userPassword, String userEmail ) {
username.sendKeys(username);
password.sendKeys(userPassword);
email.sendKeys(userEmail);
//點擊註冊按鈕
signup.click();
}
}
第七步：產品經理可以實時查看驗收測試報告，驗收測試報告同時也是產品說明文檔。
圖4 BDD測試生成文檔
最後說明一下，BDD 自動化測試代碼可以使用持續集成平臺或 DevOps 平臺根據指定的持續集成規則運行，這樣可以提高團隊協作效率，及時公佈單元測試、集成測試和用戶驗收測試的測試狀態。