选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：

　　（1）、再测试全部用例选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有低的遗漏回归错误的风险，但测试成本高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。
　
　　（2）、基于风险选择测试可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。
　
　　（3）、基于操作剖面选择测试如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对重要或频繁使用功能的测试用例，释放和缓解高级别的风险，有助于尽早发现那些对可靠性有大影响的故障。这种方法可以在一个给定的预算下有效的提高系统可靠性，但实施起来有一定的难度。
　
　　（4）、再测试修改的部分当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
　
　　再测试全部用例的策略是安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。
　
　　3、回归测试的基本过程有了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循下述基本过程进行：

　　（1）。 识别出软件中被修改的部分；

　　（2）。 从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0.

　　（3）。 依据一定的策略从T0中选择测试用例测试被修改的软件。
　
　　（4）。 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。
　
　　（5）。 用T1执行修改后的软件。
　
　　第（2）和第（3）步测试验证修改是否破坏了现有的功能，第（4）和第（5）步测试验证 修改工作本身。
　
　　三、 回归测试实践在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略，自动测试工具应该是通用的和灵活的，以便满足达到不同回归测试目标的要求。
　
　　在测试软件时，应用多种测试技术是常见的。当测试一个修改了的软件时，测试者也可能希望采用多于一种回归测试策略来增加对修改软件的信心。不同的测试者可能会依据自己的经验和判断选择不同的回归测试技术和策略。
　
　　回归测试并不减少对系统新功能和特征的测试需求，回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要求。
　
　　回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效率，在实际工作中可以采用一些策略减轻这些问题。例如，安排新的测试者完成手工回归测试，分配更有经验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad hoc测试。还可以在不影响测试目标的情况下，鼓励测试者创造性地执行测试用例，变化的输入、按键和配置能够有助于激励测试者又能揭示新的错误。
　
　　在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。
　
　　在实际工作中，可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的测试可以发现兼容性问题，而同时也可以揭示编码在回归方面的错误。