?
?

??作者簡介：博主是一位測試管理者，同時也是一名對外企業(yè)兼職講師。
??主頁地址：【Austin_zhai】
??目的與景愿：旨在于能幫助更多的測試行業(yè)人員提升軟硬技能，分享行業(yè)相關最新信息。
??聲明：博主日常工作較為繁忙，文章會不定期更新，各類行業(yè)或職場問題歡迎大家私信，有空必回。

?
?

1. 目的

??web自動化測試作為軟件自動化測試領域中繞不過去的一個“香餑餑”，通常都會作為廣大測試從業(yè)者的首選學習對象，相較于C/S架構的自動化來說，B/S有著其無法忽視的諸多優(yōu)勢，從行業(yè)發(fā)展趨、研發(fā)模式特點、測試工具支持，其整體的完整生態(tài)已經遠遠超過了C/S架構方面的測試價值。

??在我們所熟知的自動化測試過程中，除了測試同學之外還有著另外一個非常重要的角色，開發(fā)。我們的被測對象的“親生父母”，那么在自動化測試開展的過程中，如何才能顯著提升被測對象的質量與健壯性呢，今天我們就來講講與之息息相關的兩個開發(fā)方法，BDD與TDD。

?
?

2. BDD

??BDD也就是我們常說的行為驅動開發(fā)(Behavior-Driven Development)，它是一種基于用戶行為的開發(fā)方法，強調以用戶需求為核心，用自然語言描述用例場景，并在此基礎上進行開發(fā)和測試。那么在BDD的行為模式下就需要開發(fā)人員與產品人員進行緊密的合作，將用戶故事和場景描述轉化為可執(zhí)行的測試用例。這樣可以確保軟件的功能符合用戶需求，同時也有助于產品人員更好地理解軟件開發(fā)過程。從上面我們不難看出這個開發(fā)的行為模式下，開發(fā)不是拿到產品需求就開始設計概設、詳設就開始開發(fā)工作的，基于產品的需求之上還要求開發(fā)要參照產品與用戶的行為與需求，重點根據以用戶行為為中心而設計的故事進行側重開發(fā)。我們在BDD模式下將產品故事成為測試用例，而這個測試用例則是需要產品、開發(fā)、測試共同進行設計、編寫與審核的，這個與我們日常測試活動中所涉及的工作流程會有所不同，所以對于三個團隊的緊密合作與溝通要求水準會比較高。

?

2.1 工作流程

??對于BDD模式下項目活動，這個大致的主線與一般的開發(fā)模式相同，只不過在每個階段的執(zhí)行過程中會有著其獨特的特征存在并左右項目的質量優(yōu)良與否。接下來我們就一起來看一看該模式下的一些基礎工作流程。

?

2.1.1 需求理解

??開發(fā)團隊、測試團隊和產品團隊需要深入理解用戶的需求和期望，包括功能需求、行為規(guī)范等。這包括與需求人員的討論、用戶故事編寫和使用場景描述等。

2.1.2 規(guī)范定義

??圍繞用戶需求，開發(fā)團隊與產品團隊、測試團隊一起定義可執(zhí)行的用戶行為規(guī)范。這些規(guī)范用自然語言描述系統的行為和期望結果，一般采用類似于Gherkin語言的格式進行規(guī)范與編寫。

2.1.3 用例編寫

??測試團隊根據行為規(guī)范編寫測試用例，將其轉化為可執(zhí)行的測試腳本。測試用例描述了具體的場景和期望結果，用于驗證系統的行為是否符合預期。測試用例應該具有可讀性和可理解性，以便業(yè)務人員能夠理解和參與討論。

2.1.4 測試執(zhí)行

??測試團隊使用適當的自動化測試框架和工具，將測試用例轉化為可執(zhí)行的自動化測試腳本。這些腳本可以模擬用戶的行為，與系統交互并驗證行為是否符合規(guī)范。然后開始執(zhí)行這些測試腳本，至于是否放在開發(fā)本地還是CI環(huán)境中都可以。

2.1.5 后續(xù)優(yōu)化

??根據測試結果和反饋，測試團隊進行迭代和改進，修復問題并改進系統的行為。這包括與產品團隊、開發(fā)團隊的協作和討論，以確保軟件開發(fā)朝著正確的方向進行。

?

??從上面的基礎流程上來看，大家不難發(fā)現，在很多的階段中測試團隊都擔任了非常重要的角色，不僅僅要和產品與開發(fā)團隊保持高度的通過與合作頻率，更需要主導大部分的流程工作內容。所以BDD的模式下對于產品的需求與用戶行為有著很強的針對性，相較于一般的測試模式，BDD模式在需求理解、溝通和測試用例編寫方面具有較為明顯的優(yōu)勢，通過強調共同理解、用戶需求驅動和自然語言描述的測試用例，提高了團隊合作和軟件質量。另外該模式對于自動化測試持續(xù)改進與優(yōu)化迭代有很好的兼容性，所以也主要出現在團隊的自動化測試活動中。

