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