BUG描述规范

本文档主要是目的是规范BUG的描述，清晰简单描述好BUG，编写有效的BUG实例，帮助开发人员有效的进行BUG定位，重现错误，从而去有效的定位错误，修改错误。

一、BUG级别定义

1. P0级别

阻碍开发或测试工作；严重的产品质量问题、系统功能基本不可用；系统崩溃；数据库数据丢失；严重影响项目进度等问题。

该级别BUG需立即解决。

详细分类：

• 重要或者紧急需求没有实现
• 功能设计与需求严重不符
• 正常使用场景下系统卡死、崩溃无法恢复、内存泄漏
• 任何一个主要功能不可用且无法恢复
• 其它导致无法测试的错误, 如服务器500错误
• 用户数据丢失或破坏
• 严重安全问题等

2. P1级别

系统核心功能部分缺失、用户数据丢失、系统不稳定等，导致模块无法测试，但不影响其他功能的测试。

该级别BUG需尽快修复解决

详细分类：

• 模块功能未实现（任意需求没有实现至少P1）
• 核心功能实现不完整、不正确或业务逻辑不正确等
• 核心功能中的部分功能不可用
• 非主流场景下的系统卡死、崩溃无法恢复、内存泄漏
• 影响功能使用的性能问题
• 安全性问题

3. P2级别

系统存在功能、性能等问题，但不影响用户的正常使用或影响有限。

该级别BUG在实际测试中存在最多，合理安排解决即可

详细分类：

• 一般功能性问题
• 不能接受且必须修改的UI体验问题，例如页面错乱影响理解等
• 不影响使用的性能问题，例如响应慢等
• 兼容性问题

4. P3级别

界面、文案显示等建议优化类BUG。

该级别BUG优先程度低，在保障进度和质量的前提下尽量安排修改

详细分类：

• 提示优化类，例如提示文字未采用行业专业术语、提示不友好等
• UI布局优化类，例如字体大小，按钮大小不合适，文字排列不对齐
• 辅助说明描述不清楚
• 个别不影响产品理解的错别字

二、BUG描述规范

1. BUG标题

BUG标题应简洁明了，从BUG标题可以直接看出问题点在哪里，标题长度尽量要控制在正常显示的范围内。

2. BUG描述

前置条件：需要说明操作前提以及环境等要素，前提条件包括平台、系统版本、设备型号等

操作步骤：操作步骤是用来复现BUG的，要做到不熟悉的人按操作描述可以复现BUG，因此要尽可能的详细。

实际结果：当前问题表现的结果，明确当前的问题

期望结果：表示正确的结果，需要准确清晰，开发才能知道修改成什么样，不能模棱两可

备注：用于备注一些关键信息，如IP地址、账号信息、其它类似问题等

如果遇到的是概率性问题，则在BUG描述里需说明问题出现的概率，如10%，或只出现1次。

3. BUG归属

选择相应的项目、版本、模块，每个BUG应该都是有模块归属的，尽量避免在根路径下。

4. BUG级别

严重程度：表示BUG是什么级别的问题，级别越高越是要修改或尽早修改，是重要的判断依据之一。分为4个级别，P0、P1、P2、P3，具体可以阅读前面的BUG级别定义。

5. BUG优先级

紧急：缺陷必须被立即解决
较紧急：缺陷严重需要优先考虑
正常：缺陷需要正常排队等待修复或者列入软件发布清单
不紧急：缺陷可以在方便时去修正

6. BUG类型

表示BUG属于哪一类问题，对后续BUG分析有重要支撑作用，可以明确软件的问题集中区。
常见类型有：

• 需求问题
• 代码错误
• 性能问题
• 安全问题
• 环境问题
• 配置问题

7. 测试阶段

测试阶段：根据项目的各个里程碑进行选择，进入测试之前都会明确下来。在验证BUG的时候属于当前的测试阶段。比如当前是第一轮测试结束了，在验证开发修改的BUG，还未正式进入第二轮，在此阶段发现的BUG，选择第一轮测试。
常见的测试阶段：

• 冒烟测试
• 第一轮测试
• 第N轮测试
• 回归测试
• UAT测试

8. 附件

• 遇到UI相关的问题，必现提供截图，截图要截完整的图
• 遇到概率性问题，如果有客户端或服务端日志，需将log一并上传到BUG附件中