?

2.2 用例的編寫

??故事的編寫（用例）是BDD中極其重要的一步，可以說沒有一個設計完整的故事，后續(xù)就很難高質量的將產品需求覆蓋完整，開頭方向都錯了后續(xù)就更加不要指望可以高效高質的完成質量保障工作了。

??前面也介紹過了，BDD模式下的故事編寫方式一般為類似Gherkin語法的方式，其實可以理解為你將某一個功能的應用場景設計為了一個簡單的故事，故事里面會將所有的前情與條件描述清楚，然后根據條件與劇情發(fā)展的不同而達成不同的結局，就好像在拍一部電影一樣。那么下面就由博主來為大家描述一個簡單的故事場景（產品功能使用場景）。

??在金融行業(yè)中我們經常會接觸到需要購買境外基金的情況，那么這樣的一個場景我們在BDD模式下應該如何進行用例的編寫呢？

場景：普通用戶進行境外基金購買
?
場景描述： 作為一位投資者，用戶希望能夠成功購買境外基金，以便將資金投資于跨境投資機會。
?
Given：
用戶已登錄到其投資賬戶；
用戶已完成合規(guī)認證，具備購買境外基金的資格；
賬戶余額足夠購買所選境外基金；
目標基金的代碼為 【ABC456】，屬于美國市場。
?
When：
在基金市場頁面，用戶選擇了境外基金 【ABC456】；
用戶輸入了購買金額 “2000”；
用戶選擇了購買貨幣為人民幣（CNY）；
用戶點擊購買按鈕。
?
Then：
用戶應該看到購買確認頁面顯示基金的詳細信息，包括名稱、代碼、購買金額和貨幣類型；
用戶確認購買信息無誤后，點擊確認按鈕；
系統應該跳轉到境外基金購買流程，并提供用戶需要提供的信息；
用戶按照指引輸入和確認所需的個人身份信息和資金來源信息；
系統應該顯示購買成功的提示信息，并更新用戶的投資賬戶余額；
用戶的投資賬戶余額應該減少購買金額 “2000”；
用戶的投資賬戶的交易記錄中應該出現一條購買境外基金的記錄，包括基金名稱、代碼、購買金額和貨幣類型。

??以上就是一個基礎的BDD模式下的產品故事（測試用例），大家可以看到，它其實就是通過一些關鍵字（given、when、then）來清晰地描述了測試的場景、條件和預期結果。那么有了這個測試團隊可以基于測試用例編寫自動化測試腳本，并執(zhí)行驗證功能的正確性和流程的完整性。

?

2.3 腳本實現

??那么基于以上所設計的測試用例，我們就可以在編寫腳本的過程中按照實現定好的劇本走向來設計業(yè)務流程的走向與其測試點。

??具體的整體腳本就不演示了，編寫所需要的技巧已經在前幾篇文章中介紹過了，這里就直接演示如何根據測試用例來實現測試腳本。

class TestPurchaseOverseasFund(unittest.TestCase):
    
    def setUp(self):
        self.driver = webdriver.Chrome()  
        self.driver.implicitly_wait(10) 

    def tearDown(self):
        self.driver.quit()

    def test_purchase_overseas_fund(self):
        # 購買境外基金的測試用例
        
        # Given
        self.driver.get("https://example.com")  # 替換為基金交易平臺的URL
        self.driver.find_element_by_id("login_username").send_keys("your_username")  # 替換為用戶名輸入框的ID
        self.driver.find_element_by_id("login_password").send_keys("your_password")  # 替換為密碼輸入框的ID
        self.driver.find_element_by_id("login_button").click()  # 替換為登錄按鈕的ID
        self.driver.find_element_by_id("balance").text = "5000"  # 替換為賬戶余額顯示元素的ID或選擇器
        
        # When
        self.driver.find_element_by_id("fund_market").click()  # 替換為基金市場入口的ID
        self.driver.find_element_by_id("fund_code_input").send_keys("ABC456")  # 替換為基金代碼輸入框的ID
        self.driver.find_element_by_id("purchase_amount_input").send_keys("2000")  # 替換為購買金額輸入框的ID
        self.driver.find_element_by_id("currency_dropdown").click()  # 替換為貨幣選擇下拉菜單的ID
        self.driver.find_element_by_id("currency_cny").click()  # 替換為人民幣選項的ID
        self.driver.find_element_by_id("purchase_button").click()  # 替換為購買按鈕的ID

        # Then
        self.assertTrue(self.driver.find_element_by_id("purchase_confirmation").is_displayed())  # 替換為購買確認頁面元素的ID或選擇器
        self.driver.find_element_by_id("confirm_button").click()  # 替換為確認按鈕的ID
        self.assertTrue(self.driver.find_element_by_id("success_message").is_displayed())  # 替換為購買成功提示信息的ID或選擇器
        self.assertEqual(self.driver.find_element_by_id("balance").text, "3000")  # 替換為賬戶余額顯示元素的ID或選擇器
        self.assertTrue(self.driver.find_element_by_id("transaction_record").is_displayed())  # 替換為交易記錄元素的ID或選擇器

