1、單元測試概念
1）單元測試是對軟件基本組成單元進行的測試，如函數（fuction或procedure）或一個類的方法（method）。這里，基本單元不一定是指一個具體的函數（fuction或procedure）或一個類的方法（method），在具體實現時，也可能對應的是多個程序文件中的一組函數。
2）在軟件系統中，單元也具有一些基本屬性，如：明確的功能、規格定義、明確的與其他部分的接口定義等，可清晰的與同一程序的其他單元划分開來。
2、單元測試的目的
1)單元測試的目的在於發現各模板內部可能存在的各種錯誤，主要是基於白盒測試。
2)軟件產品不僅僅包含代碼，還包含各種文檔，因此測試應從三方面考慮:
a.針對文檔的測試;
b.針對代碼的測試;
c.針對文檔和代碼是否一致的測試。
3）單元測試階段，對應的文檔時詳細設計說明書，對應的代碼是單元代碼，因此單元測試的目的主要有三方面：
a.驗證單元代碼和詳細設計文檔的一致性;
b.跟蹤詳細設計文檔中設計的實現，發現詳細設計文檔中存在的錯誤;
c.發現在編碼過程中引入的錯誤(編碼過程中引入的錯誤包含兩類:和設計不符引入的錯誤;和設計相符但由於編碼出現疏漏導致錯誤),這里其實是針對文檔和代碼是否一致的測試。
3、單元測試中常見錯誤（單元測試關注重點）
單元的常見錯誤一般出現在5個方面：代碼的穩定、易讀、規范、易維護、專業。
因此，單元測試的關注的重點有5點：單元接口、局部數據結構、邊界條件、獨立路徑、出錯處理，下列一一介紹。
1）單元接口
接口實際上就是輸入輸出對應關系的集合，如果數據不能正確的輸入和輸出，就談不上進行其他測試，單元接口處常見錯誤：
a.被測單元的輸入輸出參數在個數、屬性、順序上和詳細設計中的描述不一致；
b.修改了只做輸入用的形式參數，可能會導致數據的錯誤修改；
c.約束條件通過形式參數來傳送，導致函數間的控制耦合增大（耦合是指兩個實體相互依賴於對方的一個度量）。
2）局部數據結構
在單元工作過程中，必須測試單元內部的數據能否保持完整性，包括內部數據的內容、形式及內部關系不發生錯誤。
對於局部數據結構，應該在單元測試中注意發現以下幾類錯誤：
a.不正確或不一致的數據類型說明；
b.使用尚未賦值或尚未初始化的變量；
c.錯誤的初始值或錯誤的缺省值；
d.變量名拼寫或書寫錯誤。
3）獨立路徑
對基本執行路徑和循環進行測試會發現大量的錯誤，常見的錯誤有：
a.運算的優先次序不正確或誤解了運算的優先次序；
b.運算的方式錯誤；
c.不同數據類型的比較；
d.關系表達式中不正確的變量和比較符；
e.“差1錯”。即不正確的多循環或少循環一次；
f.錯誤的或不可能的循環終止條件；
g.當遇到發散的迭代時不能終止的循環；
h.不適當地修改了循環變量等。
4）出錯處理
比較完善的單元設計要求能預見出錯條件，並設置適當的出錯處理，以便在出錯時，能對出錯程序重新作安排，保證其邏輯上的正確性，出錯處理模塊常見的錯誤或缺陷有：
a.出錯的描述難以理解；
b.出錯的描述不足以對錯誤定位和確定出錯的原因（這個錯誤由系統的安全級別來定）；
c.現實的錯誤與實際的錯誤不符；
d.對錯誤條件的處理不正確；
e.在對錯誤驚醒處理之前，錯誤條件已經引起系統的干預等。
5）邊界條件
邊界上出現錯誤是比較常見的，單元測試時，應當仔細的測試為限制數據處理而設置的邊界條件。
需要注意與邊界有關的數據類型如數值、字符、位置、數量、尺寸等，還需注意這些邊界的首個、最后一個、最大值、最小值等特征，常見錯誤出現情況：
a.在n次循環的第n次，取最大最小值時容易發生錯誤；
b.特別要注意數據流，控制流中剛好等於、大於、小於確定的比較值時出現錯誤的可能性。
4、單元測試環境
在單元測試時，由於單元本身不是一個獨立的程序，一個完整的可運行的軟件系統並未構成，所以需要設置一些輔助測試單元，輔助測試單元有兩種：驅動單元和樁單元。
1）驅動單元（Driver）
用來模擬被測試單元的上層單元，相當於被測函數的主程序，它接收測試數據，將相關數據傳送到被測單元，啟動被測單元，最后再輸出實測結果。當被測單元能完成相關功能時，也可以不要驅動單元。
驅動單元，主要完成以下幾個步驟
a.接受測試數據，包含測試用例的輸入和預期輸入；
b.把測試用例輸入傳送給要測試的單元，驅動被測單元執行；
c.將被測單元的實際輸出和預期輸出進行比較，得到測試結果；
d.將測試結果輸出到指定位置。
2）樁單元（Stub）
指用來代替被測單元工作過程中調用的子單元，樁單元的功能是從測試角度模擬被測單元所調用的其他單元，樁單元需要針對不同的輸入，返回不同的期望值，模擬不同的功能。如果被測單元為底層函數嗎，則不需要設計樁單元。
樁單元的類型：系統函數、自定義函數。
樁單元模擬的單元可能是自定義函數：這些自定義函數可能尚未編寫完成，為了測試被測單元，需要構造樁單元來替代他們；或者可能存在錯誤，會影響測試結果，給分析被測單元造成困難，因此需要構造正確無誤的樁單元來達到隔離的目的。
3）構造單元的測試環境的主要工作
a.構造最小運行調度系統，即驅動單元，用以模擬被測單元的上一級單元;
b.模擬實現單元接口，即單元函數需調用的其他函數接口，即樁單元;
c.模擬生成測試數據和狀態，為單元運行准備動態環境。
5、單元測試策略
一般的單元測試策略有3種：孤立的單元測試策略、自頂向下的單元測試策略、自底向上的單元測試策略。
1）孤立的單元測試策略（Isolation Unit Testing）
a.方法：不考慮每個模塊與其他模塊之間的關系，為每個模塊設計樁模塊和驅動模塊;
每個模塊進行獨立的單元測試.
b.優點：最簡單，最容易操作;
可以達到高的結構覆蓋率;
可以並行開開展；
是純粹的單元測試。
c.缺點：樁函數和驅動函數工作量很大，效率低。
2）自頂向下的單元測試策略（Top Down Unit Testing ）
a.方法：先對最頂層的單元進行測試，把頂層所調用的單元做成樁模塊；
對第二層進行測試，使用上面已測試的單元做驅動模塊；
如此類推直到測試完所有模塊。
b.優點：可以節省驅動函數的開發工作量，測試效率較高。
c.缺點：隨着被測單元一個一個被加入，測試過程將變得越來越復雜，並且開發和維護的成本將增加。
3）自底向上的單元測試策略（Bottom Up Unit Testing）
a.方法：先對模塊調用層次圖上最底層的模塊進行單元測試，模擬調用該模塊的模塊做驅動模塊；
然后再對上面一層做單元測試，用下面已被測試過的模塊做樁模塊；
以此類推，直到測試完所有模塊。
b.優點：可以節省樁函數的開發工作量，測試效率較高。
c.缺點：不是純粹的單元測試，底層函數的測試質量對上層函數的測試將產生很大的影響。
6、單元測試過程及主要活動
1）單元測試計划階段：完成單元測試計划
2）單元測試設計階段：完成單元測試方案
3）單元測試實現階段：完成單元測試用例、單元測試教程、單元測試腳本及數據文件
4）單元測試執行階段：執行單元測試用例。修改發現的問題並進行回歸測試，提交單元測試報告
7、單元測試原則
1）對全新的代碼或修改過的代碼進行測試；
2）單元測試根據單元測試方案和計划進行，排除測試的隨意性；
3）必須保證單元測試計划、單元測試方案、單元測試用例等經過評審；
4）當測試用力地測試結果與預期結果不一致時，單元測試的執行人員需如實記錄實際的測試結果；
5）只有當測試計划中的結束標准達到時，單元測試才能結束；
6）對被測試單元需達到一定的代碼覆蓋率要求。
8、單元測試工具
1）代碼靜態分析工具
2）代碼檢查工具
3）測試腳本工具
4）覆蓋率檢測工具
5）內存檢測工具
6）專為單元測試設計的工具