这个话题比较难定义，随便谈谈自己的体会吧……
题目要求还是老传统——“高效”！那就意味着必须有的放矢的实施工作，不能一股脑儿都重新来一遍。而“回归”的核心并不是“执行”测试，其实是回归测试前需要做的准备和测试后的结果分析。
1、回归测试的前提
在第一次乃至第二次、第三次测试过程中，应该保存下来每次测试的缺陷记录单和详细缺陷描述表。且缺陷应该适当进行归纳和等级划分。这个是定位回归测试点“ 轻重”的前提条件。且必须考虑修正缺陷后，原有缺陷是否会给系统带来相应功能模块的连带影响，孰轻孰重、及其范围的大小。
2、回归测试的执行
有了清晰的测试重点，那么对症下药很容易对先前出现过的缺陷再进行测试。而大型系统肯定是基于较完整的测试用例库和测试脚本来执行测试的。利用自动化工具，对系统做一个完整回归执行，可以明显减少诸多成本。
3、回归测试的分析
测试完了，结合工具跟踪后得到的报表或统计分析图，看原有缺陷的修正情况，以及该缺陷覆盖周边的最可能已经触发的新缺陷。这点比较关键，测试开始前理清思路，现在分析时就一目了然。一般情况下，测试工程师回归自己发现的缺陷很容易，如同楼上所说，仅靠脑袋里想法和自身累积的项目经验即可完成回归测试工作。
4、工具的结合使用
开发工程师往往只会对测试工程师发现的缺陷修正。然而，其他一系列新问题还是可能发生了，只找原发现的缺陷，肯定片面，还是会遗漏诸多新问题。如，回归后，对系统带来的新的严重的问题。所以，最好还是利用原先录制好的用例和脚本对全局进行完整的自动化操作。否则，缺这补那，永远难以结束复杂的“回归”之路。性能测试更需使用工具来执行测试，不是么？
以上只是个人想法，请诸位不吝指正，谢谢！
版权声明：原创作品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。
本文出自51Testing软件测试网，感谢会员土土的豆豆在每周一问（08-12-01）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html
相关阅读：
