随着信息产业的持续规模化发展，在软件应用的开发端和用户端，软件质量日益受到重视。作为软件质量的重要保障手段软件测试理所当然受到广泛关注，越来越多的人热衷于软件测试技术研究，并在很大程度上丰富了软件测试的手段。尤其是最近的十几年，自动化测试概念被广泛讨论和实践，很多国际知名软件厂商的自动化测试工具获得众多拥，但是无论如何，在目前阶段软件测试仍然存在以下3个特点：

　　● 软件测试仍然是一项有很大重复性、枯燥，容易让人厌倦的一项工作；

　　● 自动化测试仍然无法完全替代手工测试，手工测试在很多时候仍是主流；

　　● 基于用例的测试技术是手工测试期间最核心的测试技术；

　　这些问题实际上是有一些内在联系的，传统的软件测试生命周期仍在指导着当前软件测试的组织和实施，人们对于软件测试过程模型的研究并没有革命性的改变，自动化测试从技术到工具还没有取得与其宣传相匹配的实际功效，测试人员依然需要“循规蹈矩”，测试质量仰赖于测试人员的职业道德和高度的责任心，用双手劳动，用眼睛和大脑去发现缺陷的蛛丝马迹。时至今日，基于用例的测试分析和设计几乎仍然占了软件测试的全部，而落后的用例编制手段使测试用例编制的工作量非常繁重，对一些稍具规模的应用系统，用例编制几乎走到了崩溃的边缘。

　　测试负责人往往要面临这样一个选择题：完善的测试用例、更快的开始并结束测试、更多的报告软件缺陷。软件用户希望发现更多的缺陷，软件开发者需要更短的软件测试周期，测试人员需要完善的测试用例以确保软件测试的覆盖性，而这需要时间！他们之间彼此高度关联，又不可调和。

　　通过以上简要分析，可以看出如何快速高效的完成测试用例的编制是目前软件测试领域需要解决的一个核心问题。拿什么来拯救我们的测试用例？经研究和实践，笔者认为组合测试不失为一个好的选择。组合测试对一些资深的测试从业人员来说，也许并不是新鲜的东西，但是也许正因为它是“旧品”，反而忽略了对它的深入研究呢？事实上，当把组合测试应用于行业软件、通用软件的用例设计过程时，发现组合测试并不生涩，反之有种“众里寻他千百度，蓦然回首，那人却在灯火阑珊处”的感觉。

　　1、组合测试介绍及其原理

　　组合测试是近年来比较活跃的研究方向，学术界对组合测试技术的研究取得了一系列的成果。组合测试也在工业界取得了广泛的应用，IBM、微软、Bell实验室等国际知名企业都开发了相应的组合测试工具。组合测试已被软件业公认为一种行之有效的测试方法。

　　大量实践经验表明，软件在处理数据的边界值时更容易出现问题，因此基于数据输入的测试在通常的软件功能测试中占据了很大一部分工作。在数据测试中，一个很显然的问题就是我们需要什么样的数据、多少组数据才能确保软件测试做得足够？对一个具有k个参数的待测系统（software under test，简称SUT），这些参数分别有v1，v2，…，vk个可能取值，完全测试这个系统需要个测试用例。即便是一个简单的系统，恐怕这个数字也是很庞大的，显然在实际的测试过程中，是不可能有充足的时间去执行这些用例的，也是不必要的，因为统计表明80%的问题可能在执行完20%的缺陷的时候已经被发现，我们是不是有必要花费更多的测试资源去寻找那另外的20%的缺陷呢？另外，通过对组合测试的测试数据跟踪发现，80%至90%的问题是在测试输入的两两组合、三三组合中出现的，也就是是说我们在使用数据组合进行测试时，只需从个测试用例中选取一部分测试用例就可以了。

　　这个选取的方法我们称之为组合测试策略，对组合测试的研究本质上就是对组合测试策略的研究。让我们来看一下下面这个实例：

　　有一个软件版本要从1.0升级到2.0，需要让测试工程师模拟不同的用户环境来充分检验软件的兼容性和适应性。通过用户调查，得到以下基本环境数据：

　　● 操作系统：Windows 2000/xp/2003、Win7/vista；

　　● 浏览器类型：Internet8/7/6、Firefox；

　　● 操作系统语言种类：English、German、CHS；

　　● 运行库：1.0、2.0

　　测试人员在这个数据基础上要完全测试的话，需要构建5*4*3*2=120种测试环境，但是如果使用组合测试技术，我们只需要构建20种环境进行测试即可达到120种测试环境相当的测试效果（如图1是基于PICT生成的测试组合），组合测试优势明显。