了解 Bug

大家好，欢迎来到IT知识分享网。

一、Bug 基本信息

缺陷（Bug）就是存在于产品（文档、数据、程序等）之中的，那些我们不希望或者不能够接受的偏差。Bug 的结果是产品运行于某一特定条件时出现故障、从而产生一种不希望或者不能够接受的行为结果。

缺陷的存在会导致产品在某种程度上不能满足用户需求。

1.1 Bug 的生命周期

Bug 的生命周期，也称为 Bug 的处理管理流程，是从 Bug 被发现到被关闭的整个过程。这个过程主要包括以下阶段：

1. New（新的）：Bug 首次被发现并被记录，此时的状态是新的。
2. Assigned（已指派）：经过确认，Bug 被指派给特定的开发人员进行处理。
3. Open（打开的）：开发人员开始处理这个 Bug，此时的状态是打开的。
4. Fixed（已修复）：开发人员完成 Bug 的修复工作，标记 Bug 为已修复，等待测试人员进行验证。
5. Pending Reset（待再测试）：测试人员开始对已修复的 Bug 进行验证，确认其是否真正被修复。
6. Reset（再测试）：测试人员完成验证，如果 Bug 仍然存在，Bug 状态会重新变为待验证状态，进行再次修复和验证。
7. Closed（已关闭的）：如果经过验证，Bug 确实已被修复，那么 Bug 的状态会被设置为已关闭，表示这个 Bug 的生命周期已经结束。
8. Reopen（再次打开的）：如果 Bug 在验证过程中被发现仍然存在，那么 Bug 的状态会再次被打开，开发人员需要重新进行修复。

此外，还有一些其他的状态，如Rejected（被拒绝的），表示开发人员认为这不是一个 Bug 而拒绝修改；Delay（延迟），表示暂时不需要或者不能修改这个 Bug ，将其延后处理；以及Later（延期修改），表示这个 Bug 会在下一个版本中进行修复。

以上就是Bug的生命周期的主要阶段和状态。通过管理这些状态，可以有效地跟踪 Bug 的处理进度，确保问题得到及时解决。

1.2 Bug 级别划分

Bug的级别通常可以划分为高、中、低以及建议性四级，具体描述如下：

1. 高（High）：
   • 描述：高级别的 Bug 通常会对系统的核心功能或主要特性产生严重影响，可能导致系统无法正常运行或用户无法完成关键任务。
   • 示例：系统崩溃、数据丢失、主要功能完全丧失、严重资源不足导致应用模块无法启动或异常退出等。
   • 影响：这些Bug会严重影响用户体验和系统稳定性，需要立即修复。
2. 中（Medium）：
   • 描述：中级别的 Bug 通常会对系统的某些功能或性能产生一定影响，但不会完全阻止用户完成任务。
   • 示例：次要功能丧失、功能异常、数据错误、操作界面错误、提示信息不准确等。
   • 影响：这些 Bug 可能会影响用户体验和满意度，需要在合适的时间进行修复。
3. 低（Low）：
   • 描述：低级别的 Bug 通常是一些小的缺陷或问题，如界面上的拼写错误、美观度问题等，不会影响用户的主要任务。
   • 示例：用户界面不太友好、对齐方式不一致、产品说明不明确等。
   • 影响：这些 Bug 可能对用户体验产生一定影响，但通常不会造成太大的麻烦，可以在后续的版本中进行修复。
4. 建议（Suggestion）：
   • 描述：建议性的 Bug 通常是从用户角度提出的建议或意见，旨在改进产品或提高用户体验。
   • 示例：用户建议增加某个功能、改进某个操作流程等。
   • 影响：这些建议可能有助于产品的持续改进和优化，提高用户满意度。

通过合理的 Bug 级别划分和描述，开发团队和测试团队可以更好地理解和处理 Bug，制定更合理的修复计划，确保系统的稳定性和可用性。同时，这也有助于评估软件的质量和用户体验，为产品的持续改进和优化提供重要依据。

1.3 Bug 中的角色职责

提交人 

• Bug 提交人可以是测试人员、开发人员、评委、会议记录员
• 职责：提交 Bug 申请，对 Bug 进行详细、清楚的描述

审核人

• Bug 审核人一般是提交人的直接主管或导师
• 职责：审核提交人提交的 Bug 信息，确保 Bug 被正确提交及描述

解决人

• 职责：准确、及时的修复 Bug ；在 Bug 修复过程中，要将 Bug 的状态、修改思路等信息添加到缺陷单中

验证人

• 职责：根据缺陷单记录的内容对 Bug 进行测试、验证；记录验证的手段、验证通过的轮次、版本等信息

1.4 Bug 的执行准则

• 每发现一个 Bug 就必须将其提交至缺陷管理系统（不管是硬件测试、结构测试、稳定性测试、耐久性测试、系统测试或者在项目结束后发现的 Bug 都需要提交哈），每条 Bug 只描述一个问题
• 要记得记录 Bug 处理信息（引入原因、处理方法、处理位置、产生影响的范围等等）
• 项目中 Defer、Delay 状态的 Bug 必须经过开发代表的审核，后续也需组织会议进行三方评审
• 开发代表和测试工作组长必须跟踪所有相关 Bug 的处理过程
• Bug 处理按照流程及相关规范处理，禁止以下违规操作：a. Bug 降级违规操作：一轮未复现降级、跨等级降级（从高到低）、Bug 降级未经发布评估会评估；b. Bug 关闭违规操作：对难以重现且解决人员无法定位解决的 Bug 单做关闭处理

1.5 Bug 的准入准出条件

• 准入条件：在评审、调试、测试、产测过程中发现了 Bug
• 准出条件：已修复的 Bug 通过验证并关闭

二、Bug 描述要求

Bug 描述的要求为：分类准确、叙述简洁、步骤清楚、有实例、复杂 Bug 有据可查（截图或视频、日志或其他形式附件）。

对于那些不好描述的内容，可以把工程文件或截图作为附件提交。具体要求如下：

• 描述一般格式：缺陷描述时，一般建议分步描述 -> 模块或功能点、测试步骤、期望结果、实际结果、其他信息、建议（据实际情况灵活调整）
• 单一：a. 尽量做到一个 Bug 只描述一个错误，这样便于解决人迅速定位一个错误、集中精力每次只修正一个错误；b. 校验者每次只校验一个错误是否已经正确修正；c. 可以避免出现遗漏的情况；d. 文档评审类缺陷在具体问题描述情况的基础上，可以分类合并提交
• 简洁：每个步骤的描述都应尽可能的简洁，只解释事实，演示和描述 Bug 必要的细节，不要写无关信息
• 复杂的 Bug 应附截图补充说明或直接通知制定的修改人
• 报告中不允许出现抽象词句，比如 “有错误” 之类的词句，需要将 “有错误” 改为 “字符乱码”