浅析软件测试之灰盒测试-软件测试白盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

“白盒”测试又称结构测试，在测试过程中测试者可以看到被测的源程序，通过分析程序的内部结构，根据其内部结构设计测试用例。理想的“白盒”测试应该使选取的测试用例覆盖所有的路径，然而，这是不可能的，而且“白盒”测试不关注测试程序的外部功能。

“黑盒”测试又称功能测试，在测试过程中被测程序被视为黑盒，测试者在完全不考虑程序内部结构和内部特征（或对于上述信息无从获知）的情况下，根据需求规格说明书设计测试用例和推断测试结果的正确性。“黑盒”测试的不足在于，测试用例的选择只考虑了程序的输入，以及在该情况下的输出，并没有考虑程序的内部结构。因此，程序内部结构是否规范、结构化程度的好坏、系统的性能如何等都得不到测试。

“白盒”测试和“黑盒”测试各有其自身的特点，但也都存在着明显的不足，主要表现在只考虑了程序某一方面的属性和特征，没有综合考虑。要进行较全面的程序测试，不得不把测试工作分两次进行，用“白盒”测试方法测试一次，再用“黑盒”测试方法测试一次。这不但浪费时间，而且测试的效果不一定好。“灰盒”测试正是基于这一点提出的。

“灰盒”测试是一种综合测试法，它将“黑盒”测试、“白盒”测试结合在一起，构成一种无缝测试技术。“灰盒” 测试以程序的主要性能和主要功能为测试依据，测试方法主要根据程序的程序图、功能说明书以及测试者的实践经验来设计。这里所说的主要性能和主要功能凭借测试者的经验来确定，即可以把容易发生错误的变量域及程序图（非流程图）作为测试的内容，而把那些不容易发生错误的变量输入和流程图中的不影响或不改变内部逻辑的细节忽略。事实上，许多测试工作是在不完全了解程序的内部逻辑的情况下进行的，这也就是“灰色”的由来。

同时，“灰盒”测试涉及输入和输出，但通常使用关于代码和程序操作等在测试人员视野之外的信息设计测试。在现在的测试工程中，最常见的“灰盒”测试是集成测试。但是“灰盒”测试的概念已经由原来单一的“黑盒”测试和“白盒”测试的一些测试方法的简单叠加，衍生出许许多多新颖的分析方法。

跟“黑盒”测试和“白盒”测试相比，“灰盒”测试有以下特性：

“灰盒”测试通常是在集成测试前期进行的，“灰盒”测试通常在程序员做完“白盒”测试之后，在功能测试人员进行大规模集成测试之前进行的。
“灰盒”测试需要了解代码工程的实现。
“灰盒”测试是通过类似“白盒”测试的方法进行的，是通过编写代码，调用函数或者封装好的接口进行的。
“灰盒”测试是由测试人员进行测试的。

在软件测试领域，对“灰盒”测试的应用属于比较新型的尝试，它打破了长久以来“黑盒”和“白盒”测试技术在这一领域的统治地位。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，才能完全覆盖到语句，这就是“黑盒”测试与“白盒”测试相结合的产物。

希望对你有帮助。

【编辑推荐】