传统的回归测试
1、依赖收集,构建依赖拓扑。
2、如果依赖文件发生改变,所有受到关联的模块,都需要进行回归测试。
如图:蓝色菱形文件发生改变,最终导致 1、2、3、4 都需要进行回归测试。
缺点:
受到依赖影响的地方,都得进行回归测试。而其中有些回归测试 Duck 不必。
新的方式:预测测试选择
思路:
哪些代码更改后,通常会导致哪些测试用例不通过?
我们有大量这样的历史数据。
那么通过机器学习建模,能不能训练出一个预测模型,用来预测一段代码更改后,最高概率出问题的测试用例有哪些?
然后按这个概率我们去进行选择性的测试。
算法:梯度递增的决策树模型
策略:
-
更改中修改的文件和行数衡量其大小;较大的更改更可能导致破坏
-
对修改后的文件所做的更改数量确定了更易于回归的活动区域
-
最近接触修改过的文件的贡献者数量很好地衡量了修改后的代码的所有权有多严格。我们发现,对代码进行修改后,开发人员越少,损坏的可能性就越小
-
最近一次测试运行的历史记录很好地预测了下周该测试被破坏的可能性
-
构建依赖项的拓扑结构提供了有关修改后的代码与特定测试之间的距离的重要信息。更严格的测试往往会提供有关代码正确性的更多信息
-
特定代码与特定测试一起被修改的频率。这可能表明工程师修复了一个错误,然后添加了相应的测试用例以防止进一步的退化
如图,同样是蓝色菱形文件被修改,通过参数的方式表明需要进行回归测试的概率。