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

回归测试(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的汉语意思是回归、退化、倒退的意思。

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

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

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

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

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

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

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

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

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

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

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

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

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