所谓回归测试就是当软件发生改变时，重新测试已经通过测试的测试区域，以验证修改的正确性及其影响。换句话说，它的目的是检验已经被发现的缺陷有没有被正确的修改和修改过程中有没有引发新的缺陷。其实我们做测试的大部分工作也是在做回归测试，严格按照定义的话一旦软件作了修改就必须进行回归测试。我想对修改过后的软件要进行回归测试应该就是无可厚非的，无论是教科书上的介绍还是前人的经验总结都知道回归测试的必要性与重要性。那非要做回归测试，那样怎样才能做得更为有效有意义呢？显然这都需要从测试用例着手。

　　首先我们必须有个管理良好的测试用例库，这个用例库中的所有用例必须是有效的，有达到足够的覆盖率，并且是容易查找组织的。这需要有良好的测试管理工具，并有相应的资源（时间与人力）去维护这个测试用例库，务必使其中没有过时、冗余的测试用例，并达到一定的覆盖率。要做好回归测试，组织管理良好的测试用例库是前提。

　　有了测试用例库，那我做回归测试时就执行所有有效的测试用例？这个没有绝对的答案，在很多的时候如果你有足够的资源用全部测试用例来做回归测试是最佳选择。但现实中有足够资源这个理想状态比较少。如果只是修改了某个警告对话框中的单词就要执行完所有测试例以确保其修改正确性及其影响？或许你会说只有疯子才会那么做，但事实上有时候我们正是那个疯子。基本上很多时候连开发人员自己都不敢肯定会不会影响到其它部分，所以我们就不得不扩大测试范围。那应该如何选择回归测试使用呢？主要是如下4种：

　　1.选择全部测试用例。选择测试用例库中的所有测试用例作为回归测试用例，这是一个较为保险的方法。在理想的状态下（有足够的资源，测试人员不知疲惫），这种方法绝对是首选。但是无论从现实资源考虑还是从成本上考虑都不可能每次回归测试包都是选择所以测试用例。

　　2.基于风险选择测试用例。这是基于一定的风险标准从测试用例库中选择部分测试用例形成测试包。按测试优先级来来选择最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例。这样测试任务会大为减轻但效果并不差，因为由此没有被发现的缺陷是较少并严重性较低的。

　　3.基于操作剖面选择测试用例。这种方法适用于测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试时可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。

　　4.再测试修改部分。这种是基于开发对修改的影响区域有较大把握时所采取的一个策略。通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上，此时只选择相应的测试用例来做回归测试。此策略风险最大，但成本也是最能低的，通常用于做小回归测试。

　　以上四种回归测试策略各有优缺点，实际应用中应根据项目的资源，进度及项目开发的模式等实际情况来选择最优策略。一般情况在在一个非用于基线的 build中作了小修改，建议采用策略4，只测试修改部分，因为现在的开发流程中build更新较快，特别是极限编程中，要进行完全的回归测试是比较不现实的，即使有自动化工具的辅助亦未必能实现。在一个milestone中，一个作为基线的build中则可采用策略2或3，基于一定的风险选择测试，这是一个较为折中的办法，但如果资源允许的话建议进行全回归测试。较重要的mileStone或是最终版本，最好选择全回归测试。因为如果一般来说此时软件改动会较大，选择全部测试较为保险。当然这还是要依据当时的实际出发。

　　但无论采取何种策略，回归测试还是让人弃之不做却又不得不做的一种测试，因为它重复多并且经常工作量大但经常发现的缺陷相对工作量来说太少。但是谁都不敢承担不做回归测试带来的后果。所以在做回归测试时我们必须采取一些较为有效的方法来保证做好回归测试。最重要的就是引进自动化测试，因为机器不会累，可以日夜跑。