mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
geekpi
GitHub
commit
861cf24250
@ -1,68 +0,0 @@
|
||||
translated by lixinyuxx
|
||||
The life cycle of a software bug
|
||||
======
|
||||
|
||||
|
||||
|
||||
In 1947, the first computer bug was found—a moth trapped in a computer relay.
|
||||
|
||||
If only all bugs were as simple to uncover. As software has become more complex, so too has the process of testing and debugging. Today, the life cycle of a software bug can be lengthy—though the right technology and business processes can help. For open source software, developers use rigorous ticketing services and collaboration to find and mitigate bugs.
|
||||
|
||||
### Confirming a computer bug
|
||||
|
||||
During the process of testing, bugs are reported to the development team. Quality assurance testers describe the bug in as much detail as possible, reporting on their system state, the processes they were undertaking, and how the bug manifested itself.
|
||||
|
||||
Despite this, some bugs are never confirmed; they may be reported in testing but can never be reproduced in a controlled environment. In such cases they may not be resolved but are instead closed.
|
||||
|
||||
It can be difficult to confirm a computer bug due to the wide array of platforms in use and the many different types of user behavior. Some bugs only occur intermittently or under very specific situations, and others may occur seemingly at random.
|
||||
|
||||
Many people use and interact with open source software, and many bugs and issues may be non-repeatable or may not be adequately described. Still, because every user and developer also plays the role of quality assurance tester, at least in part, there is a good chance that bugs will be revealed.
|
||||
|
||||
When a bug is confirmed, work begins.
|
||||
|
||||
### Assigning a bug to be fixed
|
||||
|
||||
A confirmed bug is assigned to a developer or a development team to be addressed. At this stage, the bug needs to be reproduced, the issue uncovered, and the associated code fixed. Developers may categorize this bug as an issue to be fixed later if the bug is low-priority, or they may assign someone directly if it is high-priority. Either way, a ticket is opened during the process of development, and the bug becomes a known issue.
|
||||
|
||||
In open source solutions, developers may select from the bugs that they want to tackle, either choosing the areas of the program with which they are most familiar or working from the top priorities. Consolidated solutions such as [GitHub][1] make it easy for multiple developers to work on solutions without interfering with each other's work.
|
||||
|
||||
When assigning bugs to be fixed, reporters may also select a priority level for the bug. Major bugs may have a high priority level, whereas bugs related to appearance only, for example, may have a lower level. This priority level determines how and when the development team is assigned to resolve these issues. Either way, all bugs need to be resolved before a product can be considered complete. Using proper traceability back to prioritized requirements can also be helpful in this regard.
|
||||
|
||||
### Resolving the bug
|
||||
|
||||
Once a bug has been fixed, it is usually be sent back to Quality Assurance as a resolved bug. Quality Assurance then puts the product through its paces again to reproduce the bug. If the bug cannot be reproduced, Quality Assurance will assume that it has been properly resolved.
|
||||
|
||||
In open source situations, any changes are distributed—often as a tentative release that is being tested. This test release is distributed to users, who again fulfill the role of Quality Assurance and test the product.
|
||||
|
||||
If the bug occurs again, the issue is sent back to the development team. At this stage, the bug is reopened, and it is up to the development team to repeat the cycle of resolving the bug. This may occur multiple times, especially if the bug is unpredictable or intermittent. Intermittent bugs are notoriously difficult to resolve.
|
||||
|
||||
If the bug does not occur again, the issue will be marked as resolved. In some cases, the initial bug is resolved, but other bugs emerge as a result of the changes made. When this happens, new bug reports may need to be initiated, starting the process over again.
|
||||
|
||||
### Closing the bug
|
||||
|
||||
After a bug has been addressed, identified, and resolved, the bug is closed and developers can move on to other areas of software development and testing. A bug will also be closed if it was never found or if developers were never able to reproduce it—either way, the next stage of development and testing will begin.
|
||||
|
||||
Any changes made to the solution in the testing version will be rolled into the next release of the product. If the bug was a serious one, a patch or a hotfix may be provided for current users until the release of the next version. This is common for security issues.
|
||||
|
||||
Software bugs can be difficult to find, but by following set processes and procedures, developers can make the process faster, easier, and more consistent. Quality Assurance is an important part of this process, as QA testers must find and identify bugs and help developers reproduce them. Bugs cannot be closed and resolved until the error no longer occurs.
|
||||
|
||||
Open source solutions distribute the burden of quality assurance testing, development, and mitigation, which often leads to bugs being discovered and mitigated more quickly and comprehensively. However, because of the nature of open source technology, the speed and accuracy of this process often depends upon the popularity of the solution and the dedication of its maintenance and development team.
|
||||
|
||||
_Rich Butkevic is a PMP certified project manager, certified scum master, and runs[Project Zendo][2] , a website for project management professionals to discover strategies to simplify and improve their project results. Connect with Rich at [Richbutkevic.com][3] or on [LinkedIn][4]._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/6/life-cycle-software-bug
|
||||
|
||||
作者：[Rich Butkevic][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者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
|
||||
67
translated/tech/20180625 The life cycle of a software bug.md
Normal file
67
translated/tech/20180625 The life cycle of a software bug.md
Normal file
@ -0,0 +1,67 @@
|
||||
软件 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
|
||||
Loading…
Reference in New Issue
Block a user