軟件測試之關于白盒測試

白盒測試，也稱為結構化測試、基于代碼的測試，是一種測試用例設計方法，它從程序的控制結構導出測試用例。用白盒測試產生的測試用例能夠：測試用例模板
　　1）保證一個模塊中的所有獨立路徑至少被使用一次；

　　2）對所有邏輯值均需測試true和false；

　　3）在上下邊界及可操作范圍內運行所有循環；

　　4）檢查內部數據結構以確保其有效性。

　　“我們應該更注重于保證程序需求的實現，為什么要花費時間和精力來擔心（和測試）邏輯細節？”答案在于軟件自身的缺陷：

　　· 邏輯錯誤和不正確假設與一條程序路徑被運行的可能性成反比。當我們設計和實現主流之外的功能、條件或控制時，錯誤往往開始出現在我們工作中。日常處理往往被很好地了解，而“特殊情況”的處理則難于發現。

　　· 我們經常相信某邏輯路徑不可能被執行，而事實上，它可能在正常的基礎上被執行。程序的邏輯流有時是違反直覺的，這意味著我們關于控制流和數據流的一些無意識的假設可能導致設計錯誤，只有路徑測試才能發現這些錯誤。

　　· 筆誤是隨機的。當一個程序被翻譯為程序設計語言源代碼時，有可能產生某些筆誤，很多將被語法檢查機制發現，但是，其他的會在測試開始時才會被發現。筆誤出現在主流上和不明顯的邏輯路徑上的機率是一樣的。

　　正如Beizer所說的：“錯誤潛伏在角落里，聚集在邊界上”，而白盒測試更可能發現它

　　國內很少公司花很大的精力去做白盒測試，一般在單元測試過程中，白盒測試全是由開發人員來完成，商業軟件所使用到的技術主要是黑盒測試技術，這是其特點所決定的。還有少量的白盒技術，但在實際中很少有公司愿意投入人力來作。

　　白盒測試的方法：

　　1.確定軟件中的模塊（數據計算、校驗模塊、功能模塊）

　　2.在每一個模塊中用常用的覆蓋率覆蓋方法計算所有滿足的路徑（覆蓋率方法有很多，看軟件要求程度，比如航空、醫療軟件要求嚴格，使用Do-178B的MC/DC覆蓋率標準）

　　3.設計測試用例，滿足覆蓋要求（注：想滿足所有路徑都覆蓋是不可能的，花費也隨之上升，沒有公司愿意這么做，不現實）。

　　在經費和時間不足的情況下，應采取對關鍵點的白盒測試，就是針對重要環節的測試，然后用黑盒測試做補充，目前國內大多數公司采用：先對軟件進行黑盒測試，然后查看覆蓋率再對未覆蓋的代碼進行白盒測試，這樣做可以節省時間和花費，當然缺點也有，畢竟黑盒測試不能代替白盒測試，即使在正確的輸入下得到正確的輸出也未必是所設想的路徑。

　　

原文轉自：http://www.anti-gravitydesign.com