不同的系统其回归测试的相关策略是不同的。现就该问题说明下个人的一些观点：

　　1. 自动化回归测试的确可以缓解这种问题，但是仅限于由这个必要和实力进行该项工作的公司。很多公司在项目开发上比较少使用这种方式，是因为这种方式的初期投入巨大且成效并不一定很好（受限于很多的因素，如开发流程是否规范、文档资料的是否完备等因素），另外，其实施成本高过手工回归很多倍（可能是手工测试投入的5倍以上）——不论在人员素质上，管理成本上，还是实施周期上。如果不是一种长期的、可延续性的项目或产品，则无法突出其效能，甚至是浪费有限资源在一个无底洞上。另一个缺点也是很明显的，则是该项工作往往滞后开发很多，需求的变更、编码设计的变化对其影响更甚。除此之外，目前的自动化回归测试技术还存在僵化、死板的问题，目前还没有一套比较成熟、灵活的框架可以适应所有的系统来完成对应的自动化开发，仅限于某一类特定框架、某一种特定类型而论。

　　2. 可采用迭代的开发模式来减少测试次数——我觉得几乎不可能。从开发模式上来说，频繁进行集成的确有助于提高系统的代码质量，提高集成的效率，但是从测试方面来说，该问题的实质并没有得到缓解。标准RUP的生命周期是集成不断，测试不断的生命周期，该周期内，只要一次正式发布，则必然有一次正式的测试过程，无论其质量是否已经真正提高了，该过程无法省略，也绝不可能省略。这种方式的有效性需要基于设计的模块间低耦合度才能达到其应有的效能，但是问题是现代的大型系统往往都是相对耦合度较高的系统，其模块间接口、系统间接口繁杂，必然导致测试工作量成倍增加，我觉得，若是这种情况，倒是应该考虑第一点的自动化测试说明，但是手工测试依然无法避免，至少要一次。讲到这里，相信大家都明白，开发模式无论如何变化，其最终的测试工作的简化是基于开发的具体流程而不是开发模式的好坏。

　　3. 版本管理。这个方法可能是被认为是最有效的办法，但是对于一个需求不断变化的系统而言，实现其版本管理的实质应该是对需求范围的阶段性实现进行管理的广义定义，而不是单纯意义上对代码、文档、模型、发布等内容上的管理。讲白了，版本管理的方法可能更多的是治标而不是治本。光靠这个方法还不能完全实现测试效率的提升。

　　个人觉得提升测试效率，降低测试轮次需要多方协作，数种方法组合才可能真正有效，必须针对特定的开发模式，系统架构、当前的阶段以及可用的有效资源，着实确定各项方案策略，结合实际的管理现状才有可能达成该项目标，否则的话，往往疲于奔命，劳苦不堪，却无任何成果可言。

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

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