多变量测试一般性方法
本文针对系统测试中黑盒输入变量较多提出一些测试方法，可以提高有限的测试资源下测试设计的有效性。对于计费、报表等测试设计有较好的实用价值。
1. 从实践中常遇到的问题开始：
在黑盒系统测试计划设计中，一般将界定的测试需求细化为详细的测试功能集，每个可测试的功能都有一些输入和输出，通过组合特定的输入来校验预期的输出。
常见的组合方法有：等价类划分、因果图、正交矩阵法、边界分析、判定表驱动、功能图等，主要是解决输入穷举数量级与测试有效性的矛盾。
对于较少的输入变量，通常有较好的效果，或者多种方法复合使用等等。但是当输入因素较多时（比如有200个），如果照搬套用的话，那么数量级将超出测试资源的约束，也就是说可能不得不牺牲测试的有效性。
在计费测试中，简单地按照黑盒测试划分输入因素，计费文件和配置数据将组合出太多的可能；如果轻率地只用几个测试用例，那么计费的有效性显然没有说服力。
报表测试与此类似，影响某个报表结果的数据库输入组合同样很多。
如果把输入变量的组合理解为一个区域，白色为已有的测试用例：
那么在灰色区域都没有经过测试，无法确认里面没有BUG。
2. 缩减输入变量的简易方法：
最简单的方法就是尽可能减少输入变量的个数和每个变量可能的取值范围，比如筛选出一些不变量或变化不大的变量不列入输入变量，当做是系统恒定值处理；再如根据需求筛选一些变量的取值范围，或剔除一些无意义的组合等等。目的是减小测试区域的面积。
这些方法只能减少较为有限的幅度，而且受应用的限制比较大。
3. 测试范围的界定：
在测试开始的时候，必须确定测试的范围，表面上看似乎是“毋庸置疑”的，但却可以重新认真选择和考量，比如：
在该图中可以选择不同的椭圆作为测试的范围。如果选择最小的椭圆作为测试范围，那么可能需要把config和input作为输入变量考虑；如果用中间的椭圆作为测试范围，只需要用input作为输入变量考虑；如果选择最大的椭圆作为测试范围，那么就没有输入变量了。（注：并非测试范围扩大就一定会得到较少的输入）
可以看到，选择不同的测试范围对测试输入有影响。一般来说，测试系统的范围至少要大于需求的范围，若把一些因素比如配置变量纳入测试范围内，则会减少输入变量。
对于上述将一些因素放入测试范围内而不再参加输入组合的穷举，必须有相应的“典型值集合”来弥补可能的遗漏。
同样以上图为例：选取一个集合config-A
config-A={config1,config2,config3,...,confign}
input-B={input1,input2,input3,…,inputn}
集合中将是一些典型的具有代表意义的若干组合，然后对集合A做INPUT的穷举组合（组合方法见前述黑盒测试方法）测试，再对集合B做CONFIG的穷举组合测试，如果必要的话可能在产品部署前针对确定的CONFIG-C做一次回归测试。
集合选取的策略可以根据需要灵活把握。
以此类推可以根据选择和组合将较多的输入变量简化为容易测试的集合。值得特别注意的是：例子中的config在需求中，恰好是一旦确定后变化不大，那么是否可以随意选择其他任意的因素呢？
4. 黑盒测试中的白盒测试
先看下图：
最大方框代表选定的测试范围（不能遗漏需求），蓝色区域表示设计实现部分，显然如果在灰色区域设计测试用例是无意义的，因为那里没有可测试的任何东西。
简单的，会联想到将白盒测试的一些方法用到这里会减少测试的范围，但是这样会产生什么问题呢？
5. 黑盒测试混用白盒的前提条件：
回到测试理论基础上面，黑盒测试基于产品需求而白盒测试基于具体实现，如果用两个椭圆代表是这样的：
两个不重合的椭圆代表设计实现对需求的偏差，显然如果混用白盒测试，必须保证落在重合区域内；同时应该采用白盒测试方法确定偏出需求的实现（剔除或不加理会）和未实现的需求（缺陷），这是很重要的前提条件。
在实际测试中并不总能简单地明确这些区域，但是如果选择容易明确的区域则可以大大提高工作效率。
比如在报表测试中，将从前台客户端生成选择条件，然后将SQL语句（或其他协议）提交后台数据库或应用服务器，再从后台取得数据输出显示或打印处理。如果将这些流程全部作为黑盒测试，那么将面临太多的输入组合，无法确保业务的有效性。
混用白盒方法可以简单一些。先将生成SQL语句和报表输出用黑盒测试解决，至于SQL语句在数据库或应用服务器的执行过程，则可以省略，从测试范围中剔除（除非你想替数据库厂商做外包测试）------余下的采用白盒处理------只需验证SQL语句跟产品需求的一致性即可。
6. 在黑盒测试中采用白盒一般性方法
首先确认选取所知部分的结构信息（流程、接口。。。），对缩减输入变量有作用；其次，确保选取部分所影响的区域符合产品需求并验证（白盒）；最后，根据缩减的输入来设计测试用例（黑盒）。选取的策略是关键，也是非常灵活的。
举例如下：计费测试
选取计费流程，原因是这样能剔除大量不存在的测试区域，首先假设为流程中每个模块是正常的，然后用白盒做路径遍历，检查流程设计是否符合产品需求并且无遗漏；其次，根据流程的约束设计黑盒测试用例，输入变量的组合可能将大大减少。
一般来说，如果所选取的设计结构没有形式化（比如代码或用例图），而是一些文档的非形式化的（比如文本的设计文档或无推导性关联的流程图），最好经过同行评审的方法确保白盒测试的有效性。
混用白盒测试和黑盒测试并非一定在系统测试中采用，可以在测试的任何阶段使用。黑盒测试、白盒测试和混用测试可以这样理解：某一些测试方法比如等价类划分和边界分析都具有不需要内部结构的属性，将它们归为一个集合，称之为黑盒测试方法集；白盒测试方法集类同。“混用”黑盒和白盒测试方法实际是重新构建了新方法集，对于新方法集则需要从测试策略上重新校验与测试目的最终一致性，而不象黑盒或白盒方法集一样可以采用缺省的校验方式，比如系统测试的目的恰好与黑盒测试方法集策略形式一致，而单元测试则与白盒测试形式上很接近，但这并非一定如此，仅仅是多数情况下简便一点。
测试方法、测试方法集与测试策略都属于测试方法论，最终是为某种测试目的服务，而某种测试方法在实践中将推导出测试用例的集合，这是整体测试的框架（测试目的最重要！）。不过测试方法集仅是测试策略里的一个角度，下面来看另一个角度。
7. 系统测试的测试对象选择
测试策略是体现测试目的针对性策略的集合，它不是一个简单的平面，比如象测试方法集一样没有时间和空间维度。例如：可能在测试早期和后期采用不同的策略，早期侧重单元测试，后期侧重系统测试；在某些BUG较多的开发组采取复杂的测试，而在BUG较少的开发组采取相对简单的测试等等。
可以将所有测试策略理解为一个区域，这个区域内选择符合测试目的部分，显然测试策略也象测试方法一样可以根据属性分类，比如按照测试颗粒度划分为单元测试、集成测试和系统测试，值得强调的是：划分的基本属性是颗粒度大小，可以推导出集成测试依赖于单元测试，那么单元测试则需早些进行，但划分的依据并非是测试的时间阶段。
系统测试假设每个单元及其相互关系已经经过验证（或者没有验证但也不去关心），测试的对象将是系统功能级的对象（thread）,这个概念的可以简单理解为功能级的颗粒，或者映射为实现功能的一些实体，比如IVR流程就是个好的例子，每个播放语音的实体功能框并不需要关心如何实现（黑盒），但整个流程却可以利用路径方法遍历（白盒）；有限状态机同样是这样的例子，有很多方法可以严密推导出所有的系统测试用例。
实践中需要关注的是颗粒度的大小，太细将使系统测试涵盖过多内容无法实施，或者是只用较少测试用例企图验证所有功能区域；太大的颗粒度会将缺陷包裹在难以测试的内部模块和接口中而被忽略，比如采用打电话的方式测试交换系统，就很难触及维护信令的缺陷，而当交换系统与其他不同种系统互联时就会暴露出可以更早发现的缺陷。一般来说，系统测试的颗粒度受对外接口影响，这些接口是集成测试接口中的子集，为了测试的方便，在输入变量多的情况下，甚至就直接采用集成测试的接口集，以期通过更多的内部结构缩减输入的复杂度；不同的是集成测试接口时关注的是对内的行为，而系统测试时关注的是对外的行为。
如何根据已有的设计结构（ER图、有限状态机、类继承图、乒乓图。。。等等）推导系统测试用例有很多成熟的方法可供借鉴。
8. 测试目的对测试策略的影响
测试目的对测试测试有着至关重要的主导作用，同样的一套系统在不同的测试策略下可能是完全不同的测试实现，比如航天系统和游戏系统将有不同的测试目的，导致对质量要求不同，测试实现也差距很大。显然，游戏软件的严重缺陷可以延迟维护，而航天系统则可能无法接受。
虽然通过本文可以了解到众多的令人感兴趣测试方法，需要强调的是实践中更重要的是测试目的（目标）。
9. 总结
通过一些例子希望有助了解测试的大体架构，但由于条件所限，难免有所遗漏和错误，望不吝指正。后一篇将介绍一些常用的测试方法。
