错误生命周期

在本节中，我们将了解错误的生命周期以及错误和错误报告模板的不同状态。

在这里，我们将讨论从发现，修复，重新测试和关闭阶段开始的错误的完整生命周期。

我们有一些不同的错误状态，例如new / open，assigned，fix，re-open和closed 。

一旦测试工程师发现了错误，状态将显示为“新建”，这表示刚刚发现了错误。

需要通过将状态更改为“已分配”来将此新错误报告给有关的开发人员，以便负责人员应负责处理该错误。

然后，开发人员首先检查该错误，这意味着开发人员阅读了所有导航步骤，以决定它是否是有效的错误。

基于此，如果错误有效，则开发人员开始在应用程序上重现错误，一旦成功重现错误，开发人员将分析代码并进行必要的更改，并将状态更改为固定。

完成代码更改并修复错误后，测试工程师将重新测试该错误，这意味着测试工程师将再次执行相同的操作(在错误报告中提到)，并相应地更改状态：

如果错误已正确修复，请关闭，并根据要求正常运行。

要么

重新打开，如果该漏洞仍然存在或未根据要求正常运行，则该漏洞再次将其发送回开发人员。

这个过程一直持续进行，直到修复并关闭所有错误为止。

注意1：由于以下原因，测试工程师无法向开发人员口头告知该错误：开发人员可能会忽略该错误开发人员误解了该错误忘记了该错误可能在确切的位置找不到该错误。

谁来分配错误

该错误可以分配给以下内容：

• 开发者
• 开发人员领导
• 测试线

开发人员：如果我们知道谁开发了该特定模块。

开发主管：如果我们不认识开发特定模块的开发人员。

测试负责人：当我们与开发团队没有任何互动时。

当错误已修复并关闭或对其他模块有影响时，我们将提交新的错误报告。

要么

当错误的状态为“重新打开”(未修复)并影响另一个模块时，我们必须准备新的错误报告。

注意2：每当发现错误并由开发人员修复时，我们都必须检查一轮影响区域。如果旧错误已正确修复，请将状态更改为“关闭”。如果我们在影响区域发现了一个错误，则将其报告为新错误。如果旧错误未正确修复，则将状态更改为“重新打开”。或者，如果我们发现错误影响区域，则将状态更改为“新建”或报告为新错误。

错误的另一种状态

一旦我们准备了一个错误报告并将其发送给开发人员，开发人员将接受该错误并开始进行必要的代码更改，这些更改将成为错误生命周期的积极流程。

在某些服务条件下，开发人员可能无法进行必要的代码更改，并取决于具体情况，这会成为错误流或错误生命周期的状态。

以下是错误生命周期的不同状态：

• 无效/已拒绝
• 重复
• 推迟/推迟
• 无法修复
• 不可复制
• RFE(增强功能请求)

无效/被拒绝

当测试工程师由于对需求的误解而编写了错误的错误报告时，开发人员将不接受该错误，并将其状态设置为“无效”并发回。 (有时，开发人员也会误解要求)。

开发人员不接受的任何错误都称为无效错误。

错误状态无效的原因

该错误的无效状态是由于以下原因引起的：

• 测试工程师误解了需求
• 开发人员误解了需求

让我们看一个例子，测试工程师和开发人员误解了需求，如下图所示：

重复

当不同的测试工程师多次报告同一错误时，称为重复错误。

错误状态重复的原因

以下是重复状态的原因：

• 常见功能：例如：假设我们有测试工程师P和Q正在测试软件，测试工程师P和Q将测试其功能，例如登录应用程序。在这里，测试工程师P输入有效的用户名和密码，然后单击登录按钮。 P单击登录按钮后，将打开一个空白页，这意味着它是一个错误。之后，P准备针对特定错误的错误报告，并将其发送给开发人员。然后，测试工程师Q也登录了该应用程序，并得到了相同的错误。 Q还准备了一个错误报告，并将其发送给开发人员。一旦开发人员获得了两个测试工程师的错误报告，他/她就将错误报告发回给Q，并说它是重复的。
• 依赖模块正如我们在下图中看到的那样，测试工程师想要撰写邮件，因此，首先，测试工程师需要登录，然后只有他/她才能撰写邮件。如果在登录模块中发现错误，则测试工程师无法进行进一步的处理，因为编写模块依赖于登录模块。

• 避免重复的错误如果开发人员遇到重复的错误，则他/她将转到错误存储库并搜索错误，并检查错误是否存在。如果存在相同的错误，则无需再次在报告中记录相同的错误。或者如果不存在该错误，则记录一个错误并将其存储在错误存储库中，然后发送给开发人员和测试工程师，并将其添加到[CC]中。

注意1：通常，我们不会在存储库中搜索每个bug来检查重复性。为了节省时间，我们只搜索具有共同特征和相关特征的错误。
注意2：每当我们比较两个错误报告以发现它们是否重复时，我们都应始终注意以下两点：导航步骤应相同。除了关闭状态，其他任何状态都应该存在，我们不应该记录错误，否则它将成为重复的错误，如下图所示：

