模板
教程
环境
性能
功能
管理
回归测试最佳实践(2)
注意：函数的 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)
|
Case Name
原文转自：http://www.uml.org.cn/Test/200903313.asp 
|
