解决方案

　　基于对问题 1） 和问题 2） 的原理分析，我们设计并实施了回归测试的解决方案，如下图所示。它包含了 3 个主要步骤。一是测试用例的录入；二是对新旧两个版本的变更分析；三、通过测试用例优化选择和覆盖率分析，得到相应的测试用例优化选择报告，和覆盖率分析报告。

　　图 5. 回归测试解决方案

　　步骤一， Trace Test Case 负责录制测试用例，并将捕获到的测试用例的 Runtime Trace 存放到数据库中；

　　测试用例在后台运行中的 Runtime Trace 是动态分析 （Dynamic Analysis） 中的重要信息。这些实际的运行信息为测试用例的优化选择和覆盖率分析创造了条件。下面是测试用例跟踪的框架图：

　　图 6. 测试用例跟踪的框架图

　　从上图我们可以看出，测试人员触发 Trigger 之后，会启动 Agent Controller 。 Agent Controller 一直对 JVM 中的 JVMTI 进行监听，以获取部署在 JVM 上的被测应用程序。这些 Agent Controller 还负责将收集到的数据传输给 Data Collector 。又 Data Collector 将这些 Runtime Trace 写入如下表所示的数据库表中。

　　注意：函数的 Signature 信息作为函数的参数标识也需要记录下来。以区别同名不同参数的函数。

　　步骤二， Change Analysis 用于将新旧两个版本作比较，得到 Change Report，即程序变更报告，可以精确到 Method 粒度。一般来说代码变更有 4 种级别，分别为包级别 （Package），类级别 （Class），函数级别 （Method） 及语句级别 （Statement） 。

　　对于包级别和类级别来说，比较的力度过粗，会影响到回归测试优化的质量。而函数级别和语句级别都能起到很好的回归测试的作用。其中语句级别因为粒度最细，等到的分析结果也最精确，回归测试质量最高。但与函数级别的变更分析相比，回归测试的质量相差很有限，但造成了过多的执行时间代价，影响了回归分析的效率。因此我们采用函数级别的变更分析作为回归测试的变更粒度。

　　确定比较粒度之后，可以选择分析比较的方法。最简单的常用比较方法就是文本比较。包括源代码和可执行文件 （binary code） 的文本比较。根据 Java 语言面向对象的特点，还可以采用基于面向对象分析的比较方法。后者得到的分析粒度更细，但是所花的代价也越高。

　　步骤三， 在通过测试用例录制得到测试用例具体的 Runtime Trace 信息，以及通过 Change 分析得到新旧两个版本的变更信息之后，我们可以对测试用例优化问题及覆盖率分析问题进行求解。

　　Test Case Prioritization 中，通过测试用例与运行的 Runtime Trace 进行匹配得到相关的测试用例。并利用测试用例优化排序算法对相关的测试用例进行排序，得到优化结果。现在的优化排序算法有多种，这里不对优化排序算法进行讨论。

　　Coverage Analysis 中，通过对已被相关测试用例覆盖的 Method 数量，及未被测试用例覆盖到的 Method 数量的分析，可以得到基于代码更新的覆盖率报告。测试人员得到这份报告之后，可以找到未被覆盖到的 Method，并对其进行针对性的开发新的测试用例。以完成对新功能的覆盖。

　　我们可以看到步骤一，二共同服务于测试用例优化选择和覆盖率分析两个模块。有了测试用例的 Runtime Trace 和 Change Report. 我们可以将 Change 结果与 Runtime Trace 进行匹配，找出能覆盖程序更改的测试用例。同样，对于没有被测试用例覆盖到的 Change 部分。由于没有相关测试用例被找出，我们现有的测试用例是不足的，需要针对未被覆盖到的 Change 部分开发新的测试用例。

　　而覆盖率作为软件测试的一项重要指标，可以根据已经得到覆盖和未被覆盖的 method 进行求解，即已得到覆盖的 change method 数与总的 change method 之比。