單元測試是軟件開發(fā)過程中的第一個防線，旨在檢查回歸和修復錯誤。通過快速執(zhí)行針對函數(shù)或方法的測試，可以輕松識別代碼更改導致的問題，促進了快速故障排除。本文介紹了何時需要或不需要單元測試的場景，強調了當超過 80% 的代碼庫被覆蓋時，單元測試的有效性。此外，它還討論了規(guī)劃和實施單元測試的關鍵步驟，強調了測試框架、可測試性設計和隔離框架的重要性。

單元測試是防范錯誤的第一道防線。這一級別的保護至關重要，因為它為以下測試過程奠定了基礎：集成測試、驗收測試以及最終的手動測試（包括探索性測試）。

在本文中，我將闡明單元測試與其他方法的區(qū)別，并提供示例來說明何時可以或不能沒有單元測試。我們還將涉及自動化測試，它在確保代碼可靠性和質量方面發(fā)揮著重要作用。

單元測試

單元測試的理念是為每個重要的函數(shù)或方法編寫測試。這樣可以快速檢查最近的代碼更改是否導致了回歸，即程序中已經測試過的部分是否出現(xiàn)了錯誤，同時也使檢測和修復此類錯誤變得更加容易。

當單元測試過多時

任何長期項目如果沒有適當?shù)臏y試覆蓋，遲早都注定要從頭開始重寫。單元測試是大多數(shù)項目的必備步驟，但有些情況下可能會忽略此步驟。例如，您正在創(chuàng)建一個用于演示目的的項目。時間表非常緊張。您的系統(tǒng)是硬件和軟件的組合，在項目開始時，最終產品的外觀并不完全清楚。該軟件將在展覽或演示期間運行 1-2 天。在這種情況下，無需實施單元測試。

另一種情況是，您正在制作廣告網站、簡單的 Flash 游戲或橫幅，這些內容涉及復雜的布局、動畫和大量靜態(tài)內容。以上所有內容都用于演示。

如果您正在構建一個簡單的名片網站，其中包含一組靜態(tài) HTML 頁面和一個電子郵件提交表單，則無需進行單元測試。客戶很可能會對此感到滿意，并且不需要任何其他東西。手動檢查和測試所有內容很可能更快。

單元測試實施

在規(guī)劃單元測試時，請記住，您的目標是確保單元測試代碼覆蓋率超過 80%。這意味著在運行單元測試時，至少有 80% 的代碼庫被執(zhí)行。為此，我推薦使用JaCoCo for Java或 Istanbul for JavaScript 等工具。因此，要開始將單元測試納入您的開發(fā)流程，請嘗試執(zhí)行以下步驟。

1.選擇合適的測試框架

選擇適合您需求的框架，而不是重新設計輪子。例如，許多.NET開發(fā)人員使用 MsTest，因為它是 Visual Studio 附帶的，但 NUnit 或 xUnit 可能為您的項目提供更好的功能。

2. 決定測試什么

并非所有代碼都需要測試。簡單、無依賴關系的代碼可能不需要測試，而具有許多依賴關系的復雜代碼可能需要在測試之前進行重構。專注于測試復雜的算法代碼和相互依賴的組件，以確保清晰的交互和集成。

3.保持一致的測試結構

使用排列、行動、斷言 (AAA) 模式來實現(xiàn)清晰度和可維護性。

4. 一次只測試一件事

每個測試應該只驗證代碼的一個方面。對于復雜的流程，將其分解成較小的部分并單獨測試。

5. 使用 Fakes 處理依賴關系

用虛假實現(xiàn)替換真實依賴項，以避免測試不必要的組件。使用存根進行預定義響應，使用模擬進行驗證交互。

6.使用隔離框架

使用 Moq 或 Rhino Mocks 等現(xiàn)有框架來創(chuàng)建模擬和存根，而無需自己編寫。這可以減少錯誤和維護開銷。

7.可測試性設計

最初編寫代碼時要考慮可測試性。使用依賴項注入，避免在方法內直接實例化對象，并盡量減少使用靜態(tài)方法和具有邏輯的構造函數(shù)。

8. 重構遺留代碼

如果要處理無法測試的遺留代碼，請先重構小而易管理的部分，并在編寫單元測試之前用集成和驗收測試覆蓋它們。逐步將此過程擴展到代碼庫的大部分。

自動化測試

