白盒測試技術的理論性比較強，也比較成熟，現實中不是每個單元都可以很好地完整運用白盒測試技術。如不是關鍵的單元也沒有必要將所有的理論付諸子實踐。本節主要講述白盒測試的基本方法和準則。具體如何運用白盒測試技術導出測試用例，請參見第14童。
· 因果圖法。
· 功能圖法。
在功能性測試方面我們通常會利用三種數據來進行測試，即正常數據、邊緣數據和錯誤數據。
· 正常數據：在測試中所用的正常數據的量是最大的，而且也是最關鍵的。少量的
測試數據不能完全覆蓋需求，但要從中提取出一些具有高度代表性的數據作為測
試數據，以減少測試時間。
· 邊緣數據：是界于正常數據和錯誤數據之間的一種數據。它可以針對某一種編程語言、編程環境或特定的數據庫而專門設定。例如，若使用sQL server數據庫，則可把sOL s豇ver關鍵字(如：。；As：Join等)設為邊緣數據。其他邊緣數據還有HⅣL的HTML；o等關鍵字以及空格、@、負數、超長字符等。邊緣數據要靠測試人員的豐富經驗來制定。
· 錯誤數據：顯而易見，錯誤數據就是編寫與程序輸入規范不符的數據從而檢測輸入篩選、錯誤處理等程序的分支。
另外，還得考慮接口測試、性能測試、內存測試等。
· 性能分析：代碼運行緩慢是開發過程中的一個重要問題。一個應用程序運行速度較慢，程序員不容易找到是在哪里出現了問麒。如果不能解決應用程序的性能問題，將降低并極大地影響應用程序的質量，于是查找和修改性能瓶頸成為調整整個代碼性能的關鍵。
· 內存分析：內存泄漏會導致系統運行的崩潰，尤其對于資源比較匱乏、應用非常
廣泛的嵌入式系統．可能導致無法預料的熏大損失。通過測量內存使用情況·可
以了解程序內存分配的真實情況，發現對內存的不正常使用t在問題出現自口發現
征兆，在系統崩潰前發現內存泄露錯誤。發現內存分配錯誤t并精確顯示發生錯
誤時的上下文情況，指出發生錯誤的原由。
一位優秀的開發人員會主動要求測試人員對其代碼進行充分的測試。一位優秀的測試人員也會對關鍵的單元十分敏感，進行充分的測試。下面就是筆者所在項目組的一個真實事例。
案例；
套司正在進行一項大型的網絡服務系統的開發，項目組承擔的是服務器端的軟件開發。其中有個項目負責多臺數據庫服務器的數據復制。服務系統是實時的，對數據復制的性能要求當然很高。當開發人員完成了數據傳輸模塊時(還未編寫和數據庫相關的模塊)，就主動要求對其性能進行單元測試。
進行這樣的性能測試，不需要詳細了解該單元的結構，但首先要掌握設計文檔中相關
的性能指標和運行的網絡環境度服務器環境等指標。咀便搭建相應的測試環境。
其次，要求開發人員提供相應的程序接口，設計驅動程序和樁程序用來運行并測試該單元程序。此處我們蝙寫了一個功能簡單的小程序，即作為驅動模塊也是樁模塊。該驅動程序在服務器端運行模擬數據庫提供和接收需復制的數據，它能夠隨機產生可設置大小的數據包，按設置好的單位時間發包數量進行數據包的發送，同時它也是接收端，能對接收到的數據包的數量和大小進行簡單的統計，以便實現簡單的驗證，如圖5—2所示。驅動模塊__—一被測試單i卜—一驅動模塊
圖5．2具有樁模塊作用的驅動程序
接著就要設計測試用例并實施測試。設計測試用例時要求：
· 根據指標考慮數據包的大小和頻率，如大包低頻或小包高頻。
· 考慮兩個驅動程序的數據對發。
· 從兩個驅動程序變為多個驅動程序的數據對發。
· 從同一網段變為多個網段，驗證代理服務器或網關造成的影響。
發現問題后，得先排除網絡等環境因素，再報告開發人員進行調試。
這樣會確保該單元不會是誼項目的性能瓶頸，也避免了后續開發的盲目性。很多參考書中誤導人們認為單元測試采用的是白盒測試技術，由開發人員完成。這很片面，在有些情況下是完全不對的。從另一方面來說，該案例的測試工作也可由開發者完成，但在開發的初期，測試人員并沒有大的測試壓力，而開發者面臨著大量代碼編寫壓力，浪費開發者的時間直接影響項目的進度。何況開發者與測試者的心理狀態的不同，還可能直接影響測試結果的可靠性。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
