1. 介绍
change impact analysis可以在以下三个方面帮助开发者：
- 帮助开发者在不同编辑上进行实验，观察受影响的代码段，用这些信息确定选择哪个编辑和如何设置参数
- 通过排除确定不被给定改变影响的测试用例，减少运行回归测试需要的时间和人力
- 通过给定一个安全的近似给定受测试失败影响的修改范围，减少debug需要的时间和人力
本文给定的回归测试方法假设有一个回归测试集$\mathcal{T}$，change impact analysis包含如下步骤：
- 源代码的编辑包含了一系列相互关联的原子修改$\mathcal{A}$，粒度达到方法级别
- 然后对$\mathcal{T}$中的每个测试用例构建调用图，本文中使用动态执行测试用例的方法构建调用图
- 给定一个回归测试的集合$\mathcal{T}$，确定一个子集$\mathcal{T’}$可能被改变$\mathcal{A}$影响，
- 对于每个测试$t_i\in\mathcal{T’}$，通过分析可以得到原子修改$A$的子集$\mathcal{A’}$可能影响测试$t_i$的行为
本文工作与之前的动态改变影响分析的工作不同的地方在于之前的方法确定受给定改变集合的程序中方法的子集。与之相反，我们的工作是给定测试，把影响这些测试的修改找出来。另外，本文的方法把代码编辑拆分成一系列语义合理，相互关联的“原子改变”，可以用来生成中间程序版本。
本文贡献：
- 示范了基本change impact analysis framework的用法(Change Impact Analysis for Object-Oriented Programs)
- 扩展了上文提到的技术来处理Java语言，包括匿名类和重载
- 通过39组版本间的改变影响分析，发现平均52%的测试会受到影响；对于每个可能被影响的测试，平均3.95%的原子改变会影响到它们
2. 方法概述
本文中的变化影响分析依赖于计算atomic changes，这些变化在语义层面上捕获所有源代码的修改。目前atomic changes还停留在相对粗粒度的程度，包括添加类（AC），删除类（DC），添加方法（AM），删除方法（DM），改变方法（CM），增加域（AF），删除域（DF）和查找（如X.m()）修改（LC）。
同时也计算原子改变之间的句法依赖。一个原子改变$A_1$依赖于另一个原子改变$A_2$若$A_1$在没有进行$A_2$操作的前提下修改了源程序后在句法上出现了错误。
4. 原型
Chianti已经在eclipse环境中实现插件，该插件在概念上拆分为3个功能模块。一个模块负责从两个版本间导出原子改变，这个通过项目两个版本的抽象语法树比较实现。第二个部分读取测试调用图，计算受影响的测试及其影响的改变。第三部分管理允许用户可视化查看改变影响分析的信息的视图。
当分析结果可用时，Eclipse workbench会产生一系列视图：
- affecting changes视图，每个受影响的测试都会显示关联的changes，
- automic-changes-by-category视图，显示通过类别进行分组的不同的原子改变
6. 相关工作
6.2 回归测试选择
选择回归测试的目的是约减软件变更之后必须测试的测试用例。
TestTube使用了模块级别的覆盖，DejaVu使用了语句级别的覆盖
Bates et al.提出基于程序依赖图和程序切片的细粒度程序覆盖方法，为理解变更的影响提供帮助
本文变更影响分析和之前工作不同的是本文工作分析受影响的测试不需要在两个版本的程序上执行测试的信息
Regression test selection is safe：所有可能暴露错误的测试都保证会被选择到
本文提出的发现受影响的测试用例方法也是safe的，因为它保证能识别可能暴露fault的测试（？？？）。本文方法将编辑划分为一系列的原子变更，然后通过结点和变将影响传递到测试。
7. 结论和未来工作
实验结果表明，平均而言，受影响的测试集合在所有测试可能的测试中占了将近52%，并且对于每个受影响的测试，影响它的变更只有很少的部分（3.95%）。这些发现说明我们的变更影响分析方法对于程序理解和debug是有效的方法