一、 白盒測試的實施方案

　　在開發階段

　　要保證產品的質量，產品的生產過程應該遵循一定的行業標準。軟件產品也是同樣，沒有標準可依自然談不上質量的好壞。所有關心軟件開發質量的組織、單位，都要定義或了解軟件的質量標準、模型。其好處是保證公司實踐的均勻性，產品的可維護性、可靠性以及可移植性等。

　　在測試階段

　　與軟件產品的開發過程一樣，測試過程也需要有一定的準則，來指導、度量、評價軟件測試過程的質量。

　　定義測試準則

　　為控制測試的有效性以及完成程度，必須定義準則和策略，以判斷何時結束測試階段。準則必須是客觀的，可量化的元素，而不能是經驗或感覺。

　　根據應用的準則和項目相關的約束，項目領導可以定義使用的度量方法，和要達到的覆蓋率。

　　度量測試的有效性、完整性

　　對每個測試的測試覆蓋信息和累計信息，用圖形方式顯示覆蓋比率，并根據測試運行情況實時更新，隨時顯示新的測試所反映的測試覆蓋情況。

　　允許所有的測試運行依據其有效性進行管理，用戶可以減少不適用于非回歸測試的測試的過程。

　　優化測試過程

　　在測試階段的第一步，執行的測試是功能性測試。其目的是檢查所期望的功能是否已經實現。在測試的初期，覆蓋率迅速增加。象樣的測試工作一般能達到70%的覆蓋率。但是，此時要再提高覆蓋率是十分困難的，因為新的測試往往覆蓋了相同的測試路徑。在該階段需要對測試策略做一些改變：從功能性測試轉向結構化測試。也就是說，針對沒有執行過的路徑，構造適當的測試用例來覆蓋這些路徑。

　　在測試期間，及時地調整測試策略，并檢查分析關鍵因素，以提高測試效率。

　　在維護階段

　　有一點認識越來越為大多數人所認可：應用系統的維護費用與初始的開發費用基本相等，而在維護過程中，在對應用結構、邏輯、運行的理解上花費的時間，要用去50%的時間。

　　由于系統維護人員很可能不是開發人員本人，再加上人員的流動、團隊內部的交流的不足，都需要對應用系統的理解。

　　理解應用系統

　　將應用系統的設計，以文件形式(部件文件間的關系)和調用圖的形式(函數和過程間的關系)可視化。

　　函數的邏輯結構以控制流圖的形式顯示，在控制流圖上選定一個節點，即可得到相對應的代碼。

　　應用系統可以在不同的抽象層上進行分析，不同層次間的導航關聯，促進對整體的理解。

　　對應用按其資源的使用進行檢測，由此促進對函數之間(參數傳遞)的信息流、數據間的關系，以及其它資源的理解。

　　安全地修改軟件

　　維護軟件意味著修改軟件，修改后的程序確認需要大量的工作。因為，看起來很小的修改，都可能會滾雪球似的導致數十處甚至上百處的修改。這種后繼的修改需求，越早發現越好，最好是在編譯前就發現并做出修改，最壞的情況是在調試和非回歸測試期間發現。