軟件測試中談一談單元測試的肥肉與骨頭
無處不在80-20規則，在軟件開發中也同樣存在，例如，80%的錯誤存在于20%的代碼中，80%的項目時間消耗在20%的代碼上，當然這只是粗略的估計，不同的項目，比例可能有所不同。
那么，這20%是哪些代碼呢？是功能邏輯復雜的代碼，也就是算法密集的代碼。一個算法密集的函數，通常要對數據進行仔細的分類，一個判定就是一次分類，嵌套的判定就是分類的翻番，要做到分類正確完整且處理無誤，是很困難的事。遺漏一個分類，或一個分類的處理不正確，就會造成錯誤，錯誤與行數的比值會很高，而且，只有當輸入匹配時錯誤才能表現出來，難于在系統測試中發現。
一個功能邏輯較簡單的函數，也許行數不少，也有一些判定，但這些判定通常用于攔載非法輸入，以及進行調度，其功能邏輯是容易理解和明確的，錯誤與行數的比值較低，而且，通常一些很常規的輸入，就可以覆蓋全部功能邏輯，因此，錯誤也容易在系統測試中發現。
對于程序員來說，很多代碼都是敲鍵盤，通過編譯后，再仔細看一兩遍就可以了，這些代碼編寫速度很快，錯誤很少，調試時間也少。另一些代碼，即算法密集的代碼，往往是解決問題的關鍵，需要創造性的和慎密的思維，這些代碼占用了多數的編程時間和調試時間。
單元測試的成本與所需的數據規模正相關，即數據密集的函數，需要更多的測試時間來構建這些數據。算法密集的代碼，一般不會同時數據密集，如果是，也應該將算法密集的部分分離出去形成獨立函數，例如，一個函數，要對一個結構指針數組里的各個項做復雜處理，那么，這個復雜的處理過程應該獨立出去，這是很容易做到的，也是一個基本的編碼規范。
算法密集的代碼包含大多數錯誤，且難于在系統測試中完整測試，而單元測試很容易做到這一點，且構建數據的成本低廉，是單元測試的“肥肉”。其他代碼或者錯誤較少且容易在系統測試中發現，或者構建數據的成本較高，是單元測試的“骨頭”。
單元測試應該首先將“肥肉”吃到口，至于“骨頭”，則視情況選擇。
文章來源于領測軟件測試網 http://www.k11sc111.com/
