在软件开发的迭代过程中，每当软件被修改或升级后，都会进行回归测试。这种测试主要是为了确认以前发现并修复的错误在新版本中是否依然存在。简单来说，就是通过重新运行旧的测试用例来确保软件的核心功能没有因为修改而受到破坏。
### 测试策略的制定
测试策略通常由经验丰富的测试经理或测试组长制定。以下是几种常见的回归测试策略：
1. **执行全部测试用例**：如果软件在之前的版本中发现了大量错误，那么在新的回归测试中，应当重新执行所有的测试用例。这种方法虽然耗费时间和人力，但可以确保所有功能点都经过验证，不会遗漏任何问题。
2. **重点测试关键功能点**：在第二轮或后续的回归测试中，可以选择性地执行重要的、常用的或与已修复错误相关的功能点的测试用例。这种方法可以节省时间和资源，但需要测试人员对软件的功能有深入的了解。
3. **选择性测试**：在后期回归测试中，可以根据剩余的Bug数量和严重程度，选择性地执行一些关键功能点的测试用例。这种方法适用于软件已经相对稳定的情况。
4. **仅测试出现Bug的功能点**：如果测试团队认为软件已经非常稳定，可以选择只测试那些在最新修改中出现问题的功能点。
### 处理测试争议
测试人员和开发人员之间因为Bug的处理经常会产生争议。以下是一些处理争议的建议：
- **对事不对人**：在任何争议中，都应专注于问题本身，而不是攻击对方。 - **详细描述Bug**：测试人员提交的Bug报告应详细清晰，提供充足的证据和描述，以便开发人员能够理解并处理。 - **沟通与协商**：如果开发人员对Bug的处理持有不同意见，测试人员应寻找合适的时间进行沟通，说明Bug可能对产品质量的影响。 - **寻求上级介入**：如果沟通无法解决问题，测试人员可以向上级汇报，由测试经理或更高层的管理者来协调解决。 - **坚持原则**：测试人员应保持原则性，对待问题不能轻易妥协，这是成为一名合格测试人员的重要特质。
测试人员与开发人员之间的密切合作是保证软件质量的关键。通过不断的沟通和协作，两者可以共同发现并解决软件中存在的问题，从而提升产品的整体质量。
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，以减少两者间的隔膜，增加测试人员与开发人员之间的信任和了解。直接沟通也应贯穿到产品开发、测试的每个环节当中。
