單元測試是針對代碼單元的獨立測試�！蔼毩ⅰ笔侵笇⒋a從原始項目及其依賴的環境中隔離出來，針對各個單元單獨進行測試，包括三方面含義：形式獨立、實質獨立和意識獨立。單元測試之所以困難，就在于技術上無法解決形式獨立和實質獨立，主觀上沒有達到意識獨立。
形式獨立
將測試任務從原始項目及其依賴環境中隔離出來，并能在易于測試的環境下運行。企業項目通常高耦合、可測性差、依賴于特定的軟件環境或硬件環境，單元測試要首先將測試任務從依賴的代碼和環境中分離出來，并解決編譯、平臺差異等問題，使測試任務在易于測試的環境下能夠獨立測試。
實質獨立
被測試代碼通常會調用各種底層函數，其功能邏輯難免受底層函數的影響，如何獨立完整地進行測試?實際上，調用底層函數獲得的數據，與通過參數傳遞的數據具有同等意義，例如，調用底層函數得到一個返回值，要測試的是被測程序對這個值的各種可能有沒有做合適的判斷處理，并不關心底層函數如何計算這個值，正如只關心是否對參數的各種可能做了合適處理，而不關心參數是如何傳遞和由誰傳遞一樣。因此，調用底層函數獲得的數據可視為被測函數的一種輸入，稱為內部輸入。
如果可以模擬底層函數的各種輸出，并將這些輸出視為被測函數的內部輸入，那么，無論底層函數屬于哪種情形，都可以完整測試被測代碼的功能邏輯，這就是實質獨立。
內部輸入分為易于自然取得(調用真實的底層函數獲得)、不可控(調用真實底層函數但其行為難于控制)、失真(打樁的必然后果)、難于自然取得等四種情形。易以自然取得的內部輸入并不影響被測函數的獨立性，而后三種則是單元測試的關鍵難點。靜態局部變量也是麻煩的內部輸入。關于內部輸入的詳細說明，請看這篇文章。
意識獨立
意識獨立是主觀要素，是指在制定測試目標和執行測試時，要適應“單元測試是針對代碼單元的獨立測試”這一基本現實，把測試任務看作一個一個的獨立單元，正確設定測試目標、正確選擇測試方法及工具。
單元測試有獨特的優勢，例如易于完整地測試代碼單元的功能邏輯，這些優勢來自“獨立”，但凡事有其長必有其短，既然是“獨立”，就難于測試與其他代碼和依賴環境的相互關系。單元測試與系統測試是互補關系，不是代替關系，“獨立”狀態下易于發現的錯誤，才是單元測試的目標;集成后才易于發現的問題，應該留待系統測試。
代碼單元本身的功能邏輯錯誤都是單元測試的目標，而性能問題(時間性能如執行速度，空間性能如存儲空間大小、內存泄漏)難于在最小單元內測試，不是單元測試目標。
單元測試也不考慮平行和向上依賴關系，并把向下依賴抽象為內部輸入，例如，測試一個函數時，不考慮這個函數在項目中是被普通調用、系統回調、消息或信號調用、還是中斷調用;不考慮多線程、重載;嵌入式環境中的端口、寄存器等在代碼中都是內存，視為全局變量;并把底層函數(包括操作系統API)的輸出視為內部輸入�？傊�，只用各種輸入是否產生了正確輸出的方式，完整測試函數的功能邏輯，也正因為這個原因，單元測試可以脫離原來的平臺環境，在易于實施的平臺上進行，例如，在PC上測試嵌入式項目，在Windows上測試Linux項目，都是可行的。
編碼規范檢查與單元測試無關，無論是否實施單元測試，編碼規范檢查都是必不可少的工作。靜態分析屬于全局掃描，嚴格來說也不是單元測試，提高編譯器的警告級別，就是最簡單高效的靜態分析。
單元測試是意義重大且困難的工作，目標應該具體而明確，將不屬于單元測試或單元測試不擅長的目標牽扯進來，其結果往往是“揀了芝麻，丟了西瓜”。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
