近一年多一直在從事服務端的測試
工作，雖然之前也做過兩年，但融合了自動化測試和功能測試以及單元測試，所以精力有限，接觸到的白盒測試比較碎也比較淺。近期專案進入了調整期，有時間整理下對於專案測試中的**測試一些感觸。 順便對未來的工作方向和計畫做好準備工作。
2023年可能需要繼續負責服務端專案測試工作，但到底白盒測試和功能測試以及模組測試，自動化測試之間應該如何進行抉擇，如何進行搭配，相互補充，來達到專案高質，高效的目的呢？ 站在整個專案的角度，從以下幾個維度對白盒測試進行了一些思考：
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類似的功能
白盒測試一些方法
白盒測試足針對軟體內部結構的測試，土要是川覆蓋的方式對程式 進行測 戚。下面就白盒測試中的六種典型覆蓋方法進行 1 語句覆蓋 作為最基本的邏輯覆蓋方法，語句覆蓋 的含義是 選擇足夠多的測試資料，使得被測程式中的每個語句至少執行一次。通過語句覆蓋，可以直觀地從源 得到測試用例，無須細分每條判定表示式 ...
java白盒測試的想法
我們在進行日常程式開發和維護的時候，或許總有乙個疑問，為什麼老有改不完的bug！其實，陷入這種困境的原因往往是不注重單元測試導致的。我們知道一般將測試分為黑盒測試和白盒測試兩部分，黑盒測試較為基礎直觀，是從錯誤的表面現象中去找問題的原因，一般的bs測試人員都是在進行這種測試，總體講黑盒測試對技術的要...
白盒測試及其存在的一些問題
白盒測試，又稱結構測試 透明盒測試 邏輯驅動測試或基於 的測試。盒子就是指被測的軟體，白盒的意思就是軟體內部的結構是可視的，測試人員可以根據 在分析完程式的結構之後，我們全面了解程式內部邏輯結構 對所有邏輯路徑進行測試。我們要窮舉路徑，從檢查程式的邏輯著手，得出測試資料。但有的時候，貫穿程式的獨立路...