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

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

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

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

TDD與BDD

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

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

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

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

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

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

BDD的好處是什么？

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

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

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

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

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

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

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

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

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

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

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

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

減少通過(guò)使用BDD進(jìn)行API測(cè)試來(lái)實(shí)現(xiàn)測(cè)試代碼的技術(shù)障礙

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

請(qǐng)考慮以下示例：

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

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

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

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

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

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

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

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

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

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

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

結(jié)論

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

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