這種方法的名稱是不言而喻的：在自動化測試中，測試用例是自動執(zhí)行的。它比手動測試快得多，甚至可以在夜間進行，因為整個過程只需要最少的人為干預。當您需要獲得快速反饋時，這種方法絕對可以改變游戲規(guī)則。然而，與任何自動化一樣，在初始設置階段可能需要大量的時間和財力資源。即便如此，它還是完全值得使用的，因為它將使整個過程更高效，代碼更可靠。

自動化測試實施

第一步是了解項目是否包含測試自動化。您需要確保項目有一個強大的測試自動化框架。反過來，自動化工程師應該熟練掌握工具堆棧（例如，Selenium、Appium、Cypress）并遵循既定的自動化指南。

1. 自動化覆蓋范圍與手動測試的比較

爭取實現(xiàn)高比例的測試用例自動化，理想情況下超過 90%，以最大限度提高效率并減少對手動測試的依賴。

2. 項目概述及自動化實施

自動化測試通常是一個大型項目，涉及多個團隊開發(fā)共享產品，每個團隊都有手動 QA 測試人員。測試側重于前端和后端方面。 

3. 了解項目

首先，我們需要了解產品的用途和用戶。這有助于確定自動化工作的優(yōu)先順序。例如，如果產品服務于企業(yè)，則重點測試法律合規(guī)性和支付交易。對于面向消費者的產品，優(yōu)先考慮卡對卡轉賬和服務支付等關鍵操作。自動化應該全面應用于整個產品，而不僅僅是單個團隊。

4. 確定關鍵利益相關者

熟悉所有利益相關者至關重要，因為與他們互動是必要的。關鍵人物包括：

• 產品所有者：他們是自動化的客戶并定義其要求。

• QA 工程師：他們是自動化工具的最終用戶，他們的滿意度是衡量成功的標準。

• 手動測試負責人：他們幫助組織流程并協(xié)調手動測試。

• 前端開發(fā)主管：影響自動化測試的穩(wěn)定性和質量。

• 采購專家：負責硬件分配，主要用于服務器設備。

5. 了解團隊

收集有關每個團隊項目范圍的信息，無論是涵蓋前端、后端還是兩者。了解 QA 團隊如何測試他們的部分以及他們對自動化的熟悉程度。確定測試挑戰(zhàn)并確定自動化的優(yōu)先領域。

6.制定自動化要求

大多數(shù)情況下，我們采用的是傳統(tǒng)方法，沒有創(chuàng)新的解決方案：

• 編程語言：Java，以方便聘請專家

• 前端測試：使用 Selenium。

• 后端測試：使用REST-assured進行 REST 交互。

• 數(shù)據(jù)庫測試：使用標準 Java 庫

• 自動化測試：選擇 Cucumber 既可以培訓手動 QA 測試人員，又可以降低成本。

• 報告：最后，但并非最不重要的是，使用 Allure 來制作有吸引力且信息豐富的報告。

7. 演示和入門

為所有利益相關者（包括產品負責人、QA 工程師、開發(fā)人員和分析師）進行演示，重點是清晰度。從前端團隊開始，以創(chuàng)建可見的結果。開發(fā) 5-10 個自動化測試，記錄它們，并使用 Allure 顯示結果以獲取圖形報告。說明自動化基礎設施、主要目標和效果，并比較手動和自動化測試。

8. 準備自動化的 UI

為了確保自動化測試的可靠性和穩(wěn)定性，請data-test-id在前端負責人和產品負責人的配合下，集中為 UI 元素添加“ ”屬性。此做法可使測試不受 UI 元素位置或內容變化的影響，從而大大提高測試的可靠性。

9.開發(fā)自動化測試

在自動化測試人員之間分配任務。使用模板創(chuàng)建自動化項目框架。準備用于前端測試的 Cucumber 步驟，使這些步驟可跨項目重復使用，并設置 Selenoid 和 Jenkins。通過設置存儲庫、創(chuàng)建 Jenkins 作業(yè)以及在 Cucumber、Git 和開發(fā)環(huán)境中培訓 QA，將團隊整合到自動化中。 

然后，QA 手動測試人員將編寫自動化測試，這些測試將由自動化工程師審查和集成。Cucumber 的最終步驟開發(fā)將在沖刺的空閑時間進行。在每個沖刺結束時，展示結果并在產品演示中宣布新功能。

結論

如您所見，單元測試和自動化測試是互補的方法。通過每天使用它們來識別缺陷，您可以減少每個階段的回歸測試時間。此外，這將逐漸導致產品更快地投入生產，從而節(jié)省時間和資源。

路由網(www.lu-you.com)您可以查閱其它相關文章！