以前曾經(jīng)寫了一篇博文談如何推廣
單元測試，最近有朋友問我如下的問題，因此便又寫了本文，閱讀時請綜合原來的博文。
問題：
有開發(fā)人員認(rèn)為進(jìn)行單元測試會花費大量時間來編寫
測試用例，因此他們做單元測試的意愿比較低，請問有何好的建議進(jìn)行單元測試的改進(jìn)？
解答：
1、首先應(yīng)該明確單元的含義。單元在面向?qū)ο蟮某绦蛑兄傅氖且粋€類，在結(jié)構(gòu)化的方法中指的是一個函數(shù)。
2、其次應(yīng)該明確單元測試的方法。單元測試的常用方法包括：
(1) 靜態(tài)檢查，即采用靜態(tài)代碼檢查的工具對程序進(jìn)行內(nèi)部邏輯的分析，以分析程序中可能的錯誤或壞味道。
(2) 動態(tài)測試，通過編寫單元測試程序，設(shè)計單元測試用例，測試每個函數(shù)或每個類的邏輯正確性。
3如果一個類或一個函數(shù)對其他的類或環(huán)境依賴性很強(qiáng)，需要編寫大量的樁程序或驅(qū)動程序，那恰恰說明了這個類或這個函數(shù)的設(shè)計有問題，違背了“低耦合”的基本設(shè)計原則，這也正式
敏捷方法中提倡的“測試驅(qū)動開發(fā)”的作用之一。
4、質(zhì)量的投入產(chǎn)出也是一種平衡，需要在單元測試上投入到什么程度首先是公司的一個管理方針。如果每個單元都進(jìn)行單元測試則測試代碼的規(guī)模和產(chǎn)品代碼的規(guī)模能夠達(dá)到1：1，也就是說編寫測試代碼的
工作量還是比較大的，但是也要看到單元測試的產(chǎn)出。在單元測試、集成測試、
系統(tǒng)測試中，單元測試是投入產(chǎn)出比最大的測試種類，即單元測試在單位時間內(nèi)發(fā)現(xiàn)的缺陷個數(shù)大于集成與系統(tǒng)測試。原則上單元測試的投入最大，找到的缺陷最多，集成測試與系統(tǒng)測試依次遞減。
5、在實踐中推廣單元測試時可以采用如下的方法：
(1) 加大靜態(tài)檢查的力度。通過靜態(tài)檢查的工具快速地識別程序中的錯誤、警告、壞味道，公司可以規(guī)定對檢查出的哪些警告、壞味道必須進(jìn)行修改，注意如果修改所有的警告、壞味道可能工作量比較大。靜態(tài)檢查是一種投入產(chǎn)出比很高的單元測試方法。在JAVA下可以采用check Style, Source monitor，PMD，F(xiàn)ind Bugs，Jslink等。
(2) 通過測試策略的選擇減少測試程序的工作量。單元測試一般有三種策略：
策略一：自底向上的策略：先測底層的函數(shù)或類，再測上層的函數(shù)或類，此時只需要編寫驅(qū)動程序，不需要編寫樁程序。
策略二：自頂向下的策略：先測上層的函數(shù)或類，再測試底層的函數(shù)類，此時只需要編寫樁程序，不需要或很少需要編寫驅(qū)動程序。
策略三：混合策略：綜合上述的2種策略，需要綜合編寫樁程序與驅(qū)動程序。
如果被測的單元需要調(diào)用很多其他的單元，則可以采用自底向上的策略減少驅(qū)動程序的編寫量。如果被測的單元需要很多外圍的環(huán)境準(zhǔn)備則可以采用自頂向下的策略。
(3) 在組織級可以規(guī)定執(zhí)行單元測試的時機(jī),比如：
i)系統(tǒng)中最核心的、最關(guān)鍵的功能模塊；
ii)算法復(fù)雜的功能模塊；
iii)出錯最多的功能模塊；
iv)客戶最常使用的功能模塊；
v)復(fù)用的底層代碼
根據(jù)Pareto定律，我們可以選擇少部分代碼執(zhí)行單元測試。
6、單元測試的技術(shù)
(1) XUnit的工具
(2) 生成測試用例時可以采用如下的方法：
i）單元功能分析
ii）入口參數(shù)等價類分析
iii）入口參數(shù)邊界分析
iv）全程變量、共享數(shù)據(jù)的等價類與邊界分析
v）調(diào)用函數(shù)返回值的等價類與邊界分析
vi）覆蓋率分析
上述的方法要求的嚴(yán)格程度可以循序漸進(jìn),不能的嚴(yán)格程度需要投入的工作量不同。