一、 缺陷报告的组成
1、缺陷编号(Defect ID)
提交bug的顺序
2、缺陷标题(summary)
简明扼要的说明一下该bug
3、缺陷的发现者(Detected By)
一般就是自己
4、发现缺陷的日期(Detected on date)
（区别：data数据）
一般就是当天
5、缺陷所属的模块(subject)
在测试哪个模块的时候发现的bug；开发经理会据此找到bug的修改负责人
6、发现缺陷版本(Detected in release)
在测试哪个版本的时候发现的bug
7、指派给谁处理(Assigned to)
测试人员指派给开发经理
开发经理根据bug所在的模块指派给相应的开发人员进行缺陷修改
8、缺陷的状态(status)
表明缺陷此时所处的情况或处理状态
（1）测试人员发现bug，把缺陷的状态写成：new（新提交的bug）
（2）开发经理看到此bug，进行验证，如果是bug，把缺陷状态改为：open（打开的bug，开发组承认的bug）；如果不是bug，把缺陷状态改为：rejected（拒绝的bug）
（3）开发人员看到指派给自己的bug，进行bug修改，修改完后，把状态改为：fixed（已经修复的bug，待返测的bug）
（4）测试人员对修复的bug进行返测，如果返测成功，把bug的状态改为：closed（关闭的bug，归档的bug）；如果返测失败，把bug的状态改为：reopen（重新打开的bug，返测为通过的bug）
整个过程称为缺陷的处理流程（缺陷的跟踪过程）
New—>open—>fixed
—>closed
缺陷的严重程度(severity)
1.Bug对软件造成的影响有多大
2.Urgent：对软件和用户造成巨大影响的bug，如死机、蓝屏、重启等
3.Veryhigh：非常严重的bug
4.High：大的问题
5.Medium：中等程度的问题
6.Low：小的问题
7.需要在正式文档或测试计划中定义好评价标准
8.Bug Level（级别） Definition（定义）
9.Performance性能
10.Function功能
10、缺陷的优先级（priority）
测试人员希望程序员在什么时间内或哪个版本中解决该bug
1.Urgent：立即修改，否则影响开发/测试进度
2.Veryhigh：本版本修改
3.High：下版本修改
4.Medium：发布之前修改
5.Low：允许发布中存在的bug
需要考虑的主要因素：
A、bug的严重程度
一般越严重，越优先（但不是绝对）
B、bug影响的范围
一般影响范围越大，越优先
C、开发组当前的工作进度
D、解决的难以程度
11、缺陷描述（description）
把发现bug的步骤、使用的数据、操作过程记录下来
练习重点
缺陷报告用途
1、 记录bug
2、 对bug进行分类（提交者、模块、版本、严重程度、优先级、状态）
3、 对bug进行跟踪管理（new——closed）
4、 对bug进行分析、统计、总结
二、如何识别bug
1、测试用例的预期结果
（实际结果与预期结果不一致，就是bug）
2、看需求（从bug的5点定义判断）
3、与开发、需求人员、用户讨论
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
