回归测试详解(定义&目的、策略以及什么叫做回归等)

目录

1.回归测试的定义和目的
2.触发回归测试的变化
3.回归测试的策略
4.测试用例库及其维护
5.回归测试的测试过程
6.回归测试的优缺点及用途
7.回归测试在测试中的实践

1. 定义&目的

回归测试(Regression Test)是指在软件项目中，开发人员在修改了软件的代码以修复已经发现的bug后，测试人员在需要重新测试前面已经测试过的内容，以确认此次修改没有引入新的错误。 也就是说，回归测试的目的就是检查开发人员在修复已有bug时是否又导致了新的bug。
在维基百科中，对于回归测试的定义原文是Regression testing is re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change. If not, that would be called a regression，按照这个定义，回归测试就是指的是重新运行以前的测试(功能性和非功能性)，以确保先前开发和测试的软件在修改后仍能够正常运行。而根据定义后面来看，回归(regression)指的则是一个导致软件不能正常运行的bug，也就是说造成软件退步或者说衰退(不如修改前)的一个bug就叫做一个回归bug，也叫做回归(regression)。之所以说回归测试叫衰退测试，也是因为regression的汉语意思是回归、退化、倒退的意思。

2. 触发回归测试的变化

按照上面所述，回归测试是指软件在发生某种变化后而引起的，根据维基百科所述，这种变化一般有以下几个：

1. 错误或者说bug修复(bug fixed)
2. 软件的增强(software enhancements)： 比如软件增加/删除/优化了功能等等
3. 配置的更改(configuration changes)
4. 电子元件的替代(substitution of electronic components)

不过，在原文描述中，电子元件的替代只是有可能会引起回归测试的发生，具体是否需要进行回归测试还要看具体的情况，原文为“ include … and even substitution of electronic components”。

3. 回归测试的策略

从回归测试的定义可以看出，软件在其生命周期的任何一个阶段，只要发生了上述的几种类型的变化，就有可能会引入新的问题，为了减少这类新出现的问题，我们引入了回归测试。显而易见的是，随着软件的开发和迭代，以前测过的测试用例也会越来越多，也就是说回归测试的人力和时间成本会越来越大，而现在对于工作的效率和有效性要求都比较高。在这种情况下，我们就需要有针对性的进行回归测试，也就是说有策略的进行回归测试。
回归测试的策略集中体现在对于回归测试的测试用例的选择上面，一般来讲，总体分为两大类，一种是完全回归，一种是部分回归，而部分回归又分为几种具体的回归方法，完全回归和部分回归的定义如下：

1. 完全回归(Retest all)： 完全回归是指测试时选择基线测试用例库中的所有用例进行回归测试，这是一种最为保险的策略，相对于部分回归策略，其可以将遗漏回归bug(regression bug)的概率降到最低，但这种方式同时也是所有策略中成本最高的一种方式，尤其是越往后，随着测试用例的不断增多，最后完全回归所需要的时间和成本往往超出了预算。
2. 部分回归： 部分回归是指在回归测试时选择基线测试用例库中的一部分用例进行回归测试，而不是所有用例全部执行，相对于完全回归测试，这种测试策略效率很高，并且所需要的时间和成本比较少，但也没有完全回归覆盖率高(或者说遗漏回归bug的概率比完全测试高)。

根据部分回归的定义，部分回归需要选择一部分测试用例来进行回归测试，那么自然就要有具体的选择方法，也就是说如何选择出这一部分的测试用例来执行回归测试，一般来讲，在部分回归测试时，选择测试用例的方法分为以下几种：

1. 基于风险选择测试用例： 这种方法是指按照一定的风险标准从基线测试用例库中选择回归测试用例(回归测试包)。首先运行最重要的、关键的和可疑的测试用例，而跳过那些非关键的、优先级别低的或者稳定性高的测试用例，因为这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。
2. 基于操作剖面选择测试用例： 如果基线测试用例库的测试用例是基于软件操作剖面开发的，那么测试用例的分布情况就反映了系统的实际使用情况。回归测试的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。
3. 针对修改的部分选择测试用例(再测试修改的部分)： 当测试者对修改的局部化有足够的信息时，可以通过相依性分析分析识别软件的修改情况并分析修改的影响，将回归测试集中在被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。

附： 软件操作剖面是软件质量管理之中的概念，其包含了各种操作的集合以及每种操作出现的概率，其是对软件使用方式的数值描述，也可以理解为各种使用方式的概率。

4. 测试用例库

在实际的软件项目中，项目组会将测试编写的测试用例放在一起，形成一个测试用例库(测试用例库中包含的是不仅仅是功能测试的测试用例，也有其他类型测试的测试用例，比如自动化测试脚本用例)，并且会不断的对其进行维护和管理。每当得到一个软件的基线版本(软件的基线版本是指软件文档或源码以及其它产出物的一个稳定版本，它是进一步开发的基础)时，用于基线版本测试的所有测试用例就构成了一个基线测试用例库。在进行回归测试的时候，就可以根据回归测试中测试用例的选择策略，从基线测试用例库中提取合适的测试用例组成回归测试的用例包，通过运行回归测试的用例包来实现回归测试。
上面说过需要对测试用例库进行维护，有关测试用例库的维护详述如下。

