对Bug起争议时的处理

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

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

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

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

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

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

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

回归测试的策略

假如XYC邮箱的测试工作已完成，Bug已全部修复，并已达到上线标准。接下来就以XYC邮箱为例来回顾一下XYC邮箱回归测试的基本流程

下面对以上流程图进行一个简要说明。

（1）开发人员把最初开发出来的XYC邮箱命名为XYC邮箱V1.0版本。测试人员就会针对XYC邮箱V1.0版本进行第一轮测试。第一轮测试执行完成后，测试人员一共发现了100个Bug，其中存在多个严重问题，XYC邮箱无法达到上线标准。

（2）开发人员随后对XYC邮箱V1.0版本的这100个Bug进行修复。Bug修复完成后，就把修复后的软件命名为XYC邮箱V1.1版本，以区别V1.0版本。接着测试人员就会在V1.1版本上进行第二轮的回归测试以验证开发人员是否修复了这100个Bug，结果发现100个Bug中有15个Bug并没有修复好，另外还新引入了25个Bug，相当于XYC邮箱V1.1版本还存在40个Bug，且存在多个严重问题，故达不到上线标准。

（3）开发人员随后对XYC邮箱V1.1版本上的这40个Bug进行修复，Bug修复完成后，就把修复后的软件命名为XYC邮箱V1.2版本，以区别V1.1版本。接着测试人员就会在V1.2的版本上进行第三轮的回归测试以验证开发人员是否修复了这40个Bug，结果发现40个Bug中有2个Bug并没有修复好，另外还新引入了10个Bug，相当于XYC邮箱V1.2版本存在12个Bug，且存在1个严重问题，故达不到上线标准。

（4）开发人员随后对XYC邮箱V1.2版本的这12个Bug进行修复，Bug修复完成后，就把修复后的软件重新命名为XYC邮箱V1.3版本，以区别V1.2版本。接着测试人员就会在V1.3的版本上进行第四轮的回归测试以验证开发人员是否修复了这12个Bug，结果发现仅有2个Bug存在，且这2个Bug都是建议性的问题，并不影响用户对功能的使用和体验，达到上线标准，此时XYC邮箱V1.3版本就可以上线让用户使用了。

以上展示的就是一个回归测试的基本流程，从中可以看到：

（1）即使上一轮的Bug被修复了，在下一轮的测试中还可能发现新的Bug，并不是说上一轮的Bug修复好了就不会再出现其他问题了；

（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提交等关键性的测试工作之后所要开展的工作，可以说此时的测试人员已经完全融入测试体系当中，也完全可以胜任相应的测试工作了。至于回归测试的策略，初级软件测试人员可通过先学习测试经理制定的策略，再从执行回归测试策略过程中进一步提升自己的测试经验。

测试如何应对新的开发模式？

为什么需要测试左移，测试右移？

测试可以保证产品质量，重要性不言而喻。但，要做好测试也比较困难，需要克服很多挑战。尤其是，持续交付、敏捷开发等开发模式为传统 软件测试方式带来了更大的时间压力。

我们先来看看下面这种熟悉的测试方式都有什么问题：测试人员接到项目后参与需求评审，然后根据需求文档写用例、准备脚本，等开发提测之后正式开始测试、提 Bug、回归，测试通过后就结束了，项目交给运维上线，之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么错，但有两大问题：

• 测试人员非常被动。当需求质量、开发质量较差的时候，测试人员只能被动接受。
• 但同时，测试又被认为是质量的责任人。如果因为需求质量、开发提测质量差而导致上线延期，大家通常会首先怪罪测试团队。

这些问题，在新的开发模式下愈发严重。因为这些新的开发模式有一个共同点，就是要缩短产品的交付周期，对自动化的要求越来越高，能够专门留给传统竖井流程中测试环节的时间越来越短，自然更难保证质量。在极端的情况下，比如在持续部署的模式下，所有测试都是自动化的，已经完全没有留给测试人员专门进行手工测试的时间了。与此同时，测试的能力和质量又是这些开发模式成功的关键。否则，即使可以频繁地构建产品，质量不过关价值也为零。所以，在快速开发模式的挑战下，测试左移、测试右移就应运而生了。这些测试模式，能让测试人员拥有更多主动权，以及更多的时间进行测试。

那，到底什么是测试左移和测试右移呢？

什么是测试左移和测试右移？

测试左移和右移，就是把测试的范围从传统测试的节点中释放出来，向左和右扩展。

向左扩展，就是让测试介入代码提测之前的部分。比如，扩展到开发阶段，在架构设计时就考虑产品的可测试性，并尽量进行开发自测等。另外，测试可以更进一步扩展到需求评审阶段，让测试人员不只是了解需求，更要评估需求的质量，比如分析需求的合理性以及完整性等。

