淺析軟件測試之灰盒測試
灰盒測試，是介于白盒測試與黑盒測試之間的，可以這樣理解，灰盒測試關注輸出對于輸入的正確性，同時也關注內部表現，但這種關注不象白盒那樣詳細、完整，只是通過一些表征性的現象、事件、標志來判斷內部的運行狀態，有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法。
“白盒”測試又稱結構測試，在測試過程中測試者可以看到被測的源程序，通過分析程序的內部結構，根據其內部結構設計測試用例。理想的“白盒”測試應該使選取的測試用例覆蓋所有的路徑，然而，這是不可能的，而且“白盒”測試不關注測試程序的外部功能。
“黑盒”測試又稱功能測試，在測試過程中被測程序被視為黑盒，測試者在完全不考慮程序內部結構和內部特征（或對于上述信息無從獲知）的情況下，根據需求規格說明書設計測試用例和推斷測試結果的正確性。“黑盒”測試的不足在于，測試用例的選擇只考慮了程序的輸入，以及在該情況下的輸出，并沒有考慮程序的內部結構。因此，程序內部結構是否規范、結構化程度的好壞、系統的性能如何等都得不到測試。
“白盒”測試和“黑盒”測試各有其自身的特點，但也都存在著明顯的不足，主要表現在只考慮了程序某一方面的屬性和特征，沒有綜合考慮。要進行較全面的程序測試，不得不把測試工作分兩次進行，用“白盒”測試方法測試一次，再用“黑盒”測試方法測試一次。這不但浪費時間，而且測試的效果不一定好。“灰盒”測試正是基于這一點提出的。
“灰盒”測試是一種綜合測試法，它將“黑盒”測試、“白盒”測試結合在一起，構成一種無縫測試技術。“灰盒” 測試以程序的主要性能和主要功能為測試依據，測試方法主要根據程序的程序圖、功能說明書以及測試者的實踐經驗來設計。這里所說的主要性能和主要功能憑借測試者的經驗來確定，即可以把容易發生錯誤的變量域及程序圖（非流程圖）作為測試的內容，而把那些不容易發生錯誤的變量輸入和流程圖中的不影響或不改變內部邏輯的細節忽略。事實上，許多測試工作是在不完全了解程序的內部邏輯的情況下進行的，這也就是“灰色”的由來。
同時，“灰盒”測試涉及輸入和輸出，但通常使用關于代碼和程序操作等在測試人員視野之外的信息設計測試。在現在的測試工程中，最常見的“灰盒”測試是集成測試。但是“灰盒”測試的概念已經由原來單一的“黑盒”測試和“白盒”測試的一些測試方法的簡單疊加，衍生出許許多多新穎的分析方法。
跟“黑盒”測試和“白盒”測試相比，“灰盒”測試有以下特性：
- “灰盒”測試通常是在集成測試前期進行的，“灰盒”測試通常在程序員做完“白盒”測試之后，在功能測試人員進行大規模集成測試之前進行的。
- “灰盒”測試需要了解代碼工程的實現。
- “灰盒”測試是通過類似“白盒”測試的方法進行的，是通過編寫代碼，調用函數或者封裝好的接口進行的。
- “灰盒”測試是由測試人員進行測試的。
在軟件測試領域，對“灰盒”測試的應用屬于比較新型的嘗試，它打破了長久以來“黑盒”和“白盒”測試技術在這一領域的統治地位。DO-178B規范也新進加入了利用“灰盒”測試方法來進行作業的標準。
下面是根據一個實例來介紹一種傳統的“白盒”測試與“黑盒”測試相結合的“灰盒”測試方法的應用。
（1） 閱讀需求
- SDRD26537 (Software Design Requirement Document)
- Requirement: Yes
- Delivery: AESS
- Magnetic Heading shall be ser invalid if value outside range of -180 inclusive and 180 exclusive.
- [/TCAS TPA-100X/Tests]
需求要求飛機在巡航過程中它的有效磁場角度范圍為[–180，180]。（因為這是航空領域的實例，有些是專業術語或縮寫，但這不影響閱讀）
（2） 分析需求
這個例子很簡單，根據分析，測試人員優先選擇“黑盒”測試方法的邊界值分析方法，并確定取值范圍為[-180，180]。設計一個健壯最壞情況邊界值分析測試用例如下：–180.1， –180.0， –179.9， –1.0， 0.0， 1.0， 180.0， 179.9 。
（3） 根據分析寫出測試用例腳本
詳細的測試用例腳本由于篇幅太長，故不在這里一一寫出。然后將測試用例腳本在測試環境里運行出結果。
但是在后面的測試工作中出現了意外，雖然測試用例的結果獲得了通過，但是在做代碼的“白盒”覆蓋率時，未達到規定的覆蓋率要求。為什么這么簡單的一個單元測試失敗了呢？在重新分析了需求和測試腳本以后，我們排除了這兩方面帶來的問題，原因很可能出在根據需求設計的腳本和源代碼的實現有出入。
（4） 分析相應的源代碼
找到源代碼的相應模塊，如下所示：
- //========================================================================
- const float MAX_VALID_ANGLE = 180.0;
- bool TcasAircraftInputSignallfcClass::getTrueHeading(int *argValue)
- {
- static const float scalingFactor = 16384.0 / 90.0;
- float roundFactor =(((1.0 / 16384.0)/2.0)*90.0);
- float temp;
- if (trueHeading->get(&temp))
- {
- temp=(temp<MAX_VALID_ANGLE -roundFactor ? temp : MAX_VALID_ANGLE - roundFactor);
- temp=(temp>+-MAX_VALID_ANGLE+roundFactor?temp : -MAX_VALID_ANGLE+roundFactor);
- if (temp < 0)
- {
- roundFactor = -roundFactor;
- }
- *argValue = (int)((temp + roundFactor)*scalingFactor);
- return(true);
- }
- else
- {
- //return false signal is invalid
- return(false);
- }
- }
經過對源代碼的仔細分析，果然發現了問題所在。由于“黑盒”測試的特征以及DO-178B的規范，測試人員是完全根據需求文檔來設計的測試用例。而需求文檔在設計的時候設置的磁角度精確值統一為0.1，但是在實際軟件開發過程中，因為可靠性的要求，精確度提升到了0.001。
需求文檔卻未相應更新，導致最終的覆蓋率失敗。在這里，不能取179.9，而必須取179.998，才能完全覆蓋到語句，這就是“黑盒”測試與“白盒”測試相結合的產物。
希望對你有幫助。
【編輯推薦】
