單元測試

單元測試（也稱為單元測試或組件測試）是一種軟件測試，用于檢查計算機程序的各個可定義部分（例如，選定的代碼部分、模塊、子程序、單元或類）。 這些通常由軟件開發者自己進行的軟件測試的目的是證明它們的技術可操作性和技術（部分）結果的正確性。

元測試也被理解為測試的早期階段，測試軟件內部最詳細的組件。根據軟件驗證和 驗證計劃單元測試僅對于關鍵性較低的模塊（發生錯誤時對用戶造成的不便很少）是不必要的。

由于單元級別的算法通常只有有限的復雜性，并通過明確定義的接口激活，因此可以用相對較少的測試用例對其進行全面測試。 這是后續測試級別集成測試的先決條件，以便能夠將測試用例與更大的功能部分或整個應用程序的集成交互對齊； 因此，特定于模塊的詳細星座可以限制為隨機樣本，從而xxx減少所需的測試用例數量。

為了進行比較：只有在確保其各個部分的功能時，才對設備進行整體測試。

元測試是白盒測試。 這意味著在定義測試用例時，要測試的源代碼是已知的。 軟件的規格僅用于確定目標結果。 原則上，所有源代碼部分必須至少執行一次。 語句覆蓋、分支覆蓋或路徑覆蓋可以幫助確定至少在理論上需要哪些測試用例（請參閱面向控制流的測試程序）。 在實踐中，人們通常會嘗試用盡可能少的測試用例來達到設定的覆蓋率目標，因為所有單元測試也必須持續維護。

通常所有的元測試都是基于統一的基本結構。 首先 (1) 初始化初始狀態，然后 (2) 執行要測試的操作，最后 (3) 將實際結果與從規范導出的目標值進行比較。 測試框架為這些比較提供斷言方法。

單元測試測試孤立的模塊，基本上不與其他模塊交互。 因此，其他模塊或外部組件，如數據庫、文件、后端系統或子程序，必須或可以通過單元測試中的輔助對象來模擬，只要被測試的模塊（測試項或測試對象）有此要求。

可用于此目的的輔助對象基本上可以根據

• 是否替換調用模塊（測試是調用模塊；替換對象稱為“存根”），
• 它們是否替換了待測模塊/子程序的調用（環境）（測試是子程序，模擬調用的程序稱為“驅動程序”）。

輔助例程如何完全映射原始行為，例如在合理性檢查或返回響應代碼時，必須通過適當的測試用例設計來考慮。 特別是在面向對象的編程語言中，更進一步，可以在這方面區分更詳細的幫助對象類別，請參閱模擬對象。

這樣的輔助對象是 z，作為代理實現，通過控制反轉的方式提供。 與所有模塊都已集成相比，通常可以更容易地測試模塊，因為在這種情況下，必須考慮各個模塊的依賴性，并在測試處理中加以考慮。 如果測試實際需要的其他組件尚不可用，這種孤立的單元測試也是可能的。

所有組件在其原始版本中的完整測試是稍后進行的集成和系統測試的主題 - 在單元測試中未識別的錯誤（例如，由于測試對象和輔助例程的相同錯誤假設）應該被發現。

根據契約設計原則，元測試不測試方法的內部結構，而只測試其外部效果（返回值、輸出、狀態變化、到保險絲）。 如果檢查方法的內部細節（這稱為白盒測試），即使外部影響沒有改變，測試也可能失敗。 因此，通常推薦所謂的黑盒測試，即只檢查外部影響。

隨著敏捷軟件開發方法的傳播，尤其是測試驅動開發，盡可能自動地運行元測試已經變得很普遍。 為此，通常在 JUnit 等測試框架的幫助下編寫測試程序。 測試框架用于調用各個測試類并運行它們的組件測試。 大多數測試框架都提供測試結果的圖形摘要。

自動化元測試的優點是運行起來簡單且成本低廉，并且可以快速發現新的程序錯誤。

• 平均而言，30% 的錯誤可以使用自動化單元測試檢測出來。 使用測試驅動開發時，平均可以避免 45%，最多 85% 的錯誤。
• 在開發過程中通過元測試檢測到錯誤。 根據十法則，單元測試避免的錯誤成本是后期測試級別的許多倍，這使得單元測試成為最有效的測試級別。
• 如果出現錯誤，可以更精確地縮小范圍，從而更快地找到并糾正錯誤。
• 測試實現了動態文檔的目的。 結合有意義的對象命名（干凈的代碼），可以省略額外的文檔措施。
• 因為單個模塊只有少數可能的代碼執行路徑，所以與其他類型的測試相比，要考慮的可能組合執行路徑要少得多。 更高級別的測試可以隨機關注最重要的執行路徑，從而顯著減少。
• 因為只測試單個模塊，單元測試可以執行得更快，通常快幾個數量級，因此比其他類型的測試更頻繁（或連續）。
• 通過測試保護錯誤將防止該錯誤再次發生。
• 錯誤的減少導致大中型軟件項目的開發速度優勢。
• 由于必須避免依賴才能啟用元測試，因此可以相對快速地更改代碼。 這樣可以更快地響應不斷變化的需求。
• 由于自動化測試比手動測試快幾個數量級，因此測試時間顯著縮短。 這意味著可以更快地完成開發階段并縮短發布周期。

• 實現新功能時，不僅要實現功能，還要準備/定義相關測試。 這通常會導致多項實施工作。
• 如果發生更改，不僅更改后的功能而且相關的測試都必須進行調整。 因此，測試通常是一個障礙，特別是在開發原型時，代碼庫變化很快。
• 因為測試使用了該功能，所以在 IDE 中更難查看某個功能是否不再在其他地方使用并因此可以刪除。
• 如果測試相互依賴（例如，由于共享測試數據），對代碼庫的個別更改可能會影響大量測試，這會隨著代碼庫的大小呈指數級增加更改工作量。

元測試（與任何測試一樣）不能保證或證明被測試的模塊沒有錯誤，僅支持它。 元測試的局限性必然是只能發現所使用的測試能夠檢測到的那些錯誤。 因此，測試“綠色”的軟件組件不一定沒有錯誤。

測試“綠色”的代碼的特性以及對這個結果的渴望可能導致實際（無意識地）只進行這么多測試，直到所有測試都是“綠色”。 將沒有失敗測試的模塊視為無錯誤是測試驅動開發實踐中的謬誤。

為了獲得足夠的測試覆蓋率，在創建測試用例之前應用重構措施可能是值得的。