白盒測試程式碼應該怎麼測試

之前一直在做黑盒測試，最近公司需要做白盒測試，在網上查閱了一些資料，做白盒測試程式碼應該怎麼測試？現總結如下：

1、白盒測試一種測試方法，單元測試是一種測試型別。

白盒測試一般是使用工具進行各個指標測試，如語句覆蓋、分支覆蓋、條件覆蓋等等。

白盒測試又分靜態和動態，靜態就是程式碼的規則規範檢測等，動態就是單元測試、覆蓋率測試、記憶體檢測，執行時錯誤檢測等。

2、進行白盒測試，首先你要會程式設計比如Java、python等。

測試的時候你可能需要寫一點簡單的程式碼來呼叫這個函式，這就是所謂的驅動函式，你也可能需要寫一些程式碼來接收或者驗證被測單元的輸出是否正確，這就是所謂的樁函式；白盒測試方法就是你透過分析被測單元的實現程式碼，根據不同的測試策略（如分支覆蓋或者邏輯覆蓋等）來設計測試用例並作相應的測試。

一般是針對程式碼進行測試，測試中發現的缺陷可以定位到程式碼級，根據測試工具原理的不同，又可以分為靜態測試工具和動態測試工具。靜態測試工具直接對程式碼進行分析，不需要執行程式碼，也不需要對程式碼編譯連結，生成可執行檔案。靜態測試工具一般是對程式碼進行語法掃描，找出不符合編碼規範的地方，根據某種質量模型評價程式碼的質量，生成系統的呼叫關係圖等；動態測試工具與靜態測試工具不同，動態測試工具的一般採用“插樁”的方式，向程式碼生成的可執行檔案中插入一些監測程式碼，用來統計程式執行時的資料。其與靜態測試工具最大的不同就是動態測試工具要求被測系統實際執行。

白盒測試工具一般是針對程式碼進行測試，測試中發現的缺陷可以定位到程式碼級，根據測試工具原理的不同，又可以分為靜態測試工具和動態測試工具。靜態測試工具直接對程式碼進行分析，不需要執行程式碼，也不需要對程式碼編譯連結，生成可執行檔案。靜態測試工具一般是對程式碼進行語法掃描，找出不符合編碼規範的地方，根據某種質量模型評價程式碼的質量，生成系統的呼叫關係圖等；動態測試工具與靜態測試工具不同，動態測試工具的一般採用“插樁”的方式，向程式碼生成的可執行檔案中插入一些監測程式碼，用來統計程式執行時的資料。其與靜態測試工具最大的不同就是動態測試工具要求被測系統實際執行。

提到白盒測試的用例，首先想到的是介面測試用例和邏輯覆蓋用例，但小白最近遇到了這樣的一個問題：

問題：黑盒白盒同時進入測試，黑盒測平臺，白盒測核心，專案上線時間為平臺測試結束時間，開始迫於壓力將核心的測試完成時間壓縮到上線前，但後期時間緊張，測試混亂、不全面，上線問題較多，壓力山大。

面對這樣的問題大家怎麼考慮的呢，我認為這個問題的直接原因有兩個：

白盒測試效率較低，前期需要鋪墊的東西較為複雜（程式碼瞭解、用例編寫、用例除錯等），等白盒測試這邊鋪墊完成，黑盒這邊功能都測完了；

白盒測試人員考慮問題簡單，認為所有待測的核心功能都需要白盒測試，沒有針對不同的功能選擇測試的方法，導致將大量的時間耗費在一些沒有必要做白盒測試的功能上；

怎樣解決這樣的問題呢，首先要先清楚各種測試手段的優勢和劣勢：

隨機測試的時間消耗最少但覆蓋面也最小，適合做迴歸測試；

黑盒測試的時間消耗中等覆蓋面較全面，適合做直觀功能的測試；

白盒測試的時間消耗較高但覆蓋面十分全面，適合做核心邏輯的驗證；

自動化測試的時間消耗極高可覆蓋規模性的資料，適合做策略性的驗證；

根據上面所述測試手段的優勢和劣勢，我們嘗試用下面的辦法解決上述的問題：

白盒測試排期前，需要針對測試的功能和測試的時間判斷測試的手段，根據測試手段的不同和時間消耗給出準確的排期；

對於專案進行中插入進來的任務要考慮當前測試時間是否寬裕、插入任務是否複雜，考慮後再判斷是否要接插入任務；

過程中遇到白盒用例設計較為複雜的情況時，應考慮是否可以採用其他方式（如黑盒測試）的方式來解決，不應鑽牛角尖，將大量時間花費在寫用例程式碼上。