單元測試概述

標籤：

1、為什麼需要單元測試

    軟體開發的標準流程包括以下幾個階段：［需求分析階段］、［設計階段］、［實現階段］、［測試階段］、［發布］。其中測試階段通過人工或者自動手段來運行或測試某個系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。按照軟體工程思想，軟體測試可以分為單元測試、整合測試、功能測試、系統測試等。功能測試和系統測試一般來說是測試人員的職責，但單元測試和整合則必須由開發人員保證。

    1）單元測試：單元測試時開發人員編寫的一小段代碼，用於檢驗目標代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試用於判斷某個特定條件或特定情境下某個特定函數的行為。在一個情況下，一個功能模組往往會調用其他功能模組完成某項功能，如業務層的業務類可能會調用多個DAO完成某項任務。對某個功能模組進行單元測試時，我們希望屏蔽對外功能模組的依賴，以便將焦點放在目標功能模組的測試上。這時類比對象是最有力的工具，它依據外在模組的介面類比特定操作行為，這樣單元測試就可以在假設關聯模組正確工作的情況下驗證本模組邏輯的正確性了。

    2）整合測試：整合測試是在功能模組開發完成以後，為驗證功能模組之間匹配調用的正確性而進行的測試。在單元測試時，往往需要通過類比對象屏蔽外在模組的依賴，而整合測試恰恰是要驗證模組之間整合後的正確性。

    3）功能測試：功能測試主要檢查已實現的軟體是否滿足了需求規格說明中確定了的各種需求，以及軟體功能是否完全、正確。

    4）系統測試主要對已經經過確定的軟體納入實際運行環境中，與其他系統成份組合在一起進行測試。

 

2、測試的好處

    1）是軟體品質最簡單、最有效保證；

    2）是目標代碼最清晰、最有效文檔；

    3）可以最佳化目標代碼的設計；

    4）是代碼重構的保障；

    5）是迴歸測試和持續整合的基石。

 

3、單元測試基本概念

    1）被測系統：SUT（System Under Test）

    被測系統資料表示正在被測試的系統，目的是測試系統能否正確操作。軟體系統測試的一個特例是對應用軟體的測試，稱為被測應用程式（AUT，Application Under Test）。SUT也表明軟體已經到了成熟期，因為系統測試在測試周期中是整合測試的後一階段。

    

    2）測試替身：Test Double

    在單元測試時，使用Test Double減少對被測對象的依賴，使得測試更加單一。同時，讓測試案例執行的時間更短，運行更加穩定，同時能對SUT內部的輸入輸出進行驗證，讓測試更加徹底深入。但是，Test Double也不是萬能的，Test Double不能被過度使用，因為實際交付的產品是使用實際對象的，過度使用Test Double會讓測試變得越來越脫離實際。

    要理解測試替身，需要瞭解一下Dummy Object， Test Stub，Test Spy， Fake Object這幾個概念。

        a、Dummy Object：Dummy Object泛指在測試中必須傳入的對象，而傳入的這些對象實際上並不會產生任何作用，僅僅是為了能夠調用被測對象兒必須傳入的一個東西。

        b、Test Stub：測試樁是用來接受SUT內部的間接輸入（indirect inputs），並返回特定的值給SUT。可以理解Test Stub是在SUT內部打的一個樁，可以按照我們的要求返回特定的內容給SUT，Test Stub的互動完全在SUT內部，因此，它不會返回內容給測試案例，也不會對SUT內部的輸入進行驗證。

        c、Test Spy：Test Spy像一個間諜，安插在了SUT內部，專門負責將SUT內部的間接輸出（indirect outputs）傳到外部。它的特點是將內部的間接輸出返回給測試案例，由測試案例進行驗證，Test Spy只負責擷取內部情報，並把情報發出去，不負責驗證情報的正確性。

        d、Mock Object：Mock Object和Test Spy有類似的地方，它也是安插在SUT內部，擷取到SUT內部的間接輸出（indirect outputs），不同的是，Mock Object還負責對情報（intelligence）進行驗證，總部（外部的測試案例）信任Mock Object的驗證結果。

        e、Fake Object：經常，我們會把Fake Object和Test Stub搞混，因為它們都和外部沒有互動，對內部的輸入輸出也不進行驗證。不同的是，Fake Object並不關注SUT內部的間接輸入（indirect inputs）或間接輸出（indirect outputs），它僅僅是用來替代一個實際的對象，並且擁有幾乎和實際對象一樣的功能，保證SUT能夠正常工作。實際對象過分依賴外部環境，Fake Object可以減少這樣的依賴。

    

    3）測試夾具：Test Fixture

    測試夾具（Fixture），就是測試回合程式（test runner）會在測試方法之前自動初始化、回收資源的工作。在Junit4中通過@Before來初始化欄位和配置環境，通過@After來進行登出。這可以保證各個測試之間的獨立性和互不干擾，但是效率低。

        一個測試案例可以包含若干個打上@Test註解的測試方法，測試案例測試一個或多個類API介面的正確性，當然在調用類API時，需要事先建立這個類的對象及一些關聯的對象，這組對象就稱為測試夾具（Fixture），相當於測試案例的“工作對象”。

 

    4）測試案例：Test Case

    在JUnit3中，測試方法都必須以test為首碼，且必須時public void的，JUnit4以後，就沒有這個限制，只要在每個測試方法標註@Test註解，方法簽名可以是任何取名。可以在一個測試案例類中添加多個測試方法，運行器為每個方法產生一個測試案例執行個體並分別運行。

     

    5）測試套件：Test Suite

    通過TestSuite對象將多個測試案例組裝成一個測試套件，則測試套件批量運行。需要特別指出的是，可以把一個測試套件整個添加到兩一個測試套件中，就像小籮筐裝進大籮筐變成一個筐一樣。

        套件機制用於將測試從邏輯上分組並將這些測試作為一個單元測試來運行。Junit4為了替代老版本的套件測試，套件被兩個新註解替代：@RunWith、@SuteClasses。通過@RunWith指定一個特殊的運行器，即Suite.class套件運行器，並通過@SuiteClasses註解，將需要進行測試的類列表作為參數傳入。

        建立步驟說明：

        * 建立一個空類作為測試套件的入口（這個空類必須使用public修飾符，而且存在無參建構函式）；

        * 將@RunWith、@SuiteClasses注釋修飾這個空類；

        * 把Suite.class作為參數傳入@RunWith注釋，以提示Junit將此類指定為運行器；

        * 將需要測試的類組成數組作為@SuiteClasses的參數。

 

    6）斷言：Assertions

        斷言（assertions）是測試架構裡面的若干個方法，用來判斷某個語句的結果是否為真或判斷是否與預期相符。

    

單元測試概述