不可复制

开发人员接受该错误，但由于某些原因而无法复制。

经过测试工程师在错误报告中给出的导航步骤后，这些错误是开发人员无法找到的错误。

错误状态无法重现的原因

错误状态不可重现的原因如下：

• 错误的错误报告测试工程师没有在报告中提及完整的导航步骤。
• 环境不匹配环境不匹配可以用两种方式描述：
  • 服务器不匹配
  • 平台不匹配

服务器不匹配：测试工程师正在使用其他服务器(测试服务器)，而开发人员正在使用其他服务器(开发服务器)来重现该错误，如下图所示：

平台不匹配：测试工程师使用不同的平台(窗口7和Google Chrome浏览器)，而开发人员也使用不同的平台(窗口XP和Internet Explorer )。

• 数据不匹配测试工程师在测试与开发人员使用不同值时会使用不同的值。例如：给管理员和用户的要求。

即，两个都对同一登录模块使用不同的值。

• 内部版本不匹配测试工程师将在一个内部版本中找到错误，而开发人员正在另一内部版本中复制相同的错误。该错误可能会在修复另一个错误时自动修复。
• 错误的Bug有时会发现Bug，有时也不会发现。解决不一致的错误的方法：一旦发现错误，请首先截取屏幕截图，然后开发人员将重新确认该错误并进行修复(如果存在)。

无法修复

当开发人员接受该错误并且也能够复制但由于某些限制而无法进行必要的代码更改时。

无法修复错误状态的原因

以下是无法修复错误的约束或原因：

• 没有技术支持：我们使用的编程语言本身没有解决问题的能力。
• 错误是代码(框架)的核心：如果错误很小(不重要，不会影响应用程序)，开发负责人表示可以在下一版本中对其进行修复。或者，如果该漏洞很严重(经常使用且对业务很重要)，并且开发负责人无法拒绝该漏洞。
• 修复错误的成本远远超过保留缺陷的成本。

注意：如果有任何较小的错误，但是开发人员无法修复，则表示开发人员可以修复，但是该错误影响了现有技术，因为它存在于代码的核心。每个无法修复的错误都是次要错误。

推迟/推迟

延迟/推迟是由于时间限制而将错误推迟到未来版本的状态。

由于时间限制，错误的延迟状态在初始版本中未得到固定。

正如我们在下图中看到的：

Bug ID-B001错误是在初始版本中发现的，但不会在同一版本中得到修复，它将被推迟，并在下一个版本中得到修复。

Bug ID- B0024，B0025和B0026是在构建的最后阶段发现的那些bug，由于这些bug是次要的bug，因此将予以修复。

注意：不能推迟所有次要的bug，但是所有推迟的bug都是次要的bug。只要没有将来的发行版，则仅在维护阶段修复已推迟的错误。

RFE(增强功能请求)

这些是测试工程师以错误报告的形式提出的有关增强应用程序的建议。 RFE代表“增强请求” 。

正如我们在下面的示例图像中看到的那样，测试工程师认为应用程序或软件的外观和感觉不佳，因为测试工程师正在以最终用户身份测试应用程序，他/她将状态更改为RFE 。

如果客户说是，则状态应该为Fix 。

要么

如果客户说没有，那么状态应该是关闭。

错误报告模板(excel)

错误报告模板如下：

让我们看一个错误报告的例子：

在这里，我们描述了错误报告的一些重要属性。

错误ID：这是错误的唯一编号。

测试用例名称：发现错误后，我们会向相关的开发人员发送错误报告，而不是测试用例。它用作测试工程师的参考。

严重性：这是错误对应用程序的影响。它可以是阻止程序，严重，主要和次要阻止程序。

优先级：在此，我们必须决定必须首先修复哪个错误。可能是P1 / P2 / P3 / P4，紧急，高，中和低。

状态：错误的不同状态，可以分配，无效，重复，推迟等等。

记者：在这里，我们将提及发现该漏洞的人的名字。可能是测试工程师，有时可能是开发人员，业务分析师，客户等。

日期：提供发现错误的日期。

发布/构建版本：它提供了发生错误的发布编号，以及应用程序的构建版本。

平台：提及平台详细信息，我们可以在其中找到错误。

说明：在此，我们将说明特定错误的导航步骤，预期结果和实际结果。

附件：附上我们捕获的bug的屏幕快照，因为它有助于开发人员查看bug。

手动错误报告的缺点

以下是手动错误报告的缺点：

• 耗时在错误报告中搜索每个错误时，这将花费大量时间。
• 人为错误的可能性错误可能会重复出现，错误报告中会提及错误的数据，并且会错过要在错误报告中添加的内容。
• 没有安全性任何人都可以更改或删除它。
• 繁琐的过程
• 没有集中式存储库