引言

测试用例设计是软件测试中的核心问题。在实践的过程中，一般采用业务流程覆盖、数据流覆盖、语句覆盖等作为测试充分性准则进行测试用例的设计。而变异测试则提供了基于缺陷的对测试充分性进行度量的角度，针对测试用例集的充分性进行评估和改进。

定义

根据《中国软件测试标准规范》（以下简称规范）的定义，变异测试（在规范中称为程序变异，以下二者互用）是一种差错驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小差错。本方法一般用变异测试工具动态进行，属于动态测试。下面就变异测试的原理来阐明其定义。

原理

首先，具体来说，测试人员首先根据被测程序特征设计变异算子（mutation operator），变异算子一般在符合语法前提下仅对被测程序作微小改动。然后对被测程序应用变异算子可生成大量变异体（mutant），在识别出等价变异体（equivalent mutant）后,若已有测试用例不能杀除所有非等价变异体，则需要额外设计新的测试用例，并添加到测试用例集中，以提高测试充分性。流程如下图：

变异测试流程图

除了可用于测试用例集的充分性评估，变异测试也可以通过采用变异缺陷来模拟被测软件的真实缺陷，从而对研究人员提出的测试方法的有效性进行辅助评估。根据Andrews等的《Is mutation an appropriate tool for testing experiments?》的研究表明变异算子生成的变异缺陷与真实缺陷在有效性评估中效果相似。这就是为什么说变异测试是基于缺陷的、差错驱动的测试。

在这个过程中，有两个前提假设：

假设1 （熟练程序员假设）即假设熟练程序员因编程经验较为丰富，编写出的有缺陷代码与正确代码非常接近，仅需作小幅度代码修改就可以完成缺陷的移除。基于该假设，变异测试仅需通过对被测程序作小幅度代码修改就可以模拟熟练程序员的实际编程行为。

假设2（耦合效应假设）若测试用例可以检测出简单缺陷，则该测试用例也易于检测到更为复杂的缺陷。这里简单缺陷的含义是仅在原有程序上执行单一语法修改形成的缺陷，而复杂缺陷的含义是在原有程序上依次执行多次单一语法修改形成的缺陷。

从这两个假设，我们不难看出，如果程序中存在着明显的代码错误，变异测试则不一定有效。所以在《规范》的定义中指出“是为了查出被测软件在做过其他测试后还剩余一些的小差错”。而一些小的差错，无论经过多少产品、开发、测试、架构评审，往往是测试用例无法覆盖到的。这正是变异测试的用武之地。

应用

变异测试的基本测试过程，可以用下图表示：

变异测试过程

目前，可以应用在java上的工具有：MuJava、MuClipse（均是学术研究的原型工具，尚未发现可用于企业生产开发的工具）。但在这段时间的使用中由于缺少extendedOJ.jar未能成功运行。而参考官方文档说明，其使用也十分不友好。变异测试从理论到实际应用，还有一段路。（当然，也可能无路可走。）