【IT168 技术文档】

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

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

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

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

　　回归测试的流程

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

　　2.确定回归测试版本

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

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

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

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

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

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

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

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

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

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