关于回归测试的策略

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。

因此，通过选择正确的回归测试策略以及后续的执行方案来改进回归测试的效率和有效性是很有意义的。

 

下面关于回归测试建议从以下几方面来做

一、测试用例库的维护：

•  删除过时的测试用例

   改进不受控制的测试用例（一些对输入或运行状态十分敏感的测试用例，其测试不易重复且结果难以控制，影响回归测试的效率，需要进行改进，使其达到可重复和控制的要求）

•   删除多余/重复的测试用例

•   增添/补充新的测试用例

二、回归测试方案选择：

•   再测试全部用例

（保险起见的方法，但实现成本太大，一般情况下少用）

•   基于风险选择测试

（选择最重要、最常用、存在风险的功能进行测试）

•   基于操作剖面选择测试

（如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反应了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或者最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度）

•   再测试修改的部分

结合实际工作情况最常用的为：D+A组合（优先验证当前版本解决的问题，再验证最重要、常用和存在风险的用例）

三、回归测试的基本过程：

•  确认软件中被修改的部分（根据bug管理系统中开发提供的修改和测试意见跟踪）；

•  从原基线测试用例库中，选择对应的测试用例（基本的）建立新测试基线。

•   若有测试用例改动（删除或变更）或需求变更（增加新需求）则先进入用例更新，再展开测试。

四、回归测试时注意点：

•   各版本所修改的问题一定要在本版本内完成回归，以免将错误遗留到下一测试版本；

•   回归测试期间应对该软件版本冻结，将回归测试发现的问题发现未解决问题或问题解决不完善，可根据公司实际情况进行退回版本等操作