Bug生命周期
Bug生命周期
在本节中，我们将了解错误生命周期以及错误和错误报告模板的不同状态。
在这里，我们将讨论从发现、修复、重新测试和关闭阶段开始的错误的完整生命周期。
我们有一些不同状态的错误，例如
<强>
新建/打开、分配、修复、重新打开和关闭。
测试工程师一发现bug，状态就被赋值为New，表示刚刚发现了一个bug。
这个新的bug需要上报给相关的Developer将状态更改为已分配，以便负责人处理错误。
然后开发人员首先检查错误，这意味着开发人员阅读了所有导航步骤来决定它是否是一个有效的错误。
在此基础上，如果错误是有效的，则开发人员开始重现应用程序中的错误，一旦错误被成功重现，开发人员将分析代码并进行必要的更改，并将状态更改为已修复。
一旦代码更改完成，bug 修复，测试工程师重新测试 bug，这意味着测试工程师再次执行相同的操作，这在 bug 报告中提到，并相应地更改状态:
关闭，如果错误修复正确，并且功能按照要求工作。
OR
重新打开，如果错误仍然存在或不能按要求正常工作，则错误再次将其发送回开发人员。
此过程将持续进行，直到所有错误已修复并关闭。
注意: 注1: 由于以下原因，测试工程师不能口头告诉开发人员该错误: 开发人员可能会忽略该错误 开发人员误解了该错误 忘记该错误 该错误可能不是在确切位置找到
分配给谁的bug
该bug可以分配给以下:
开发人员
开发者主管
测试主管
开发人员: 如果我们知道谁开发了该特定模块。
开发人员负责人: 如果我们不知道开发特定模块的开发人员。
测试负责人: 当我们与开发团队没有任何互动时。
当错误是
<强>
已修复并关闭，或者如果它对其他模块有任何影响，那么我们将提交新的错误报告。
OR
当bug的状态是重新打开(未修复)并影响另一个模块时，那么我们必须准备新的bug报告。
注意: 注意2: 每当我们发现一个bug并且开发者修复它时，我们必须检查一轮影响区域。如果旧错误已正确修复，请将状态更改为关闭。并且如果我们在影响区域发现了一个bug，那么就报告为一个新的bug。如果旧错误未正确修复，则将状态更改为重新打开。或者，如果我们发现错误影响区域，则将状态更改为"新建"或报告为新错误。
该错误的另一种状态
一旦我们准备好错误报告并将其发送给开发人员，开发人员将接受该错误并开始执行必要的代码更改成为错误生命周期的积极流程。
可能存在一些情况，开发人员可能不进行必要的代码更改并视情况而定，这成为错误生命周期的负面流或状态。
以下是错误生命周期的不同状态:
无效/被拒绝
重复
推迟/推迟
无法修复
不可重复
RFE(增强请求)
无效/被拒绝
当测试工程师因为误解需求而写出错误的 Bug 报告时，开发人员将不会接受该 Bug，并给出状态为 无效 并将其发回。(有时开发人员也可能会误解要求)。
任何未被开发人员接受的错误都称为无效错误。
错误状态无效的原因
出现这个bug的无效状态的原因如下:
测试工程师误解了要求
开发人员误解了要求
让我们看一个测试工程师和开发人员误解需求的例子，如下图所示:
重复
当同一个错误被不同的测试工程师多次报告时，被称为重复 错误。
重复状态的原因bug
以下是重复状态的原因:
常见功能:
例如: 假设我们有测试工程师 P 和 Q 正在测试软件，测试工程师 P 和 Q 将测试他们的功能如登录应用程序。
这里，测试工程师P输入有效的用户名和密码，然后点击登录按钮。
一旦P点击登录按钮，它会打开一个空白页面，这意味着它是一个错误。
之后，P 为特定的错误准备了一个错误报告并将其发送给开发人员。
然后测试工程师 Q 也登录了应用程序并得到了相同的错误。 Q 还准备了一份错误报告并将其发送给开发人员。
一旦开发人员收到了两个测试工程师的错误报告，他/她就会将错误报告发回给 Q 并说它是重复的。
依赖模块
如下图所示，测试工程师想要撰写邮件，所以首先，测试工程师需要login，那么只有他/她可以撰写邮件。
如果在登录模块中发现错误，测试工程师无法做进一步的处理，因为撰写模块依赖于登录模块。
避免重复的bug
如果开发者得到重复的bug，那么他/她会去bug存储库搜索bug并检查bug是否存在.
如果存在相同的错误，则无需再次在报告中记录相同的错误。
或
如果错误不存在，则记录错误并存储在错误存储库中，然后发送给开发人员和测试工程师，将它们添加到 [抄送]。
注意: 注1: 一般情况下，我们不会搜索存储库中的每个错误来检查重复性。为了节省时间，我们只搜索具有共同特征和依赖特征的错误。
注意: 注2: 每当我们比较两个错误报告以找出它是否重复时，我们应该总是看两件事，如下所示: 导航步骤应该是相同的。除了关闭状态，任何其他状态都应该存在，我们不应该记录错误，否则它将成为重复的错误，如下图所示:
不可重现
开发者接受该错误，但由于某些原因无法重现。
这些是开发人员在完成测试工程师在错误报告中给出的导航步骤后无法找到的错误。
bug状态不可复现原因
bug状态不可复现原因如下:
不完整的错误报告
测试工程师没有在报告中提到完整的导航步骤。
环境不匹配
环境不匹配可以用两种方式描述: 服务器不匹配 平台不匹配
服务器不匹配: 测试工程师使用不同的服务器(测试服务器)，开发人员使用不同的服务器(开发服务器) 用于重现错误，如下图所示:
平台不匹配: 测试工程师使用不同的平台(window 7 和 Google Chrome 浏览器)，开发者使用不同的平台(window XP 和 internet资源管理器)。
数据不匹配
te 使用的不同值测试工程师和开发人员使用不同的值。
例如:
要求是针对管理员和用户的。
| 测试工程师(用户)使用以下要求: |
开发者(管理员)使用以下要求: |
用户名→ abc
密码→ 123 |
用户名 → aaa
密码 → 111 |
即，对于同一个登录模块，两者都使用不同的值。
构建不匹配
测试工程师会在一个构建中发现错误，而开发人员会在另一个构建中重现相同的错误。该错误可能会在修复另一个错误时自动修复。
不一致的bug
有的时候发现Bug，有的时候不会发生。
不一致bug的解决方法:
As一旦我们发现错误，首先截取屏幕截图，然后开发者将重新确认错误并修复它(如果存在)。
无法修复
当开发者接受该错误并且也能够重现，但由于某些限制而无法进行必要的代码更改时。
无法修复bug状态的原因
以下是无法修复错误的限制或原因:
无技术支持: 我们使用的编程语言本身没有解决问题的能力。
Bug 是代码(框架)的核心: 如果 Bug 次要(不重要，不影响应用程序)，开发负责人会说可以在下一个版本中修复。
或者如果该错误严重(经常使用并且对业务很重要)并且开发主管无法拒绝该错误。
修复错误的成本不仅仅是保留它。
注意: 如果有任何bug是次要的，但开发者无法修复，这意味着开发者可以修复，但该错误正在影响现有技术，因为它存在于代码的核心。每个无法修复的错误都是次要错误。
推迟/推迟
推迟/推迟是由于时间限制将错误推迟到未来版本的状态。
由于时间原因，初始构建中未修复bug的延迟状态约束。
如下图所示:
Bug ID-B001 错误在初始构建时被发现，但不会在相同的构建，它将推迟，并在下一个版本中修复。
Bug ID-B0024、B0025 和 B0026 是那些错误，在构建的最后阶段发现，它们将被修复，因为这些错误是小错误。
注意: 所有小错误都不能被延迟，但所有延迟的错误都是小错误。每当没有未来版本时，延迟错误将仅在维护阶段修复。
RFE(Request for Enhancement)
这些是测试工程师以bug的形式对应用程序的增强给出的建议报告。 RFE 代表增强请求。
正如我们在下面的示例图片中看到的，测试工程师认为应用程序或软件的外观和感觉不好，因为测试工程师正在以最终用户的身份测试应用程序，他/她会将状态更改为 RFE。
如果客户说是，那么状态应该是修复。
或者
如果客户说否，则状态应为关闭。
Bug Report Template(excel)
Bug 报告模板如下:
让我们看一个错误报告的例子:
| 错误 ID |
Boo12 |
| 模块 |
登录 |
| 要求 |
1 |
| 测试用例名称 |
Gmail_login_compose _mail |
| 记者 |
测试工程师姓名 |
| 发布 |
增量 |
| 版本 |
3.0 |
| 状态 |
已分配 |
| 日期 |
23-02-2020 |
| 分配给 |
YY 开发者 |
| 抄送 |
测试主管，开发人员 |
| 严重程度 |
关键 |
| 优先权 |
P2 |
| 平台 |
Window XP，internet explorer7.0 |
| 版本号 |
B02 |
| 测试数据 |
用户名=xyz，密码=123 |
| 简要说明 |
|
| 导航步骤 |
登录 Gmail 应用程序 应显示撰写邮件和确认消息 |
| 观察邮件 |
在收件箱中找不到 |
| 预期结果邮件 |
也应该在收件箱中。 |
| 实际结果 |
在收件箱中找不到邮件 |
| 附加评论 |
------ |
在这里，我们描述了错误报告的一些重要属性。
错误 ID: 它是为错误提供的唯一编号。
测试用例名称: 当我们发现错误时，我们会向相关开发人员发送错误报告，而不是测试用例。它用作测试工程师的参考。
严重性: 它是错误对应用程序的影响。它可以是阻塞程序、关键程序、主要程序和次要程序。
优先级: 在此，我们必须决定必须首先修复哪个错误。可能是 P1/P2/P3/P4、紧急、高、中、低。
状态: 可以分配、无效、重复的错误的不同状态、延期等等。
记者: 在此，我们将提及发现错误的人的姓名。可能是测试工程师，有时可能是开发人员、业务分析师、客户等。
日期: 它提供了发现错误的日期。 发布/构建版本: 它提供了发生错误的发布编号，以及应用程序的构建版本。
平台: 提及平台详细信息，我们准确地找到错误的位置。
说明: 在此，我们将解释特定错误的导航步骤、预期和实际结果。
附件: 附上bug的截图，我们抓到了，因为它可以帮助开发者看到bug。
缺点手动错误报告的缺点
以下是手动错误报告的缺点:
耗时
在搜索错误报告中的每个错误时，这将是一个耗时的过程。
人为错误的可能性
一个错误可能会重复出现，错误报告中提到了错误的数据，并且遗漏了错误报告中要添加的内容。
没有安全性
任何人都可以更改或删除它。
繁琐的过程
没有集中存储库
