單元測試的方法其實最主要的是測試用例的生成方法。教科書上的方法與實踐中還是有些差距的，實踐是“不管白貓黑貓，帶住老鼠就是好貓”，實踐中一般是先對被測單元的入口參數進行等價類劃分、邊界值分析以生成測試用例，然后再考慮單元內部的實現邏輯進行覆蓋率分析以生成測試用例。
3 過程
在進行單元測試的過程定義與相關的規范定義時應把握一個基本的原則：“先松后嚴，形成閉環”。即，在推廣的初期，要求可以沒有必要那么深入，可能是先要求大家做測試用例，然后再要求測試用例個數，再要求的覆蓋率等等。但是定義了制度就要檢查，要落實，要確保制度的執行。
單元測試是由開發人員自己來進行的，過程的定義要簡單，只要把握幾個關鍵點就OK了：
（1）是否寫了測試用例？
（2）測試用例是否達到了組織級要求的個數？
（3）測試的缺陷是否記錄了？
（4）是否自我分析了缺陷的原因、類型及分布情況？
測試驅動的開發方法提倡在編碼之前寫測試用例，這種實踐可以很好的預防錯誤，值得嘗試。上述的4個關鍵點中開發人員就不愿意做的是測試缺陷記錄，最容易忽略的是缺陷的分析。自己的BUG，自己改，出了錯就去修改，不愿意記錄下來，認為耽誤自己的時間，沒有什么用途，如果開發人員自己分析了自己缺陷的原因、類型等分布情況，可以發現自己的弱點，在以后的開發過程中改進之，實現自我的提高。子曰：君子日三省其身。不反省，就不能天天向上。
單元測試和同行評審一樣，都是很簡單的質量措施，但是推廣的時候卻會有很多的具體問題和阻力，需要從公司建立起這種文化，讓開發人員形成這樣的開發習慣，才能充分發揮其作用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
