單元測試是防止錯誤的第一道防線。這種級別的保護至關(guān)重要，因為它為以下測試過程奠定了基礎(chǔ)：集成測試、驗收測試以及最后的手動測試，包括探索性測試。
在本文中，我將闡明單元測試與其他方法的區(qū)別，并舉例說明何時可以或不可以沒有單元測試。我們還將討論自動化測試，它在確保代碼可靠性和質(zhì)量方面發(fā)揮著重要作用。
單元測試
單元測試的想法是為每個重要的函數(shù)或方法編寫測試。這使得它能夠快速檢查最近的代碼更改是否導致了回歸，這意味著已經(jīng)測試過的程序部分中存在錯誤，并且還可以更輕松地檢測和修復(fù)此類錯誤。
當單元測試過多時
任何沒有適當測試覆蓋率的長期項目注定遲早要從頭開始重寫。單元測試是大多數(shù)項目的必備步驟，但在某些情況下可能會忽略此步驟。例如，您正在創(chuàng)建一個用于演示目的的項目。時間表非常艱難。您的系統(tǒng)是硬件和軟件的組合，在項目開始時，并不完全清楚最終產(chǎn)品會是什么樣子。該軟件將在展覽或演示期間運行1-2天。在這種情況下，就沒有必要進行單元測試。
另一種情況是當您在制作廣告網(wǎng)站，或者簡單的Flash游戲，或者橫幅時，其中涉及復(fù)雜的布局、動畫和大量的靜態(tài)內(nèi)容。以上都是為演示服務(wù)的。
如果您正在構(gòu)建一個包含一組靜態(tài) HTML 頁面和一個電子郵件提交表單的簡單名片網(wǎng)站，則不需要進行單元測試。客戶很可能對此感到滿意，并且不再需要任何東西。手動檢查和測試所有內(nèi)容很可能會更快。
單元測試實施
在規(guī)劃單元測試時，請記住您的目標是確保單元測試代碼覆蓋率超過 80%。這意味著在運行單元測試時至少執(zhí)行了 80% 的代碼庫。出于這些目的，我推薦使用JaCoCo for Java或 Istanbul for JavaScript 等工具。因此，要開始將單元測試合并到您的開發(fā)過程中，請嘗試執(zhí)行以下步驟。
1.選擇合適的測試框架
選擇一個適合您需求的框架，而不是重新發(fā)明輪子。例如，許多.NET開發(fā)人員使用 MsTest，因為它隨 Visual Studio 一起提供，但 NUnit 或 xUnit 可能會為您的項目提供更好的功能。
2. 決定測試什么
并非所有代碼都需要測試。簡單、無依賴項的代碼可能不需要測試，而具有許多依賴項的復(fù)雜代碼可能會從測試前的重構(gòu)中受益。專注于測試復(fù)雜的算法代碼和相互依賴的組件，以確保清晰的交互和集成。
3. 保持一致的測試結(jié)構(gòu)
使用排列、執(zhí)行、斷言 (AAA) 模式以獲得清晰性和可維護性。
4. 一次測試一件事
每個測試應(yīng)該僅驗證代碼的一個方面。對于復(fù)雜的流程，將其分解為較小的部分并單獨進行測試。
5. 處理假貨的依賴關(guān)系
用假實現(xiàn)替換真正的依賴項，以避免測試不必要的組件。使用存根進行預(yù)定義響應(yīng)，使用模擬來驗證交互。
6.使用隔離框架
使用 Moq 或 Rhino Mocks 等現(xiàn)有框架來創(chuàng)建模擬和存根，而不是編寫自己的框架。這減少了錯誤和維護開銷。
7. 可測試性設(shè)計
最初編寫代碼時要考慮到可測試性。使用依賴注入，避免在方法內(nèi)直接實例化對象，并盡量減少使用帶有邏輯的靜態(tài)方法和構(gòu)造函數(shù)。
8. 重構(gòu)遺留代碼
如果處理無法測試的遺留代碼，請從重構(gòu)小的、可管理的部分開始，并在編寫單元測試之前用集成和驗收測試覆蓋它們。逐漸將此過程擴展到代碼庫的更大部分。
自動化測試
該方法的名稱是不言自明的：在自動化測試中，測試用例是自動執(zhí)行的。它比手動測試發(fā)生得快得多，甚至可以在夜間進行，因為整個過程需要最少的人為干擾。當您需要獲得快速反饋時，這種方法絕對會改變游戲規(guī)則。然而，與任何自動化一樣，在初始設(shè)置階段可能需要大量時間和財務(wù)資源。即便如此，它還是完全值得使用的，因為它會讓整個過程更加高效，代碼更加可靠。
自動化測試實施
這里的第一步是了解項目是否包含測試自動化。您需要確保項目擁有強大的測試自動化框架。反過來，自動化工程師應(yīng)該精通工具堆棧(例如，Selenium、Appium、Cypress)并遵循既定的自動化指南。
1. 自動化覆蓋率與手動測試的比較
努力實現(xiàn)高比例的測試用例自動化，最好超過 90%，以最大限度地提高效率并減少對手動測試的依賴。
2. 項目概述及自動化實施
自動化測試始終是一個大型項目，涉及多個團隊開發(fā)共享產(chǎn)品，每個團隊中都有手動 QA 測試人員。測試側(cè)重于前端和后端兩個方面。
3. 了解項目
首先，我們需要了解產(chǎn)品的用途及其用戶。這有助于優(yōu)先考慮自動化工作。例如，如果產(chǎn)品為企業(yè)服務(wù)，則重點測試法律合規(guī)性和支付交易。對于面向消費者的產(chǎn)品，優(yōu)先考慮卡間轉(zhuǎn)賬和服務(wù)支付等關(guān)鍵操作。自動化應(yīng)該全面應(yīng)用于整個產(chǎn)品，而不僅僅是單個團隊。
4. 識別關(guān)鍵利益相關(guān)者
熟悉所有利益相關(guān)者至關(guān)重要，因為與他們的互動是必要的。關(guān)鍵人物包括：
· 產(chǎn)品所有者：他們是自動化的客戶并定義其要求。
· QA 工程師：他們是自動化工具的最終用戶，他們的滿意度是衡量成功的標準。
· 手動測試主管：他們幫助組織流程并與手動測試進行協(xié)調(diào)。
· 前端開發(fā)領(lǐng)導：他們影響自動化測試的穩(wěn)定性和質(zhì)量。
· 采購專家：他們負責硬件分配，主要是服務(wù)器設(shè)備。
5.了解團隊
收集有關(guān)每個團隊的項目范圍的信息，無論是涵蓋前端、后端還是兩者。了解 QA 團隊如何測試他們的部分以及他們對自動化的熟悉程度。確定測試挑戰(zhàn)并優(yōu)先考慮自動化領(lǐng)域。
6. 制定自動化要求
在大多數(shù)情況下，我們的目標是采用經(jīng)典方法，而不采用創(chuàng)新解決方案：
· 編程語言：Java，方便招聘專員
· 前端測試：使用 Selenium。
· 后端測試：使用REST-assured進行 REST 交互。
· 數(shù)據(jù)庫測試：選擇標準 Java 庫
· 自動化測試：選擇 Cucumber 既可以培訓手動 QA 測試人員，又可以降低成本。
· 報告：最后但并非最不重要的一點是，使用 Allure 生成有吸引力且內(nèi)容豐富的報告。
7. 演示和入門
為所有利益相關(guān)者(包括產(chǎn)品負責人、QA 工程師、開發(fā)人員和分析師)進行演示，重點是清晰度。從前端團隊開始創(chuàng)建可見的結(jié)果。開發(fā) 5-10 個自動化測試，記錄它們，并使用 Allure 的圖形報告顯示結(jié)果。說明自動化基礎(chǔ)設(shè)施、主要目標和效果，并比較手動和自動化測試。
8. 為自動化準備 UI
為了保證自動化測試可靠穩(wěn)定，data-test-id在前端負責人和產(chǎn)品負責人的配合下，集中為UI元素添加“ ”屬性。這種做法通過將測試與 UI 元素位置或內(nèi)容的變化隔離開來，極大地提高了測試的可靠性。
9. 開發(fā)自動化測試
在自動化測試人員之間分配任務(wù)。使用模板創(chuàng)建自動化項目框架。準備用于前端測試的 Cucumber 步驟，使這些步驟可跨項目重復(fù)使用，并設(shè)置 Selenoid 和 Jenkins。通過設(shè)置存儲庫、創(chuàng)建 Jenkins 作業(yè)以及在 Cucumber、Git 和開發(fā)環(huán)境中培訓 QA，將團隊集成到自動化中。
然后，QA 手動測試人員將編寫自動化測試，并由自動化工程師進行審查和集成。最終的 Cucumber 步驟開發(fā)將在沖刺的空閑時間進行。在每個沖刺結(jié)束時，在產(chǎn)品演示中展示結(jié)果并宣布新功能。
結(jié)論
正如您所看到的，單元測試和自動化測試是互補的方法。通過每天使用它們來識別缺陷，您可以減少每個階段的回歸測試時間。此外，這將逐漸導致產(chǎn)品更快地投入生產(chǎn)，從而節(jié)省時間和資源。
下載文檔
