前面小节分别介绍了黑盒测试与白盒测试技术的应用,两者各有其优缺点。就好像矛与盾的关系,在不同的场合下,都有各自的用武之地。那么是否有一种介于黑盒测试与白盒测试之间的测试技术呢?回答是肯定的,那就是灰盒测试。
小贴士:
灰盒测试:灰盒测试是介于白盒测试和黑盒测试之间的一种测试方法,或者说是两者的结合,也有人称集成测试为灰盒测试。它关注输出对于输入的正确性,同时也关注内部表现,但这种关注不像白盒测试那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,或者说参考部分代码去做黑盒测试。
灰盒测试,正如其定义中陈述的,是介于黑盒测试与白盒测试之间的一种测试方法。由于这种测试方法在业界并没有像黑盒测试和白盒测试那样使用普遍,在讲述这种方法在项目测试中如何决策之前,我们先来看看这种方法的具体含义,以及在项目中如何操作、能给我们带来哪些好处、不足之处又是什么。如图5-9所示是灰盒测试空间示意图。
图5-9 灰盒测试空间示意图
上图,我们可以形象地理解为它就是一个方块盒子,对于黑盒测试,我们看不到盒子内部,所以全都是黑色的。但对于灰盒测试,它仍有黑色方块存在,但已出现一层层白线围起来的方块,表示看到了部分代码的实现,白线越密意味着关注的代码越多,最深处几乎为全白了。
灰盒测试结合了白盒测试与黑盒测试的要素,它考虑了用户端、特定的系统知识和操作环境,在系统组件的协同性环境中评价应用软件的设计。具体说来,灰盒测试是在了解代码实现的基础上,通过黑盒功能测试加以判断,以验证软件实现的正确性。在理解概念的基础上,开展实际工作,依据笔者的最佳实践,在以下几方面能较好地体现此方法的优点:
能有效地发现黑盒测试盲点。通过了解代码的内部实现,补充功能测试用例。这需要灰盒测试人员在查看代码之前,掌握需求,并清楚已有的功能测试用例。对某一功能点的实现进行代码分析(白盒测试),然后与黑盒测试(功能测试)充分结合起来,相互弥补,这就是灰盒测试的精髓。
可以避免过度测试,精简冗余用例。例如具有相同特点的某一功能,在进行功能测试时,是否每个界面或提示框、对话框都需进行该功能的测试。在没有采用灰盒测试之前,我们确实这样穷极测试过,虽说不上没有效果,但收效甚微。下面案例便是一个典型的例子。
能及时发现没有来源的更改。特别是在产品的维护阶段,每一行代码的更改都必须要有更改来源,但实际开发过程中,并不是每个开发人员都能做到,也并不是每个人都能清楚意识到更改后没有得到有效验证所带来的后果。像开发人员好心办坏事的例子已是屡见不鲜,所以测试人员采取事后代码审查的方法也是不得已而为之的事。
【案例】PDA闹钟事件的测试
背景描述:闹钟是PDA(Personal Digital Assistant)上的一个应用程序,它的主要功能就是在用户设置的时间点到达时,进行响铃提醒。响铃时,无论用户当前在做什么操作,会弹出一个响铃提示界面。
提出问题:一天,负责测试此模块的工程师小叶提出一个问题“闹铃事件优先级高,在所有应用程序界面、对话框或提示框上面都会弹出,黑盒测试需要进入所有情况的用户界面,然后等待闹钟事件的发生,才能全面验证到各种情况的用户使用场景。”但这样穷举测试,需耗的时间太多,效果也并不一定好。
分析问题:关于闹钟的应用,实际上该模块只提供了一个接口。如能从代码角度分析到所有其他模块调用的是同一个闹铃接口函数(对于响铃及停止响铃后对原界面的恢复,都是统一一个接口处理的),那么再通过黑盒功能测试,在某一个用户界面进行此响铃功能的验证,即可证明代码的实现是符合需求的,这正是灰盒测试的方法。
解决问题:后来,对于闹铃功能点的系统验证,采用了灰盒测试的方法,做了代码正向、逆向分析,结合功能性用户场景进行验证,节省了近2/3的测试时间。
相关链接: