错误生命周期

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

在这里，我们将讨论一个 bug 从发现、修复、重新测试和关闭阶段的完整生命周期。

我们有一些不同的错误状态，例如新的/打开的、分配的、修复的、重新打开的和关闭的。

测试工程师一发现错误，状态就会显示为 New，这表示刚刚发现了错误。

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

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

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

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

Close，如果错误修复正确，并根据要求正常工作。

或者

重新打开，如果错误仍然存在或未按要求正常工作，则错误再次将其发送回开发人员。

这个过程会持续进行，直到所有错误都被修复和关闭。

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

将错误分配给谁

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

• 开发商
• 开发者主导
• 测试线

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

开发人员负责人：如果我们不知道开发特定模块的开发人员。

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

当错误被修复并关闭或者它对另一个模块有任何影响时，我们就会去寻找一个新的错误报告。

或者

当 bug 的状态是Re-open（未修复）并影响另一个模块时，那么我们必须准备新的 bug 报告。

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

错误的另一种状态

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

可能存在一些情况，开发人员可能不会进行必要的代码更改并视情况而定，这会成为错误生命周期的负面流或状态。

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

• 无效/被拒绝
• 复制
• 推迟/推迟
• 无法修复
• 不可重现
• RFE（增强请求）

无效/被拒绝

当测试工程师因为误解需求而写出错误的Bug Report时，开发者将不会接受该Bug，并给出Invalid状态并发回。（有时开发人员也会误解需求）。

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

错误状态无效的原因

该bug的无效状态发生的原因如下：

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

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

复制

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

错误状态重复的原因

以下是重复状态的原因：

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

• 避免重复的bug 如果开发者得到重复的bug，那么他/她会去bug 存储库搜索bug 并检查bug 是否存在。 如果存在相同的错误，则无需再次在报告中记录相同的错误。 或者 如果错误不存在，则记录错误并存储在错误存储库中，并发送给开发人员和测试工程师在[CC]中添加它们。

注1：通常，我们不会搜索存储库中的每个错误来检查重复性。为了节省时间，我们只搜索具有共同特征和依赖特征的错误。

Note2： 每当我们比较两个错误报告以找出它是否重复时，我们应该始终查看两件事，如下所示：导航步骤应该相同。除了关闭状态，任何其他状态都应该存在，我们不应该记录错误，否则它将成为重复的错误，如下图所示：

不可重现

开发者接受该错误，但由于某些原因无法重现。

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

错误状态不可重现的原因

导致bug状态不可复现的原因如下：

• 不完整的错误报告 测试工程师在报告中没有提到完整的导航步骤。

• 环境不匹配

  环境不匹配可以用两种方式描述：

  • 服务器不匹配
  • 平台不匹配

服务器不匹配：测试工程师使用不同的服务器（测试服务器），开发人员使用不同的服务器（开发服务器）来重现错误，如下图所示：

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

• 数据不匹配 测试工程师使用不同的值，而测试和开发人员使用不同的值。 例如： 对管理员和用户给出了要求。

测试工程师（用户）使用以下要求：	开发人员（管理员）使用以下要求：
用户名 → abc 密码 → 123	用户名 → aaa 密码 → 111

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

• 构建不匹配 测试工程师会在一个构建中发现错误，而开发人员正在另一个构建中重现相同的错误。该错误可能会在修复另一个错误时自动修复。
• 不一致的错误 Bug 有时会被发现，有时不会发生。 不一致bug的解决方法： 一旦发现bug，首先截图，如果存在，开发者会重新确认bug并修复。

无法修复

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

无法修复错误状态的原因

以下是无法修复错误的限制或原因：

• 没有技术支持：

  我们使用的编程语言本身没有解决问题的能力。

• Bug 是代码的核心（框架）：如果 Bug很小（不重要，不影响应用程序），开发负责人说它可以在下一个版本中修复。 或者如果错误很关键（经常使用并且对业务很重要）并且开发负责人不能拒绝错误。

• 修复错误的成本不仅仅是保留它。

笔记：如果有任何 bug 很小，但开发人员无法修复它，这意味着开发人员可以修复，但该错误正在影响现有技术，因为它存在于代码的核心中。每个无法修复的错误都是次要错误。

延期/延期

deferred/postpone 是一种状态，在这种状态下，由于时间限制，错误被推迟到未来的版本。

由于时间限制，初始构建中未修复错误的延迟状态。

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

该错误ID-B001的错误是在建设初期发现，但它不会被固定在同一个构建，它会推迟，并固定在下一版本中。

而Bug ID-B0024、B0025和B0026就是那些在构建的最后阶段发现的bug，它们会被修复，因为这些bug是小bug。

笔记：不能推迟所有小错误，但所有推迟的错误都是小错误。每当没有未来版本时，延迟错误将仅在维护阶段修复。

RFE（增强请求）

这些是测试工程师以错误报告的形式为增强应用程序而给出的建议。RFE 代表Request for Enhancement。

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

如果客户说Yes，那么状态应该是Fix。

或者

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

错误报告模板 (excel)

错误报告模板如下：

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

Bug ID	Boo12
Module	Login
Requirement	1
Test case name	Gmail_login_compose _mail
Reporter	Test engineer name
Release	delta
Version	3.0
Status	assigned
Date	23-02-2020
Assign to	YY developer
CC	Test lead, developer
Severity	critical
Priority	P2
Platform	Window XP, internet explorer7.0
Build no.	B02
Test data	Username=xyz, password= 123
Brief description
Navigation steps	Login Gmail applicationCompose mail and confirmation message should be displayed
observation Mail	not found in inbox
Expected result Mail	should also be in the inbox.
Actual result	Mail not found in inbox
Additionalcomments	------

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

Bug ID：它是给Bug的唯一编号。

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

严重性：它是错误对应用程序的影响。它可以是阻滞剂、关键、主要和次要。

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

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

记者：在此，我们会提到发现漏洞的人的名字。它可能是测试工程师，有时可能是开发人员、业务分析师、客户等。

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

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

平台：提及平台详细信息，我们确切地找到了错误。

描述：在此，我们将解释特定错误的导航步骤、预期和实际结果。

附件：附上bug的截图，我们截图是为了帮助开发者看到bug。

手动错误报告的缺点

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

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