BDD - 基於示例的規範

---

---

根據《基於示例的規範》作者 Gojko Adzic 的說法，“基於示例的規範是一套流程模式，它促進軟體產品中的變更，以確保高效交付正確的產品。”

基於示例的規範是一種協作方法，用於定義軟體產品的需求和麵向業務的功能測試，該方法基於使用現實示例而不是抽象語句來捕獲和說明需求。

基於示例的規範 – 概述

基於示例的規範的目標是專注於優先順序排序、可驗證的業務需求的開發和交付。雖然基於示例的規範本身的概念相對較新，但這只是對現有實踐的一種重新表述。

它支援一種非常具體、簡潔的詞彙，稱為普遍語言，它：

• 支援可執行的需求。

• 被團隊中的每個人使用。

• 由跨職能團隊建立。

• 捕捉每個人的理解。

基於示例的規範可以直接用作構建反映業務領域的自動化測試的輸入。因此，基於示例的規範的重點是構建正確的產品並正確構建產品。

基於示例的規範的目的

基於示例的規範的主要目標是構建正確的產品。它側重於共享理解，從而建立單一事實來源。它支援驗收標準的自動化，因此重點是缺陷預防而不是缺陷檢測。它還提倡儘早測試以儘早發現缺陷。

SbE 的使用

基於示例的規範用於說明描述業務價值的預期系統行為。圖示是透過具體和現實生活中的例子來實現的。這些例子用於建立可執行的需求，這些需求：

• 無需翻譯即可測試。

• 捕獲在即時文件中。

以下是我們使用示例來描述特定規範的原因：

• 它們更容易理解。

• 它們更不容易被誤解。

SbE 的優勢

使用基於示例的規範的優勢在於：

• 提高質量

• 減少浪費

• 降低生產缺陷的風險

• 重點工作

• 可以更安全地進行更改

• 改進業務參與

SbE 的應用

基於示例的規範應用於：

• 複雜的業務或複雜的組織。

• 不適用於純粹的技術問題。

• 不適用於以 UI 為中心的軟體產品。

• 也可以應用於遺留系統。

SbE 和驗收測試

基於示例的規範在驗收測試方面的優勢在於：

• 一個插圖同時用於詳細的需求和測試

• 專案的進度以驗收測試為準：

  • 每個測試都是為了測試一種行為。

  • 一個測試要麼透過某種行為，要麼不透過。

  • 透過的測試表示特定行為已完成。

  • 如果一個需要完成 100 種行為的專案完成了 60 種行為，則表示已完成 60%。

• 測試人員從缺陷修復轉向缺陷預防，併為解決方案的設計做出貢獻。

• 自動化允許即時瞭解需求更改對解決方案的影響。

基於示例的規範 – 對不同角色的意義

基於示例的規範的目標是促進團隊中每個人的協作，包括整個專案中的客戶，以交付業務價值。為了更好地理解，每個人都使用相同的詞彙。

SbE – 一套流程模式

正如我們在本章開頭看到的那樣，基於示例的規範被定義為一套流程模式，它促進軟體產品中的變更，以確保高效交付正確的產品。

流程模式包括：

• 協作規範

• 使用示例說明規範

• 細化規範

• 自動化示例

• 頻繁驗證

• 活文件

協作規範

協作規範的目標是：

• 讓團隊中的各種角色擁有共同的理解和共享的詞彙。

• 讓每個人都參與到專案中，以便他們可以貢獻對某個功能的不同視角。

• 確保功能的共享溝通和所有權。

這些目標在規範研討會（也稱為“三位一體會議”）中得到實現。“三位一體”是指 BA、QA 和開發人員。儘管專案中還有其他角色，但這三位將負責並對從定義到交付功能負責。

在會議期間：

• 業務分析師 (BA) 提出新功能的需求和測試。

• 三位一體 (BA、開發人員和 QA) 討論新功能並審查規範。

• QA 和開發人員還會識別缺失的需求。

• 三位一體

  • 使用普遍語言使用共享模型。

  • 使用領域詞彙（如果需要，則維護詞彙表）。

  • 尋找差異和衝突。

• 此時不要跳到實現細節。

• 就功能是否已充分指定達成共識。

• 對需求和測試所有權的共享意識促進了高質量的規範

• 需求以場景的形式呈現，這些場景提供了明確無歧義的需求。場景是從使用者的角度來看系統的行為的示例。

