淺析軟件測試之灰盒測試
灰盒測試，是介于白盒測試與黑盒測試之間的，可以這樣理解，灰盒測試關(guān)注輸出對于輸入的正確性，同時也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細(xì)、完整，只是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運行狀態(tài)，有時候輸出是正確的，但內(nèi)部其實已經(jīng)錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法。
“白盒”測試又稱結(jié)構(gòu)測試，在測試過程中測試者可以看到被測的源程序，通過分析程序的內(nèi)部結(jié)構(gòu)，根據(jù)其內(nèi)部結(jié)構(gòu)設(shè)計測試用例。理想的“白盒”測試應(yīng)該使選取的測試用例覆蓋所有的路徑，然而，這是不可能的，而且“白盒”測試不關(guān)注測試程序的外部功能。
“黑盒”測試又稱功能測試，在測試過程中被測程序被視為黑盒，測試者在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特征（或?qū)τ谏鲜鲂畔o從獲知）的情況下，根據(jù)需求規(guī)格說明書設(shè)計測試用例和推斷測試結(jié)果的正確性。“黑盒”測試的不足在于，測試用例的選擇只考慮了程序的輸入，以及在該情況下的輸出，并沒有考慮程序的內(nèi)部結(jié)構(gòu)。因此，程序內(nèi)部結(jié)構(gòu)是否規(guī)范、結(jié)構(gòu)化程度的好壞、系統(tǒng)的性能如何等都得不到測試。
“白盒”測試和“黑盒”測試各有其自身的特點，但也都存在著明顯的不足，主要表現(xiàn)在只考慮了程序某一方面的屬性和特征，沒有綜合考慮。要進行較全面的程序測試，不得不把測試工作分兩次進行，用“白盒”測試方法測試一次，再用“黑盒”測試方法測試一次。這不但浪費時間，而且測試的效果不一定好。“灰盒”測試正是基于這一點提出的。
“灰盒”測試是一種綜合測試法，它將“黑盒”測試、“白盒”測試結(jié)合在一起，構(gòu)成一種無縫測試技術(shù)。“灰盒” 測試以程序的主要性能和主要功能為測試依據(jù)，測試方法主要根據(jù)程序的程序圖、功能說明書以及測試者的實踐經(jīng)驗來設(shè)計。這里所說的主要性能和主要功能憑借測試者的經(jīng)驗來確定，即可以把容易發(fā)生錯誤的變量域及程序圖（非流程圖）作為測試的內(nèi)容，而把那些不容易發(fā)生錯誤的變量輸入和流程圖中的不影響或不改變內(nèi)部邏輯的細(xì)節(jié)忽略。事實上，許多測試工作是在不完全了解程序的內(nèi)部邏輯的情況下進行的，這也就是“灰色”的由來。
同時，“灰盒”測試涉及輸入和輸出，但通常使用關(guān)于代碼和程序操作等在測試人員視野之外的信息設(shè)計測試。在現(xiàn)在的測試工程中，最常見的“灰盒”測試是集成測試。但是“灰盒”測試的概念已經(jīng)由原來單一的“黑盒”測試和“白盒”測試的一些測試方法的簡單疊加，衍生出許許多多新穎的分析方法。
跟“黑盒”測試和“白盒”測試相比，“灰盒”測試有以下特性：
- “灰盒”測試通常是在集成測試前期進行的，“灰盒”測試通常在程序員做完“白盒”測試之后，在功能測試人員進行大規(guī)模集成測試之前進行的。
- “灰盒”測試需要了解代碼工程的實現(xiàn)。
- “灰盒”測試是通過類似“白盒”測試的方法進行的，是通過編寫代碼，調(diào)用函數(shù)或者封裝好的接口進行的。
- “灰盒”測試是由測試人員進行測試的。
在軟件測試領(lǐng)域，對“灰盒”測試的應(yīng)用屬于比較新型的嘗試，它打破了長久以來“黑盒”和“白盒”測試技術(shù)在這一領(lǐng)域的統(tǒng)治地位。DO-178B規(guī)范也新進加入了利用“灰盒”測試方法來進行作業(yè)的標(biāo)準(zhǔn)。
下面是根據(jù)一個實例來介紹一種傳統(tǒng)的“白盒”測試與“黑盒”測試相結(jié)合的“灰盒”測試方法的應(yīng)用。
（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]。（因為這是航空領(lǐng)域的實例，有些是專業(yè)術(shù)語或縮寫，但這不影響閱讀）
（2） 分析需求
這個例子很簡單，根據(jù)分析，測試人員優(yōu)先選擇“黑盒”測試方法的邊界值分析方法，并確定取值范圍為[-180，180]。設(shè)計一個健壯最壞情況邊界值分析測試用例如下：–180.1， –180.0， –179.9， –1.0， 0.0， 1.0， 180.0， 179.9 。
（3） 根據(jù)分析寫出測試用例腳本
詳細(xì)的測試用例腳本由于篇幅太長，故不在這里一一寫出。然后將測試用例腳本在測試環(huán)境里運行出結(jié)果。
但是在后面的測試工作中出現(xiàn)了意外，雖然測試用例的結(jié)果獲得了通過，但是在做代碼的“白盒”覆蓋率時，未達(dá)到規(guī)定的覆蓋率要求。為什么這么簡單的一個單元測試失敗了呢？在重新分析了需求和測試腳本以后，我們排除了這兩方面帶來的問題，原因很可能出在根據(jù)需求設(shè)計的腳本和源代碼的實現(xiàn)有出入。
（4） 分析相應(yīng)的源代碼
找到源代碼的相應(yīng)模塊，如下所示：
- //========================================================================
- 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);
- }
- }
經(jīng)過對源代碼的仔細(xì)分析，果然發(fā)現(xiàn)了問題所在。由于“黑盒”測試的特征以及DO-178B的規(guī)范，測試人員是完全根據(jù)需求文檔來設(shè)計的測試用例。而需求文檔在設(shè)計的時候設(shè)置的磁角度精確值統(tǒng)一為0.1，但是在實際軟件開發(fā)過程中，因為可靠性的要求，精確度提升到了0.001。
需求文檔卻未相應(yīng)更新，導(dǎo)致最終的覆蓋率失敗。在這里，不能取179.9，而必須取179.998，才能完全覆蓋到語句，這就是“黑盒”測試與“白盒”測試相結(jié)合的產(chǎn)物。
希望對你有幫助。
【編輯推薦】
