一、缺陷的定义：
①软件未实现需求和规格要求的功能；
②软件出现了需求和规格指明不该出现的错误；
③软件实现了需求和规格未提及的功能；
④软件未实现规格未明确提出但应该实现的内容，软件难理解，不易使用，运行缓慢或者最终用户会认为不好；
⑤测试用例执行中发现的与预期结果不符的现象都是缺陷。
二、缺陷的分类：
1.按处理状态分：新提交的、待审核、待定位、待修复、修复中、待合入新版本、待确认的、关闭
2.按处理意见分：已修改的、不是问题、无法修改、延期解决、无法重现、需求变更、设计缺陷
三、缺陷的分布特性：
1.集结，缺陷喜欢扎堆，发现的缺陷多并不代表缺陷完全暴露；
2.抗药性，同样的测试思路，测试用例测试进行得越多，新缺陷就越难发现，某些缺陷只有在很特殊或者很极端的情况才会被触发,有一些原因导致我们不修复某些缺陷：没有足够的时间、不算真正的缺陷、修复的风险太大，不值得修复。
四、缺陷的严重等级：
致命：软件无法运行、主要功能丧失或者很大可能性会造成严重不良后果；
严重：软件的次要功能丧失，或者主要功能在特定情况下会出错；
一般：软件在某些情况下会出错，但造成的后果影响不大轻微；软件在某些情况下会出错，但造成的后果影响很小；
优化建议：软件微小的优化或建议类。
五、缺陷优先级：
立即解决、高、中、低
六、缺陷管理流程：
1.发现者填写《缺陷跟踪单》交给审核负责人；
2.审核负责人作初步判断，将单子转给开发人员进行问题定位 ；
3.开发人员定位出问题原因，并进行缺陷的修复；
4.开发人员将修复后的代码提交给审核负责人；
5.审核负责人决定，将该修复安排在哪个版本中合入，归档；
6.测试经理组织测试，测试人员对该修复进行验证-回归测试。
七、缺陷报告的注意事项：
1.编号、标题、严重程度、紧急度、软件版本、描述、重现步骤附属物（抓图，录像，前后台日志）
2.描述 (Description)，简洁、准确，完整，条理井然；
3.检查拼写和语法错误；
4.尽量使用业界短语；
5.每一个步骤尽量只记录一个操作，保证用的表达术语和表达方法简洁；
6.每条错误报告只包括一个错误。
