Bug管理

本篇文章，来分享Bug管理的内容。

现在，假设我们已经进入了这么一个阶段，测试用例写完了，可能有人用Excel写，可能也有人用禅道或者其他的管理工具来写。而且，用例已经评审过了，那就开始执行测试用例了。

在执行用例的时候，可能会遇到一个问题，这个测试用例不通过，这就形成一个Bug了。

Bug的定义

电脑程序里的错误，而现在更是将其延伸为漏洞，错误，可改进的细节，或与需求文档存在差异的功能实现等。

那么Bug 与缺陷有什么区别或者联系吗？

Bug是缺陷的一种表现形式，而一个缺陷是可以引起多种Bug的。

Bug的分类

对Bug的划分，可以分为以下：

1. 功能缺陷：指业务流程未实现
2. 代码错误：页面跳转时报404、500
3. 界面优化：UI 问题，图文显示的问题
4. 安装部署：安装失败或者无法访问等
5. 性能问题：响应时间久，页面加载慢
6. 安全问题：用户身份验证，数据备份等
7. 设计缺陷：需求问题
8. 其他：易用性及兼容性的问题

Bug 的严重程度

1、致命：系统崩溃（请求直接把服务器搞坏）、死机、死循环等，会导致数据库丢失，与数据库连接错误，主要功能丧失，基本模块缺失，重要的一级菜单功能不可使用等问题。

2、严重：系统主要功能部分丧失，数据保存失败，提交调用错误，功能设计与需求严重不符，自动退出，稳定性差等。

3、一般：功能菜单没有完全实现，存在缺陷但不会影响系统稳定性。如操作时间长、查询时间长、格式错误、边界条件错误、删除没有确认框、数据库表的字段过多等。

4、轻微：兼容性，界面优化，不影响操作功能的执行，错别字，页面显示重叠，提示语丢失等，此类问题在测试初期较多，优先程度低。

Bug的优先级

主要是指开发修复Bug的先后顺序，可以分为：

• 非常紧急
• 紧急
• 一般
• 不重要

Bug的优先级，最终的决定权还是掌握在开发或者产品经理的手上，测试人员只是起到建议的作用。

Bug的跟踪处理流程

根据Bug的跟踪处理流程，Bug存在以下的状态：

1. 待处理
2. 已确认
3. 已处理
4. 已修改
5. 仍处在，代表被重新激活
6. 拒绝
7. 挂起，代表暂不处理

Bug的描述概要

发现Bug之后，需要将Bug描述清楚，转交给开发处理。

关于Bug的描述，主要包含以下：

1. Bug的所属项目
2. Bug的所属模块
3. Bug产生的前提条件
4. 问题类型
5. 标题：尽量详细，方便后续快速查询
6. 严重级别
7. 优先级
8. 复现步骤
9. 期望结果
10. 实际结果
11. 附件：如有必要，可添加截图与视频等

关于高质量的Bug：

• 标题：简明扼要地描述Bug，可以让负责修复的人员快速了解，定位问题
• 测试环境：清晰描述在什么环境下发现Bug，包括软件和硬件系统
• 前提条件：用户测试步骤前的系统环境信息等
• 测试步骤：在执行怎么样的操作时，发现问题
• 预期结果：软件设计所要求达到的需求、预期目标
• 实际结果：在测试软件的过程中，软件本身表现出的结果，可能会与预期结果有差异

与开发的沟通

1、确保自己提交的Bug是有意义的，并且是可重现的

2、如果开发有疑问，或者认为这不属于Bug时，可以从用户角度进行解析

3、Bug 步骤要写清楚，方便开发人员定位Bug

4、与开发确认，修改Bug后，会影响到哪些模块，重点关注

5、注意沟通技巧

以上就是本篇文章所要分享的内容，欢迎各位大牛指正。你的指正，能让我在测试之路上快速成长。

Leo Never Stop Fighting！