4.  黑盒测试中的白盒测试

　　先看下图

　　最大方框代表选定的测试范围（不能遗漏需求），蓝色区域表示设计实现部分，显然如果在灰色区域设计测试用例是无意义的，因为那里没有可测试的任何东西。

　　简单的，会联想到将白盒测试的一些方法用到这里会减少测试的范围，但是这样会产生什么问题呢？

　　5.  黑盒测试混用白盒的前提条件：

　　回到测试理论基础上面，黑盒测试基于产品需求而白盒测试基于具体实现，如果用两个椭圆代表是这样的。

　　两个不重合的椭圆代表设计实现对需求的偏差，显然如果混用白盒测试，必须保证落在重合区域内；同时应该采用白盒测试方法确定偏出需求的实现（剔除或不加理会）和未实现的需求（缺陷），这是很重要的前提条件。

　　在实际测试中并不总能简单地明确这些区域，但是如果选择容易明确的区域则可以大大提高工作效率。

　　比如在报表测试中，将从前台客户端生成选择条件，然后将SQL语句（或其他协议）提交后台数据库或应用服务器，再从后台取得数据输出显示或打印处理。如果将这些流程全部作为黑盒测试，那么将面临太多的输入组合，无法确保业务的有效性。

　　混用白盒方法可以简单一些。先将生成SQL语句和报表输出用黑盒测试解决，至于SQL语句在数据库或应用服务器的执行过程，则可以省略，从测试范围中剔除（除非你想替数据库厂商做外包测试）------余下的采用白盒处理------只需验证SQL语句跟产品需求的一致性即可。

　　6.  在黑盒测试中采用白盒一般性方法

　　首先确认选取所知部分的结构信息（流程、接口…），对缩减输入变量有作用；其次，确保选取部分所影响的区域符合产品需求并验证（白盒）；最后，根据缩减的输入来设计测试用例（黑盒）。选取的策略是关键，也是非常灵活的。

　　举例如下：计费测试

　　选取计费流程，原因是这样能剔除大量不存在的测试区域，首先假设为流程中每个模块是正常的，然后用白盒做路径遍历，检查流程设计是否符合产品需求并且无遗漏；其次，根据流程的约束设计黑盒测试用例，输入变量的组合可能将大大减少。

　　一般来说，如果所选取的设计结构没有形式化（比如代码或用例图），而是一些文档的非形式化的（比如文本的设计文档或无推导性关联的流程图），最好经过同行评审的方法确保白盒测试的有效性。

　　混用白盒测试和黑盒测试并非一定在系统测试中采用，可以在测试的任何阶段使用。黑盒测试、白盒测试和混用测试可以这样理解：某一些测试方法比如等价类划分和边界分析都具有不需要内部结构的属性，将它们归为一个集合，称之为黑盒测试方法集；白盒测试方法集类同。“混用”黑盒和白盒测试方法实际是重新构建了新方法集，对于新方法集则需要从测试策略上重新校验与测试目的最终一致性，而不象黑盒或白盒方法集一样可以采用缺省的校验方式，比如系统测试的目的恰好与黑盒测试方法集策略形式一致，而单元测试则与白盒测试形式上很接近，但这并非一定如此，仅仅是多数情况下简便一点。

　　测试方法、测试方法集与测试策略都属于测试方法论，最终是为某种测试目的服务，而某种测试方法在实践中将推导出测试用例的集合，这是整体测试的框架（测试目的最重要！）。不过测试方法集仅是测试策略里的一个角度，下面来看另一个角度。