很多開發問題都是源于溝通不暢。例如，開發人員可能會處理他們并不完全了解的規範，或者相關人員會在并不了解某項功能的情況下就提出需求。這導緻的結果就是返工，進而導緻增加成本和項目延誤，而且很多情況下會造成項目因為遠超預算而失敗。

行為驅動開發（BDD）通過鼓勵跨職能的協作來克服這些挑戰。BDD并不是取代現有的靈活開發過程，而是作為一個插件，提高靈活開發成功的可能性——可靠、及時地傳遞工作軟體，滿足企業不斷發展的需求。

BDD幫助您實作靈活開發的承諾——可靠、按時傳遞可用軟體，且滿足不斷演變的規格要求。

一起來看看BDD和自動化測試如何共同改進軟體開發周期。

什麼是BDD？

行為驅動型開發（Behavior-driven development，簡稱BDD）通過鼓勵跨職業協作來建立對問題的共同了解，進而縮小業務和技術團隊之間的差距，并且讓團隊在小疊代中工作，縮短回報循環。還能生成業務友好的文檔，這些文檔會根據系統的行為自動進行檢查。

該過程包括三個核心步驟：

發現：針對一個即将進行的小型更改（例如使用者情景），協作建立新功能的具體示例，以此來明确問題的具體範圍，最終實作對應該傳遞的内容詳細的、共同的了解；
自動化：用可自動驗證功能是否存在的方式制定具體用例。通常，這些用例會記錄在Gherkin特性檔案中，包含Given-When-Then場景。這些功能檔案易于了解，即使對非技術人員來說也是如此；
編寫自動化測試代碼：根據每個場景描述編寫自動化測試代碼。然後将生成的自動化測試用于指導代碼開發。

BDD流程中最重要的部分是“發現”階段，即定期舉辦一個研讨會，這個研讨會中必須至少有三個視角的代表：相關人員、測試工程師和開發人員。在這個頻繁召開的簡短研讨會上，可以通過使用具體的例子來達成對要求的共識。常見的會議形式稱為“Example Mapping”。

采用BDD時，開發團隊最常見的錯誤是将其視為另一種測試。如果沒有業務團隊和技術團隊之間的對話，這些測試将無法解決溝通不暢問題，這将導緻項目延遲、預算超标。

測試自動化如何适應BDD

大多數的開發團隊對測試驅動開發（TDD）中的測試自動化都很熟悉。例如，開發人員可以編寫單元測試，測試工程師可以編寫內建測試，在每次送出或部署之前，這些測試會作為建構過程的一部分自動執行。任何問題都會被标記出來給開發人員，讓他們在投入生産之前解決。

BDD實踐與TDD是互相配合、結合使用的。在将使用者情景引入開發并開始TDD流程前，團隊應用BDD實踐來管理需求，生成具體用例，将其制定為易讀的規範，并自動執行它們以建立動态文檔。這些規範會與TDD測試一起，在像Jenkins這樣的持續內建伺服器上運作。

以下是典型的開發過程：

應用BDD實踐生成的動态文檔還有另一個好處。由于Gherkin是用簡單的英語編寫的，是以相關人員可以輕松地檢視哪些功能已經通過了，哪些功能仍在開發中已被棄用。這讓所有人都能保持同步，而無需在每個産品增量中手動更新文檔。

在實施BDD時，開發團隊面臨一些挑戰，尤其是在溝通和內建方面。

一個常見的挑戰是将活動文檔與其他測試套件一起管理，并繼續向相關人員提供可操作的報告。

TestComplete通過原生支援Gherkin的Given-When-Then場景簡化了這個過程。無需建構和維護跨多個不同工具的複雜技術堆棧，就可輕松地将功能檔案轉換為自動化測試，也不需要任何額外的插件。

與相關人員共享報表也很容易。TestComplete的Zephyr for Jira內建可以輕松地與業務團隊共享BDD見解，無需技術團隊定期生成和通過郵件發送報告。它提供了一個單一的界面，每個人都可以使用更廣泛的Jira生态系統來檢視測試狀态和相關的bug報告。

除了建立BDD場景之外，TestComplete還可以通過其業界領先的記錄和回放功能、報告特性和CI/CD內建，輕松建構自動化UI功能測試。測試工程師可以使用BDD來減少溝通問題并內建測試，確定在部署之前所有元件都能完美配合。

歸根結底，BDD有助于改善業務和技術團隊之間的溝通。通過使用TestComplete，您可以簡化流程，通過在同一平台上合作，并将BDD的實時文檔納入您的其他測試套件中。

文章來源：https://www.shdsd.com/news-550/index.html