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