最近看这个问题也看得蛮多的，学习了一些思想，过来总结下
看个IBM的资料，里面写的很具体：http://www.51testing.com/html/77/n-147877.html
大概就是要注意两个方面：
1、测试用例的优化选择(好的测试用例可以用少的用例覆盖新版本中尽量多的改动)
2、覆盖率分析(保证回归测试时的质量)
图 3. 测试用例优化选择举例 如上图所示，所有的测试用例都会有一个函数调用的路径。我们把这些调用路径一一记下来。对于新版本所作的改动，所有与之相关的上层调用的测试用例都能够准确地选出来，这样我们就能用这些准确的测试用例来覆盖这次改动所产生的影响。毫不相关的测试用例则不会被选出来。从而用较小的成本完成这次改动所需要的回归测试，既省时省力又保证较高的测试质量。
图 4. 覆盖率分析举例
如上图所示，在版本更新过程中受到影响的测试用例为 Test Case1, Test Case2, Test Case3 覆盖了 12 个 Node，在版本更新过程中的更新点是 4，其中被覆盖到的为 3，还有 1 个更新点没有被覆盖到，现有测试用例集合的更新覆盖能力为 75% 。这样，我们知道上一个版本的测试用例设计不够充分尚有程序模块没有被任何已有的测试用例所覆盖。由于代码的更新最有可能引起程序的缺陷甚至系统崩溃，所以需要添加新的测试用例以保证对更新的覆盖，以降低程序运行的风险。
对于软件的节点覆盖率，我们细化到函数粒度。我们是通过软件部署的 Binary 代码分析得知的函数情况。不需要借助源代码，因此对于软件进行测试覆盖率分析来说要求低，用较小的成本完成此次的测试用例覆盖反馈与分析。既省时省力又保证较高的测试质量。
还有些方法：
NO.1
选择回归测试的时候，首先要确定的是，回归测试用例的比例，这个要根据时间情况了，100%是最好了，我个人一般这个比例在60%左右。然后要确定回归测试用例的优先级。根据我的经验，一般有如下必须回归的用例：
第一，新修改的功能，这个显然是重点
第二，新修改的功能的关联功能，就是有耦合的部分，这个一般最好咨询一下开发人员
第三，程序最有卖点或者说亮点的部分，这个地方一旦有问题，会使程序质量大打折扣
第四，程序中最致命的部分，譬如说安全隐患，数据泄露，加密注册
第五，程序中比较脆弱的部分，这个要咨询开发人员，一般就是他们心中最没底的地方
第六，程序的主干功能
第七，如果以上做完，还有时间的话，最好把用例中级别比较高的用例再执行一遍。
以上是回归测试用例的选择优先级。
其实，即使这样做，还是有风险的。最根本的解决方法是自动化测试工具加上手工测试。具体就是常用的程序主干功能，主要功能，用自动化测试，保证每一个版本都能够执行一遍，其他修改频繁的小功能手工测试了。
说了这么多，好像比较乱，总结一下。
个人觉得解决这个回归测试的终极解决方案是：
a.作每日构建
b.基线功能自动化
c.编写用例时一定要分级（按照风险度，常用度，重要度）
手工执行回归测试用例（就是我上面说的7项）
NO.2
按照需求说明，把需求和功能点做矩阵表，然后功能点和test case作矩阵表，
每次需求有变动，就可以看它的变动所涉及的功能点，然后对应的testcase有多少，之后可以客观的分析下，所需的工作量，可以根据具体的时间作一些删减。
相关阅读：
