回归测试，有什么高效的测试方法?

1、什么是回归测试

　　回归测试（Regression testing） 指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。

2、测试策略

　　回归测试的策略一般由测试经理或测试组长制定，初级软件测试人员只要按相应的策略执行测试即可。现以XYC邮箱的测试为例，简要介绍一下回归测试的基本策略。

（1）回归测试时执行全部的测试用例

　　XYC邮箱V1.0版本的第一轮测试中发现100个Bug，那么在第二轮的回归测试中，除了测试这100个Bug之外，其他所有功能点的测试用例需要重新再执行一遍，这样做的原因在于，回归测试的V1.1版本是在修改了V1.0版本存在的100个Bug的基础上建立起来的。由于修复了大量的Bug，这就意味着要改动大量的代码，当多处代码被改动后谁也不能保证其他功能点不受影响，所以对所有的功能点进行测试是比较保险的，也是比较周密的，不会遗漏任何的测试点。使用此策略的时间周期和人力成本也是比较高的，一般情况下，当第一轮测试发现的Bug数量过多的情况下，第二轮回归测试应该执行全部的测试用例。

（2）选择重要的功能点、常用的功能点、与Bug相关联的功能点进行回归测试

　　XYC邮箱的第二轮回归测试中又发现了40个Bug，那么在第三轮的回归测试过程中，除了要测试这40个Bug之外，还应当把重要的功能点、常用的功能点、与Bug相关联的功能点的测试用例再执行一遍，其他次要的测试用例可在时间充足的情况下选择性执行。

（3）选择性执行关键功能点的测试用例

　　XYC邮箱的第三轮回归测试中又发现了12个Bug，那么在第四轮的回归测试过程中，除了测试这12个Bug之外，还可以选择性地执行一些关键功能点的测试用例，其他测试用例可在时间充足的情况下选择性执行。

（4）仅测试出现Bug的功能点

　　如果测试组认为软件的功能点已经十分稳定了，回归测试的时候可选择仅测试出现Bug的功能点。每个策略都有其适应的场景，不能一概而论，应当以Bug的数量和严重程度为导向，深入分析，然后得出适合本项目的回归测试策略。

　　回归测试是在系统测试人员完成了需求评审、测试计划、用例设计、环境搭建、Bug提交等关键性的测试工作之后所要开展的工作，可以说此时的测试人员已经完全融入测试体系当中，也完全可以胜任相应的测试工作了。至于回归测试的策略，初级软件测试人员可通过先学习测试经理制定的策略，再从执行回归测试策略过程中进一步提升自己的测试经验。

3、对Bug起争议时的处理

　　测试人员和开发人员因Bug起争议的事情常有发生，例如开发人员认为这不算是一个Bug，或认为这个Bug不重要，不需要修改，而测试人员认为这是一个很严重的Bug，需要开发人员修改，或因其他原因起了争议等。如果出现了这些情况，测试人员应如何处理呢？

　　（1）任何争议都需要“对事不对人”，不能因为Bug而激化了双方的矛盾。

　　（2）有很多初级软件测试人员提交的Bug单流转到开发人员那里后，开发人员看不懂。原因在于测试人员提交的Bug单没有描述清楚，这是一个非常常见的现象。测试人员提交的Bug单一定要描述清楚，并需要有充足的依据和理由。

　　（3）如果Bug单写清楚了，但开发人员还是不愿意修改的话，可以找一个合适的时间，心平气和地与开发人员沟通，说明此Bug对产品质量可能产生的不良影响，测试人员在沟通过程中不能意气用事。

　　（4）经沟通后，如果开发人员还是不愿意修改的话（当然开发人员不修改也有他们的原因），那么此时可以向测试经理汇报这一情况，由测试经理出面解决，或是由测试经理召开Bug评审大会（开发人员、测试人员、产品经理三方人员参与，有时也包括项目经理），共同定夺。

　　（5）有些初级软件测试人员把Bug提交到开发人员那后，经过开发人员的各种解释，就会同意开发人员的意见，也认为这确实不是一个Bug，从而忽略这个问题，这也是经常发生在初级软件测试人员身上的事情。这就要求测试人员提交Bug的过程要有原则性，这也是作为一名合格的测试人员最重要的特征之一，对待问题需要坚持原则。

　　（6）测试人员应和开发人员面对面或通过电子邮件、电话等方式保持密切沟通，共同协商和处理Bug，以减少两者间的隔膜，增加测试人员与开发人员之间的信任和了解。直接沟通也应贯穿到产品开发、测试的每个环节当中。