解决方案
基于对问题 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 之比。
内容导航结果
基于以上的回归测试解决方案，我们对一个有着 30 个测试用例的程序进行回归测试，得到如下测试用例优化选择分析报表：
Change Analysis Report
总函数 变更函数 覆盖数 未覆盖 覆盖率 108 12 10 2 83.3%
表 1 优化选择测试用例： 3 (of Total 30)
分析报告显示这次代码变更共有 12 个函数发生了更改。在 30 个测试用例中有 3 个测试用例与这些更改相关，它们覆盖了这次代码更改 12 个中的 10 个。而其它 27 的测试用例则与这 12 个代码改动毫不相关。
表 2 回归测试结果分析
从表中我们可以看到，经过测试用例优化选择之后，我们选出了 3 个和函数变更相关的测试用例，达到了 83.3% 的覆盖率。同时由于 27 个与函数变更无关的测试用例不需要重测，使得 90% 的回归测试资源得到了节省。
图 7. 覆盖率分析
从上图，我们可以清楚地看到基于每个函数改动的相关测试用例的数目，以及测试覆盖率。比如 ManageCommodityAction 这个 Class 里面，存在了 2 个 Change Method， 只有 1 个 changed method 被现有的 1 个 Test Case 所覆盖，测试覆盖率为 50% 。
上面分析报告中总共有 12 个函数发生改动，基中还有 2 个没有被任何测试用例覆盖到。那么未被覆盖的 Change Method 就需要测试人员对之进行分析并且添加新的测试用例以提高我们的测试覆盖率 ， 保证测试质量。
总结
回归测试用例的优化选择，以最少的测试用例，准确地覆盖所作改动，极大地提高了我们回归测试的测试效率与测试质量。
自动测试过程中的覆盖率反馈分析，以最小的测试代价，最精确的分析，来获得当前的测试完成情况，为测试人员提高了良好的分析报告，以便测试人员改进和新增新的测试用例。大大提高了回归测试的测试效率与质量。
文章来源于领测软件测试网 https://www.ltesting.net/
