错误生命周期

在本节中，我们将学习Bug的生命周期、Bug的各种状态以及Bug报告模板。

在这里，我们将讨论Bug从被发现、修复、重新测试到关闭的完整生命周期。

我们有几种不同的Bug状态，如新建/打开、已分配、已修复、重新打开和已关闭。

测试工程师一旦发现Bug，状态即被设为“新建”，这表明Bug刚刚被发现。

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

然后，开发人员首先会审阅Bug，这意味着开发人员会阅读所有的导航步骤，以确定它是否是一个有效的Bug。

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

代码更改完成且Bug已修复后，测试工程师会重新测试该Bug，这意味着测试工程师会再次执行Bug报告中提到的相同操作，并相应地更改状态。

已关闭，如果Bug修复正确，并且功能符合要求。

或

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

这个过程将持续进行，直到所有Bug都被修复并关闭。

注1
测试工程师不能口头向开发人员报告Bug，原因如下：

• 开发人员可能会忽略该Bug
• 开发人员误解了Bug
• 忘记了Bug
• Bug可能没有在确切的位置找到

Bug应分配给谁

Bug可以分配给以下人员：

• 开发者
• 开发负责人
• 测试负责人

开发人员：如果我们知道是哪个开发人员开发了特定模块。

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

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

当Bug被修复并关闭或对其他模块有任何影响时，我们会创建一个新的Bug报告。

或

当Bug的状态为重新打开（未修复）并影响到其他模块时，我们需要准备新的Bug报告。

注意事项2

• 每当我们发现一个Bug并由开发人员修复后，我们都需要检查一个影响范围。
• 如果旧Bug已正确修复，则将状态更改为“已关闭”。
• 如果在影响范围内发现Bug，则将其报告为新Bug。
• 如果旧Bug未正确修复，则将状态更改为“重新打开”。
• 或者，如果在影响范围内发现Bug，则将状态更改为“新建”或报告为新Bug。

Bug的其他状态

一旦我们准备好Bug报告并将其发送给开发人员，开发人员就会接受该Bug并开始进行必要的代码更改，这构成了Bug生命周期的正向流程。

在某些情况下，开发人员可能不会进行必要的代码更改，而是取决于情况，这就构成了Bug生命周期的负向流程或状态。

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

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

无效/已拒绝

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

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

Bug状态为无效的原因

Bug状态为无效是由于以下原因造成的：

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

让我们看一个测试工程师和开发人员误解需求的例子，正如我们在下图中所看到的。

重复

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

Bug状态为重复的原因

以下是重复状态的原因：

• 通用功能
  例如：假设我们有测试工程师P和Q正在测试软件，测试工程师P和Q将测试他们的功能，如登录应用程序。
  在这里，测试工程师P输入有效的用户名和密码，然后单击登录按钮。
  一旦P单击登录按钮，它会打开一个空白页面，这意味着这是一个Bug。
  之后，P准备一份针对特定Bug的报告并将其发送给开发人员。
  然后，测试工程师Q也登录应用程序并遇到了相同的Bug。Q也准备一份Bug报告并将其发送给开发人员。
  一旦开发人员收到两位测试工程师的Bug报告，他/她会将Bug报告退还给Q，并告知是重复的。
• 依赖模块
  正如我们在下图中所看到的，测试工程师想要撰写邮件，所以首先，测试工程师需要登录，然后才能撰写邮件。
  如果Bug出现在登录模块中，测试工程师将无法进行后续操作，因为撰写模块依赖于登录模块。

• 避免重复Bug
  如果开发人员发现重复Bug，那么他/她会去Bug存储库搜索该Bug，并检查该Bug是否存在。
  如果Bug存在，则无需在报告中再次记录相同的Bug。
  或
  如果Bug不存在，则记录一个Bug并存储在Bug存储库中，然后发送给开发人员和测试工程师，并将他们添加到[抄送]列表中。

注1

• 通常，我们不会搜索存储库中的每个Bug来检查重复性。
• 为了节省时间，我们只搜索具有通用功能和依赖功能的Bug。

注意事项2
每当我们比较两个Bug报告以确定它们是否重复时，我们应该始终关注两件事，如下所示：

• 导航步骤应相同。
• 除了“已关闭”状态外，任何其他状态都应存在。我们不应该记录Bug，否则它将成为重复Bug，正如我们在下图中所看到的。

无法重现

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

这些是开发人员在按照测试工程师在Bug报告中给出的导航步骤进行操作后，仍然找不到的Bug。

Bug状态为无法重现的原因

Bug状态为无法重现的原因如下：

• 不完整的Bug报告
  测试工程师未在报告中提及完整的导航步骤。
• 环境不匹配
  环境不匹配可以分为两种方式：
  • 服务器不匹配
  • 平台不匹配

服务器不匹配：测试工程师使用的是不同的服务器（测试服务器），而开发人员使用的是不同的服务器（开发服务器）来重现Bug，正如我们在下图中所看到的。

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

• 数据不匹配
  测试工程师在测试时使用不同的值，而开发人员使用不同的值。
  例如
  提供了管理员和用户的需求。

也就是说，两者都对同一个登录模块使用了不同的值。

• 版本不匹配
  测试工程师在一个版本中发现Bug，而开发人员在一个不同的版本中重现同一个Bug。Bug可能在修复另一个Bug时被自动修复。
• 不一致的Bug
  Bug有时会被发现，有时则不会发生。
  不一致Bug的解决方案
  一旦我们发现Bug，首先要截屏，然后开发人员会重新确认该Bug，如果存在则进行修复。

无法修复

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

Bug状态为无法修复的原因

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

• 无技术支持：我们使用的编程语言本身没有能力解决这个问题。
• Bug在代码核心（框架）中：如果Bug是次要的（不重要且不影响应用程序），开发负责人会说这可以在下一个版本中修复。
  或者，如果Bug是关键的（经常使用且对业务重要），开发负责人则不能拒绝该Bug。
• 修复Bug的成本高于保留它。

注意

• 如果任何Bug是次要的，但开发人员无法修复，这意味着开发人员可以修复，但Bug影响了现有技术，因为它存在于代码核心中。
• 每个无法修复的Bug都是次要Bug。

推迟/延期

推迟/延期是一种状态，由于时间限制，Bug被推迟到未来的版本。

由于时间限制，Bug的推迟状态未能在初始版本中修复。

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

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

而Bug ID- B0024, B0025, 和 B0026是在版本后期发现的Bug，它们会被修复，因为这些是次要Bug。

注意

• 并非所有次要Bug都可以推迟，但所有推迟的Bug都是次要Bug。
• 当没有未来版本时，推迟的Bug将在维护阶段进行修复。

RFE（增强请求）

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

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

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

或

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

Bug报告模板（Excel）

Bug报告模板如下：

让我们看一个Bug报告的例子

在此，我们描述了Bug报告的一些重要属性。

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

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

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

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

状态：Bug的不同状态，如已分配、无效、重复、推迟等。

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

日期：提供发现Bug的日期。

发布/Build版本：提供Bug发生的发布号以及应用程序的Build版本。

平台：提及平台详细信息，我们实际发现Bug的地方。

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

附件：附上我们捕获的Bug截图，这有助于开发人员看到Bug。

手动Bug报告的缺点

手动Bug报告的缺点如下：

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