在之前的文章里我们讲了很多种测试了，那么在测试中肯定会发现缺陷的，发现缺陷后我们一般会将缺陷转给相应的开发去处理，那么开发处理完成后要怎么办呢？将缺陷转到测试处再次测试。这个再次测试就是我们今天的主角了----回归测试。回归测试这部分内容我们从何为回归测试，为什么要回归测试，回归测试的范围以及怎样回归测试四个方面来逐一揭开他的神秘面纱。

何为回归测试？

回归测试是指修改了旧代码后，重新对相应缺陷（bug）以及相关功能点进行测试以确认修改有效且修改没有引入新的错误或导致其他代码产生错误。

这里要注意的是我们bug修订后不只要重新测试这个bug，还要重新测试与这个功能点甚至是代码块相关的部分。

为什么要做回归测试?

先来看一个例子：

假如我们买了一个桌子，回来按照说明书组装，组装完成后发现桌角少了一个轮子，跟客服沟通，客服答应给我们重新寄回一个轮子；过了3天我们收到了轮子，发现轮子与这个桌子不匹配，装不上。

这种事情大家应该都不陌生，大家一般都怎么处理的？特别生气与客服再次沟通？直接要求退货并且差评？取消关注再也不购买？如上处理对商家来说可能或多或少都造成了损失，比如：多余付了几次的邮费、可能损失了1个客户、可能损失信誉度等等。如此场景都是商家最不希望的结果。那如果商家在寄出前能反复确认，仔细核对后再发给用户，这个问题是不是就能很大程度避免呢？软件过程与这个很相似呢，我们来具体了解下。

在软件生命周期中, 只要软件发生了改变，就可能给该软件带来问题。通常软件的改变是因为发现了错误所以做了修改，也可能是因为在集成或维护阶段加入新的功能。那么

       · 当缺陷被发现时， 如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改;

       · 当开发者对缺陷理解的不够透彻, 也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身从而造成修改失败;

       · 修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本工作正常的功能产生错误。

       · 同样, 在有新代码加入软件的时候, 除了新加入的代码中有可能含有错误外新代码还有可能对原有的代码带来影响。

基于以上的种种原因，每当软件发生变化时，我们就必须重新测试现有的功能或者说相关功能，以便：

       · 确定修改是否达到了预期的目的；

       · 检查修改是否损害了原有的正常功能。

另外，还需要补充新的测试用例来测试新的或被修改了的功能。

综上所述：为了验证修改的正确性及其影响就需要进行回归测试。

回归测试的范围

在前两节其实我们都有反复提到过，回归测试不仅是要：

       · 测试被修订的bug或者新功能；

       · 还要测试与其相关的已有功能。

具体原因在为什么部分我们已经做了详细描述，这里不再赘述。

由于篇幅限制，今天就先到这里，剩余部分请期待下篇！Bye~