缺陷报告的组成

1、缺陷编号（Defect ID)，提交BUG的顺序。

2、缺陷标题（summary),   简明扼要的说明一下这个BUG。

3、缺陷的发现者（DetectedBy) ,一般是自己。

4、发现缺陷的日期（Detected on date)，一般是当天。

5、缺陷所属的模块（subject)， 在测试哪个模块的时候发现的BUG，开发经理会据此找到模块。

6、缺陷的版本（Detected in release)，在测试哪个版本时发现的BUG。

7、指派给谁处理（Assigned to)，测试人员会指派给开发经理，开发经理根据BUG 所在模块指派给相应的开发人员修复缺陷。

8、缺陷的状态（status)，表明缺陷此时所处的情况或处理状态。图为BUG管理流程图

　　

9、缺陷的严重程度（severity)

 表明该BUG对软件的影响有多大。

　　

#各个软件的定义并不完全一样。
Urgent: 造成死机、重启、异常终止等严重后果的BUG。

Veryhigh：非常重的BUG

High: 大的BUG

Medium: 中等的程度的BUG

Low:小的BUG
 

　　怎样定义这个BUG，属于缺陷的哪个级别，需要在正式的文档或测试计划中定义好评价标准

　　BUG Level(级别）

　　Definition(定义）

　　Performance(性能）

　　Function（功能）

10、缺陷的优先级（priority)

　　测试人员希望开发人员在什么时间段或哪个版本中解决该BUG

　　Urgent:立即修复、否则影响开发/测试进度。

　　Veryhigh：本版本修改。

　　High: 下版本修改。

　　Medium：发布之前修改。

　　Low：允许发布中存在BUG。

　　需要考虑的主要因素：

　　　　a.BUG 的严重程度一般越严重，越优先（但不是绝对）

　　　　b.BUG 的影响范围，一般影响范围越大，越优先

　　　　c.开发当前的工作进度

　　　　d.解决的难易程度

11、缺陷描述（description)

　　把发现的BUG的步骤