1. Bug生命周期

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

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

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

一旦测试工程师发现bug，状态就会被指定为“新建”，这表示刚刚发现了bug。

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

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

基于此，如果bug有效，开发人员开始在应用程序上重现bug，一旦bug成功重现，开发人员将分析代码并进行必要的更改，并将状态更改为“已修复”。

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

如果bug修复正确，请关闭，并根据要求在功能上工作。

或

重新打开，如果bug仍然存在或无法按照要求正常工作，则bug会再次将其发送回开发人员。

此过程将持续进行，直到修复并关闭所有bug。

2. 将bug分配给谁

该bug可以分配给以下人员：

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

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

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

测试线索：当我们与开发团队没有任何互动时。

当bug被修复并关闭时，或者如果它对其他模块有任何影响，那么我们会进行新的bug报告。

或

当bug的状态为重新打开（未修复）并影响另一个模块时，我们必须准备新的bug报告。

3. Bug的另一个状态

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

可能存在服务条件，开发人员可能不会进行必要的代码更改，而是根据情况，这将成为bug生命周期的负流或状态。

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

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

3.1 无效/已拒绝

当测试工程师因为误解需求而编写了不正确的bug报告时，开发人员将不接受该bug，并将状态指定为无效并将其发回。（有时开发人员也可能误解要求）。

Bug无效状态的原因

由于以下原因，发生了bug的无效状态：

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

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

3.2 重复

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

Bug重复状态的原因

以下是重复状态的原因：

• 共同特性：例如：

  假设我们有测试工程师P和Q正在测试软件，测试工程师P和Q将测试他们的功能，如登录应用程序。

  在这里，测试工程师P输入有效的用户名和密码，然后单击登录按钮。

  一旦P点击登录按钮，它就会打开一个空白页面，这意味着它是一个bug。

  之后，P 为特定bug 准备bug报告并将其发送给开发人员。

  然后测试工程师Q也登录了应用程序并得到了相同的错误。Q 还准备了一份bug报告并将其发送给开发人员。

  一旦开发人员都得到了两个测试工程师的bug报告，他/她就会将bug报告发回给Q并说它是重复的。

• 依赖模块

  如下图所示，测试工程师想要撰写邮件，因此首先，测试工程师需要登录，然后只有他/她才能撰写邮件。

  如果在登录模块中发现bug，测试工程师将无法执行进一步处理，因为组合模块依赖于登录模块。

  

• 避免重复bug 如果开发人员收到重复的bug，那么他/她将转到bug存储库并搜索bug，并检查bug

  是否存在。 如果存在相同的bug，则无需在报告中再次记录相同的bug。

或者

如果bug不存在，则记录bug并存储在bug存储库中，并将其发送给开发人员和测试工程师，将其添加到 [CC] 中。

3.3 不可重现

开发人员接受该bug，但由于某些原因无法重现。

Bug不可重现状态的原因

该bug状态不可重现的原因如下：

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

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

平台不匹配：测试工程师使用不同的平台（window7和谷歌浏览器），开发人员也使用不同的平台（windowXP和IE浏览器）。

• 数据不匹配

  测试工程师使用的不同值，而测试和开发人员使用不同的值。

  例如：

  对管理员和用户提出了要求。

  

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

• 构建不匹配

  测试工程师将在一个构建中发现该 bug，而开发人员将在另一个构建中重现相同的 bug。该错误可能会在修复另一个bug时自动修复。

• 不一致的bug

  该bug在某个时候被发现，有时它不会发生。

  不一致bug的解决方案：

  一旦我们发现bug，首先截取屏幕截图，然后开发人员将重新确认bug并修复它（如果存在）。

3.4 无法修复

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

无法修复bug状态的原因

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

• 无技术支持：我们使用的编程语言本身没有解决问题的能力。
• 该bug位于代码（框架）的核心：如果bug很小（不重要且不影响应用程序），开发负责人表示可以在下一个版本中修复。

  或者，如果 bug 很严重（经常使用且对业务很重要），并且开发主管不能拒绝该 bug。

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

3.5 延期/延期

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

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

如下图所示：

Bug ID-B001 bug在初始版本中发现，但不会在同一版本中修复，它将推迟，并在下一个版本中修复。

Bug ID-B0024、B0025 和 B0026 是在构建的最后阶段发现的bug，它们将被修复，因为这些bug是次要bug。

3.6 RFE（请求增强）

这些是测试工程师以bug报告的形式对应用程序增强给出的建议。RFE 代表 请求增强。

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

如果客户说“是”，则状态应为“修复”。

或

如果客户说“否”，则状态应为“关闭”。

4. Bug报告模板 （excel）

bug报告模板如下：

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

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

bugID：它是分配给bug的唯一编号。

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

严厉程度：它是bug对应用程序的影响。它可以是阻塞、关键、主要和次要。

优先权：在这种情况下，我们必须决定必须首先修复哪个bug。它可以是 P1/P2/P3/P4、紧急、高、中和低。

地位：可以分配、无效、重复、延迟等的 bug 的不同状态。

记者：在此，我们将提及发现该bug的人的姓名。它可能是测试工程师，有时可能是开发人员、业务分析师、客户等。

日期：它提供发现bug的日期。

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

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

描述：在这里，我们将解释特定bug的导航步骤，预期和实际结果。

附件：附上我们捕获的bug屏幕截图，因为它可以帮助开发人员查看bug。

5. 手动bug报告的缺点

以下是手动bug报告的缺点：

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