类似的，测试右移，是让测试介入代码提测之后的部分。比如，测试人员在产品上线过程中，利用线上的真实环境测试。另外产品上线之后，测试人员仍然介入，通过线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。这样一来，测试人员不但有更多的时间进行测试，还能发现在非生产环境中难以发现的问题。

测试左移的原则和实践

• 调整团队对测试的态度；

• 把测试添加到开发和产品需求步骤中；

• 频繁测试，快速测试。

测试左移原则一：调整团队对测试的态度

调整团队对测试的态度，打破竖井的工作方式，是测试左移的前提。一个有效的办法是，按照功能的维度管理团队，让整个功能团队对产品负责。也就是说，如果产品质量出现问题，不只是测试团队“背锅”，而是会影响整个功能团队的绩效。同时，让质量问题的直接责任人承担更多的责任，来进一步增强团队成员的责任心。这种利益绑定的办法，虽然简单但非常有效，只不过出现质量问题时要记得进行根因分析，以避免再次出现类似问题。

另外，还要改变团队成员对测试工作的认知。传统的工作方式中，我们通常认为发现 Bug 最重要，但其实为了提高产品质量，更重要的是预防 Bug。所以说，在测试左移的过程中，我们应该更聚焦在预防 Bug 上。

测试左移原则二：把测试添加到开发和产品需求步骤中

测试左移的第一步，是把测试工作融入到开发步骤中。常用的办法是，让测试人员参与到开发阶段的方案设计中，了解开发的实现方式。因为很多开发人员可能只熟悉他负责的那一部分，而测试人员往往对全局更加了解，所以测试人员要评估改动范围以及是否有遗漏的模块和系统。

另外一个比较彻底，也很有效的方法是全栈开发，通过运维团队提供工具和支持，让开发人员尽量参与到运维工作中去。对于测试来说，也是同样的道理。我们可以让测试团队转型，进行工具开发，并更多地去支持专项测试，比如性能测试、安全测试等，通过“使能”的办法，让开发人员完成功能测试，包括单元测试、集成测试等。

说到让开发人员完成部分测试工作，常常会听到很多质疑声。反对者认为，测试人员的心理模型跟开发人员不一样，他们更倾向于去找问题。而开发人员面对自己开发的产品，潜意识里就不愿意去找问题，比如，他们不愿意专门尝试各种边界输入进行测试，而把自己开发的功能搞崩溃。所以，开发人员和测试人员更适合分开。

这种观念，在 10 年前瀑布开发模式盛行时就深入人心。我曾经也非常认同，但在 Facebook 工作了 5 年后改变了看法。如果你能够把开发人员的责任界定得很清楚，谁开发的产品谁要保证质量，那么开发人员自然而然地就会去尝试做好测试，比如进行边界测试。而且，开发人员最了解自己写的代码，所以他能够最高效地对自己的代码进行测试。

当然，做全栈开发的同时我们仍会保留一部分功能测试人员，毕竟从竖井模式转变到全栈模式是一个循序渐进的长期过程。不过 Facebook 做到了极致，完全没有了功能测试人员，也就是我们所说的“去 QA”。

测试左移到了开发阶段之后，再往左移一步就到了产品设计阶段，在这里，测试人员除了解需求外，更重要的是评估需求的质量。

我推荐使用 BDD（Behavior Driven Development，行为驱动开发）的方法进行开发，促进团队在需求评审时更多地考虑测试。BDD 是通过特定的框架，用自然语言或类自然语言，按照编写用户故事或者用例的方式，从功能使用者的视角描述并编写测试用例，从而让业务人员、开发人员和测试人员着眼于代码要实现的业务行为，并以此为依据通过测试用例进行验证。

测试左移原则三：频繁测试，快速测试

测试左移的第三个重要原则是，频繁测试、快速测试。在测试左移之前，我们需要等待提测，比较被动，不能频繁测试。但测试左移到开发阶段之后，我们就有了很大的自由度去频繁运行测试，从而更好地发挥测试的作用，尽早发现更多的问题。

这里最重要的方法就是，我在讲持续开发时提到的几个关于验证的操作，具体包括：

• 规范化、自动化化本地检查；

• 建设并自动化代码入库前的检查流程；

• 提供快速反馈，促进增量开发。

另外，为了能够顺利、频繁地运行测试，我们还要提升测试运行的速度。给测试提速的常见办法包括：

• 并行运行。比如把测试用例放到多台机器上运行，用资源换时间。

• 提高构建速度。比如使用精准构建，因为通常构建之后才能运行测试。

• 精准测试，也就是只运行跟改动最相关的测试。可以建立需求与代码的关系，以及需求与测试用例的关系，从而在代码改动时重点关注与之最相关的测试用例。

• 分层测试，即不同情况运行不同测试用例集合。

• 减少不必要的用例。比如，识别不稳定的用例，对其删除或者优化。