关于回归测试的策略

回归测试作为软件⽣命周期的⼀个组成部分，在整个软件测试过程中占有很⼤的⼯作量⽐重，软件开发的各个阶段都会进⾏多次回归测试。在渐进和快速迭发中，新版本的连续发布使回归测试进⾏的更加频繁，⽽在极端编程⽅法中，更是要求每天都进⾏若⼲次回归测试。因此，通过选择正确的回归测试策略以及后续的执⾏⽅案来改进回归测试的效率和有效性是很有意义的。

下⾯关于回归测试建议从以下⼏⽅⾯来做⼀、测试⽤例库的维护：• 删除过时的测试⽤例

改进不受控制的测试⽤例（⼀些对输⼊或运⾏状态⼗分敏感的测试⽤例，其测试不易重复且结果难以控制，影响回归测试的效率，需要进⾏改进，使其达到可重复和控制的要求）• 删除多余/重复的测试⽤例• 增添/补充新的测试⽤例⼆、回归测试⽅案选择：• 再测试全部⽤例

（保险起见的⽅法，但实现成本太⼤，⼀般情况下少⽤）• 基于风险选择测试

（选择最重要、最常⽤、存在风险的功能进⾏测试）• 基于操作剖⾯选择测试

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

结合实际⼯作情况最常⽤的为：D+A组合（优先验证当前版本解决的问题，再验证最重要、常⽤和存在风险的⽤例）三、回归测试的基本过程：

• 确认软件中被修改的部分（根据bug管理系统中开发提供的修改和测试意见跟踪）；• 从原基线测试⽤例库中，选择对应的测试⽤例（基本的）建⽴新测试基线。

• 若有测试⽤例改动（删除或变更）或需求变更（增加新需求）则先进⼊⽤例更新，再展开测试。四、回归测试时注意点：

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

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