if __name__ == '__main__':
    unittest.main()

?
?

3. TDD

??TDD相信做測試的大家都應該不陌生，測試驅動開發(fā)(Test-Driven Development)，這種開發(fā)的行為模式的核心主旨就是要求測試同學在開發(fā)人員做功能實現的工作之前就完成測試用例的編寫，將測試用例做為代編寫代碼的依照與參考，完成接下去的工作。正所謂字如其名，測試驅動開發(fā)。

?

3.1 工作流程

??相較于BDD的開發(fā)行為模式，TDD的變化其實非常大，這個可以說在某些特定環(huán)節(jié)中是基本顛覆了我們日常的項目流程順序，也正因如此，排除團隊與其他不可控因素的影響，TDD模式下產出的產品與項目，其質量與需求完成度可以說是相當之高了。

3.1.1 編寫用例

??對，你沒看錯，在這個模式下，一上來就要編寫測試用例，但對于大多數測試同學來說，這個卻應該不是難事，基于需求編寫測試用例早已不是什么稀罕事了。在開發(fā)人員進行代碼編寫的工作前，測試同學就需要早早的開始用例的編寫，結束的節(jié)點也差不多是開發(fā)開始之前再早些時候。而測試用例的內容則與普通測試流程中所需要設計的用例一致。

3.1.2 執(zhí)行用例

??看到這里，大家是不是覺得更離譜了？沒有任何代碼與程序的前提下為什么要執(zhí)行測試用例呢？但我想說的是，這是一個不可或缺的驗證階段，檢驗的當然不是被測對象，而是測試用例本身，確保用例本身可以正確的執(zhí)行。

3.1.3 編寫代碼

??依照對應功能模塊的測試用例，開發(fā)人員開始編寫對應的代碼，這里的目標是編寫最少量的代碼，以使得當前的測試用例能夠通過。這里需要區(qū)別開的是，此階段的代碼編寫通常關注于滿足測試用例的需求，而不是關注整體的實現。

3.1.4 執(zhí)行用例

??基于編譯完的功能再次執(zhí)行測試用例，驗證當前編寫的功能代碼是否通過測試。如果測試用例通過，意味著功能代碼滿足了需求。如果測試用例失敗，說明功能代碼存在問題，需要進行修復。其實此步驟的執(zhí)行流程與普通階段的基本一致。

3.1.5 代碼重構

??在功能代碼通過測試之后，可以對代碼進行重構。重構是指對代碼的結構、設計和可讀性進行優(yōu)化，以改進代碼的質量和可維護性，而不改變代碼的功能。重構后需要再次運行測試用例，確保代碼重構沒有引入新的錯誤。

3.1.6 重復迭代

??之后的動作基本就是重復以上的這些流程了，以規(guī)定好的功能為范圍，進行測試驅動開發(fā)。

??其實可以看出TDD的工作流程是一個持續(xù)循環(huán)的過程，每個功能都會經歷一輪完整的測試、開發(fā)、驗證和重構。通過頻繁運行測試用例，其優(yōu)勢就是開發(fā)人員可以盡早發(fā)現問題并及時修復，從而保證代碼的正確性和可靠性。

?

3.2 用例與代碼實現

??用例的寫法與普通流程的一致，如果需要了解普通的黑盒用例寫法，大家可以翻看之前的測試用例設計相關博文，測試腳本也是類似，不再展開討論。

?
?

4. 后話

??無論是BDD也好，還是TDD也罷，并沒有所謂的最好的開發(fā)行為模式，真正有效的針對各自團隊與產品、公司現狀而使用以上兩種開發(fā)行為模式才是正道。如果你的項目需求明確、關注用戶行為與產品業(yè)務價值的權重比較高，而團隊之間又可以高度緊密合作在一起的，BDD模式就是你們產研的不二之選；另一方面，如果你的項目需求較為模糊或變動頻繁、業(yè)務功能復雜且沒有什么試錯的空間、同時又需要業(yè)務代碼又較強的維護性和質量，那么就可以大膽的嘗試TDD。當然兩者的使用場景不單單如此，更有甚者，將兩者結合使用，據項目需求和團隊特點進行靈活選擇和調整。重要的還是在于如何理解并加之在日常工作中真正的實踐總結和反復優(yōu)化。文章來源地址http://www.zghlxwxcb.cn/news/detail-454162.html

到了這里，關于web自動化測試進階篇02 ——— BDD與TDD的研究實踐的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！