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