大家好，我是十一。
前情回顾
我们先来回顾下上篇内容：
回归测试
概念：回归测试是指修改了旧代码后，重新对相应缺陷（bug）以及相关功能点进行测试，以确认修改有效，且修改没有引入新的错误或导致其他代码产生错误。
目的：为了验证修改的正确性及其影响。
内容：测试被修订的bug或者新功能；还要测试与其相关的已有功能。
本章内容
上节课我们介绍了何为回归测试，为什么要回归测试以及回归测试的内容，今天呢就来讲剩余的最最重要的部分：怎样回归测试（回归测试的策略+实践）。
回归测试的策略
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发 中，新版本的连续发布使回归测试进行得更加频繁，而在极限编程方法中, 更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
通常我们做回归有如下几种方式：全部回归、只回归修改部分、主线功能回归。下面一一介绍：
ps:
介绍之前我们先来回顾下测试用例库：我们在对一个产品进行测试之前，都会编写测试用例，且所有测试用例必须存以及档入库，以便后续测试使用。
全部回归
再次对测试用例库中的所有测试用例进行测试。
这其实是最安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，它几乎可以应用到任何情况下，且几乎不需要进行分析。但是也正是因为这样，此方法的测试成本极其高昂，随着开发工作的进展，测试用例会不断增多，那么测试用例库就会不断的增大，如果我们每次回归测试都将这么极其庞大的测试用例库跑一遍，可想而知这个工作量有多么庞大，其预算和进度将会远远超出我们的预期。
有人会说那如果我们的自动化测试很完善呢？我们就可以都做全部回归了！那我认为也不能实现每次提交代码都全部回归，因为自动化测试很完善，意味着本身自动化测试集也是一个大家伙，他的执行也是需要时间的，如果大家提交很频繁，每次提交都执行全部的自动测试集的话，可想而知，如此高压高强度的工作服务器也难当重任呀，迟早崩溃！正确做法是：定时执行全部回归（自动测试脚本）以及上线前执行。
只回归修改的部分
当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况，并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。
通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
这个方法对测试人员的要求还是很高的，需要测试人员不仅要熟悉业务，还要能看懂代码且了解代码结构。这么来看这个方法风险还是很高的，那么项目规程可以做稍微改进下，如下：
要求开发修订bug后在缺陷管理工具上直接标明影响范围，测试只做审核和实施。
这样是不是简单很多且更准确点？毕竟开发是代码的创造者，他能准确知道代码结构和其相依性。
主线功能回归
软件程序最最常用的功能一定是它的主线功能；比如：淘宝的主线功能就是搜索物品-->点击购买-->支付-->快递-->收货。那淘宝的每次修订bug或者发布更新，如果都能保障主线功能跑通的，那大概率不会出现重大失误。因此在时间和成本都不足的情况下，我们对主线功能回归测试是一个不错的选择。
回归测试实践
通常我们在什么情况下需要回归测试呢？大致归为以下几种情况：
· 开发修订了bug
· 版本发布
· 新功能提测
三者的共同点是期间代码都发生了变化；不同点是影响范围不同，当然回归范围也不同：
· 开发修订了bug：影响较小，很容易获悉影响范围，以及回归测试用例的选择；
· 版本发布/更新：每次版本的发布或者更新，都必须保障原有功能的正确性以及新功能的正确性；因此回归测试的范围必须是全面的；
· 新功能提测：新上线的功能，我们首先要保障新功能的正确性；另外保障它没有影响与其相关联的功能，即保障其相关功能的正确性。
我们来总结下其上三者的回归策略的相同和不同之处：
· 相同之处：三者在回归时均要回归修订过的部分（针对bug）和新增加的部分（针对新功能），保证变动的代码的正确性；
· 不同之处：开发修订了bug和新功能提测这两者只需要回归相关联部分即可，而版本发布/更新要回归整个产品，确认产品可用，无明显bug。
以上都是针对手工测试来说的；如果自动化部分做的很好，我们则可以在新功能提测、版本更新/发布以及固定时间（1天或者一周）执行一次全部回归（执行自动化测试用例脚本）。这样更能及早的发现bug，从而保证产品的质量；当然这样做的前提是必须先回归变动过的部分，确认变动部分正确，且需要做到实时更新和补充测试用例和自动化测试用例脚本（这样做才能保证测试用例和自动化测试脚本的完整性、正确性）。
总结下：回归测试需要两部分，回归变动的部分（修订的bug和新增的功能）以及回归影响的部分。
好了，今天的内容到此结束。我们下期再见！