>测试用例库的维护

为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变，软件的功能和应用接口以及软件的实现发生了演变，导致测试用例库中的一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。同时，对于被修改的或新增添的软件功能，仅仅靠重新运行以前的测试用例并不足以揭示其中的问题，所以还要追加新的测试用例来测试这些新的功能或特征。因此，测试用例库的维护工作还应包括开发新测试用例，这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面：

1. 删除过时的测试用例： 因为需求的改变等原因可能会使一个基线测试用例不再适合测试被测试系统，这些测试用例就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。所以，在软件每次修改后都应将过时的测试用例从测试用例库中删除。
2. 改进不受控制的测试用例： 随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。
3. 删除冗余的测试用例： 如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，将冗余的用例删除掉。
4. 增添新的测试用例： 如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。

维护测试用例的库的好处在于不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。

>回归测试包的选择

在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，这时就不得不选择一个缩减的回归测试包来完成回归测试。回归测试的价值在于它是一个能够检测到回归错误的受控实验。当选择缩减的回归测试包时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。不过，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。

5. 回归测试的测试过程

在有了测试用例库的维护方法和回归测试包的选择策略的基础上，回归测试的过程大致可以分为如下的几步：

1. 识别出软件被修改的部分；
2. 从原基线测试用例库中剔除掉所有不再适用的测试用例，保留对新版本的软件依然有效的测试用例，然后形成一个新的基线测试用例库；
3. 从形成的新的基线测试用例库中依据选择测试用例的策略选择测试用例来执行测试；
4. 如果需要，还可以形成新的测试用例集，以测试上一步选择的测试用例集无法覆盖或者无法充分覆盖到的软件部分；
5. 执行上面新形成的测试用例集。

在上面的步骤中，其中第2步和第3步是验证软件的修改是否造成了软件的衰退(或者说破坏了软件现有的功能)，而第4步和第5步则是验证修改工作本身了。

6. 回归测试的优缺点及其用途(Benefits、drawbacks and uses)

1. 优点： 可以确定当对软件的现有功能进行更改后，此次的更改没有影响软件现有的功能，这些功能是不变的。
2. 缺点： 在敏捷软件开发中，软件开发生命周期非常短，资源稀缺，对软件的更改非常频繁-回归测试可能会带来大量不必要的开销。 在一个倾向于使用来自第三方的黑匣子组件的软件开发环境中，执行回归测试可能是很困难的，因为第三方组件的任何更改都可能干扰系统的其余部分(并且对第三方组件执行回归测试是困难的，因为它是一个未知的实体)。
3. 用途： 回归测试不仅可用于测试程序的正确性，还可用于跟踪其输出的质量。例如，在编译器的设计中，回归测试可以跟踪代码大小以及编译和执行测试套件所需的时间案例。理论上，每次修复后，必须运行之前针对系统运行的整个测试用例，以确保系统没有以模糊的方式损坏。在实践中，回归测试也必须以这个理论思想为指导来进行。

7. 回归测试在测试中的实践

根据第6部分中关于回归测试用途的描述，可以知道在实际工作中，回归测试需要反复的执行(软件发生改变就需要执行)，而当测试人员不断的去执行这些重复的测试用例时，不仅会让人心生厌烦，而且随着时间的推移，需要执行的测试用例的数量也越来越多，导致整个回归测试的效率降低。因此，在回归测试时，需要通过测试自动化的思想，运用自动化测试工具来提高回归测试的效率。 而对于测试的工具的要求就是其要足够灵活和具有一定的通用性，以便满足不同回归测试目标的要求。
在实际对软件进行回归测试时，应用多种测试技术是常见的，并且在回归测试时选择多种回归测试策略也可以增加人们对修改软件的信心。而且需要注意的是，回归测试并不会减少对系统新功能和特征的测试需求，并且回归测试包应包括软件新功能和特征的测试，如果回归测试用例包不能达到要求的覆盖率，则必须从以前的用例中再选取新的测试用例来补充回归测试用例包，使其达到要求的覆盖率。
还有一点就是回归测试是重复性较多的活动，容易使测试人员感到疲劳和厌倦，降低测试效率，在实际工作中可以采用一些策略减轻这些问题。例如，安排新的测试人员完成手工回归测试，分配更有经验的测试人员开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad-hoc测试(ad- hoc测试就是为了某个特定目的进行的测试，以后不会再执行这个测试了)。还可以在不影响测试目标的情况下，鼓励测试人员创造性地执行测试用例，变化的输入、按键和配置能够有助于激励测试人员和揭示新的错误。
最后，组织回归测试时要注意两点，一个是各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。另一个是回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。 在实际的工作中，可以将回归测试和兼容性测试放在一起结合起来进行，在新的配置条件下运行旧的测试可以发现兼容性问题，而同时也可以揭示编码在回归方面的错误。

回到顶部
参考资料：
《regression test》
《回归测试》
《你真的了解什么是回归吗？》
《ad-hoc测试介绍》