行為驅動開發（BDD）通過利用業務領域和QA專業人員的領域專業知識來確保開發團隊構建正確的軟件，從而解決了定義不明確的需求的問題。請繼續閱讀以了解有關如何在企業中采用BDD的更多信息。

在過去的幾年中，許多組織已經過渡到敏捷開發，以加快交付速度并從市場上獲得更及時的反饋。在這些組織中，盡管開發開始快速發展，但是質量保證團隊將難以跟上步伐，除非他們將自動化軟件測試實踐集成到開發管道中，所以這通常是要克服的第一個瓶頸。

但是，在成功采用測試自動化并且整個組織的發展速度更快之后，組織開始問自己是否正在構建正確的軟件。通過自動連續測試來加速軟件開發并確保軟件質量是一項偉大的成就，但是如果軟件不是客戶想要或不需要的軟件，那將是無濟于事的。

在軟件開發流程發展的現階段，人們正在密切關注BDD，以確保他們的軟件滿足組織的業務需求。但是BDD到底是什么？它與測試有什么關系？

TDD與BDD

BDD是測試驅動開發（TDD）方法的演變，開發人員在其中開發測試，然后再編寫代碼。在設計出無法通過的測試以啟動之后，練習TDD的開發人員只需編寫足以確保測試通過的代碼，然后編寫另一個測試；沖洗并重復。結果是精簡且具有較高測試覆蓋率的代碼。

TDD是一項旨在提高軟件質量并確保代碼覆蓋率的活動。相比之下，BDD解決了正確實現需求的問題。BDD與其專注于驗證您要實現的功能的測試，不如定義應用程序的行為以使其滿足特定的業務需求。

TDD和BDD之間的相似之處在于，在完成任何工作之前要實施契約機制，以確保輸出符合特定期望。但這就是相似性結束的地方。在TDD中，測試是一項旨在確保應用程序滿足特定功能要求的合同。在BDD中，行為是旨在確保應用程序滿足特定業務需求的合同。

什么是軟件開發中的BDD？

我們一直在隨意使用“行為”一詞，但是它在BDD中確實具有技術意義。在BDD中，行為是遵循特定格式的精心設計的，人類可讀的語句。它們收集在“功能文件”中，可以集成到開發過程中。

功能文件通常以Gherkin編寫，Gherkin是BDD特定的語法，它使BDD工具（例如Cucumber和SpecFlow）能夠自動執行驗證行為的過程。這些BDD工具解析功能文件中的行為并執行適當的“膠水代碼”。該粘合代碼將“行為”映射到特定測試引擎中的執行步驟，通常是開發人員編寫的Java或.NET測試代碼。這些映射通常被稱為“步驟定義”或“step-defs”。因此，測試人員可以將功能文件用作測試用例，以驗證與需求相關的行為。

BDD的好處是什么？

業務驅動開發為軟件開發帶來了許多優勢。使用BDD，您可以：

• 增加協作。BDD為組織中的不同角色提供了一種通用語言。這有助于技術和非技術團隊成員了解項目的預期功能和業務需求。

• 利用更廣泛的領域專業知識。由于行為是以人類可理解的格式定義的，因此組織可以利用具有不同觀點和背景的測試人員，架構師和其他利益相關者的專業知識。

• 以測試為重點滿足要求。BDD著眼于滿足需求來推動測試覆蓋范圍，從而確保最終產品與組織的業務需求相關。

• 促進重用并降低自動化的復雜性。鼓勵開發粘貼代碼的開發人員編寫可重用的測試步驟，以及更多可測試的代碼。例如，應用程序可能具有一些重復的設置步驟，需要調用這些步驟才能實現某種狀態。開發人員可以在粘合代碼中定義這些步驟，這些步驟可以重用于處理設置和執行。

最后一點是BDD的主要功能之一。模塊化，可重復使用的測試步驟使測試人員可以在驗證和確認需求時依靠BDD工具進行繁重的工作。但是，問題的關鍵在于，仍然需要開發人員編寫將行為綁定到需求的粘合代碼。接下來，我們將詳細討論。

在企業中實施BDD的成本

與實現BDD相關的最大成本是編寫粘合代碼。在大多數情況下，此任務落在開發團隊上，這將創建用于驗證需求的測試工件的負擔從測試人員轉移到了開發人員。

