软件测试一个软件的生命周期_软件错误的生命周期

软件测试一个软件的生命周期

1947年，发现了第一个计算机错误-蛾子被困在计算机继电器中。

如果仅发现所有错误，就这么简单。 随着软件变得越来越复杂，测试和调试过程也越来越复杂。 如今，软件错误的生命周期可能很长，尽管正确的技术和业务流程可以提供帮助。 对于开源软件，开发人员使用严格的票务服务和协作来发现和缓解错误。

确认电脑错误

在测试过程中，错误会报告给开发团队。 质量保证测试人员尽可能详细地描述错误，并报告其系统状态，正在进行的过程以及错误的表现方式。

尽管如此，某些错误从未得到证实。 它们可能会在测试中报告，但永远不能在受控环境中复制。 在这种情况下，它们可能无法解决，而是被关闭。

由于所使用的平台种类繁多以及用户行为的类型多种多样，因此很难确认计算机错误。 有些错误只会间歇地发生，或者在非常特殊的情况下发生，而其他错误似乎是随机发生的。

许多人使用开源软件并与之交互，并且许多错误和问题可能是不可重复的，或者可能没有得到充分描述。 但是，由于每个用户和开发人员也至少部分地扮演着质量保证测试员的角色，因此很有可能会发现错误。

确认错误后，便开始工作。

分配要修复的错误

已确认的错误已分配给要解决的开发人员或开发团队。 在此阶段，需要重现该错误，发现问题并修复相关的代码。 如果漏洞的优先级较低，开发人员可以将此漏洞归类为待解决的问题，如果漏洞的优先级较高，则开发人员可以直接分配人员。 无论哪种方式，在开发过程中都会打开票证，并且该错误成为已知问题。

在开源解决方案中，开发人员可以从他们要解决的错误中进行选择，或者选择他们最熟悉的程序领域，或者从最高优先级着手。 诸如GitHub之类的整合解决方案使多个开发人员可以轻松地在不干扰彼此工作的情况下开发解决方案。

在分配要修复的错误时，报告者还可以为错误选择优先级。 重大错误的优先级可能较高，例如，仅与外观相关的错误的优先级可能较低。 该优先级确定了分配开发团队的方式和时间，以解决这些问题。 无论哪种方式，都需要解决所有错误，然后才能认为产品是完整的。 在这方面，使用适当的可追溯性返回优先级要求也可能会有所帮助。

解决错误

修复错误后，通常会将其作为已解决的错误发送回质量保证。 然后，质量保证再次使产品步入正轨，以重现错误。 如果该错误无法复制，则质量保证将假定已正确解决该错误。

在开源情况下，所有更改都将被分发-通常作为正在测试的临时发行版。 该测试版本已分发给用户，这些用户再次担负质量保证的角色并测试产品。

如果该错误再次发生，则将问题发送回开发团队。 在此阶段，该bug被重新打开，并且开发团队应重复解决该bug的周期。 这可能会发生多次，尤其是在错误无法预测或间歇性的情况下。 众所周知，间歇性错误很难解决。

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

关闭错误

在解决，识别和解决了错误之后，便会关闭该错误，并且开发人员可以继续进行软件开发和测试的其他领域。 如果从未发现错误或开发人员无法重现错误，也将关闭该错误-无论哪种方式，下一阶段的开发和测试都将开始。

在测试版本中对该解决方案所做的任何更改都将纳入该产品的下一个版本。 如果该错误是严重的错误，则可以为当前用户提供补丁或修补程序，直到发布下一个版本为止。 这对于安全性问题很常见。

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

开源解决方案分散了质量保证测试，开发和缓解的负担，这通常会导致更快速，更全面地发现和缓解错误。 但是，由于开源技术的本质，此过程的速度和准确性通常取决于解决方案的普及程度以及其维护和开发团队的奉献精神。

Rich Butkevic是PMP认证的项目经理，认证的败类管理员，并运营Project Zendo （一个专为项目管理专业人士设计的网站），以发现简化和改善项目成果的策略。 在Richbutkevic.com或LinkedIn上与Rich 联系 。

翻译自: https://opensource.com/article/18/6/life-cycle-software-bug

软件测试一个软件的生命周期