1.软件缺陷
1.软件未达到说明书表明的功能
2.软件出现了需求规格说明书指明出现的错误
3.软件的功能超出了需求规格说明书指明的范围
4.软件未达到规格说明书虽未指明而应该达到的目标
5.软件测试人员认为软件难以理解，不易使用，或用户不满意的情况
2.软件缺陷的状态
1.提交(Submited)：以提交的缺陷
2.打开(Open)：确认“提交的缺陷”，等待处理
3.拒绝(Rejected)：拒绝“提交的缺陷”，不需要修复或不是缺陷，重复缺陷，无法重现
4.修复(Resolved)：缺陷被修复
5.关闭(Closed)：确认修复的缺陷，将其关闭
6.推迟（Later）：可以以后解决，确认以后的日期或版本
3.软件的严重程度
1.low：表面性错误，如错别字
2.Medium:影响一个独立的功能；仅仅在特定条件发生；与产品需求不一致；断断续续出现问题
3.High：功能点没有实现，或不符合客户的需求；数据丢失
4.VeryHigh：频繁的死机，系统大部分功能不可用
5.Critical：系统瘫痪，异常退出，死循环，严重的计算错误等
4.软件缺陷的优先级
1.low：最低优先级，时间和资源允许时修正
2.Medium:低优先级，不会延迟发布，但是会在以后修复
3.High：中优先级，制约开发和测试活动的进行，如果先前没有修复他，那么需要在发布前修复他
4.VeryHigh:高优先级，错误对这套系统的能力产生严重的影响
5.Urgent
最高优先级，在这个错误影响下，系统几乎不可用
5.缺陷的所属模块
1.系统缺陷：不能正常工作或重要功能，使系统崩溃或资源不足
2.数据缺陷
3.数据库缺陷
4.接口缺陷
5.功能缺陷
6.安全性缺陷
7.兼容性缺陷
8.性能缺陷
9.界面缺陷
6.缺陷报告注意事项
1.尽量保证缺陷可以重现
2.简洁，准确，完整
3.一个缺陷报告只写一个缺陷
7.缺陷报告的书写规范
1.标题简洁，提供缺陷的本质信息即可
2.复现的步骤要详细，用数字编号
3.实际结果要描述清楚复现后的结果
4.列出期望结果
5.提供附件
6.提供严重性属性和其他公司需要填写的属性
注意：避免一些常见的错误：
(1)
避免使用情绪化语言和强调性标点符号
(2)
避免使用模糊的词语
(3)
避免使用自认为幽默的语言，直接描述问题即可
(4)
避免提交不确定的缺陷
8.缺陷的跟踪
新提交的缺陷为“新建”状态，在确认有效之后变为打开状态，开发人员修改后变为”已修复”状态，此时开发人员需要回归测试，如果验证问题已经解决，状态变为“已解决”，如果问题依然存在，状态为“打开”；如果开发人员任务此缺陷可以延期修改，状态为“延期”；注意此时必须由项目相关人员讨论后确定，才能延期处理，否则状态继续为“打开”。
9.缺陷密度
每千行代码的缺陷数：
缺陷密度=1000*缺陷个数/代码行数