在BDD之前的世界中，測試人員將使用工具和框架來創建測試，以驗證功能（不一定是要求）。使用BDD，測試人員、業務分析師和其他涉眾可以在功能文件中定義行為，但是仍然需要開發人員或具有代碼編寫技能的人員編寫將行為映射到功能的粘合代碼。

BDD增加了開發成本這一事實可能會損害開發資源有限的組織。盡管膠水代碼旨在可重用并且更易于用于測試自動化，但是在整個企業中擴展和實施BDD所需的投資通常太高。

如何減輕BDD的技術負擔

幫助減輕與BDD測試代碼創建和維護相關的技術負擔。有多種方法可以自動測試應用程序，其中主要是API測試和UI測試。可以以不同方式減輕每種產品的技術負擔；

減少通過使用BDD進行API測試來實現測試代碼的技術障礙

使非開發人員可以編寫作為SOAtest測試執行的step-def，從而大大減少了編寫測試所需的技術資源。使用SOAtest-Cucumber執行程序，每個步驟定義都映射到在執行該步驟時運行的可重用SOAtest測試或測試套件。

請考慮以下示例：

• 第一個步驟定義引用了調用特定API的SOAtest REST客戶端

• 第二個步驟定義引用了連接到JSON聲明器的SOAtest REST客戶端，該客戶端在來自其他API的響應中驗證數據

• 第三個步驟定義引用了連接到Value Assertor的SOAtest DB Tool，該工具執行DB查詢并驗證結果集中的數據。

步驟定義還可以引用單個SOAtest測試或其中包含許多測試的測試套件。

使用Selenium和BDD降低UI測試自動化的日常維護成本

將UI測試集成到BDD解決方案中時，還會遇到其他獨特的技術挑戰。與的API測試解決方案類似，Selenic能夠從瀏覽器記錄UI動作并創建可以與您的step def相關聯的純Selenium代碼，以驅動UI測試自動化。為了減少對純Selenium腳本的日常維護，Selenic利用頁面對象模型創建Selenium測試。頁面對象模型是一種UI測試設計范式，用戶可以在其中定義與它們所在的頁面相關聯的UI元素，由于元素位置是在一個位置定義的，因此可以更輕松地維護腳本在您的測試套件中。首先降低了創建初始測試腳本所需的技術技能。

但是，創建是一次性的成本，并且BDD測試代碼所產生的大部分負擔都在維護中。隨著時間的流逝，隨著您的應用程序更改元素定位符，底層Selenium測試代碼中最初定義的等待條件可能會中斷。在查看測試結果時，這會引起混亂，因為很難確定測試是否由于應用程序中的實際缺陷或簡單的UI更改而失敗。這會侵蝕BDD提供的價值。

在您的IDE中激活，或者對于CI/CD，通過將一行代碼更改為命令行執行來激活，Selenic對測試執行進行運行時分析。當測試失敗時，它將應用其AI啟發式方法來確定如何避免該失敗（例如，通過更新定位器或等待條件），然后嘗試在運行時自行修復測試，以便管道可以繼續進行。您可以避免浪費時間來調試由于不穩定的測試而導致的構建失敗調試，并且它可以同時了解有關測試的更多信息。

所有這些都減少了您花費在維護、修復和修復損壞的測試上的時間，并讓您獲得BDD的真正好處，即由于測試自動化而增強了協作并增強了信心。

降低與測試自動化和BDD相關的成本

將更多的控制權交給測試人員，使他們充滿信心，以確保他們已經完全涵蓋了測試中的功能。利用成熟的、功能豐富的端到端測試解決方案，可以輕松進入測試自動化、測試維護，并自然地集成到現有CI/CD工作流程中。從較高的角度看，它使組織可以利用較少的技術資源來實施BDD、釋放開發資源、更改創建區域，如下所示：

結論

BDD是一種強大的開發實踐，可以確保構建正確的功能。但是，將BDD擴展到企業級別可能很困難，因為實施該實踐需要大量技術資源。通過使用戶能夠使用簡單易懂的UI將行為語句映射到步驟執行定義來降低技術障礙。步驟定義作為SOAtest測試執行，使測試人員和非技術人員更容易為驗證過程做出貢獻。Selenic通過為定位器和運行時的等待條件提供AI生成的建議，減少了通過Selenic與UI測試相關的日常維護。

如果您有興趣了解有關SOAtest-Cucumber執行器的更多信息，請，或通過單擊下面的。