阿里、字节等大厂面试处处坑，手把手教你如何应付——测试基础篇

什么是回归测试？

回归测试是指在修改后重新测试之前的测试，以确保修改的正确性。理论上，当一个新版本的软件产生时，有必要进行回归测试，以验证以前发现和修复的错误是否会在新版本的软件中再次出现。

基本策略

回归测试的策略一般由测试经理或测试组长制定，初级软件测试人员只需要按照相应的策略进行测试即可。现在以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提交等关键测试工作后要进行的工作。可以说此时的测试人员已经完全融入了测试系统，完全有资格进行相应的测试工作。对于回归测试的策略，初级软件测试人员可以先学习测试经理制定的策略，然后通过实施回归测试策略进一步提升自己的测试体验。

Bug起争议的处理

测试人员和开发人员争论bug是很常见的。比如，开发人员认为这不是bug，或者认为这个Bug不重要，不需要修改，而测试人员则认为这个Bug是非常严重的Bug，需要开发人员修改，或者因为其他原因产生纠纷。如果发生这种情况，测试人员应该怎么做？

(1)任何争议都需要“对事不对人”，双方的矛盾不能因为bug而激化。

(2)初级软件测试人员提交的Bug单有很多是开发人员转交给他们之后无法理解的。原因是测试人员提交的Bug列表没有描述清楚，这是一个非常普遍的现象。测试人员提交的Bug列表必须描述清楚，有足够的依据和理由。

(3)如果Bug列表写的很清楚，但是开发人员还是不愿意修改，可以找一个合适的时间和开发人员冷静沟通，说明这个Bug对产品质量可能产生的不利影响，测试人员在沟通过程中不要冲动。

(4)沟通之后，如果开发人员还是不想修改(当然开发人员也不是因为自己的原因不修改)，那么这个情况可以在这个时候上报给测试经理，测试经理可以出面解决，或者测试经理可以召开Bug评审会议(开发人员、测试人员、产品经理，有时候还有项目经理)共同决定。

(5)将Bug提交给开发人员后，一些初级软件测试人员会认同开发人员的意见，认为真的不是Bug，从而忽略了这个问题，这也是初级软件测试人员经常会遇到的事情。这就要求测试人员原则上提交bug，这是一个合格的测试人员最重要的特征之一，在处理问题的时候也要坚持原则。

(6)测试人员应面对面或通过电子邮件或电话与开发人员保持密切沟通，共同协商和处理bug，以减少他们之间的隔阂，增加测试人员与开发人员之间的信任和理解。直接沟通也要贯穿产品开发和测试的每一个环节。

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/te-hg/8574.html