近一年多一直在從事服務端的
測試工作，雖然之前也做過兩年，但融合了
自動化測試和
功能測試以及
單元測試，所以精力有限，接觸到的
白盒測試比較碎也比較淺。近期項目進入了調整期，有時間整理下對于項目測試中的代碼測試一些感觸。 順便對未來的工作方向和計劃做好準備工作。
2014年可能需要繼續負責服務端項目測試工作，但到底白盒測試和功能測試以及模塊測試，自動化測試之間應該如何進行抉擇，如何進行搭配，相互補充，來達到項目高質，高效的目的呢？ 站在整個項目的角度，從以下幾個維度對白盒測試進行了一些思考：
1. 什么樣的項目可以考慮做白盒測試
1.1. 大項目，周期比較長（因為需要前期介入review RD代碼）
1.2. 功能測試不放心的項目，接口比較明確，重要函數做的修改
1.3. 對整個項目了解較清晰，時間要求較低
1.4. 新項目
1.5. 邏輯較復雜的模塊
1.6. 通用類的
1.7. 異步的、多線程的程序
1.8. 函數用到的外部數據較多的不適合做，構造起來非常復雜，如大量的信令、詞典等
2. 如何結合白盒測試和其它測試方法
首先，需要根據項目特點，比如項目周期，項目難度等來確定測試方法。
然后，如果滿足做白盒測試的條件，則需要先確定白盒測試處于項目測試中的什么階段，如果是迭代或優化類的項目，建議進行分層測試，重點對更新的代碼進行白盒測試，其它的進行傳統的自動化或手工回歸測試。如果是周期比較長的全新項目，可以考慮在RD編碼階段介入，了解接口和底層內部函數構造，為白盒測試做準備。 為了避免白盒測試和功能測試的交叉工作量，可以底層庫用白盒測試，上層功能測試用功能測試，在功能測試上就不再關注底層的測試，可借助分層測試思想。
3. 如何降低白盒測試成本
不管從技術還是從周期上，白盒測試成本比較大，所以站在高效和簡易的基礎上，盡量借助工具來盡量減少白盒測試范圍，比如可以借助：
3.1. 手工測試+代碼覆蓋率測試來覆蓋一部分代碼
3.2. C代碼可以用gdb（其它語言也有）來構造一些比較難引入的上層變量，再結合代碼覆蓋率來做
3.3. 單測工具，比如cppunit，gtest等來做
接口測試 3.4. 其它
我們之前的做法是將模塊測試做成自動化CASE，然后新版本來后，進行自動化測試回歸，并結合代碼覆蓋率來出一份覆蓋報告（從分支和代碼行兩個維度），然后再對新升級的代碼進行review，并拓展用例來覆蓋，如果功能測試實在無法模擬，會采取gtest，最后仍不好模擬會采用gdb掛載的方式
4、 白盒測試收益和風險是什么
4.1. 功能測試無法深入到底層的測試上，白盒測試可以
4.2. 投入成本較大，收益較小
4.3. 通過白盒測試只能發現函數級的錯誤，較難發現函數接口之間的錯誤
4.4. 時間會增加，覆蓋率會增加
4.5. 可促進rd的單元測試做的更充分
4.6. 短期收益不明顯，長遠會有收益
5、白盒測試方法
5.1. 最基層的函數做詳細的測試(傾向于功能)，策略較復雜的做詳細測試(傾向于邏輯)，通過自己寫5.2. 程序去調用被測函數，外層的通過GDB的方式去測試
5.3. 自己寫驅動去調用被測程序或構造上下層來驗證被測程序
5.5. 通過程序包裝被測程序，通過多線程的方式去實現多個動作之間的交互
5.6. cppunit去做，但調用關系較復雜的測試很難去實現，支持case的管理、驗證
5.7. 可借助gtest去實現，擴展為和c++test類似的功能
版權聲明：本文出自 800716 的51Testing軟件測試博客：http://www.51testing.com/?359684
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。