使用示例說明規範

使用 Given-When-Then 結構指定場景以建立可測試的規範：

Given <某些前提條件>

And <附加前提條件> 可選

When <某個動作/觸發器發生>

Then <某些後置條件>

And <附加後置條件> 可選

此規範是系統行為的一個示例。它也代表系統的驗收標準。

團隊討論示例，併合並反饋，直到達成一致意見，認為這些示例涵蓋了該功能的預期行為。這確保了良好的測試覆蓋率。

細化規範

要細化規範，

• 編寫示例時要精確。如果示例變得複雜，請將其拆分為更簡單的示例。

• 關注業務視角，避免技術細節。

• 考慮正面和負面條件。

• 遵守特定領域的詞彙。

• 與客戶討論示例。

  • 選擇對話來完成此任務。

  • 僅考慮客戶感興趣的示例。這僅支援生成所需程式碼，並避免涵蓋可能不需要的每種可能的組合

• 為了確保場景透過，該場景的所有測試用例都必須透過。因此，增強規範以使其可測試。測試用例可以包括各種範圍和資料值（邊界和角點情況）以及導致資料變化的不同業務規則。

• 指定其他業務規則，例如複雜的計算、資料處理/轉換等。

• 將非功能場景（例如效能、負載、可用性等）包括為基於示例的規範

自動化示例

自動化層需要保持非常簡單 – 只需將規範連線到被測系統即可。您可以為此使用工具。

使用領域特定語言 (DSL) 執行測試自動化，並顯示輸入和輸出之間的清晰連線。關注規範，而不是指令碼。確保測試精確、易於理解且可測試。

頻繁驗證

在每次更改（新增/修改）時，將示例驗證包含在您的開發管道中。有許多技術和工具可以（也應該）被採用以幫助確保產品的質量。它們圍繞三個關鍵原則展開：**儘早測試、測試良好**和**經常測試**。

頻繁執行測試，以便您可以識別薄弱環節。表示行為的示例有助於跟蹤進度，並且只有在相應的測試通過後，才認為行為已完成。

活文件

使規範儘可能簡單和簡短。組織規範並在工作進展時對其進行改進。使團隊中的所有人都可以訪問文件。

基於示例的規範流程步驟

圖示顯示了基於示例的規範中的流程步驟。

反模式

反模式 (Anti-patterns) 是軟體開發中某些被認為是不良程式設計實踐的模式。與設計模式（design patterns）相反，設計模式是對常見問題的常用方法的總結，已被正式化，並普遍認為是一種良好的開發實踐，而反模式則恰恰相反，是不可取的。

反模式會導致各種問題。

問題的解決方案 - 質量

可以透過關注反模式來確保質量。為了最大限度地減少反模式造成的問題，您應該：

• 一起使用示例進行規範。

• 清理和改進示例。

• 編寫滿足示例的程式碼。

• 自動化示例並部署。

• 對每個使用者故事重複此方法。

為了解決因反模式造成的問題，意味著要遵守：

• 協作。

• 關注“是什麼”。

• 關注業務。

• 做好準備。

讓我們瞭解上述每一點的含義。

協作

在協作中：

• 業務人員、開發人員和測試人員從各自的角度提供輸入。

• 自動化的示例證明團隊構建了正確的東西。

• 過程比測試本身更有價值。

關注“是什麼”

您必須關注“是什麼”這個問題。在關注“是什麼”時：

• 不要試圖涵蓋所有可能的案例。

• 不要忘記使用不同型別的測試。

• 保持示例儘可能簡單。

• 示例應該易於系統使用者理解。

• 工具不應在研討會中扮演重要角色。

關注業務

為了關注業務：

• 將規範保持在業務意圖層面。

• 讓業務參與建立和審查規範。

• 將所有細節隱藏在自動化層中。

做好準備

為以下情況做好準備：

• 即使改變了團隊實踐，好處也不立即顯現。

• 引入基於示例的規範 (SbE) 具有挑戰性。

• 需要時間和投資。

• 自動化測試並非免費。

工具

基於示例的規範 (Specification by Example) 不強制要求使用工具，儘管實際上有許多工具可用。即使不使用工具，也有一些案例成功遵循了基於示例的規範。

以下工具支援基於示例的規範：

• Cucumber

• SpecFlow

• Fitnesse

• Jbehave

• Concordion

• Behat

• Jasmine

• Relish

• Speclog