灰盒测试

出自 MBA智库百科(https://wiki.mbalib.com/)

　　灰盒测试定义为将根据需求规范说明语言(RSL)产生的基于测试用例的要求(RBTC)，用测试单元的接口参数加到受测单元，检验软件在测试执行环境控制下的执行情况。灰盒测试法的目的是验证软件满足外部指标要求以及软件的所有通道都进行了检验。通过该程序的所有路径都进行了检验和验证后，就得到了全面的验证。完成功能和结构验证后，就可随机地一次变化一行来验证软件测试用例在软件遇到违背原先验证的不利变化时软件的可靠性。灰盒测试法是在功能上验证嵌入式系统软件的一种10步骤法。

　　1999年，美国洛克希德公司发表了灰盒测试法的论文，提出了灰盒测试法。灰盒测试是一种综合测试法，它将黑盒测试、白盒测试、回归测试和变异(Mutation)测试结合在一起，构成一种无缝测试技术。它是一种软件全寿命周期测试法，用于在功能上检验为嵌入式应用研制的Ada、C、FORTRAN和汇编语言软件。该方法可自动生成所有测试软件，从而降低了成本，减少了软件的研制时间。初步研究表明过去要用几天时间对一套软件进行彻底测试，现在不到4小时就可完成，软件测试时间减少75％。

　　灰盒测试方法是指结合白盒测试和黑盒测试的测试方法。

　　白盒测试，又称结构测试，在测试过程中测试者可以看到被测的源程序，通过分析程序的内部结构，根据其内部结构设计测试用例J。黑盒测试，又称功能测试，在测试过程中被测程序被视为黑盒，测试者在完全不考虑程序内部结构和内部特征(或对于上述信息无从获知)的情况下，根据需求规格说明书设计测试用例和推断测试结果的正确性。

　　显然，这两类测试方法是从完全不同的角度出发对软件进行测试。实践证明，两类方法各有侧重，在测试的实践中都是有效和实用的，不能指望一类方法能够完全代替另一类方法。但显然二者又各具缺点，这些缺点不是通过在各自的测试方法内部进行完善就能够解决的。只有通过将二者有效地结合，即进行所谓的“灰盒测试”，才能弥补任何一种方法的不足，使测试方法的机理更完善。

　　传统意义上的软件可靠性测试的实践方法是根据用户实际使用软件的方式，即运行剖面生成测试数据，利用测试数据驱动软件运行，获得失效数据，利用现有的软件可靠性模型进行评估，直到可靠性估计以某种形式收敛。软件可靠性测试从概念上讲采用的是黑盒测试方法，因为它是面向需求、面向使用的测试，它不需要了解程序的结构以及如何实现等问题，测试数据的生成和可靠性估计与测试中软件如何运行没有任何明确的关系。这种明确关系的缺乏，是我们反对用单纯的“黑盒测试”方法估计软件可靠性的出发点。

　　而且，这种传统作法生成的测试数据中，很多是对程序结构的重复执行，使得某些结构测试的密度高，某些结构测试的密度低，带来了许多无用的测试代价。大量的测试数据需要花费大量的人力、物力和财力，在交货期限紧张的情况下，往往不能满足，导致获得的可靠性估计值是不可信的。因此，需要结合“白盒测试”的信息，作为衡量测试质量和控制测试进程的手段。