在软件生命周期中，会由于增加新的功能或增强原有的功能、修正所发现的缺陷而修改软件，一旦软件被修改了，就可能引起新的缺陷，使原来工作正常的功能出现了问题。回归测试的目的就是在程序有修改的情况下保证原有功能正常的一种测试策略和方法，因为这时的测试一般不需要进行从头到尾的全面测试，而是根据修改的情况和由修改引起的影响面来进行有效的测试。另一方面看，由于扩充和维护的测试用例库可能变得相当庞大，每次回归测试都重新运行完整的测试用例包变得不切实际，时间和成本约束也不允许。所以，需要根据软件修改所影响的范围，从测试用例库中选择相关的测试用例，构造一个优化的测试用例组来完成回归测试。
回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时，有可能忽略了那些将揭示回归错误的测试用例，而错失了发现回归错误的机会。然而，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会影响回归测试的结果。选择回归测试方法应该兼顾测试风险（覆盖面）和有效性两个方面，根据项目实际情况，达到平衡。
基于风险选择测试，基于一定的风险标准来从测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些次要的、例外的测试用例或那些功能相对很稳定的模块。运行那些次要用例即便发现缺陷，这些缺陷的严重性也较低。
基于操作剖面选择测试。如果测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。
再测试修改的部分。当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及被修改的或新加的代码。在允许的条件下，回归测试尽可能覆盖受到影响的部分。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但需要良好的经验和深入地代码分析。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都可能需要进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极限编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
可以参考
[url=http://blog.csdn.net/kerryzhu/archive/2006/06/16/804468.aspx]
预知后事如何，请读下回分解：第16回 不容忽视的安装或部署测试
版权所有，软件测试演义® ——系列讨论的目录，见：
