BDD 101: BDD 簡介
系列概覽
BDD 101 是一個博客系列，教授行為驅動開發的基礎知識。它既是 BDD 初學者的“入門”指南，也是專業人士的最佳實踐參考。我為參與軟件開發日常職責的任何人編寫了這個系列：開發人員、測試人員、Scrum 管理員、產品所有者和經理。本系列中的內容來自我在許多項目中使用 BDD 的經驗。它側重於基於 Gherkin 的規范，測試自動化將是一個主要主題。如果這個系列適合你，那就讓我們潛入吧！
BDD 101 目錄在 Automation Panda BDD 頁面上給出。請注意，該系列中的一些文章相隔幾個月發布，並且不會使用“上一篇”和“下一篇”文章箭頭一起出現。
BDD 大圖：BDD 的主要目標是協作和自動化。
什么是行為？
行為是產品或功能的運作方式。它被定義為輸入、行動和結果的場景。一個產品或功能表現出無數的行為。單獨識別行為會帶來清晰和簡單。它還有助於解釋行為之間的關系。以下是行為示例：
-
登錄網頁
-
單擊導航欄上的鏈接
-
提交表格
-
成功撥打服務電話
-
接收預期錯誤
分離個體行為可以很容易地定義一個系統，而無需不必要的重復。例如，可能有多種方式導航到同一頁面。
什么是行為
行為驅動開發 (BDD) 是一種以測試為中心的軟件開發過程，它源於測試驅動開發 (TDD)。它大約從 2000 年代中期開始出現。 BDD 專注於從一開始就清楚地確定功能的所需行為。行為是使用實例規范來識別的：行為規范是為了用現實的例子來說明所需的行為，而不是用抽象的、通用的行話編寫的。它們既作為產品的需求/驗收標准（開發前）又作為測試用例（開發后）。 Gherkin 是編寫正式行為規范最流行的語言之一——它將行為捕獲為“Given-When-Then”場景。借助自動化工具，可以輕松地將場景轉換為自動化測試用例。從工程師到產品負責人，任何人都可以編寫 BDD 場景，因為它們只是英文短語。 BDD 讓開發人員專注於准確交付產品所有者想要的東西。它還加快了測試速度。因此，BDD 與敏捷軟件開發完美結合。
知識速記
- BDD 是示例規范。
- 當有人說“BDD”時，立即想到“Given-When-Then”。
- BDD 首先關注行為。
- 行為場景是 BDD 的基石。
- BDD 是敏捷過程的改進，而不是大修。
- 它正式確定了驗收標准和測試覆蓋率。
- BDD 是一種范式轉變。
- 行為成為團隊的主要關注點。
BDD 的起源
以下引用來自 Dan North（“BDD 之父”）於 2006 年 3 月撰寫的題為 Introducing BDD 的文章：
我有問題。在不同環境中的項目中使用和教授測試驅動開發 (TDD) 等敏捷實踐時，我不斷遇到同樣的困惑和誤解。程序員想知道從哪里開始，測試什么，不測試什么，一次測試多少，如何調用他們的測試，以及如何理解測試失敗的原因。
我對 TDD 越深入，我就越覺得我自己的旅程與其說是一連串的死胡同，不如說是一個逐漸掌握的漸進式、漸進式的過程。我記得當時在想“要是有人告訴我就好了！哇，一扇門打開了。”我決定必須有可能以一種直接獲得好東西並避免所有陷阱的方式來呈現 TDD。
我的回答是行為驅動開發（BDD）。它是從既定的敏捷實踐發展而來的，旨在使敏捷軟件交付的新手團隊更容易獲得和有效地使用它們。隨着時間的推移，BDD 已經發展為涵蓋更廣泛的敏捷分析和自動化驗收測試。
12大好處
BDD 以十幾種方式改進了開發過程：
包容性 任何人都可以編寫 BDD 場景，因為它們是用簡單的英語編寫的。想想三個朋友。
清晰性 場景特別關注正在開發的產品的預期行為，從而減少開發內容的歧義。
精簡 需求 = 驗收標准 = 測試用例。模塊化語法也加快了自動化。
左移 測試用例定義本質上成為修飾的一部分。
工件 場景形成了測試用例的集合。任何未自動化的測試都可以添加到已知的自動化積壓工作中。
自動化 BDD 框架可以輕松地將場景轉換為自動化測試。
測試驅動 大多數 BDD 框架可以運行場景失敗，直到實現該功能。
代碼重用 “Given-When-Then”步驟可以在場景之間重用。
參數化 步驟可以參數化。例如，單擊按鈕的步驟可以接收其 ID。
變化 使用參數，示例表可以輕松運行具有不同輸入組合的相同場景。
水到渠成 隨着更多步驟定義的添加，場景的編寫和自動化變得更容易、更快。
適應性 隨着產品和功能的變化，場景很容易重寫。
測試建議
由於 BDD 專注於實際的功能行為，行為規范最適合更高級別的、功能性的、黑盒測試。例如，BDD 非常適合測試 API 和 Web UI。 Gherkin 擅長驗收測試。然而，行為規范對於單元測試來說是多余的，對於關注指標而不是通過/失敗結果的性能測試來說，它也不是一個好的選擇。在 BDD 101：單元、集成和端到端測試一文中了解更多相關信息。