軟件測試系列--單元測試（Unit Testing）
一、單元測試的概念
單元測試（Unit Testing）是對軟件基本組成單元進行的測試，如函數（function或procedure）或一個類的方法（method）。當然這里的基本單元不僅僅指的是一個函數或者方法，有可能對應多個程序文件中的一組函數。
單元也具有一些基本的屬性。比如：明確的功能、規格定義，明確的與其他部分的接口定義等，可清晰地與同一程序的其他單元化分開來。
二、單元測試的目的
單元測試的目的在於發現各模塊內部可能存在的各種錯誤，主要是基於白盒測試。（也就是說，在單元測試過程中，用的最多的是白盒測試方法，也可能會有灰盒或者黑盒。單元測試和白盒測試是不同的划分，不存在包含關系）。
在單元測試階段對應的文檔是詳細設計文檔（LLD）；對應的代碼就是單元代碼，因此單元測試的目的主要有3點：
1、驗證代碼是與設計相符合的；
2、發現設計和需求中存在的錯誤；
3、發現在編碼過程中引入的錯誤。
三、單元的常見錯誤
單元的常見錯誤一般出現在以下五個方面，因此這五個方面是單元測試應該關注的重點。
1、單元接口。
2、局部數據結構。
3、獨立路徑。
4、出錯處理。
5、邊界條件。
四、如何進行單元測試
在單元測試時，由於單元本身不是一個獨立的程序，一個完整的可運行的軟件系統並沒有構成，所以需要設置一些輔助測試單元，輔助測試單元有兩種，一種是驅動單元，另外一種是樁單元。
1、驅動單元（Driver）:用來模擬被測單元的上層單元，相當於被測函數的主函數，如main函數。所以驅動單元主要完成以下4個步驟：
（1）接受測試數據，包含測試用例輸入和預期輸出；
（2）把測試用例輸入傳送給被測單元，驅動被測單元測試；
（3）將被測單元的實際輸出和預期輸出進行比較，得到測試結果；
（4）將測試結果輸出到指定位置。
2、樁單元（Stub）：用來代替被測單元工作過程中調用的子單元。
樁單元模擬的單元可能是自定義函數：這些自定義函數可能尚未編寫完成，為了測試被測單元，需要構造樁單元來代替它們，可能存在錯誤，會影響測試結果，所以需要構造正確無誤的樁單元來達到隔離的目的。
驅動單元和樁單元都是額外的開銷，雖然在單元測試的時候必須寫，但是並不需要作為最終的產品提供給客戶。
五、單元測試策略
一般的單元執行策略有三種：孤立的單元測試策略（Isolation Unit Testing），自頂向下的單元測試策略（Top Down Unit Testing）和自底向上的單元測試策略（Bottom Up Unit Testing）。需要注意的是：在集成測試中也有自頂向下和自底向上的測試策略，但是測試對象不同。
1、孤立的單元測試策略（Isolation Unit Testing）
方法：不考慮每個模塊與其它模塊之間的關系，為每個模塊設計樁模塊和驅動模塊，每個模塊進行獨立的單元測試。
優點：這個方法比較簡單，最容易操作，可以達到很高的結構覆蓋率，可以並行開展，該方法是純粹的單元測試。
缺點：樁函數和驅動函數工作量很大，效率低。
2、自頂向下的單元測試策略（Top Down Unit Testing）
方法：先對最頂層的單元進行測試，把頂層所調用的單元做成樁模塊，其次對第二層進行測試，使用上面已經測試過的單元做驅動模塊，以此類推，直到測試完所有模塊。
優點：可以節省驅動函數的開發工作，效率高。
缺點：隨着被測單元一個一個被加入，測試過程將變得越來越復雜，並且開發和維護的成本將增加。
3、自底向上的單元測試策略（Bottom Up Unit Testing）
方法：先對最底層的模塊進行單元測試，將模擬調用該模塊的模塊設置為驅動模塊，然后再對上面一層做單元測試，用下面已經測試好的模塊做樁模塊，以此類推，直到測試完所有模塊。
優點：可以節省樁函數的開發工作量，測試效率較高。
缺點：不是純粹的單元測試，底層函數的測試質量對上層函數的測試將產生很大影響。