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的步骤
