細說白盒測試

大家好我是飼養員，今天跟大家細說下什麼是白盒測試。

在進行日常測試的時候，我們大部分時間花在手動的功能測試上，功能測試又可稱為手工測試，官方一點的學名叫黑盒測試，當然作為測試工程師，我們一般俗稱點點點。

黑盒測試是一種軟體測試方法，它的主要目的是檢查軟體的功能和效能，而不考慮軟體的內部實現和程式碼。在黑盒測試中，測試人員不瞭解軟體的內部結構和實現，只能根據軟體的需求文件（PRD）、使用者手冊或其他相關文件，來設計測試用例和執行測試。

在進行黑盒測試時，不需要看程式碼，而是直接根據需求文件編寫黑盒測試用例，根據測試用例就可以進行業務測試。

那什麼是白盒測試呢？

白盒測試是一種軟體測試方法，它透過檢查和評估軟體程式碼的內部結構和實現細節來測試軟體的功能、安全性和穩定性。在白盒測試中，測試人員通常具有軟體開發和程式設計的知識，可以訪問程式碼和系統的內部結構，以檢查程式碼是否符合規範和標準，是否遵循最佳實踐和設計原則。

對比黑盒測試和白盒測試的最大區別，就是測試工程師能否看到開發寫的程式碼。白盒測試究竟該怎麼做，在一直做點點點的同學心裡一直是一個謎，其實白盒測試本來在業界並沒有完整的方法論標準。看過許多軟體測試相關書籍以及部落格，大家瞭解到的白盒測試理論一般侷限在白盒測試的分類以及 6 種常用白盒測試的覆蓋方法。

白盒測試的分類

• 靜態分析：不需要執行程式程式碼，就可以進行的測試，例如：Code Review（程式碼走查）、靜態程式碼掃描。
• 動態分析：需要執行程式程式碼，才可以進行的測試，例如：單元測試，Debug 測試，打樁測試等。

6 種白盒測試的覆蓋方法

• 語句覆蓋：每條語句至少執行一次
• 判定覆蓋：每個判定的每個分支至少執行一次
• 條件覆蓋：每個判定的每個條件應取到各種可能的值
• 判定條件覆蓋：同時滿足判定覆蓋條件覆蓋
• 條件組合覆蓋：每個判定中各條件的每一種組合至少出現一次
• 路徑覆蓋：使程式中每一條可能的路徑至少執行一次

若按照覆蓋嚴格程度來看，語句覆蓋< 判定覆蓋 < 條件覆蓋 < 判定條件覆蓋 < 條件組合覆蓋 < 路徑覆蓋，即在這 6 種覆蓋方法中最嚴格的是路徑覆蓋。

看到這裡對於新人小白來說，可能就會產生疑問了，做好白盒測試，是不是隻要達到最嚴格的路徑覆蓋就行？理論能夠指導實踐，我們可以根據覆蓋方法進行白盒測試，但不管是黑盒還是白盒測試，測試的目的都是在有限的測試時間內，儘量發現更多的 Bug，而不是追求更加嚴格的測試覆蓋率。

做好白盒測試的關鍵點

那麼做好的白盒測試的關鍵點到底是什麼呢？丟擲一個觀點就是理解程式碼，換句話說就是能看懂開發寫的每一行程式碼，並定位到有問題的程式碼行，至於是否要達到白盒測試中的非常嚴格的覆蓋程度是次要的。

為什麼會這麼說？主要是因為看懂程式碼是發現 Bug 的最快方式，掃一眼就能知道這裡會不會有 Bug，當然想擁有這樣過眼就能發現問題的能力，需要掌握紮實的計算機基礎以及看過幾萬甚至幾十萬行程式碼。另外開發寫的程式碼當中，有的邏輯並沒有分支，所以達到語句覆蓋就行，個別存在多個分支的情況可以考慮加大覆蓋程度，如到達條件覆蓋，但達到更高的覆蓋率意味著測試時間會拉長。

測試是否要去看開發的程式碼，是一個長久以來比較有爭議的話題，持反對意見的同學認為沒必要看，公司沒要求，自己也看不懂，有問題直接拋給開發。

但從目前測試行業來看，以及微服務架構和前後端分離的流行，網際網路大廠的測試早已經劃分出一種測試角色，叫服務端測試，也稱 SQA（Server QA），這種工種承接的日常測試工作，基本以介面測試，Code Review，以及後端程式碼的白盒測試為主，也是目前在測試行業裡面發展相對前景較好的崗位。

綜上，能夠看懂程式碼對於我們測試來說，只有好處沒有任何壞處，在就業環境如此差的今天，測試能看懂程式碼就是一道分水嶺！

白盒測試舉例

從看懂程式碼語法，再到理解程式碼，再到定位 Bug 到程式碼行，提供修改建議，是一個循序漸進的過程。

程式碼究竟怎麼看才能快速發現問題，應該關注哪些測試點，拿一個比較典型的介面來舉例子，下面是一段虛擬碼，描述了一個很常見的業務場景，如果 Redis 快取中有資料，則讀取 Redis 當中的資料，沒有資料則讀取資料庫 DB 裡面的資料。

如果要測試這段程式碼，需要檢查 Redis 裡面有資料的情況下，是否能正常從 Redis 當中讀取資料。同理，需要檢查在 Redis 沒有資料的情況下，能否正常從 MySQL 當中讀取資料。
為了便於驗證資料，我們可以使用程式語言自帶的列印函式，如各大程式語言當中的 print 函式，PHP 當中的 var_dump，或者呼叫程式碼框架當中已經封裝好列印日誌函式。

測試這段程式碼的核心關鍵是在於理清資料流，變數 var 從哪裡來，接下來又會在哪些地方去使用，理清資料流同樣也是白盒測試當中的關鍵點。
留一個思考題，假設在測試過程當中，發現 Redis 裡面有資料，但是經過 Debug 後發現，程式碼邏輯走到了讀取資料庫當中的資料，這個問題產生的原因是什麼？

最後

在白盒測試當中，理解程式碼和理清資料流是做好白盒測試兩個關鍵點，至於能夠在白盒測試當中發現多少問題，取決於測試工程師對於技術的理解深度。