其实最有效的回归测试方法建立在开发测试库的基础上；开发在创建测试库，每次生成程序的新版本时都可以运行这些用例。  
只有有效的从源头避免风险才能有效的进行回归测试(目前国内的公司，能从事此级别的，太少）

1 强调单元测试时加强回归测试，引入代码评审，引入自动测试;
2 集成和系统级的测试时，加强测试用例评审，回归测试用例的选择；

具体的选择可以参考以下几点：
1 开发设计测试用例时制定优先级，如高，中，低，方便以后自动化或是策略选择；
2 配置管理时，引入测试用例基线管理，有效管理测试用例；
3 定期维护测试用例增，删，保持最新状态；


回归测试时需考虑效率和覆盖度有效配合，通常的策略有以下几种：

基于风险选择测试：
哪些功能是软件的特色？
哪些功能是用户最常用的？
哪些功能出错将导致用户不满？
哪些程序是最复杂、最容易出错的？
哪些程序最容易扩散错误？
哪些程序是开发者最没有信心的？
备注：只有有效的避免最大的风险，用户反感的问题，回归测试可以说达到了70%任务!

---

时间紧迫也可以采用80/20原则，把用户经常操作、还有bug经常发生的地方进行完全的回归或选择有效的用例回归，然后只要保证剩余的模块不出现高等级的bug，其他的地方可以等时间空下来的时候测试人员再进行测试
如果软件几经发布，发现bug以补丁形式发布。

---

a.作每日构建

b.基线功能自动化

c.编写用例时一定要分级（按照风险度，常用度，重要度）

d.手工执行回归测试用例（就是下面说的7项）

第一，新修改的功能，这个显然是重点

第二，新修改的功能的关联功能，就是有耦合的部分，这个一般最好咨询一下开发人员

第三，程序最有卖点或者说亮点的部分，这个地方一旦有问题，会使程序质量大打折扣

第四，程序中最致命的部分，譬如说安全隐患，数据泄露，加密注册，

第五，程序中比较脆弱的部分，这个要咨询开发人员，一般就是他们心中最没底的地方

第六，程序的主干功能

第七，如果以上做完，还有时间的话，最好把用例中级别比较高的用例再执行一遍。

OK ，以上是回归测试用例的选择优先级。

基于Regress衰退概念的测试：
开发人员修改的局部程序时，可能已经处理了症状，所以主要测试其被改变的模块和它的接口上；
但是也可能存在未触及到根本原因，所以需要测试周边程序及相互依赖性的部分；
错误本身可能得到了修复，但修复也可能造成其他错误，所以有必要为每个修复的错误，设计回归测试。

基于全面测试策略：
如果时间充足，资源齐全，可以进行全面测试,最低的遗漏回归错误的风险，但测试成本最高，非上策!

对于质量要求高的软件，那就必须进行完全的回归了，这时可以选用自动化工具（公司有条件可以自己开发工具），可以选用QTP,WR等
在软件没有完全稳定的时候可以选用描述性编程。

其它的回归测试：
1 基于GUI方式的自动化回归测试技术
2 基于Ad Hoc 回归测试：增加随机测试，避免回归测试肓点
备注：Ad Hoc Testing可参考:卖烧烤的鱼的测试博客：http://www.cnblogs.com/mayingbao/archive/2006/04/25/384160.html
3 基于交叉测试：多人互动的回归测试，尤其在核心的功能点，交互性比较的

我们在做回归测试的时候可以采用不同的策略.

策略(1) 可以选择完全重复测试.把所有的测试用例,全部再完全的执行一边,以确认问题修改的正确性和修改后周边是否受到影响.缺点是由于要把用例全部执行,所以会增加项目成本,也会影响项目进度.所以很难来完全执行,所以引出了回归测试策略(2) 选择性重复测试.

策略(2) 可以选择性重复测试.可以选择一部分进行执行,以确认问题修改的正确性和修改后周边是否受到影响.那么我们怎样去选择用例呢？这里有三个方法：１．覆盖修改法　针对发生错误的模块，选取这个模块的全部用例进行测试．这样只能验证本模块是否还存在缺陷，但不能保证周边与它有联系的模块不会因为这次改动而引发缺陷．所以引出第２个方法，即２．周边影响法．除了把出错模块的用例执行之外，把周边和它有联系的模块的用例也执行一边，保证回归测试的质量．当然我们还可以用量化的角度去分析模块的质量，比如：经过上面的一系列回归测试后，看看遗留的缺陷率是否已经在允许的范围之内了，那么我们以此为标准可以结束本次回归测试．也就是我要提到的第三个方法　３．指标达成法．

　　　回归测试的流程

１．在测试策略制定阶段，制定回归测试策略

２．确定回归测试版本

３．回归测试版本发布，按照回归测试策略执行回归测试

４．回归测试通过，关闭缺陷跟踪单

５．回归测试不通过，缺陷单返回开发人员．等重新修改，再次做回归测试．