转自：

http://www.51testing.com/html/93/n-148193.html

最近看这个问题也看得蛮多的，学习了一些思想，过来总结下

　　看个IBM的资料，里面写的很具体：http://www.51testing.com/html/77/n-147877.html

　　大概就是要注意两个方面：

　　1、测试用例的优化选择(好的测试用例可以用少的用例覆盖新版本中尽量多的改动)

　　2、覆盖率分析(保证回归测试时的质量)

　　图 3. 测试用例优化选择举例 如上图所示，所有的测试用例都会有一个函数调用的路径。我们把这些调用路径一一记下来。对于新版本所作的改动，所有与之相关的上层调用的测试用例都能够准确地选出来，这样我们就能用这些准确的测试用例来覆盖这次改动所产生的影响。毫不相关的测试用例则不会被选出来。从而用较小的成本完成这次改动所需要的回归测试，既省时省力又保证较高的测试质量。

　　图 4. 覆盖率分析举例

　　如上图所示，在版本更新过程中受到影响的测试用例为TestCase1, Test Case2, Test Case3 覆盖了 12 个 Node，在版本更新过程中的更新点是 4，其中被覆盖到的为 3，还有 1 个更新点没有被覆盖到，现有测试用例集合的更新覆盖能力为 75% 。这样，我们知道上一个版本的测试用例设计不够充分尚有程序模块没有被任何已有的测试用例所覆盖。由于代码的更新最有可能引起程序的缺陷甚至系统崩溃，所以需要添加新的测试用例以保证对更新的覆盖，以降低程序运行的风险。

　　对于软件的节点覆盖率，我们细化到函数粒度。我们是通过软件部署的 Binary 代码分析得知的函数情况。不需要借助源代码，因此对于软件进行测试覆盖率分析来说要求低，用较小的成本完成此次的测试用例覆盖反馈与分析。既省时省力又保证较高的测试质量。

　　还有些方法：

　　NO.1

　　选择回归测试的时候，首先要确定的是，回归测试用例的比例，这个要根据时间情况了，100%是最好了，我个人一般这个比例在60%左右。然后要确定回归测试用例的优先级。根据我的经验，一般有如下必须回归的用例：

　　第一，新修改的功能，这个显然是重点

　　第二，新修改的功能的关联功能，就是有耦合的部分，这个一般最好咨询一下开发人员

　　第三，程序最有卖点或者说亮点的部分，这个地方一旦有问题，会使程序质量大打折扣

　　第四，程序中最致命的部分，譬如说安全隐患，数据泄露，加密注册

　　第五，程序中比较脆弱的部分，这个要咨询开发人员，一般就是他们心中最没底的地方

　　第六，程序的主干功能

　　第七，如果以上做完，还有时间的话，最好把用例中级别比较高的用例再执行一遍。

　　以上是回归测试用例的选择优先级。

　　其实，即使这样做，还是有风险的。最根本的解决方法是自动化测试工具加上手工测试。具体就是常用的程序主干功能，主要功能，用自动化测试，保证每一个版本都能够执行一遍，其他修改频繁的小功能手工测试了。

　　说了这么多，好像比较乱，总结一下。

　　个人觉得解决这个回归测试的终极解决方案是：

　　a.作每日构建

　　b.基线功能自动化

　　c.编写用例时一定要分级（按照风险度，常用度，重要度）

　　手工执行回归测试用例（就是我上面说的7项）

　　NO.2

　　按照需求说明，把需求和功能点做矩阵表，然后功能点和test case作矩阵表，

　　每次需求有变动，就可以看它的变动所涉及的功能点，然后对应的testcase有多少，之后可以客观的分析下，所需的工作量，可以根据具体的时间作一些删减。

以下转自：

http://www.51testing.com/html/78/n-116678.html

如何高效进行回归测试

　　很久没有写东西了，都是金融危机惹的祸，说说个人想法，最近正在整理一些流程规范的东西，回归测试正是需要考虑的部分。

