章七 帶上X光眼鏡測試軟體

章七 帶上X光眼鏡測試軟體

本章講四個基本測試之中的第四個——動态白盒測試。另三個為靜态黑盒（測試産品說明書）、動态黑盒（測試軟體）和靜态白盒（檢查程式代碼）。

一、動态白盒測試

1、動态白盒測試是指利用檢視代碼功能（做什麼）和實作方式（怎麼做）得到的資訊來确定哪些需要測試、哪些不要測試、如何開展測試。

2、動态白盒測試的另一個常用名稱是結構化測試（structural testing），因為軟體測試員可以檢視并使用代碼的内部結構，進而設計和執行測試。

3、動态白盒測試不僅僅是檢視代碼的運作情況，還包括直接測試和控制軟體，動态白盒測試包括以下4個部分：

（1）直接測試底層函數、過程、子程式和庫。在windows中稱為API。

（2）以完整程式的方式從頂層測試軟體，但是根據對軟體運作的了解調整測試用例。

（3）從軟體獲得讀取變量和狀态資訊的通路權，以便确定測試與期望結果是否相符，同時，強制軟體以正常測試難以實作的方式運作。

（4）估算執行測試時“命中”的代碼量和具體代碼，然後調整測試，去掉多餘的測試用例，補充遺漏的用例。

二、動态白盒測試和調試

不要混淆動态白盒測試和調試，兩者表面上相似，因為它們都包括處理軟體缺陷和檢視代碼的過程，但目标大不相同。

動态白盒測試的目标是尋找軟體缺陷，調試的目标是修複缺陷。然而它們在隔離軟體缺陷的位置和原因上确實存在交叉現象。

執行這些底層的測試，會用到許多和程式員使用的相同的工具。如果程式編譯過，可能會使用相同的編譯器。

可能會使用代碼級的調試器來單步跟蹤程式，觀察變量，設定斷點，等等。也可能自己編寫程式來分别測試需要檢查的子產品代碼。

三、分段測試

一般産生高額費用的原因有：

（1）難以找出導緻問題的原因；

（2）某些軟體缺陷掩蓋了其它軟體缺陷，測試可能失敗。

1、單元測試和內建測試

解決上述問題的方法當然是一開始就不讓它發生。如果代碼分段建構和測試，最後合在一起形成更大的部分，那麼整個産品無疑會連結在一起。

在底層進行的測試稱為單元測試（unit testing）或者子產品測試（module testing）。單元經過測試，底層軟體缺陷被找出并修複之後，就內建在一起，對子產品的組合進行內建測試（integration testing）。這個不斷增加的測試過程繼續進行，加入越練越多的軟體片段，直至整個産品——至少是産品的主要部分——在稱為系統測試（system testing）的過程中一起測試。

采取這種測試政策很容易隔離軟體缺陷。

在單元級發現問題時，問題肯定就在那個單元中，如果在多個單元內建時發現軟體缺陷，那麼它一定與子產品之間的互動有關。當然也有例外。

這種遞增測試有兩條途徑：自底向上（bottom－up）和自頂向下（top－down）。

在自底向上測試中，要編寫稱為測試驅動的子產品調用正在測試的子產品。測試驅動子產品以和将來真正子產品同樣的方式挂接，向處于測試的子產品發送測試用例資料，接受傳回結果，驗證結果是否正确。采取這種方式，可以對整個軟體進行非常全面的測試，為它提供全部類型和數量的資料，甚至高層難以發送的資料。

自頂向下測試有點像小規模的大爆炸測試。

2、單元測試用例

在進行白盒測試之前，一定要根據說明書建立黑盒測試用例，用這種方式可以真正測試子產品的功能和作用。

如果先從子產品的白盒角度建立測試用例，檢查代碼，就會偏向于以子產品工作方式建立測試用例。如程式員誤解了說明，于是測試用例就會不對。

雖然測試用例精确完整地測試了子產品，但是可能不準确，因為沒有測試預期的操作。

根據白盒知識增減測試用例時根據程式内部的資訊對等價劃分的進一步提煉。

四、資料覆寫

檢視代碼決定如何調整測試用例。合理的方法是像黑盒測試那樣把軟體代碼分成資料和狀态。從同樣的角度看軟體，可以相當容易地把得到的白盒資訊映射到已經寫完的黑盒測試用例上。

首先考慮資料。資料包括所有的變量、常量、數組、資料結構、鍵盤和滑鼠輸入、檔案、螢幕輸入/輸出、以及數據機、網絡等其它裝置的輸入和輸出。

1、資料流（Data Flow）

