軟件白盒測試總體概述 單元測試工具
白盒測試，也稱為結構化測試、基于代碼的測試，是一種測試用例設計方法，它從程序的控制結構導出測試用例。用白盒測試產生的測試用例能夠：
1)保證一個模塊中的所有獨立路徑至少被使用一次;
2)對所有邏輯值均需測試true和false;
3)在上下邊界及可操作范圍內運行所有循環;
4)檢查內部數據結構以確保其有效性。
“我們應該更注重于保證程序需求的實現，為什么要花費時間和精力來擔心(和測試)邏輯細節?”答案在于軟件自身的缺陷：
· 邏輯錯誤和不正確假設與一條程序路徑被運行的可能性成反比。當我們設計和實現主流之外的功能、條件或控制時，錯誤往往開始出現在我們工作中。日常處理往往被很好地了解，而“特殊情況”的處理則難于發現。
· 我們經常相信某邏輯路徑不可能被執行，而事實上，它可能在正常的基礎上被執行。程序的邏輯流有時是違反直覺的，這意味著我們關于控制流和數據流的一些無意識的假設可能導致設計錯誤，只有路徑測試才能發現這些錯誤。
· 筆誤是隨機的。當一個程序被翻譯為程序設計語言源代碼時，有可能產生某些筆誤，很多將被語法檢查機制發現，但是，其他的會在測試開始時才會被發現。筆誤出現在主流上和不明顯的邏輯路徑上的機率是一樣的。
正如Beizer所說的：“錯誤潛伏在角落里，聚集在邊界上”，而白盒測試更可能發現它
國內很少公司花很大的精力去做白盒測試，一般在單元測試過程中，白盒測試全是由開發人員來完成，商業軟件所使用到的技術主要是黑盒測試技術，這是其特點所決定的。還有少量的白盒技術，但在實際中很少有公司愿意投入人力來作。
白盒測試的方法：
1.確定軟件中的模塊(數據計算、校驗模塊、功能模塊)
2.在每一個模塊中用常用的覆蓋率覆蓋方法計算所有滿足的路徑(覆蓋率方法有很多，看軟件要求程度，比如航空、醫療軟件要求嚴格，使用Do-178B的MC/DC覆蓋率標準)
3.設計測試用例，滿足覆蓋要求(注：想滿足所有路徑都覆蓋是不可能的，花費也隨之上升，沒有公司愿意這么做，不現實)。
在經費和時間不足的情況下，應采取對關鍵點的白盒測試，就是針對重要環節的測試，然后用黑盒測試做補充，目前國內大多數公司采用：先對軟件進行黑盒測試，然后查看覆蓋率再對未覆蓋的代碼進行白盒測試，這樣做可以節省時間和花費，當然缺點也有，畢竟黑盒測試不能代替白盒測試，即使在正確的輸入下得到正確的輸出也未必是所設想的路徑。
來看一個實際案例：有兩個產品形態接近的項目，A項目正式實施單元測試與集成測試，另一個項目B項目沒正式做白盒測試(簡單的拿調試當測試)。最后項目結束時對研發全過程的全部問題進行缺陷分析。
A. 項目的缺陷類型分析
B. 項目的缺陷類型分析
A項目的所有問題中，應該發現問題的階段是白盒測試(單元測試與集成測試)的占50%，而B項目所有問題中，應在白盒測試階段發現的僅占33%，另外，A項目發現邏輯錯誤占13%，而B項目只占8%。由這個統計數據表明，不做白盒測試必然導致大量問題漏測。
白盒測試要做到什么程度才算合適
既然白盒測試不可或缺，那么，白盒測試應做到什么程度才算合適呢?具體來說，白盒測試與黑盒測試應維持什么樣的比例才算合適?
一般而言，白盒測試做多做少與產品形態有關，如果產品更多的具備軟件平臺特性，白盒測試應占總測試的80%以上，甚至接近100%，而如果產品具備復雜的業務操作，有大量GUI界面，黑盒測試的份量應該更重些。根據經驗，對于大多數嵌入式產品，白盒方式展開測試(包括代碼走讀)應占總測試投入的一半以上，白盒測試發現的問題數也應超過總問題數的一半。
由于產品的形態不一樣，很難定一個標準說某產品必須做百分之多少白盒測試，但依據歷史經驗，我們還可以進行定量分析的。比如，收集某產品的某歷史版本在開發與維護中發生的所有問題，對這些問題進行正交缺陷分析(Orthogonal Defect Classification，ODC)，把“問題根源對象”屬于概要設計、詳細設計與編碼的問題整理出來，這些都是屬于白盒測試應發現的問題，統計這些問題占總問題數的比例，大致就是白盒測試應投入的比例。
通過正交缺陷分析，還能推論歷史版本各階段測試的遺留缺陷率，根據“發現問題的活動”，能統計出與“問題根源對象”不相匹配的問題數，這些各階段不匹配問題的比例就是該階段的漏測率。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
