关于回归测试

关于回归测试     软件测试

一、

在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。
 
    回归测试在软件生命周期中扮演着重要的角色，因忽视回归测试而造成严重后果的例子不计其数，导致阿里亚娜5型火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试造成的。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

二、回归测试的策略

回归测试是贯穿在整个测试的各个阶段的一个测试活动。它的目的是检验已经被发现的缺陷有没有被正确的修改和修改过程中有没有引发新的缺陷。软件在测试或者其他活动中发现的缺陷经过修改后，都要进行回归测试的验证。在做回归测试的时候可以采用不同的策略。

　　策 略（1） 可以选择完全重复测试。把所有的测试用例，全部再完全的执行一边，以确认问题修改的正确性和修改后周边是否受到影响。

　　缺点是由于要把用例全部执行，所以会增加项目成本，也会影响项目进度。所以很难来完全执行，所以引出了回归测试策略（2） 选择性重复测试。

策 略（2） 可以选择性重复测试。可以选择一部分进行执行，以确认问题修改的正确性和修改后周边是否受到影响。那么我们怎样去选择用例呢？这里有三个方法：１．覆盖修 改法　针对发生错误的模块，选取这个模块的全部用例进行测试．这样只能验证本模块是否还存在缺陷，但不能保证周边与它有联系的模块不会因为这次改动而引发 缺陷．所以引出第２个方法，即２．周边影响法．除了把出错模块的用例执行之外，把周边和它有联系的模块的用例也执行一边，保证回归测试的质量．当然我们还 可以用量化的角度去分析模块的质量，比如：经过上面的一系列回归测试后，看看遗留的缺陷率是否已经在允许的范围之内了，那么我们以此为标准可以结束本次回 归测试．也就是我要提到的第三个方法　３．指标达成法．

三、回归测试的流程

        1．在测试策略制定阶段，制定回归测试策略

　　2．确定回归测试版本

　　3．回归测试版本发布，按照回归测试策略执行回归测试

　　4．回归测试通过，关闭缺陷跟踪单

　　5．回归测试不通过，缺陷单返回开发人员．等重新修改，再次做回归测试．

　　每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的I/O 操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。

　　在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。

　　回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：

　　* 能够测试软件的所有功能的代表性测试用例。

　　* 专门针对可能会被修改影响的软件功能的附加测试。

　　* 针对修改过的软件成分的测试。

在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只对出现错误的模块的主要功能进行测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。

四、回归测试实践 

    在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略，自动测试工具应该是通用的和灵活的，以便满足达到不同回归测试目标的要求。

    在测试软件时，应用多种测试技术是常见的。当测试一个修改了的软件时，测试者也可能希望采用多于一种回归测试策略来增加对修改软件的信心。不同的测试者可能会依据自己的经验和判断选择不同的回归测试技术和策略。

    回归测试并不减少对系统新功能和特征的测试需求，回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要求。

    回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效率，在实际工作中可以采用一些策略减轻这些问题。例如，安排新的测试者完成手工回归测试，分配更有经验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad hoc测试。还可以在不影响测试目标的情况下，鼓励测试者创造性地执行测试用例，变化的输入、按键和配置能够有助于激励测试者又能揭示新的错误。
在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。

    在实际工作中，可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的测试可以发现兼容性问题，而同时也可以揭示编码在回归方面的错误。

原文转自：http://www.ltesting.net