软件开发中的错误生命周期
我们将在本课中介绍缺陷的生命周期，以帮助您了解测试人员在测试环境中工作时必须处理的缺陷的多个阶段。
在缺陷生命周期方面，我们还包含了最常被要求的面试问题。了解缺陷的生命周期需要了解故障的多个阶段。测试活动的主要目标是查看产品是否有任何缺陷或故障。
错误/错误/故障在现实世界中都被称为错误/缺陷，因此我们可以说测试的基本目标是保证产品不太容易出现缺陷（没有缺陷是不现实的情况）。
究竟什么是缺陷？
简而言之，缺陷是应用程序中的故障或错误，它通过将预期行为与实际行为不匹配来阻止程序的正常流程。
当开发人员在应用程序的设计或开发过程中犯了错误，而这个问题被测试人员发现时，它被称为缺陷。
测试人员的工作是彻底测试应用程序，以发现尽可能多的缺陷，从而将高质量的产品送到消费者手中。在继续处理问题的过程和各个阶段之前，掌握缺陷生命周期至关重要。
因此，让我们进一步进入缺陷生命周期。
到目前为止，我们已经讨论了什么是缺陷以及它与测试过程的关系。现在让我们看看缺陷生命周期，了解缺陷过程以及缺陷的各个阶段。
什么是缺陷的生命周期？
在软件测试中，生命周期是指缺陷或错误在其整个存在过程中所经历的阶段的确切集合。缺陷生命周期的目标是通过方便地协调问题的当前状态并将其传达给多个受让人，使缺陷修复过程更加系统和高效。
缺陷状态
缺陷或缺陷状态缺陷生命周期中缺陷或缺陷的当前状态称为状态。缺陷状态的目的是准确地表示缺陷或错误的当前状况或进展，以便可以更好地跟踪和理解缺陷生命周期。
从项目到项目，故障通过的状态数量各不相同。下面的寿命图描绘了所有可能的状态。
新- 当新故障最初被记录和公布时，它被称为“新”。它的状态为 NEW。
已分配- 一旦测试人员提交了问题，测试人员的领导就会接受它并将其分配给编程团队。
打开- 开发人员开始研究和修复缺陷。
固定- 开发人员可以在进行所需的代码修改并对其进行验证后将问题标记为“已修复”。
Pending retest - 一旦缺陷被修复，开发人员会向测试人员提供一个特定的代码来重新测试代码。发布的状态是“待重新测试”，因为软件测试仍在等待测试人员结束。
重新测试- 在此级别，测试人员重新测试代码以查看开发人员是否已修复缺陷并将状态更改为“重新测试”。
Verified - 测试人员在开发人员解决问题后重新测试问题。如果程序中没有发现错误，则修复问题，状态更改为“已确认”。
Reopen - 如果开发人员解决问题后问题仍然存在，测试人员会将状态更新为“重新打开”。昆虫再次经历生命周期。
已关闭- 当错误不再存在时，测试人员将其标记为“已关闭”。
重复- 如果缺陷再次重复或缺陷与相同的错误想法有关，则状态将更改为“重复”。
Rejected - 如果开发人员认为问题不真实，则缺陷被标记为“已拒绝”。
Deferred - 如果当前问题不是最优先考虑的问题并且预计在未来版本中得到解决，则它被授予“Deferred”状态。
不是错误- 如果错误对应用程序的操作没有影响，则错误的状态设置为“不是错误”。
缺陷的生命周期
该缺陷是由测试人员发现的。
该缺陷已被授予新的状态。
故障会报告给项目经理，项目经理将进行调查。
项目经理确定缺陷是否合法。
由于缺陷无效，状态设置为“已拒绝”。
因此，项目经理将其标记为拒绝。如果问题没有被拒绝，下一阶段是确定它是否在项目范围内。假设我们有另一个功能，例如同一程序的电子邮件功能，而您发现它存在缺陷。然而，当此类故障被赋予推迟或延迟状态时，它不是当前版本的一部分。
然后经理检查之前是否提到过类似的问题。如果答案是肯定的，则故障被标记为重复。
如果答案是否定的，问题就会分配给开发人员，他开始处理代码。此时故障处于进行中状态。
一旦代码被更正。缺陷的状态尚未修复。
然后代码将由测试人员重新测试。如果测试用例成功，则缺陷被关闭。如果测试用例再次失败，问题将重新打开并分配给开发人员。
考虑这样一个场景：在 Flight Reservation 的第一次发布期间发现传真订单中的错误，该版本已修复并处于关闭状态。相同的错误再次出现在第二个升级版本中。在这种情况下，关闭的故障将重新打开。
实施缺陷生命周期：指南
在开始使用缺陷生命周期之前，应遵循某些基本原则。
以下是详细信息 -
在开始处理缺陷生命周期（如上所述）之前，整个团队必须了解问题的各个阶段，这一点至关重要。
为了尽量减少未来的误解，缺陷生命周期应该被彻底记录下来。
为了获得更好的结果，请确保被赋予与缺陷生命周期相关的职责的每个人都完全了解他们的责任。
每个改变缺陷状态的人都应该充分了解该状态，并提供有关该状态的足够数据以及放置该状态的理由，以便处理该故障的每个人都可以轻松理解这种缺陷状态的原因。
为了保持跨缺陷的一致性，从而在缺陷生命周期过程中保持一致性，应谨慎使用缺陷跟踪工具。
错误、缺陷和故障之间的主要区别是什么？
错误 - 当开发人员在开发过程中发现应用程序的实际行为和预期行为之间存在差异时，他们会将其标记为错误。
缺陷 - 当测试人员在测试过程中发现应用程序的实际行为和预期行为之间存在差异时，就会发生缺陷。
失败 - 当客户或最终用户在生产阶段发现程序的实际行为和预期行为之间存在差异时，就会发生失败。
无效或重复的缺陷报告
当由于测试环境或误解等非代码因素导致故障时，应将报告作为无效缺陷关闭。
一个重复的报告被保留，而另一个作为重复关闭。经理接受某些错误的报告。
整个缺陷管理和过程归测试经理所有，缺陷管理工具跨职能团队负责处理报告。
参加者包括测试经理、开发人员、项目经理、生产经理和其他感兴趣的各方。
缺陷管理委员会应评估每个缺陷的有效性，并决定是否应该修复或推迟。考虑不修复任何问题的成本、危险和优势，以得出此结论。
如果必须纠正故障，则必须确定其优先级。
有关缺陷或错误的其他详细信息
在整个软件开发生命周期的任何时候，都可能引入故障。
越早发现和纠正缺陷，总质量成本就越便宜。
当在引入问题的同一阶段内消除问题时，质量成本就会降低。
静态测试识别缺陷而不是故障。因为不需要调试，所以费用保持在最低限度。
当动态测试出现故障时，问题的存在就暴露出来了。
编写一个体面的错误报告：一些提示！
生成可靠的错误报告的能力是测试人员工具箱中最重要的才能之一。找茬只是成功的一半；如果开发人员无法复制您发现的问题，他们将很难纠正这些问题。为确保测试人员提供他们发现的故障的完整报告，您的错误跟踪软件应包含许多基本字段。此外，测试人员应该提高他们的描述能力。