3>基于操作剖面选择测试用例
这种方法适用于测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试时可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。
4>再测试修改部分
这种是基于开发对修改的影响区域有较大把握时所采取的一个策略。通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上，此时只选择相应的测试用例来做回归测试。此策略风险最大，但成本也是最能低的，通常用于做小回归测试。
以上四种回归测试策略各有优缺点，实际应用中应根据项目的资源，进度及项目开发的模式等实际情况来选择最优策略。1>一般情况在在一个非用于基线的 build中作了小修改，建议采用策略4，只测试修改部分，因为现在的开发流程中build更新较快特别是极限编程中，要进行完全的回归测试是比较不现实的，即使有自动化工具的辅助亦未必能实现。2>在一个milestone中，一个作为基线的build中则可采用策略2或3，基于一定的风险选择测试，这是一个较为折中的办法，但如果资源允许的话建议进行全回归测试。3>较重要的mileStone或是最终版本，最好选择全回归测试。因为如果一般来说此时软件改动会较大，选择全部测试较为保险。当然这还是要依据当时的实际出发。
但无论采取何种策略，回归测试还是让人弃之不做却又不得不做的一种测试，因为它重复多并且经常工作量大但经常发现的缺陷相对工作量来说太少。但是谁都不敢承担不做回归测试带来的后果，真是食之无味，弃之不能。所以在做回归测试时我们必须采取一些较为有效的方法来保证做好回归测试。例如安排新的测试者完成手工回归测试，让更有经验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad hoc测试。或是采取轮流执行不同模块，尽量避免一人一直测试某一模块，不论从测试感受还是测试效果来看，这都是一个不好的方法。但我觉得最重要的就是基于实际可行的话引进自动化测试，因为机器不会累，可以日夜跑。
回归测试这个令人头痛的问题需要根据项目跟测试资源等实际情况来采取更有效的策略来解决。其中需要注意的是必须重视回归测试，在测试计划中有很好的进度安排及选择相应的回归，重视测试用例的维护，借助于自动化工具。
文章来源于领测软件测试网 https://www.ltesting.net/
