mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
68 lines
5.7 KiB
Markdown
68 lines
5.7 KiB
Markdown
|
软件 bug 的生命周期
|
|||
|
|
======
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
1947年，发现了第一个计算机 bug --被困在计算机继电器中的飞蛾。
|
|||
|
|
|
|||
|
|
要是所有的 bug 都能如此简单地发现就好了。随着软件变得越来越复杂，测试和调试的过程也变得更加复杂。如今，软件 bug 的生命周期可能会很长， 尽管正确的技术和业务流程可能会有所帮助。对于开源软件，开发人员使用严格的票务服务和协作来查找和缓解 bugs 。
|
|||
|
|
|
|||
|
|
### 确认计算机 bug
|
|||
|
|
|
|||
|
|
在测试过程中，会向开发团队报告 bug 。质量保证人员尽可能详细地描述 bug ， 报告他们的系统状态、他们正在进行的进程以及 bug 是如何表现出来的。
|
|||
|
|
|
|||
|
|
尽管如此， 一些 bug 从未得到证实；它们可能会在测试中报告， 但永远无法在受控环境中重现。在这种情况下，它们可能得不到解决， 而是被关闭。
|
|||
|
|
|
|||
|
|
由于使用的平台种类繁多， 用户行为也非常多， 因此很难确认计算机 bug ，有些 bug 只是间歇性地或在非常特殊的情况下发生的，而另一些 bug 可能会出现在随机的情况下。
|
|||
|
|
|
|||
|
|
许多人使用开源软件并与之交互，许多 bug 和问题可能是不可重复的， 或者可能没有得到充分的描述。不过， 由于每个用户和开发人员也都扮演质量保证测试员的角色，至少在一定程度上， 很有可能会发现 bug 。
|
|||
|
|
|
|||
|
|
确认 bug 后，工作就开始了。
|
|||
|
|
|
|||
|
|
### 分配要修复的 bug
|
|||
|
|
|
|||
|
|
已确认的 bug 被分配给解决的开发人员或开发团队。在此阶段， 需要重现 bug ，发现问题，并修复相关代码。如果 bug 的优先级较低，开发人员可以将此 bug 分类为稍后要修复的问题，也可以在该 bug 具有高优先级的情况下直接指派某人。无论哪种方式，都会在开发过程中打开票证，并且 bug 将成为已知的问题。
|
|||
|
|
|
|||
|
|
在开源解决方案中，开发人员可以从他们想要解决的 bug 中进行选择， 要么选择他们最熟悉的程序区域，要么从最优先的开始。综合解决方案， 如 [GitHub][1] 使多个开发人员能够轻松地处理解决方案, 而不会干扰彼此的工作。
|
|||
|
|
|
|||
|
|
在分配要修复的 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 可能很难找到， 但通过遵循集过程和过程， 开发人员可以使过程更快、更容易、更一致。质量保证是这一过程的重要组成部分， 因为 QA 测试人员必须发现和识别 bug ， 并帮助开发人员重现这些 bug 。在 bug 不再发生之前， 无法关闭和解决 bug。
|
|||
|
|
|
|||
|
|
开源解决方案分散了质量保证测试、开发和缓解的负担, 这往往导致 bug 被更快、更全面地发现和缓解。但是, 由于开源技术的性质, 此过程的速度和准确性通常取决于解决方案的受欢迎程度及其维护和开发团队的敬业精神。
|
|||
|
|
|
|||
|
|
_Rich Butkevic 是一个 PMP 项目经理认证,，敏捷开发框架认证（*certified scrum master*） 和 [Project Zendo][2] ，供项目管理专业人员发现简化和改进其项目成果策略的网站。与 Rich 联系 [Richbutkevic.com][3] 或者使用 [LinkedIn][4] 。_
|
|||
|
|
|
|||
|
|
--------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
via: https://opensource.com/article/18/6/life-cycle-software-bug
|
|||
|
|
|
|||
|
|
作者：[Rich Butkevic][a]
|
|||
|
|
选题：[lujun9972](https://github.com/lujun9972)
|
|||
|
|
译者：[lixinyuxx](https://github.com/lixinyuxx)
|
|||
|
|
校对：[校对者ID](https://github.com/校对者ID)
|
|||
|
|
|
|||
|
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|||
|
|
|
|||
|
|
[a]:https://opensource.com/users/rich-butkevic
|
|||
|
|
[1]:https://github.com/
|
|||
|
|
[2]:https://projectzendo.com
|
|||
|
|
[3]:https://richbutkevic.com
|
|||
|
|
[4]:https://www.linkedin.com/in/richbutkevic
|