關于白盒測試的一些想法

　　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.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

原創作品，轉載時請務必以超連結形式标明本文原始出處、作者資訊和本聲明，否則将追究法律責任。

最新内容請見作者的github頁：http://qaseven.github.io/