[轉] 單元測試詳解

1.什麼是單元測試(Unit Testing)？

測試(Testing)這個詞很容易理解，那麼什麼是單元(Unit)呢？ 一個單元指的是應用程序中可測試的最小的一組源代碼。一組源代碼可測試，通常要求其有明確的輸入和輸出。所以，通常來說，源代碼中包含明確的輸入和輸出的 每個方法被認爲是一個可測試的單元。注意，這裏指的輸出，並不侷限於方法的返回值或對輸入參數的改變，而包括了方法的執行過程當中，改變的任何數據。

單元在程序裏能夠簡單的理解爲一個模塊，一個方法。單元測試也就是在完成每一個模塊後都進行的測試。從確保每一個模塊沒有問題，從而提升總體的程序質量。

2.單元測試的目的？

單元測試的目的，是將應用程序的全部源代碼，隔離成最小的可測試的單元，保證每一個單元的正確性。理想狀況下，若是每一個單元都能保證正確，就能保證應用程序總體至關程度的正確性。

 

另外一方面，單元測試也是一種特殊類型的文檔，相對於書面的文檔，測試腳本自己每每就是對被測試代碼的實際的使用代碼，對於幫助開發人員理解被測試單元的使用是至關有幫助的。

3.單元測試的手段

測試分爲黑盒測試白盒測試。

黑盒測試：只知道WHAT下進行的測試，黑盒測試通常由測試人員進行。

單元測試是一種白盒測試，目的是驗證所設計的類是否符合需求。

在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。

 

白盒測試：知道被測軟件如何(HOW)完成功能和完成什麼樣的功能(WHAT)，白盒測試通常由開發人員完成。

4.如何進行單元測試

1）隔離

要進行單元測試，首先就是要將被測試的單元，與全部外部依賴進行隔離。通常來說，進行隔離主要有兩種可選的技術，一種叫Stub，一種叫Mock。對於兩個的區別和取捨，Martin Fowler有一個很經典的文章：Mocks Aren't Stubs。簡單來講，若是要Stub或Mock一個方法，Stub指的是，爲了測試，手動寫一個相同簽名的方法，根據個人測試須要，對給定的輸入參數，返回必定的輸出；而Mock則藉助必定的框架組件，自動生成一個方法的實現，對於給定的輸入，返回必定的輸出。固然，所謂的Stub或Mock，並不單指對方法，尤爲是在面向對象編程中，也能夠是對屬性，對對象或者對接口，等等。

爲了方便實現隔離，對軟件設計和開發的一個潛在的激勵是，軟件模塊的設計人員和開發人員，不得不時時思考，在當前語言支持的各類特性的條件下，如何使得所寫的代碼，可以被方便的被隔離。雖然這看起來很像是一種限制，可是和軟件設計的SOLID原則，實際上是不謀而合的，所以，也就何嘗不是一個優勢了。

5.單元測試的內容

模塊接口測試：對經過被測模塊的數據流進行測試。爲此，對模塊接口，包括參數表、調用子模塊的參數、全程數據、文件輸入/輸出操做都必須檢查。

局部數據結構測試：設計測試用例檢查數據類型說明、初始化、缺省值等方面的問題，還要查清全程數據對模塊的影響。

路徑測試：選擇適當的測試用例，對模塊中重要的執行路徑進行測試。對基本執行路徑和循環進行測試能夠發現大量路徑錯誤。

錯誤處理測試：檢查模塊的錯誤處理功能是否包含有錯誤或缺陷。例如，是否拒毫不合理的輸入;出錯的描述是否難以理解、是否對錯誤定位有誤、是否出錯緣由報告有誤、是否對錯誤條件的處理不正確;在對錯誤處理以前錯誤條件是否已經引發系統的干預等。

邊界測試：要特別注意數據流、控制流中恰好等於、大於或小於肯定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。

此外，若是對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以肯定最壞狀況下和平均意義下影響模塊運行時間的因素。這類信息對進行性能評價是十分有用的。

6.單元測試的步驟

