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

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

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

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

TDD與BDD

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

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

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

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

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

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

BDD的好處是什么？

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

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

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

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

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

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

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

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

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

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

如何減輕BDD的技術(shù)負(fù)擔(dān)

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

減少通過使用BDD進(jìn)行API測試來實現(xiàn)測試代碼的技術(shù)障礙

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

請考慮以下示例：

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

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

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

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

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

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

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

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

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

降低與測試自動化和BDD相關(guān)的成本

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

結(jié)論

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

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