软件缺陷的生命周期

1947年，发现了第一个计算机错误——一只飞蛾被困在计算机继电器里。

如果所有错误都像发现这只飞蛾一样简单就好了。 随着软件变得越来越复杂，测试和调试的过程也随之变得复杂。 今天，软件缺陷的生命周期可能很长，但正确的技术和业务流程可以提供帮助。 对于开源软件，开发人员使用严格的票务服务和协作来查找和减轻错误。

确认计算机错误

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

尽管如此，有些错误永远无法确认。 它们可能在测试中被报告，但永远无法在受控环境中重现。 在这种情况下，它们可能不会被解决，而是会被关闭。

由于正在使用的平台种类繁多以及用户行为类型多种多样，因此很难确认计算机错误。 有些错误仅间歇性地发生或在非常特殊的情况下发生，而另一些错误可能看似随机发生。

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

当确认错误时，工作就开始了。

分配要修复的错误

确认的错误会被分配给开发人员或开发团队进行处理。 在此阶段，需要重现该错误，发现问题，并修复相关的代码。 如果该错误优先级较低，开发人员可能会将该错误归类为稍后修复的问题，如果优先级较高，他们可能会直接分配给某人。 无论哪种方式，都会在开发过程中打开一个工单，并且该错误变成已知问题。

在开源解决方案中，开发人员可以选择他们想要处理的错误，可以选择他们最熟悉的程序区域，或者从最高优先级开始工作。 诸如GitHub之类的综合解决方案使多个开发人员可以轻松地协同工作，而不会互相干扰。

在分配要修复的错误时，报告者还可以为该错误选择优先级。 主要错误可能具有较高的优先级，而仅与外观相关的错误（例如）可能具有较低的优先级。 此优先级决定了何时以及如何分配开发团队来解决这些问题。 无论哪种方式，在产品被认为是完整之前，都需要解决所有错误。 在这方面，正确追溯到优先排序的需求也可能有所帮助。

解决错误

修复错误后，通常会将其作为已解决的错误发送回质量保证部门。 然后，质量保证部门再次对产品进行测试，以重现该错误。 如果无法重现该错误，则质量保证部门将假定该错误已得到正确解决。

在开源环境中，任何更改都会被分发出去——通常是以正在测试的临时版本形式。 此测试版本被分发给用户，用户再次履行质量保证的角色并测试该产品。

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

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

关闭错误

在错误被处理、识别和解决后，该错误将被关闭，开发人员可以继续进行软件开发和测试的其他领域。 如果从未发现错误，或者开发人员始终无法重现该错误，则该错误也将被关闭——无论哪种方式，都将开始下一个开发和测试阶段。

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

软件错误可能很难找到，但是通过遵循既定的流程和程序，开发人员可以使该过程更快、更简单和更一致。 质量保证是此过程的重要组成部分，因为QA测试人员必须查找和识别错误，并帮助开发人员重现它们。 只有在错误不再发生时，才能关闭和解决错误。

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

Rich Butkevic是一位经过PMP认证的项目经理，经过认证的Scrum Master，并且运营Project Zendo，这是一个供项目管理专业人员发现简化和改善其项目成果的策略的网站。 在Richbutkevic.com或LinkedIn上与Rich联系。