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

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

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

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

TDD與BDD

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

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

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

什么是軟件開發(fā)中的BDD？

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

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

BDD的好處是什么？

業(yè)務驅動開發(fā)為軟件開發(fā)帶來了許多優(yōu)勢。使用BDD，您可以：

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

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

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

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

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

在企業(yè)中實施BDD的成本

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

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

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

如何減輕BDD的技術負擔

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

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

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

請考慮以下示例：

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

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

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

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

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

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

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

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

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

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

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

結論

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

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