你知道如何选择回归测试策略？

在整个测试环节中、回归测试很少被人提及、网上的对于回归测试的资料也不是很多，而测试类书籍中提及回归测试的部分也比较少。但是做过测试的朋友都知道回归测试在整个测试周期中的重要性。

看看维基百科对回归测试的定义(回归测试旨在检验软件原有功能在修改后是否保持完整)、通过这段简短的说明我们发现回归测试其实就是当研发修正BUG之后的一个检验工作、当然如果你就这样理解的话会发现其实回归测试就是检验BUG是否被修正。

软件工程中一款软件是由各个不同功能的模块组成、将所有模块组合起来成一个完整的软件、所以各个模块之间是有关联的、如果在回归测试阶段仅仅检验BUG是否被修正的话、那么没人保证研发在修正BUG的时候不会引人其他BUG。这样一来我们在做回归测试的时候就需要回归一些此BUG之外的功能。

回归测试阶段的测试策略基本上有如下4种。

(1)、再测试全部用例
选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。

(2)、基于风险选择测试
可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。

(3)、基于操作剖面选择测试
如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。

(4)、再测试修改的部分
当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。

在以上4种回归测试策略中再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。

在不同的阶段使用不同的回归测试策略是一种比较明智选择、我们知道项目管理中、项目进度、成本、质量是一个三角形的关系、每一个都狠重要、所以当你这个项目有几千条测试用例的时候用再测试全部用例的回归测试策略时 项目进度和成本控制就会出现问题、在什么阶段使用什么样的回归测试策略是每一个合格的测试人员都应该考虑的问题。

在编写测试用例的时候测试人员都追求用最少的测试用例来达到最大的用例覆盖率、在回归测试中测试人员也会追求在保证项目进度和成本的情况下最大限度完成回归测试。

关注收藏我就要券591q.cn