Bug基本组成要素

Bug组成

分类

描述

是否解决

备注

bug标题

对你所提交的Bug进行简明扼要的描述

bug详细描述

测试步骤

实际结果

预期结果

对Bug进行进一步详细的描述，例如在什么情况下发生了什么现象（简短明了易懂即可）

测试步骤：对测试过程简单的描述，从开始测试到发现bug的时刻为止（测试过程的一步步罗列）

实际结果：在测试软件的过程中，软件功能所表现出来的特征或行为

预期结果：软件功能所要求达到的结果或目标

bug所属业务线

属于哪个业务线

如：A、B

bug所属项目版本

哪个项目中的哪个版本

如：A项目1.0版本

B项目1.2版本

bug所涉及的域

是哪个域产生的bug

如：abc.cc

test.cc

bug所属模块

属于哪个功能模块

一般按菜单、功能划分

bug产生环境

测试环境

回归环境

预发布环境

线上环境

在什么环境下发现的这个bug，例如：什么系统，什么环境等。

对于bug环境的描述简单的罗列即可（精简为主）

bug优先级

紧急

重要非常紧急：优先级最高，一定要做的

Immediate 即“马上解决”，

表示问题必须马上解决，否则系统根本无法达到预定的需求。

高

重要比较紧急：可以先缓一缓 但一定要做的

Urgent即“急需解决”，

表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。

中

重要不紧急：暂时可以先缓一缓 但一定要做的

High即“高度重视”，

表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。

低

紧急不重要：可以先准备下，随时准备做的

问题在系统发布以前必须确认解决或确认可以不予解决

一般

不紧急不重要：可忽略不计的

bug严重程度

Blocker

即系统无法执行、崩溃或严重资源不足、

应用模块无法启动或异常退出、

无法测试、造成系统不稳定。

· 阻碍开发或测试工作的问题；

· 严重的数值计算错误

· 功能设计与需求严重不符

· 其它导致无法测试的错误, 如服务器500错误

· 接口不可用或调用不通

· 内存泄漏

· 用户数据丢失或破坏

· 造成系统崩溃、死机、死循环，导致数据库数据丢失，

· 与数据库连接错误，主要功能丧失，基本模块缺失等问题。

· 如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用

· 内存泄漏、无法登录、无法正常退出、关联程序间调用冲突等。

· 模块无法启动或调用，程序重启、自动退出

1-2小时

Critical

即影响系统功能或操作，

主要功能存在严重缺陷，

但不会影响到系统稳定性。

· 功能未实现（如增删改查未实现）

· 功能错误

· 数据错误（数据间交互调用错误、数值计算错误、数据库保存错误、用户数据丢失）

· 系统刷新错误

· 安全性问题

· 一级功能菜单不能使用

2-4小时

Major

即界面、性能缺陷、兼容性。

· 操作界面错误（包括数据窗口内列名定义、含义是否一致）

·  边界条件下错误

· 提示信息错误（包括未给出信息、信息提示错误等）

· 长时间操作无进度提示

·系统未优化（性能问题）

· 光标跳转设置不好，鼠标（光标）定位错误

· 兼容性问题（个别浏览器按钮不可点击等）

· 影响功能及界面的错误字或拼写错误

· 功能没有完全实现但是不影响使用

· 功能菜单存在缺陷但不会影响系统稳定性。

· 如：查询时间长、边界条件错误，数据库表中字段过多、容错性不好、大数据无响应

.操作时间长、格式错误、删除没有确认框、没有滚动条等

1天

Normal

即“正常处理”，进入个人计划解决

表示问题不影响需求的实现，但是影响其他使用方面，

页面跳转访问出错，调用出错等。

1-2天

Low

即“低优先级”

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化的方案等。

如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，

描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确

2天

bug状态

新的New

当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的问题是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New 

已指派Assigned

当一个bug状态为New时，将其指派给开发人员，开发人员将确认这是否是一个bug，如果是，开发负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

已解决fixed

当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”已解决

已关闭closed

 若测试人员经过再次测试之后确认bug 已经解决，就将bug的状态设置为“Closed”

重开Reopen

若经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次分配给开发组，并将bug的状态设置为“Reopen”

Rejected(被拒绝) 

开发负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与项目人员讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

Postponed（延期）

对于一些不影响使用或不紧急经沟通确认后可优化解决的bug，bug的状态可由项目人员设置为“Postponed“

bug处理人

开发

测试

产品

指派给谁，谁需要处理这个bug

bug产生原因

代码问题

白盒测试、自测、代码review

业务逻辑方面以及业务功能等相关问题

功能上错误性bug

设计问题

开发设计文档、需求概要/详细设计文档未涉及到的

用户界面

表单逻辑、样式、内容问题

用户界面：UI表现，包括对话框样式和文字描述问题

需求问题

原有需求基础上的更改

新增需求：会议上邮件聊天工具中提出的新需求

功能已满足但待改善，属于改良性优化建议

环境问题

如web服务器或者数据库配置等问题

安装部署：项目部署时出现的错误，可能不是程序本身的问题而是工具本身和人为因素引起

性能问题

负载、压力测试等问题

安全问题

加密、数据处理等安全性

测试误报

不理解功能需求设计未跟开发产品确认

其他

bug解决方案

代码

需求

设计

其他

简单说明bug是如何解决的

备注

对bug的一些补充

例如：其它系统也发生，上个版本不发生等需要补充的内容