一、bug的定义

软件的bug，狭义指软件程序的漏洞或缺陷，广义指测试工程师或用户提出的软件可改进的细节、或与需求文档存在差异的功能实现等

对应三个测试目的：（3个为了）

1. 为了发现程序的代码或业务逻辑错误；

2. 为了检查产品是否符合用户需求；

3. 为了提高用户的体验。

二、bug的类型

对bug的划分，禅道为例，包括：

1. 代码错误；

2. 设计缺陷；

3. 界面优化；

4. 性能问题；

5. 配置相关；

6. 安装部署；

7. 安全相关；

8. 标准规范；

9. 测试脚本；

10. 其他划分：功能类、界面类、性能类、易用性类、兼容性类、其他。

三、bug的等级

一级bug，必须优先要改

致命错误：

1. 常规操作引起的系统崩溃、死机、死循环；

2. 造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露；

3. 涉及金钱，如支付类软件，金钱计算错误。

二级bug

严重错误：

1. 重要功能不能实现（例如：微信没有实现语音聊天、朋友圈，等）；

2. 错误的波及面广，影响到其他重要功能正常实现；

3. 非常规操作导致的程序崩溃、死机、死循环(非常规操作：用户使用软件时不会进行的操作）；

4. 外观难以接受的缺陷（例如：直播平台的封面图片的失真、压缩，完全变形）；

5. 密码明文显示。

3级bug

一般错误：

不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷

1. 次要功能不能正常实现；

2. 操作界面错误（包括数据窗口内列名的定义，含义不一致）例如：列名与列名下的内容不一致；

3. 查询错误、数据错误显示；

4. 简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可由前端判断）；

5. 删除操作未给出提示。

4级bug

程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误

1. 界面不规范；

2. 辅助说明描述不清楚；

3. 提示窗口文字未采用行业术语；

4. 界面存在文字错误；

5. 改进意见：可以提高产品质量的建议，包括新需求和对需求的改进。

四、bug的处理流程图

重点：发现bug后，------->有可能有bug--------确认实实在在的bug------提交bug

确认bug时不能停留在表面，需要进行深究：

例如：下拉框选择银行，却发现只有3个银行？

1. 首先需确认数据库的表信息是否正确；

2. 如果数据库表只要3个银行（需要沟通）研发的话只需要添加数据就好了；

3. 数据库表正常=====直接提bug，代码有问题。

指派bug:

1. 指派给相关功能模块的开发

五、bug的状态处理

已指派的bug

1. 跟踪、提醒开发；

2. 已修复的，更新环境验证。

已解决的bug

1. 更新环境验证；

2. 验证通过，关闭；

3. 验证不通过，重新打开；

4. 回归验证时继续跟进bug，直到关闭bug。

重复的bug

1. 确认重复，关闭；

2. 不重复，写明原因。

不是bug

1. 首先确认开发环境和测试环境是否一致；

2. 不是缺陷关闭；

3. 是缺陷和开发沟通；

4. 未得到解决与产品沟通。

无法重现

1. 首先确认开发环境和测试环境是否一致；

2. 重现不了，与产品和开发一起确认关闭（依据bug的严重程度）；

3. 找到重现原因，写明清楚，指派给开发。

不予解决

1. 找产品经理确认；

2. 不予解决，关闭；

3. 要解决，写明原因给开发。

设计如此

1. 找产品经理确认；

2. 不予解决，关闭；

3. 要解决，写明原因给开发。

延期修改

1. 根据bug的严重程度，是否影响当前版本的发布；

2. 与产品经理确认；

3. 不予延期，写明情况，激活；

4. 确认延期，做好记录，后续版本进行关注。

作者：那个杰克

原文链接：https://www.cnblogs.com/yangsun/p/9751581.html