如何更高效的进行软件回归测试？

问题描述：项目频繁的改动，我们在做回归测试的时候若选择完全重复测试。把所有的测试用例，全部再完全的执行一边，以确认问题修改的正确性和修改后周边是否受到影响，但是如果把全部用例全部执行，会增加项目成本，也会影响项目进度。若选择性重复测，不能确保周边受影响的能测试到，请问如何更高效的进行回归测试？

回答：

　　1、回归测试基本策略及其评价

　　基于以上基本原则的阐述，回归测试的基本策略目前有如下几种，现一一进行阐述。

　　1.1 回归测试方式

　　● GTRT：全面用例回归测试选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度（即使在引入了回归测试自动化来缓解回归测试的工作强度及时间进度压力）。

　　● BRRT：基于风险的回归测试可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。

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

　　● BIRT：基于影响面分析的回归测试当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。

本文出自51Testing软件测试网，感谢会员archonwang在每周一问（08-12-01）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

　　1.2 回归测试基本策略

　　评价具体的回归测试基本策略评价表如下所示：

　　图表2　回归测试基本策略评价表

　　全面用例回归测试的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略，进行缩减的回归测试。某一个项目的回归测试往往是针对具体的情况，分别引用不同的执行策略而确定的。

原文转自：http://www.ltesting.net