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

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

單元測試

單元測試的想法是為每個重要的函數或方法編寫測試。這使得它能夠快速檢查最近的代碼更改是否導致了回歸，這意味著已經測試過的程序部分中存在錯誤，并且還可以更輕松地檢測和修復此類錯誤。

當單元測試過多時

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

另一種情況是當您在制作廣告網站，或者簡單的Flash游戲，或者橫幅時，其中涉及復雜的布局、動畫和大量的靜態(tài)內容。以上都是為演示服務的。

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

單元測試實施

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

1.選擇合適的測試框架

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

2. 決定測試什么

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

3. 保持一致的測試結構

使用排列、執(zhí)行、斷言 (AAA) 模式以獲得清晰性和可維護性。

4. 一次測試一件事

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

5. 處理假貨的依賴關系

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

6.使用隔離框架

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

7. 可測試性設計

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

8. 重構遺留代碼

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

自動化測試

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

自動化測試實施

這里的第一步是了解項目是否包含測試自動化。您需要確保項目擁有強大的測試自動化框架。反過來，自動化工程師應該精通工具堆棧(例如，Selenium、Appium、Cypress)并遵循既定的自動化指南。

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

努力實現高比例的測試用例自動化，最好超過 90%，以最大限度地提高效率并減少對手動測試的依賴。

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

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

3. 了解項目

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

4. 識別關鍵利益相關者

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

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

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

· 手動測試主管：他們幫助組織流程并與手動測試進行協調。

· 前端開發(fā)領導：他們影響自動化測試的穩(wěn)定性和質量。

· 采購專家：他們負責硬件分配，主要是服務器設備。

5.了解團隊

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

6. 制定自動化要求

在大多數情況下，我們的目標是采用經典方法，而不采用創(chuàng)新解決方案：

· 編程語言：Java，方便招聘專員

· 前端測試：使用 Selenium。

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

· 數據庫測試：選擇標準 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é)省時間和資源。