最近，从生产上反馈了一些产品缺陷，开发、测试一起对缺陷进行了多维度的原因分析，缺陷的逃逸是由产品生产过程中多种因素造成的，其中有部分原因是回归测试的策略选用不当。在此，我们有必要聚焦一下回归测试。

什么是回归测试

回归测试的英文名称：Regression Testing，从字面上看，是“倒退测试”。这就表明，软件有当前状态和原来状态之分。回归测试就是对软件的原来状态重新进行功能和非功能的测试，用以确保先前开发并测试过的软件在缺陷修复、配置改变、软件更新等等这些变化之后，仍能符合要求的运行（即：软件当前状态中那些没有被修改的部分的功能和非功能与原来状态保持一致）。

这里所说的软件当前状态和原来状态的概念，可以简单的认为，每一个当前提交测试的版本就是该软件的当前状态，上一个版本就是原来状态。或者，当前基线就是当前状态，上一次基线就是原来状态。具体如何区分，可以根据管理要求来制定。

回归测试的时机

不论是基于新产品的开发还是老产品的维护升级，回归测试都是一个完整测试必不可少的一部分。通常，需要进行回归测试的时机是：

1）缺陷修复

当开发人员完成对当前状态的软件进行缺陷修复之后，并且提交新的测试版本或进行了代码基线；

2）软件更新

开发人员完成新增功能和代码重构之后，并且提交测试版本或进行了代码基线。其中，新增功能往往对应于维护类的产品，对其要进行完整的测试，即对新功能的验证测试，以及回归测试。对于代码重构，应该本着运行质量永远高于代码质量的原则慎重对待，如果一旦决定重构，则必须进行全量回归测试；

3）配置改变

出于软件参数配置灵活性以及运维高效的需要，对配置文件、脚本、批处理命令、存储过程进行修改并正式通知测试部门之后。

回归测试的技术

回归测试的技术通常有以下三种：

1）全量测试用例重复测试

对当前状态的软件进行全部测试用例的执行和结果检查。这种技术由于进行的是全量测试用例的重新执行，能将缺陷遗漏的风险降至最低水平，但是测试成本（时间成本、人力成本、财务成本）很高；

2）选择部分测试用例重复测试

与上述不同的是，只对当前状态的软件进行部分测试用例的执行和检查。这种技术的最大好处是测试成本（时间成本、人力成本、财务成本）低于全量测试用例重复测试；

3）测试用例优化

测试用例的优化技术是指，从测试用例的范围即有效和效率角度出发，优化、提取对后续软件版本或特定版本有用的测试用例（集合）。

回归测试的策略

回归测试技术用以服务于回归测试策略。通常情况下，我们在日常工作中会在以下策略中进行选择。

全量回归测试策略

在一些特殊行业，比如金融、通信行业，对生产环境中软件产品质量的要求通常是严重以上级别的逃逸缺陷是0，在此情况下，我们必须用安全系数最高、风险等级最低的策略进行回归测试，以达到质量要求。这时，我们可以采用全量测试策略，使用全量测试用例重复测试的技术进行回归测试。

全量回归测试策略可以适用任何情况，它是一种不是策略的策略，虽然有效，却不

高效。

非全量回归测试策略

实际工作中，测试用例会越来越多，工作量也会越来越大，特别是维护更新类的产品。当质量要求不变，又有上线时间以及其它条件制约时，我们会选择非全量回归测试策略，使用部分测试用例重复测试技术进行回归测试。这也是我们最常使用的策略。

这种策略的核心思想就是使用测试用例优化技术，提高测试效率，减少资源投入。

但是这种策略的漏测风险也是显而易见的，比如，测试人员对代码的相依性分析能力较弱，这很容易导致忽略了可能会发现缺陷的测试用例。为了规避这个风险，除了采用测试用例优化技术之外，还应该结合基于业务风险驱动的分析方法来进行。

总体上，测试人员需要通过与开发人员、业务人员的讨论，对被测试软件进行风险分析和操作分析，了解被测软件最重要、最频繁使用的功能，也就是了解被测试软件的业务关键度与故障可能性，然后根据这两个维度的风险分析结果采用相应的测试用例（集合）优化技术进行回归测试。

具体的，在测试行业里业务影响测试是一个公理，因此，要了解被测软件的业务关键度是首要任务。其次，软件及其中的模块都有故障可能性，这二者的相关指标及示例可以用以下二表所示：

表1：业务关键度指标与示例

表2：故障可能性指标与示例

通过以上二表，结合业务关键度与故障可能性评估得出被测软件功能模型的风险等级，如下表所示：

通过上表，为非全量回归测试策略中缩减测试用例集合，集中力量做最需要的测试，提供了依据，从而降低漏测风险。当然，不论表1还是表2，其中的等级划分需要测试人员的经验积累，也需要业务人员、开发人员的有力支持。

自动化回归测试策略

由于回归测试是一个反复的过程，通常我们一提到回归测试的时候，就会考虑使用自动化的方式进行。因此，可以通过使用测试用例优化技术将提取出的测试用例进行按维护、复用、自动化的步骤进行自动化回归测试平台的建设，这种方式对维护类、升级类软件（比如：市场监察、结算系统）的回归测试可以做到即有效且高效。

但是，若要达到使用自动化回归测试策略的目的，需要专门人员进行实施，从业务流驱动、数据与用例分离、组件技术、统一的平台多维度出发进行长期建设。

我们都知道，测试不可能做到完全穷尽，但我们可以通过在软件的不同阶段采取不同的回归测试策略，减少直至避免在生产上出现严重以上级别的逃逸缺陷。当然，如果从软件生产的全生命周期入手严格进行代码与缺陷管理可以更直接的降低线上产生缺陷的风险了，毕竟回归测试也是可以用于单元测试的。