所以，越早測試就越能節約成本，白盒測試作為早期測試，跳過不做是得不償失的。
依據上述原因，我們評估白盒測試效率時，通常將發現問題總數乘上一個系數K，以此為據再與其它測試方段的發現問題效率做對比，來權衡白盒測試值不值得去做。系數K取值與產品形態相關，按照實際經驗，系數K取值區間為1.5~2.5，產品越復雜，出現問題越不容易解決的，K值要往大調。
三、白盒測試能徹底解決編碼階段引入的問題
前面我們分析了白盒測試是高效的測試，值得一做，下面我們要接著說明白盒測試必須要做，不可或缺。
先看一個案例，在某交換機產品的系統測試中，發現ISDN話機撥打某新業務號碼時，在特定線路上，若一位一位的撥至18位，不會有問題，但如果先撥完號碼再成組發送，會導致系統死機。這是一個導致死機的致命問題，最后定位出問題所在：呼叫處理的某段代碼判斷有誤，本應小于18的判斷，錯寫成小于等于18。
這個問題本該在單元測試去發現，由于單元測試沒做，問題就遺留到系統測試，慶幸的是沒把它遺留到網上，否則問題就大 了。我們從另一個角度去反思，這個問題是特定線路下的特定終端，按特定方式拔打特定業務才暴露，在系統測試好不容易把它揪出來，但類似的其它問題呢?如何 保證在系統測試階段都能測得出來?
不同階段的測試發現問題的特點各不相同，比如：單元測試階段，容易發現邏輯問題、邊界條件(如上例“小于18” 的錯誤)、變量未初始化、內存越界等問題，而集成測試容易發現接口錯誤、任務配合問題等，系統測試容易發現業務流程問題、界面操作問題等。如果某階段的測 試沒做，把問題遺留后面階段，又如何能保證查錯的徹底性。比如使用非法內存，出問題是否表現出來是隨機的，如果操作非法內存當前被系統還認為是有效的，系統并不死機，但某些情況下，操作非法內存會死機，而另一些情況，非法內存操作將不期望變化的變量改寫了，會導致其它莫名其妙的問題。類似這樣的問題，在白 盒測試階段很容易發現，也容易定位解決，但遺留系統測試階段，就很難去發現、去定位。
在V模型中，軟件開發過程與測試行為具有不同層次的對應關系，如下圖：
單元測試針對編碼階段引入的問題，集成測試與功能測試針對軟件設計中引入的問題，驗收測試針對需求與規格。單元測試不要或缺的重要原因是：編碼階段引入的問題占很高比例，不進行單元測試就難以保證系統最終的穩定性。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
