bug的合规描述

bug的合格描述：

 

发现问题的版本bug的合格描述：

开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障问题出现的环境

环境分为硬件环境和软件环境，详细的环境描述有利于故障的重现(如果是web项目，需要描述浏  览器版本，客户机操作系统等；如果是app项目，需要描述机型，分辨率，操作系统版本等)

错误重现的步骤

问题出现的最短步骤预期行为的描述

需要开发人员指导怎样才是正确的，以用户角度来描述型为是怎样的错误行为的描述

描述错误的现象

bug的生命周期 ：

New： 发 现 新 的 bug           Open： 确 认 是 bug              Fixed： 修 改 后 的 bug 标 识 Rejectd：如果认为不是bug就拒绝修改Delay：认为此bug暂时不需要进行修改Closed：通过回归测试通过，关闭bug

Reopen：经验证bug仍然存在，需要重新打开bug，进行重新修改

缺陷管理流程说明：

1、测试人员填写bug并提交给开发组长，Bug的状态为New；

2、开发组长次日工作前对bug确认是否有效。有效的bug，状态变化为open，并分配给开发人员；bug 无效或者延期修改的，将bug状态变化为Rejected，同时也在comment中注明原因。

3、开发人员上班的第一件事情是查看自己有几个bug需要修改。

4、开发人员修改bug，修改完成并进行单元测试后，将bug的状态变为fixed，在comment中说明修改方法；

5、测试人员每天查看自己提交的bug的状态变化，应该成为每个测试人员的例行行为；                  6、当bug的状态变为fixed时，测试人员打开该bug，开始对该bug进行回归测试；

7、如果该bug回归测试通过，则状态变为closed。否则bug的状态变为reopen（必须说明reopen、closed状态变化原因或者操作过程）；

8、如果回归测试通过，可是修改的同时又引入新的bug，则重新提交bug，状态为new。如果需要的时候注明相关联的bug号；

9、只有当所有的bug状态为closed，才可发布版本。--（on-hold）

10、当bug 是reject 状态需要和开发确认，如果不是一个bug就closed

bug等级：

致命（一级bug）

通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。

比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循环报错，无法正常退出。

严重（二级bug）

通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。

一般（三级bug）

通常表现为：界面、性能缺陷。

比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时， 没有提供进度条。

提示（四级bug）

通常表现为：易用性及建议性问题

比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4. 界面格式不规范。