淺析白盒測試在軟件測試中的應用

田春竹 邢航

白盒測試，是軟件功能測試中的重要一環。在當前整個測試業務中，大家主要關注于黑盒測試，由于測試過程比較繁瑣、測試成本較高等方面的原因，白盒測試往往被大家直接忽略，所占的比例非常小。本文通過針對某油田系統的一個具體功能點，詳細闡述了白盒測試的基本過程，并說明了白盒測試對黑盒測試的有力補充。

一、軟件測試概述

隨著信息化的快速發展，信息系統的建設速度也越來越快，而且呈現出規模變大，復雜度增高的趨勢。在這種情況下，無論是進行系統開發的軟件公司，還是最終的系統用戶，都開始逐漸重視軟件測試，從而進一步推動了軟件測試的發展。

軟件測試一般可分為兩種，即黑盒測試和白盒測試。其中，白盒測試也被稱為結構測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。

二、白盒測試的主要方法及測試流程

（一）白盒測試的主要方法

目前的軟件測試，通常仍是以黑盒測試為主，但是黑盒測試并不一定能發現所有的問題，在必要情況下，需要使用白盒測試進行補充。

目前比較流行的白盒測試方法包括代碼檢查法、邏輯覆蓋法、基本路徑測試法等。其中，邏輯覆蓋法又可以包含語句覆蓋、判定覆蓋、條件覆蓋等。本文在此主要介紹邏輯覆蓋法的相關應用。

（二）白盒測試的主要流程

進行邏輯覆蓋法的主要測試流程如下：

1、制定測試計劃。即根據整體測試需求以及被測系統的需求規格說明書、設計文檔等來制定測試計劃。

2、進行模塊分析。在白盒測試過程中，測試人員對被測試程序的內部結構是清楚的，需要從程序的內部邏輯結構入手，按照一定的原則設計測試用例，對軟件的邏輯路徑進行測試。因此，進行模塊分析是非常重要的一個步驟，也是整個測試的重點和難點。模塊分析主要包括兩個部分，第一是針對被測模塊的功能進行分析，了解模塊的具體業務和功能，第二是針對代碼進行分析，查看源代碼中主要的方法、函數等。如果模塊分析不準確，則后續的其他工作都將失去意義。代碼分析和功能分析工作是相輔相成的，作為軟件測試人員，如果對業務細節不懂，就做不好相應的測試。但是要在很短的時間內把所測系統的業務細節完全搞懂，也是一件非常不容易的事情。因此，一邊了解功能一邊分析代碼，在某些情況下是非常必要的。

3、測試用例設計。在完全理解具體業務細節后，根據模塊分析結果和測試要求，進行測試用例的設計。

4、測試執行。根據測試用例執行測試，并詳細記錄測試結果。

5、測試總結。針對測試結果進行分析，確認發現的相關問題，并協助開發人員解決相關錯誤。

6、回歸測試。在開發人員完成修改后，針對模塊進行回歸測試。

三、白盒測試的具體應用

接下來通過一個實例來講述白盒測試中邏輯覆蓋法的具體應用。

（一）測試背景

某油田的信息中心人員自行開發了一套測井解釋系統，在經過開發人員的自行測試后，即開始進行內部試用。但是在使用過程中發現了很多問題，為確保系統功能的正確性，該單位（即委托單位）決定聘請第三方人員進行系統的功能測試。

由于在系統試用過程中，產生了部分正式數據，而委托單位因特殊原因無法提供專用的測試環境，為了盡量避免測試過程中對系統的正常使用造成麻煩，經過和委托單位協商，由委托單位統一提供所有的測試數據。同時，經過與委托單位協商，決定采用邏輯覆蓋的方式，對系統中的幾個重要功能點進行白盒測試。

（二）測試過程

在測試過程中，“工程測井”模塊中含有一個“方位井徑校正”的功能。它是在數據庫模式下進行方位井徑曲線數據的計算，計算完成后自動保存數據。如果之前已經存在曲線數據，可根據系統提示選擇是否進行覆蓋。

這是一個非常簡單而又常見的功能點。測試人員在進行黑盒測試時，錄入測試數據，首先點擊“計算”按鈕。系統彈出是否覆蓋數據的提示后，點擊“確定”，系統提示已經覆蓋數據，點擊“取消”后，系統界面未發生任何變化，也無任何提示，功能測試通過。

由于“工程測井”是本系統的一個重點模塊，在功能測試完畢后，開始進行白盒測試。具體過程如下：

1、根據“方位井徑校正”功能的具體業務，結合系統代碼（如圖1）及設計文檔，進行“計算”功能的流程分析，并標識出所有的判斷邏輯（如圖2）。

2、根據此流程圖，可以判斷出需要編寫五個測試用例，分別是

（1）TC_C_001曲線名是否為空的邏輯判定

（2）TC_C_002是否覆蓋原有數據的邏輯判定

……

其中TC_C_002是否覆蓋數據的邏輯判定，便是針對前面所述功能的分析結果。

3、設計測試用例

根據流程圖中的分析結果，結合系統設計文檔及具體代碼，完成了測試用例的設計，如表1所示。

4、執行測試用例

在執行此用例時，我們使用了開發平臺中的斷點調試，即分別點擊“確定”、“取消”按鈕后，使用斷點逐步查看各變量、參數的變化情況和代碼執行情況。

根據對設計文檔和系統代碼的分析，我們初步判斷，點擊“取消”按鈕后，系統應為option變量賦值為1，然后調用return函數結束當前執行的方法。但是實際測試過程中，點擊“取消”按鈕后，發現系統為變量option的賦值為2（如圖3所示）。之后并沒有通過調用return來結束方法的執行，而是繼續執行該方法，直到完成了一次覆蓋后，才結束當前的操作。

而點擊“確定”按鈕后，系統為變量option的賦值為0，程序跳過if判斷語句，同樣繼續執行覆蓋操作。

也就是說，無論界面上操作時點擊的是“確定”還是“取消”按鈕，其實后臺都執行了一次覆蓋操作。

（三）測試總結及回歸

為何在功能測試時未能發現這個問題呢？通過總結我們發現，由于該模塊只進行校正工作，校正后的數據是供后期其他模塊匯總使用。測試人員在測試過程中，對于執行是否成功，通過該模塊的界面看不到具體效果，僅能通過系統給出的是否覆蓋成功的提示做出簡單判斷，而委托單位提供的測試數據又非常單一，從而導致功能測試時未能發現此問題。

之后，我們與委托單位負責人，以及模塊開發人員共同進行了問題確認。在開發人員完成bug修改后，由業務人員提供了多組數據，并與測試人員一起針對本功能及相關聯內容進行了回歸測試，最終確認問題得到了解決，bug關閉。

四、結語

在軟件測試中，黑盒測試重點在于系統的功能性，而白盒測試則略微偏重于邏輯方面的測試，但是通過本文中的例子可以看出，二者并不沖突，而是互補。雖然通常情況下黑盒測試基本可以發現一個系統的大多數問題，但是在白盒測試過程中也可能會發現一些黑盒測試時未能發現的問題，反之亦然。對于任何一個系統測試來說，要想更好地實現其基本功能，做好后期的具體應用，在其前期測試過程中，白盒測試與黑盒測試都是必不可少的組成部分。