多变量测试一般性方法2

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

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

　　产品需求

　　具体实现

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

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

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

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

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

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

　　举例如下：计费测试

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

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

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

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

　　7. 系统测试的测试对象选择

　　测试策略是体现测试目的针对性策略的集合，它不是一个简单的平面，比如象测试方法集一样没有时间和空间维度。例如：可能在测试早期和后期采用不同的策略，早期侧重单元测试，后期侧重系统测试；在某些BUG较多的开发组采取复杂的测试，而在BUG较少的开发组采取相对简单的测试等等。

　　可以将所有测试策略理解为一个区域，这个区域内选择符合测试目的部分，显然测试策略也象测试方法一样可以根据属性分类，比如按照测试颗粒度划分为单元测试、集成测试和系统测试，值得强调的是：划分的基本属性是颗粒度大小，可以推导出集成测试依赖于单元测试，那么单元测试则需早些进行，但划分的依据并非是测试的时间阶段。

　　系统测试假设每个单元及其相互关系已经经过验证（或者没有验证但也不去关心），测试的对象将是系统功能级的对象（thread）,这个概念的可以简单理解为功能级的颗粒，或者映射为实现功能的一些实体，比如IVR流程就是个好的例子，每个播放语音的实体功能框并不需要关心如何实现（黑盒），但整个流程却可以利用路径方法遍历（白盒）；有限状态机同样是这样的例子，有很多方法可以严密推导出所有的系统测试用例。

　　实践中需要关注的是颗粒度的大小，太细将使系统测试涵盖过多内容无法实施，或者是只用较少测试用例企图验证所有功能区域；太大的颗粒度会将缺陷包裹在难以测试的内部模块和接口中而被忽略，比如采用打电话的方式测试交换系统，就很难触及维护信令的缺陷，而当交换系统与其他不同种系统互联时就会暴露出可以更早发现的缺陷。一般来说，系统测试的颗粒度受对外接口影响，这些接口是集成测试接口中的子集，为了测试的方便，在输入变量多的情况下，甚至就直接采用集成测试的接口集，以期通过更多的内部结构缩减输入的复杂度；不同的是集成测试接口时关注的是对内的行为，而系统测试时关注的是对外的行为。

　　如何根据已有的设计结构（ER图、有限状态机、类继承图、乒乓图。。。等等）推导系统测试用例有很多成熟的方法可供借鉴。

　　8. 测试目的对测试策略的影响

　　测试目的对测试测试有着至关重要的主导作用，同样的一套系统在不同的测试策略下可能是完全不同的测试实现，比如航天系统和游戏系统将有不同的测试目的，导致对质量要求不同，测试实现也差距很大。显然，游戏软件的严重缺陷可以延迟维护，而航天系统则可能无法接受。

　　虽然通过本文可以了解到众多的令人感兴趣测试方法，需要强调的是实践中更重要的是测试目的（目标）。

　　目的

　　测试策略

　　测试方法集

　　测试用例集合

　　衍生作用

　　9. 总结

　　通过一些例子希望有助了解测试的大体架构，但由于条件所限，难免有所遗漏和错误，望不吝指正。后一篇将介绍一些常用的测试方法。