# 單元測試教程：什么是類型，工具，示例 > 原文： [https://www.guru99.com/unit-testing-guide.html](https://www.guru99.com/unit-testing-guide.html) ## 什么是單元測試？ **單元測試**是一種軟件測試，其中測試軟件的各個單元或組件。 目的是驗證軟件代碼的每個單元是否按預期執行。 單元測試由開發人員在應用程序的開發（編碼階段）中完成。 單元測試隔離一段代碼并驗證其正確性。 單元可以是單獨的功能，方法，過程，模塊或對象。 在 SDLC，STLC，V 模型中，單元測試是集成測試之前完成的第一級測試。 單元測試是 WhiteBox 測試技術，通常由開發人員執行。 不過，在現實世界中，由于時間緊迫或開發人員不愿進行測試，質量檢查工程師還會進行單元測試。 在本教程中，您將學習- * [為什么要進行單元測試？](#2) * [如何進行單元測試](#3) * [單元測試技術](#4) * [單元測試工具](#5) * [測試驅動開發（TDD）&單元測試](#6) * [單元測試神話](#7) * [單元測試優勢](#8) * [單元測試的缺點](#9) * [單元測試最佳做法](#10) ## 為什么要進行單元測試？ 有時，軟件開發人員會嘗試通過進行最少的單元測試來節省時間。 這是一個神話，因為跳過單元測試會導致在應用程序完成后，在[系統測試](/system-testing.html)，[集成測試](/integration-testing.html)甚至 Beta 測試期間，出現更高的[缺陷](/defect-management-process.html)修復成本。 在開發階段進行正確的單元測試可以最終節省時間和金錢。 這是執行單元測試的關鍵原因。 <center> <figure> <figcaption style="display: table;">Unit Testing Levels</figcaption> </figure> </center> 1. 單元測試有助于在開發周期的早期修復錯誤并節省成本。 2. 它有助于開發人員了解代碼庫，并使他們能夠快速進行更改 3. 好的單元測試可以作為項目文檔 4. 單元測試有助于代碼重用。 將您的代碼**和**都遷移到新項目中。 調整代碼，直到測試再次運行。 ## 如何進行單元測試 單元測試有兩種類型 * 手冊 * 自動化的 單元測試通常是自動化的，但仍然可以手動執行。 軟件工程不偏向于另一方，但自動化是首選。 手動進行單元測試的方法可以使用分步指導文檔。 在自動方法下- * 開發人員在應用程序中編寫一段代碼只是為了測試功能。 他們稍后將注釋掉，并最終在部署應用程序時刪除測試代碼。 * 開發人員還可以隔離功能以對其進行更嚴格的測試。 這是一種更徹底的單元測試實踐，其中涉及將代碼復制和粘貼到其自身的測試環境中，而不是自然環境中。 **隔離代碼有助于揭示被測試代碼與產品中其他單元或數據空間**之間的不必要依賴關系。 然后可以消除這些依賴性。 * 編碼人員通常使用 UnitTest Framework 來開發自動化測試用例。 開發人員使用自動化框架將標準編碼到測試中，以驗證代碼的正確性。 在執行測試用例期間，框架記錄失敗的測試用例。 許多框架還將自動標記并報告這些失敗的測試案例。 根據故障的嚴重程度，框架可能會停止后續測試。 * 單元測試的工作流程是 1）創建測試用例 2）復查/返工 3）基線 4）執行測試用例。 ## 單元測試技術 聯合測試中使用的代碼覆蓋率技術如下： * 聲明范圍 * 決策范圍 * 分行覆蓋 * 條件覆蓋 * 有限狀態機覆蓋率 有關更多信息，請參見 [https://www.guru99.com/code-coverage.html](/code-coverage.html) ## 單元測試示例：模擬對象 單元測試依賴于創建的模擬對象來測試尚不屬于完整應用程序的代碼部分。 模擬對象將填補程序缺少的部分。 例如，您可能具有一個需要尚未創建的變量或對象的函數。 在單元測試中，這些將以模擬對象的形式解決，這些對象僅出于在該部分代碼上進行單元測試的目的而創建。 ## 單元測試工具 有幾種自動化工具可用于協助單元測試。 我們將在下面提供一些示例： 1. [Junit](/junit-tutorial.html) ：Junit 是可免費使用的 Java 編程語言測試工具。 它提供斷言以標識測試方法。 該工具首先測試數據，然后將其插入代碼段。 2. [NUnit](https://nunit.org/) ：NUnit 被廣泛用于所有.net 語言的單元測試框架。 它是一個開放源代碼工具，允許手動編寫腳本。 它支持可以并行運行的數據驅動測試。 3. [JMockit](http://jmockit.github.io/index.html) ：JMockit 是開源的單元測試工具。 它是具有行和路徑指標的代碼覆蓋工具。 它允許帶有記錄和驗證語法的模擬 API。 該工具提供線覆蓋率，路徑覆蓋率和數據覆蓋率。 4. [EMMA](http://emma.sourceforge.net/) ：EMMA 是一個開源工具包，用于分析和報告用 Java 語言編寫的代碼。 Emma 支持覆蓋類型，例如方法，行，基本塊。 它基于 Java，因此它沒有外部庫依賴關系，并且可以訪問源代碼。 5. [PHPUnit](https://phpunit.de/) ：PHPUnit 是 PHP 程序員的單元測試工具。 它只占用一小部分稱為單元的代碼，并分別測試每個單元。 該工具還允許開發人員使用預定義斷言方法來斷言系統以某種方式運行。 這些只是一些可用的單元測試工具。 還有很多，尤其是對于 C 語言和 Java，但是無論使用哪種語言，您都一定會找到滿足您的編程需求的單元測試工具。 ## 測試驅動開發（TDD）&單元測試 TDD 中的單元測試涉及測試框架的廣泛使用。 為了創建自動化的單元測試，使用了單元測試框架。 單元測試框架不是 TDD 獨有的，但對于它來說是必不可少的。 下面我們看一下 TDD 帶給單元測試領域的一些內容： * 在代碼之前編寫測試 * 高度依賴測試框架 * 應用程序中的所有類均經過測試 * 快速簡便的集成成為可能 ## 單元測試神話 **誤區：**這需要時間，而且我總是安排得太久了。 我不需要單元測試。 就其本質而言，神話是錯誤的假設。 這些假設導致如下惡性循環：  事實是，單元測試可以提高開發速度。 程序員認為集成測試將捕獲所有錯誤，并且不執行單元測試。 單元集成后，很容易找到并修復的非常簡單的錯誤將花費很長時間來跟蹤和修復。 ## 單元測試優勢 * 希望了解單元提供什么功能以及如何使用它的開發人員可以查看單元測試，以基本了解單元 API。 * 單元測試允許程序員稍后重構代碼，并確保模塊仍然正常工作（即回歸測試）。 該過程是為所有功能和方法編寫測試用例，以便每當更改導致故障時，都可以快速識別并修復它。 * 由于單元測試的模塊化性質，我們可以測試項目的各個部分，而無需等待其他部分完成。 ## 單元測試的缺點 * 不能期望單元測試捕獲程序中的每個錯誤。 即使在最簡單的程序中，也無法評估所有執行路徑 * 本質上，單元測試集中于代碼單元。 因此，它無法捕獲集成錯誤或廣泛的系統級錯誤。 建議將單元測試與其他測試活動結合使用。 ## 單元測試最佳做法 * 單元測試用例應獨立。 如果需求有任何增強或變化，則單元測試用例不應受到影響。 * 一次僅測試一個代碼。 * 遵循清晰一致的命名約定，以進行單元測試 * 如果任何模塊中的代碼發生更改，請確保該模塊具有相應的單元[測試用例](/test-case.html)，并且該模塊在更改實現之前通過測試 * 在進行 SDLC 的下一階段之前，必須修復在單元測試期間發現的錯誤。 * 采用“測試作為您的代碼”方法。 未經測試而編寫的代碼越多，檢查錯誤的路徑就越多。  **摘要** * 單元測試定義為一種軟件測試，其中測試軟件的各個單元或組件。 * 如您所見，單元測試可能涉及很多內容。 根據被測試的應用程序以及所使用的測試策略，工具和理念，它可能很復雜，也可能很簡單。 在某種程度上，始終必須進行單元測試。 可以肯定的。