由于黑盒测试和白盒测试的关注点各不相同,它们在实际使用中也是各有利弊。而灰盒测试则综合了黑盒与白盒方法的优势,并有效地避开了两者各自的缺陷。
灰盒方法通过涵盖被测软件的所有层面,以增加技术的覆盖范围。如果说黑盒测试人员需要确保界面和功能方面的正常;白盒测试人员通过深入研究软件的内部结构,以修复源代码级别的错误,那么灰盒测试则是以非干扰的方式(non-intrusive)同时处理两方面的测试。
面对复杂的系统,灰盒方法借用简单的黑盒方法,让开发人员、测试人员、以及最终用户都能够上手测试。在测试用例方面,工程师需要具备部分内部结构的相关知识,其中包括:数据结构、体系架构、以及软件功能规范的文档。在此基础上生成的测试用例,可以有效地发现并消除由于软件使用不当,而暴露出的结构缺陷问题。
灰盒测试非常适合于集成测试,包括:缺乏源代码和二进制文件的Web应用,以及某些业务领域的需求规范性测试。
目前,最常见的灰盒测试设计技术有:
矩阵测试通过跟踪并映射用户的需求,以确保测试用例能够涵盖所有的方面。它能够像状态报告那样,通过全面的验证测试,来轻松地识别出任何缺少的功能。 回归测试是一种软件变更的影响分析。它往往能够检查出软件在被修改后是否还能够正常工作。据此,测试人员能够确保软件的变更既不会阻碍现有的功能,又不会引入新的错误。 模型测试会分析和检查在过往的构建、设计和软件体系架构中,测试到的缺陷。此类分析可被用于查找根本原因,以及某些给定缺陷背后的具体根源,进而防止复发。
灰盒测试的利弊
由于灰盒测试方法是基于功能规范、接口和文档等非干扰的方式开展的,因此它使得测试人员仅在宏观上获悉软件的体系架构,而不必完全访问其源代码或二进制文件。这就意味着测试人员和开发人员之间存在清晰的界线,进而保障了此类测试方法不带有任何的“偏见”。此外,灰盒测试还可以针对一些特殊的智能化授权测试场景,实现对数据类型、通信协议、以及各种异常的分析。
开展灰盒方法往往需要测试团队具有出色的某公司能力。也就是说,如果开发人员已经运行过了相关的测试用例,则不一定非要开展灰盒测试。与此同时,如果测试人员对于软件内部结构的了解非常有限,并且无法访问到其对应的源代码,那么灰盒测试可能会出现许多未经测试的代码路径,进而造成覆盖面的不足。它显然不适用于各种算法领域的测试。另外,如果您使用灰盒方法,在分布式系统中识别关联缺陷时,也往往会感觉到力不从心。 |