　　说到回归测试，可以说每个做测试的人都做过，重复，无聊，消耗时间等可能是大家做回归测试的记忆。也许实施自动化测试可以解决一部分回归测试，但不是所有的测试都可以自动化，也不是所有的公司都有能力实施自动化，下面写的内容不涉及自动化内容。

　　从三方面来讨论做回归测试：

　　一、测试流程方面

　　一般通用的测试流程都是“测试计划”—“测试设计”—“测试执行/分析”—“测试报告”，贯穿与整个项目，和开发流程相对应。由于本人做游戏测试方面，需求变更对游戏行业来说是很频繁，很正常的，在做游戏行业测试不能和通用软件测试流程一样，游戏测试流程应该是螺旋式的，单元测试，模块功能测试，集成测试，系统测试，性能测试，压力测试等是测试的一个过程，“测试计划”—“测试设计”—“测试执行/分析”—“测试报告”应该实施在每个阶段，实施在单元测试阶段，实施在模块功能测试阶段等，这样才能达到螺旋效果。而在每一次螺旋测试结束后，实施下一次螺旋测试前都应该进行回归测试，回归测试在螺旋测试中应该贯穿与每个螺旋阶段，而不是只贯穿与项目测试。

　　二、测试用例设计方面

　　有了上面的回归测试流程计划，下面要实施的就是回归测试的重点——测试用例。在设计测试用例中就应该把回归测试用例考虑进去，可以通过设置用例优先级做为后期回归测试用例的挑选条件，也可以是其他的。

　　测试用例一般在项目中分为三种，单元测试用例，功能测试用例，性能测试用例。

　　1、 在不能阶段设计测试用例，挑选回归测试用例是不同的，单元测试用例设计一般选择具有编程能力的测试人员设计，功能测试用例设计选择熟悉业务知识的测试人员设计，性能测试用例设计一般需要与开发人员商讨才能设计。也就是说只有选对设计测试用例的人员，才有可能在后期挑选出好的回归测试用例。

　　2、 项目中的拳头功能，亮点，用户大量使用的功能应该是重点保护的地方，这方面可以交给小组核心人员进行设计。

　　3、 测试用例设计一定要设置优先级(依靠测试人员个人水平，用例评审等进行设置)。

　　三、测试管理方面

　　现在的团队都讲究团队精神，可以说，一个测试团队的水平发挥，一半以上可以说和管理的好坏有关，这也就是为什么回归测试会和测试管理有关系了，也就需要一个好管理者来进行管理了。

　　1、 单单有计划还不行，还得靠执行，上面的测试流程应该在制定后严格执行，每一轮的螺旋测试后和下一轮螺旋测试之前都应该进行回归测试，如单元测试之后，模块功能测试之前，应该挑选单元测试用例进行回归测试，只有保证单元测试通过才能进入下一轮螺旋测试。

　　2、 测试管理人员在测试开始之前要非常熟悉项目，才能在后期安排任务时把不同的测试安排给合适的人选，发挥最大的力量，这就需要管理者具备良好的沟通力和分析能力

　　3、 执行测试用例评审——重点模块，亮点模块的测试用例必须经过评审

　　4、 回归测试重点地方——BUG修改，关联功能，新增加，修改功能，上一轮测试BUG多的功能。

　　5、 做好每轮螺旋回归测试工作——分析上一轮螺旋测试缺陷，找出缺陷比较多的地方是下轮回归测试重点，需要重新挑选回归用例。

　　6、 编写每轮螺旋测试报告——分析缺陷，测试方法等，为下一轮螺旋测试做修改，准备。

　　7、 持续改进——每一轮的螺旋测试后都应该分析，计划，团队，用例设计等是否需要改进，做到螺旋测试持续改进。

　　脑袋有点乱，思路可能没表达清楚，以后再修改，个人认为回归测试方法不是一成不变的，也应该是持续改进。不同阶段需要的回归测试都是不一样的。回归测试不能仅仅只和测试用例相关。