資料流覆寫主要是指在軟體中完全跟蹤一批資料。在單元測試級，資料僅僅通過了一個子產品或者函數。同樣的跟蹤方式可以用于多個內建子產品，甚至整個軟體産品。

如果在底層測試函數，就會使用調試器觀察變量在程式運作時的資料。通過黑盒測試，隻能知道變量開始和結束的值。通過動态白盒測試，還可以在程式運作期間檢查變量的中間值。根據觀察結果就可以決定更改某些測試用例。

2、次邊界

以下是次邊界導緻軟體缺陷最常見的例子：

（1）計算稅收的子產品在某些财務結算處可能從使用資料表轉向使用公式。

（2）在RAM底端運作的作業系統也許開始把資料移到硬碟上的臨時存儲區。這種次邊界甚至無法确定，它随着磁盤上剩餘空間的數量而發生變化。

（3）為了獲得更高的精度，複雜的數值分析程式根據數字大小可能切換到不同的等式以解決問題。

如果進行白盒測試，就需要仔細檢查代碼，找到次邊界條件，并建立能測試它們的測試用例。

3、公式和等式

公式和等式通常深藏于代碼中。

撇開代碼中的公式和等式，檢視它們使用的變量，在程式正常輸入和輸出之外，為其建立測試用例和等價劃分。

4、錯誤強制（error forcing）

如果執行在調試器中測試的程式，不僅能夠觀察到變量的值——還可以強制改變變量的值。

注意：在使用錯誤強制時，小心不要設定現實世界中不可能出現的情況。如果程式員在函數開頭檢查n值必須大于0，而且n值僅用于該公式中，那麼将n值設為0，使程式失敗的測試用例就是非法的。

如果仔細選擇了錯誤強制情況，并和程式員一起反複檢查以确認它們是合法的，錯誤強制就是一個有效的工具。

使用錯誤強制的上好方法就是迫使軟體中的所有錯誤提示資訊顯示出來。

大多數軟體使用内部錯誤代碼表示錯誤的提示資訊。

五、代碼覆寫（Code Coverage）

測試資料隻是一半的工作。為了全面地覆寫，還必須測試程式的狀态及程式流程。必須設法進入和退出每一個子產品，執行每一行代碼，進入軟體每一條邏輯和決策分支。這種類型的測試叫做代碼覆寫測試。

代碼覆寫測試是一種動态白盒測試。

代碼覆寫測試最簡單的形式是利用編譯環境的調試器通過單步執行程式檢視代碼。

對于小程式或者單獨子產品，使用調試器就足夠了。然而對大多數程式進行代碼覆寫測試要用到稱為代碼覆寫率分析器（code coverage analyzer）的專用工具。

代碼覆寫率測試器挂接在正在測試的軟體中，當執行測試用例時在背景執行。每當執行一個函數，一行代碼或一個邏輯決策分支時，分析器就記錄相應的資訊。從中可以獲得訓示軟體哪些部分被執行，哪些部分未被執行的統計結果。利用該資料可以得到：

（1）測試用例沒有覆寫軟體的哪些部分；

（2）哪些測試用例時多餘的；

（3）為了使覆寫率更好，需要建立什麼樣的新測試用例；

（4）軟體品質的大緻情況。

如果測試用例覆寫了軟體的90％而未發現任何軟體缺陷，就說明軟體品質非常好。這并非絕對。注意“殺蟲劑現象”，軟體測試得越多，它對測試的免疫能力越強，如果測試用例覆寫了軟體的90％而未發現任何軟體缺陷，也有可能使軟體的構造不好——可能是軟體對測試具有了免疫能力。增加新的測試用例可能會暴露餘下的10％具有非常多的缺陷。

1、程式語句和代碼行覆寫

代碼覆寫最直接的形式稱為語句覆寫（statement coverage）或者代碼行覆寫（line coverage）。如果在測試軟體的同時監視語句覆寫，目标就是保證程式中每一條語句最少執行一次。

遺憾的是，語句覆寫是一種誤導，即使全部語句都被執行了，也不能說走遍了軟體的所有路徑。

2、分支覆寫

試圖覆寫軟體中的所有路徑稱為路徑覆寫。路徑測試最簡單的形式稱為分支覆寫測試。

大多數代碼覆寫率分析器将根據代碼分支，分别報告語句覆寫和分支覆寫的結果，是軟體測試員更加清楚測試的效果。

3、條件覆寫

與分支覆寫一樣，代碼覆寫率分析器可以被設定為在報告結果時将條件考慮在内。如果測試條件覆寫，就能達到分支覆寫，順帶也能達到語句覆寫。