Change Impact Analysis for Object-Oriented Programs 总结

• 代码变更影响分析

www.fireknight.tech 个人博客，欢迎访问，CSDN不定期更新

• ABSTRACT

  • subtype和动态类型绑定导致代码中小的变更会带来较大的或者无法定位的影响
  • 主要贡献
    • 程序变更和语义影响相关联
    • 用于精确化回归测试
    • 通过测试，寻找相应的变更

• Intro

  • 问题：子类型和动态分配
  • 过程
    • 1. 源代码映射到原子更改
      2. 确定依赖顺序
      3. 对原子变化和测试程序，执行静态分析
  • 可以得到如下
    • T(测试)的子集T’，可能受到修改A的影响
    • 可能影响某一个测试t对应的修改a
    • 导出和T无关的代码更改，允许程序员忽略和T无关的变化
    • 覆盖率提醒：提醒程序员哪些修改尚未被覆盖
  • 基础：调用图

• 动机介绍

  • 加入、修改 类、方法会导致结果的完全不同

• Changes

  • 本文将修改分为以下几个部分

  

  • 将代码修改映射为原子变更

    • 任何代码都可以对应到特定的原子变更

  • 各个原子的详细介绍见论文

  • Changes affecting method dispatch – LC的详细介绍

    • 

    • lookup

      • 三个参数：
        • 运行时接收者
        • 静态标记方法
        • 实际调用方法
      • <C, A.m, B.m> A.m是声明方法，C继承于A，B是C的最近的祖先并且包含了A.m，即C < B < A

    • LC

      • <C, A.m>
      • 计算
        • 按照定义从头开始建模运行时类型和方法签名的层次结构，但有开销
        • 每次编辑后更新lookup映射 √ 见后文

    • SameLookup(B, f())

      • 在每次的调用后，最终都调用了B.f()， 有C<B<Y的继承关系

  • 变更计算

    • 

    • 举例关于LC的计算

      • LC是标识当前代码调用的符号关系代号，新旧版本的相同LC实际含义发生变更，则有代码变更影响
      • 举例

        • 原来有Professor.toString()，会有lookup如下

          • 

        • 增加Person.toString()，会有lookup如下

          • 

        • LC为

          • 

          • 这两个代表的动态调用发生了变化

  • 顺序

    • 只考虑必须满足以确保可编译性的语法依赖关系。
    • 单个的变更(包含其依赖)可以生成新的程序p’，并且p’也是可运行的。变更组合会形成P’(新代码)

• 代码变动影响力分析

  • 程序P，测试T = t1, · · · , tn
  • Nodes(P, ti) 测试ti经过的方法
  • Edges(P, ti) 方法调用
    • A.m →C B.n A.m到B.n通过对C的调用

  • 计算

    • 

    • AffectedTests(T ,A) 受A影响的测试

      • 对于每一个测试，测试经过的Nodes(P, ti)有过修改，并且调用发生了Lookup change, 则测试受到影响
      • 有一次当前调用图，然后修改。精确测试回归选择：可以找到影响了的测试

    • AffectingChanges(t,A) 影响测试t的代码变更

      • 对任何一个修改，如果修改在测试t的路径(新测试的节点)上，或者修改属于lookupchange(LC涉及到新测试t的调用)，则修改影响了测试t
      • 两个版本代码，两个调用图。可以找到测试对应的修改。

  • 效果：

    • 代码变动，affectedTest为空，说明测试不足。affectTest是找到影响的测试，如果没找到，就说明测试不足。
    • 代码变动，affectTest不为空，说明有测试受到影响。则测试是否需要修改是程序员要考虑的问题。
    • 代码修改后，测试可能产生错误。使用affectingChange寻找相关修改，用来debug。