1）對架構的反思：架構是否按照分層開發，業務邏輯是否全部在邏輯層實現而非UI實現，這些對單元測試都很重要。雖然現在提供了一些從UI開始的單元測試工具，但推薦方式或說單元測試的重點仍然在邏輯層。
2）對自我開發技能的反思：開發不做單元測試而直接做黑盒測試不利于鍛煉自己邏輯思維能力，代碼靜態分析技能。通過進行單元測試，進行分支和覆蓋分析，可以加強代碼的可測試性，促進代碼的重構。
3）單元測試是集成測試的基礎，如果單元測試都沒有做好，那就會把單元，子程序的問題遺留到系統測試的時候才發現。
4）不使用單元測試工具或框架也可以自己寫相關代碼或其它方式進行單元測試，不能單純理解單元測試就是使用JUnit，NUnit等相關工具。
-----------------------------------------------------------------
單元測試是檢查程序中的最小單位（函數，過程，類，子程序，包）有無錯誤，一般在編碼完成后由開發人員進行。
單元測試的目標是檢查編碼是否符合設計，而不能檢查設計是否正確。
單元測試的一些方法：
靜態方法：
代碼走讀：可開發人員間相互走讀代碼，可設計人員走讀開發人員代碼，比較隨意些。
代碼走查，審查：召開評審會對編碼進行評審，根據編碼檢查單，和設計相關工件對編碼進行評審。這里可以由開發人員自己對代碼進行講解，也可以由他人對編碼進行講解。
代碼的靜態分析對開發人員的技能要求很高，在沒有實際運行程序時候就能夠清楚的知道程序潛在存在的漏洞和缺陷需要多年的編程的積累和經驗的總結。
靜態測試方法關注的重點是
1）編碼的規范性
2）資源是否釋放
3）數據結構是否完整和正確
4）是否有死代碼和死循環
5）代碼本身是否存在明顯的效率和性能問題
6）代碼本身方法，類和函數的劃分是否清晰，易理解
7）代碼本身是否健壯，是否有完善的異常處理和錯誤處理
通過工具進行單元測試
1）靜態分析工具（PurifyPlus）
2）代碼規范審核工具 （FxCorp）
3）內存和資源檢查工具（PurifyPlus，MemoryChecker）
4）測試數據生成工具
5）測試框架工具（JUnit NUnit）
驅動和打樁（Test Driver & Stub）
執行一個單元測試通過三個步驟完成：模擬輸入->執行單元->檢查驗證輸出，這就是單元測試的驅動。當我們采用從頂向下執行單元測試的時候，底層執行單元及其子單元可能根本還沒有開發完成，這個時候需要模擬一些數據輸出來替代實際的單元和子單元。所以打樁一個是對單元的模擬，一個是對單元的替代。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