一般單元測試在編碼階段進行。在源程序代碼編制完成，通過評審和驗證，確認沒有語法錯誤以後，就開始進行單元測試的測試用例設計。利用設計文檔，設計能夠驗證程序功能、找出程序錯誤的多個測試用例。對於每一組輸入，應有預期的正確結果。

模塊並非一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯繫，用一些輔助模塊去模擬與被測模塊相聯繫的其它模塊。這些輔助模塊分爲兩種：

驅動模塊：至關於被測模塊的主程序。它接收測試數據，把這些數據傳送給被測模塊，最後輸出實測結果。

樁模塊：用以代替被測模塊調用的子模塊。樁模塊能夠作少許的數據操做，不須要把子模塊全部功能都帶進來，但不容許什麼事情也不作。

若是一個模塊要完成多種功能，且以程序包或對象類的形式出現，例如Ada中的包，Modula中的模塊，C++中的類。這時能夠將這個模塊當作由幾個小程序組成。對其中的每一個小程序先進行單元測試要作的工做，對關鍵模塊還要作性能測試。對支持某些標準規程的程序，更要着手進行互聯測試。有人把這種狀況特別稱爲模塊測試，以區別單元測試。

6.測試的重要性

單元測試是軟件測試的基礎，所以單元測試的效果會直接影響到軟件的後期測試，最終在很大程度上影響到產品的質量。從以下幾個方面就能夠看出單元測試的重要性在何處。

時間方面：如 果認真的作好了單元測試，在系統集成聯調時很是順利，所以會節約不少時間，反之那些因爲由於時間緣由不作單元測試或隨便作作的則在集成時總會遇到那些本應 該在單元測試就能發現的問題，而這種問題在集成時遇到每每很難讓開發人員預料到，最後在苦苦尋覓中才發現這是個很低級的錯誤而在悔恨本身時已經浪費了不少 時間，這種時間上的浪費一點都不值得，正所謂得不償失。

測試效果：根 據以往的測試經驗來看，單元測試的效果是很是明顯的，首先它是測試階段的基礎，作好了單元測試，在作後期的集成測試和系統測試時就很順利。其次在單元測試 過程當中能發現一些很深層次的問題，同時還會發現一些很容易發現而在集成測試和系統測試很難發現的問題。再次單元測試關注的範圍也特殊，它不只僅是證實這些 代碼作了什麼，最重要的是代碼是如何作的，是否作了它該作的事情而沒有作不應作的事情。

測試成本：在單元測試時某些問題就很容易發現，若是在後期的測試中發現問題所花的成本將成倍數上升。好比在單元測試時發現1個問題須要1個小時，則在集成測試時發現該問題須要2個小時，在系統測試時發現則須要3個小時，同理還有定位問題和解決問題的費用也是成倍數上升的，這就是咱們要儘量早的排除儘量多的bug來減小後期成本的因素之一。

產品質量：單元測試的好與壞直接影響到產品的質量，可能就是因爲代碼中的某一個小錯誤就致使了整個產品的質量下降一個指標，或者致使更嚴重的後果，若是咱們作好了單元測試這種狀況是能夠徹底避免的。

綜上所述，單元測試是構築產品質量的基石，咱們不要由於節約單元測試的時間不作單元測試或隨便作而讓咱們在後期浪費太多的不值得的時間，咱們也不肯意由於因爲節約那些時間致使開發出來的整個產品失敗或重來!

7.如何寫好測試代碼的Guidelines：

1）有測試總比沒測試好

2）測試儘量的小而快

3）使測試自動化

4）進行代碼覆蓋檢測

5）在寫任何新的實現代碼或測試代碼以前，先修復全部運行失敗的測試

6）再簡單的代碼也須要測試

7）特別注意輸入參數的邊界案例

8）不要只測試正常流程，還要測試可選和例外流程

9）對於每個報告的Bug，寫一個對應的測試用例，方便迴歸測試

10）時刻注意，全部測試都經過，不表明程序就真的100%沒問題，測試永遠只是輔助