软件bug的确认和解决

1947 年，发现了第一个计算机 bug —— 被困在计算机继电器中的飞蛾。

要是所有的 bug 都能如此简单地发现就好了。随着软件变得越来越复杂，测试和调试的过程也变得更加复杂。如今，软件 bug 的生命周期可能会很长，尽管正确的技术和业务流程可能会有所帮助。对于开源软件，开发人员使用严格的工单服务和协作来查找和解决 bug。

确认计算机 bug

在测试过程中，发现的 bug 会报告给开发团队。质量保证测试人员尽可能详细地描述 bug ，报告他们的系统状态、他们正在进行的过程以及 bug 是如何表现出来的。

尽管如此，一些 bug 从未得到确认；它们可能会在测试中报告，但永远无法在可控环境中重现。在这种情况下，它们可能得不到解决，而是被关闭。

有些计算机 bug 可能很难确认，因为使用的平台种类繁多，用户行为也非常多。有些 bug 只是间歇性地或在非常特殊的情况下发生的，而另一些 bug 可能会出现在随机的情况下。

许多人使用开源软件并与之交互，许多 bug 和问题可能是不可重复的，或者可能没有得到充分的描述。不过，由于每个用户和开发人员也都扮演质量保证测试人员的角色，至少在一定程度上，bug 还是很有可能会发现的。

确认 bug 后，修复工作就开始了。

分配要修复的 bug

已确认的 bug 被分配给负责解决的开发人员或开发团队。在此阶段，需要重现 bug，发现问题，并修复相关代码。如果 bug 的优先级较低，开发人员可以将此 bug 分类为稍后要修复的问题，也可以在该 bug 具有高优先级的情况下直接指派某人修复。无论哪种方式，都会在开发过程中打开一个工单，并且 bug 将成为已知的问题。

在开源解决方案中，开发人员可以进行选择他们想要解决的 bug，要么选择他们最熟悉的程序区域，要么从优先级最高的的开始。综合解决方案，如 GitHub 使得多个开发人员能够轻松地着手解决，而不会干扰彼此的工作。

当将 bug 设置为需要修复时，bug 报告者还可以为该 bug 选择优先级。主要的 bug 可能具有较高的优先级，而仅与外观相关的 bug 可能具有较低的级别。优先级确定开发团队解决这些问题的方式和时间。无论哪种方式，所有的 bug 都需要先解决，然后才能认为产品已完成。在这方面，适当的回溯到优先级高的需求也会很有帮助。

解决 bug

一旦修复了 bug ，通常会将其作为已解决的 bug 发送回质量保证测试人员。然后，质量保证测试人员再次将产品置于其工作中，以重现 bug。如果无法重现 bug ，质量保证测验人员将假定它已得到适当解决。

在开源情况下，任何更改都会被分发，通常是作为正在测试的暂定版本。此测试版本分发给用户，用户再次履行质量保证测试人员的职责并测试产品。

如果 bug 再次出现，问题将被发送回开发团队。在此阶段，该 bug 将重新触发，开发团队有责任重复解决该 bug 的循环。这种情况可能会发生多次，尤其是在 bug 不可预知或间歇性发生的情况下。众所周知，间歇性的 bug 很难解决。

如果该 bug 不再出现，则该问题将被标记为已解决。在某些情况下，最初的 bug 得到了解决，但由于所做的更改，会出现其他 bug。发生这种情况时，可能需要新的 bug 报告，然后重新开始该过程。

关闭 bug

在处理、识别和解决 bug 后，该 bug 将被关闭，开发人员可以转到软件开发和测试的其他阶段。如果始终找不到 bug ，或者开发人员无法重现 bug ，则该 bug 也将被关闭 —— 无论哪种方式，都将开始开发和测试的下一阶段。

在测试版本中对解决方案所做的任何更改都将滚动到产品的下一个版本中。如果 bug 是严重的，则在下一个版本发布之前，可能会为当前用户提供修补程序或修补程序。这在安全问题中很常见。

软件 bug 可能很难找到，但通过遵循过程，开发人员可以使开发更快、更容易、更一致。质量保证是这一过程的重要组成部分，因为质量保证测试人员必须发现和识别 bug ，并帮助开发人员重现这些 bug 。在 bug 不再发生之前，无法关闭和解决 bug。

开源的解决方案分散了质量保证测试、开发和缓解的负担，这往往导致 bug 被更快、更全面地发现和缓解。但是，由于开源技术的性质，此过程的速度和准确性通常取决于解决方案的受欢迎程度及其维护和开发团队的敬业精神。

Rich Butkevic 是一个 PMP 项目经理认证,，敏捷开发框架认证（certified scrum master） 并且 维护 Project Zendo，这是供项目管理专业人员去发现、简化和改进其项目成果策略的网站。可以在 Richbutkevic.com 或者使用 LinkedIn 与 Rich 联系。