文章目录
- [一. Bug基本概念](#一. Bug基本概念)
-
- [1. Bug 介绍](#1. Bug 介绍)
- [2. Bug 的判定标准](#2. Bug 的判定标准)
- [3. 经典面试题：如果开发认为你的提交并不是 Bug 怎么办？](#3. 经典面试题：如果开发认为你的提交并不是 Bug 怎么办？)
- [4. Bug 的严重程度](#4. Bug 的严重程度)
- [5. Bug 的优先级](#5. Bug 的优先级)
一. Bug基本概念
1. Bug 介绍
其实 Bug 就是一个电脑程序里的错误 ，也可以被称为漏洞 ，或者一个程序不完善的地方。
- 词源趣闻：早期计算机是大型机器，有一次因为一只虫子（Bug）飞进主机导致短路故障，从此大家就把程序故障统称为 Bug。
- Bug 与缺陷的区别：
- Bug：通常指表现出来的现象（比如程序崩溃）。
- 缺陷：指引发这些现象的根本原因（代码逻辑错误）。
注：实际工作中通常不做严格区分，统称为 Bug。
2. Bug 的判定标准
只要符合以下任意一条，就可以判定为 Bug：
- 功能未达标：软件未达到需求文档规定的功能或性能。
- 出现不可容忍错误：软件出现了客户无法接受的错误。
- 体验不佳：软件使用不符合客户习惯或工作环境。
- 超出范围：软件实现了需求文档范围之外的功能（画蛇添足）。
3. 经典面试题：如果开发认为你的提交并不是 Bug 怎么办？
其实这个问题面试官想要考察的就是大家对于 Bug 有没有自己的判断，还有就是在工作当中的一些软实力，比如说处理问题的思路。
-
可以先来分析一下什么样的 Bug 会让开发认为不是 Bug。
*情况分类 应对策略 问题描述不清 提升自己的业务水平，把复现步骤写清楚。 bug 难以复现 保留截图、日志（Log）等证据，做好记录。 bug 有争议/建议 组织会议讨论，达成共识。 功能性 Bug（需求理解不一致） 拿出需求文档或设计方案作为证据，对事不对人。
4. Bug 的严重程度
在软件测试中，软件缺陷的严重性的判断应该站在软件最终用户的角度，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。
-
致命 ：系统完全无法正常运行，核心功能不可用。具体表现为：系统崩溃、挂起、死机，或关键模块无法启动，导致业务流程完全中断，且无任何替代方案可绕过。
-
严重 ：核心功能存在明显缺陷，严重影响业务目标的达成。具体表现为：主要功能无法执行或产生错误结果，系统不稳定、数据被破坏，且无法通过常规操作规避。该问题在常规操作中频繁出现，或在特定流程中不可避免，导致系统性能、功能或可用性严重降低。
-
一般 ：系统基本功能可用，业务目标可以达成，但存在局部体验或性能问题。具体表现为：页面响应变慢、中间结果展示有误但不影响最终输出、非核心功能异常等，对整体业务流程影响有限。
-
建议 ：不影响功能正确性和业务目标，但影响用户体验或使用便利性。具体表现为：界面文案拼写错误、排版不美观、操作路径不够便捷、提示信息不够友好等，属于优化完善类问题。
5. Bug 的优先级
优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。
严重程度与优先级的关系
两者通常相关，但并不绝对：
- 通常情况：严重程度高，优先级也高。
- 特殊情况 A：严重程度高，但优先级低（例如：极难触发的崩溃，可能暂不处理）。
- 特殊情况 B：严重程度低，但优先级高（例如：公司 Logo 拼写错误，虽然不影响功能，但必须马上改）。