所谓回归测试，即就是在软件生命周期中，只要软件发生了改变，就可能给该软件产生问题;
具体的选择可以参考以下几点：
1 开发设计测试用例时制定优先级，如高，中，低，方便以后自动化或是策略选择;
2 配置管理时，引入测试用例基线管理，有效管理测试用例;
3 定期维护测试用例增，删，保持最新状态;
回归测试时需考虑效率和覆盖度有效配合，通常的策略有以下几种：
基于风险选择测试：
哪些功能是软件的特色?
哪些功能是用户最常用的?
哪些功能出错将导致用户不满?
哪些程序是最复杂、最容易出错的?
哪些程序最容易扩散错误?
哪些程序是开发者最没有信心的?
备注：只有有效的避免最大的风险，用户反感的问题，回归测试可以说达到了70%任务!
基于Regress衰退概念的测试：
开发人员修改的局部程序时，可能已经处理了症状，所以主要测试其被改变的模块和它的接口上;
但是也可能存在未触及到根本原因，所以需要测试周边程序及相互依赖性的部分;
错误本身可能得到了修复，但修复也可能造成其他错误，所以有必要为每个修复的错误，设计回归测试。
基于全面测试策略：
如果时间充足，资源齐全，可以进行全面测试,最低的遗漏回归错误的风险，但测试成本最高，非上策!
其它的回归测试：
1 基于GUI方式的自动化回归测试技术；
2 基于Ad Hoc 回归测试：增加随机测试，避免回归测试肓点
3 基于交叉测试：多人互动的回归测试，尤其在核心的功能点，交互性比较的
