探索式测试之旅—灰盒测试的应用

【前言】

某一控件的属性修改了，而此控件被系统中的多个模块调用，你是如何测试此更改点的呢？

某一bug，并不是某一模块专有，开发更改后，你在为回归是否彻底而发愁吗？

某些测试点仅采用用户角度出发的黑盒功能测试，费时费力，且不一定全面、充分，如何解决呢？

等等，当仅采用黑盒测试方法不能满足测试需求时，探索性的尝试灰盒测试，或许能帮你解决这些问题。

下面从三个方面与大家分享笔者在灰盒测试探索上的一点心得与体会，包括灰盒测试的介绍，案例应用（由于工作上的案例涉及机密，不方便上传，笔者借用大家日常生活中常用的手机闹铃作为案例，希望能达到一种抛砖引玉的效果，借鉴应用到其他的测试场景中。方法是相通的，或许这种表达不能满足一些读者的理解，如有兴趣，可与我单独联系aul516@126.com），最后是一点应用小结。

【灰盒测试的介绍】

在软件测试领域，白盒测试与黑盒测试是众所周知的常用测试方法。这两种测试方法的特点泾渭分明，一个是“黑”,一个是“白”,这个“黑”与“白”是指是否需要看到代码内部实现来划分的。正如辩证唯物主义中提到的矛盾论所言,任何事物都有其正反两方面的特性,白盒测试方法与黑盒测试方法都有其突出的优点，相对的也就有其缺点。或许也正因为如此，这些年来，软件测试界的朋友在对这两种方法的不断实践中，一些实战派提出了介于此两者之间的“灰盒测试”方法。在不同的行业领域，“灰盒测试”的应用场景会有所有不同，应用的广度与深度也不同。在测试过程中该如何找到切入点加于应用，是灰盒测试应用的关键。为便于读者理解，下面对灰盒测试的定义及其特点作一归纳性解释。

1、    灰盒测试是介于白盒测试和黑盒测试之间的一种测试方法，或者说是两者的结合，也有人称集成测试为灰盒测试；

2、    灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，或者说参考部分代码去做黑盒测试；

3、    灰盒测试结合了白盒测试与黑盒测试的要素，它考虑了用户端、特定的系统知识和操作环境，它在系统组件的协同性环境中评价应用软件的设计。

下图为灰盒测试空间示意图

图中，可以形象地理解为它是一个方块盒子，对于黑盒测试，我们看不到盒子内部，所以全都是黑色的。但对于灰盒测试，它仍有黑色方块存在，但已出现一层层白线围起来的方块，表示看到了部分代码的实现，白线越密意味着关注的代码越多，最深处几乎为全白盒了。

【案例】手机闹钟的测试

背景描述：闹钟是手机最常用的特性之一，它的主要功能就是在用户设置的时间点到达时，进行响铃提醒。响铃时，无论用户当前在做什么操作，会弹出一个响铃提示界面。

提出问题：一天，负责测试此特性的工程师小A提出一个问题“闹铃事件优先级高，在所有应用程序界面、对话框或提示框上面都会弹出，黑盒测试需要进入所有情况的用户界面，然后等待闹钟事件的发生，才能全面验证到各种情况的用户使用场景。但这样穷举测试，需耗的时间太多，效果也并不一定好。

分析问题：关于闹钟的应用，实际上该模块只提供了一个接口。如能从代码角度分析到所有其他模块调用的是同一个闹铃接口函数，对于响铃及停止响铃后对原界面的恢复，都是统一一个接口处理的，那么再通过黑盒功能测试，在某一个用户界面进行此响铃功能的验证，即可证明代码的实现是符合需求的，这正是灰盒测试的方法。

解决问题：后来，对于闹铃功能点的系统验证，采用了灰盒测试的方法，作了代码正向、逆向分析，结合功能性用户场景进行验证，节省了近三分二的测试时间。

【小结】灰盒测试应用优劣势

灰盒测试是在了解代码实现的基础上，通过黑盒功能测试加以判断，以验证软件实现的正确性、全面性。在理解概念的基础上，实际工作中如何开展，依据笔者的实践，在以下几方面能较好地体现此方法的优点：

l 能有效地发现黑盒测试盲点。通过了解代码的内部实现，补充功能测试用例。这需要灰盒测试人员在查看代码之前，掌握需求，并清楚已有的功能测试用例。对某一功能点的实现进行代码分析（白盒测试），然后与黑盒测试（功能测试）充分结合起来，相互弥补，这就是灰盒测试的精髓。

l 可以避免过度测试，精简用例。例如具有相同特点的某一功能，在进行功能测试时，是否每个界面或提示框、对话框都需进行该功能的测试？在没有采用灰盒测试之前，我们确实这样穷举式测试过，虽说不上没有效果，但收效甚微。

l 能及时发现没有来源的更改。特别是在产品的维护阶段，每一行代码的更改都必须要有更改来源，但实际开发过程中，并不是每个开发人员都能做到，也并不是每个人都能清楚意识到更改后没有得到有效验证所带来的后果。像这种开发人员好心办坏事的事例屡见不鲜，所以测试人员采取事后进行灰盒方法对更改代码进行局部分析、审查是有必要的。

灰盒方法，也有其不足的地方，例如我们在分析代码时，由于没有像白盒方法那样全面、具体，往往有判断错误的地方。笔者亦有这方面的教训，弄得与开发人员讨论多多，争执不断，不过，你会发现，有讨论有争议的事例你会更加牢记，未免不是好事。另外，灰盒测试大部分情况是采用正向分析，而要发现代码的问题所在，往往更需要逆向思维，在分析代码的结构或逻辑实现时，需有意识地补上这一测试点。