一、缺陷的定义：
软件未实现需求和规格要求的功能；
软件中出现了需求和规格，指出了不可出现的错误；
软件实现了需求和规格中未提及的功能
虽然没有明确提出软件未实现的规格，但是要实现的内容、软件难以理解，难以使用，动作缓慢，或者我认为最终用户不好
测试用例运行中发现的不符合预期结果的现象都是缺陷。
二、缺陷分类：
1 .按处理状态分类)新提交、等待审查、等待定位、等待修复、正在修复、等待纳入新版本、等待确认、关闭
2 .按处理意见分类：修改的、不是问题的、不能修改的、推迟解决的、不能再现的、需求的变更、设计上的缺陷
三、缺陷的分布特征：
1、集结、缺陷喜欢捆绑，被发现的缺陷多不意味着缺陷完全暴露；
2 .即使是耐性、相同的测试构想，测试用例测试越多，越难发现新的缺陷。 某些缺陷只在特殊或极端的情况下触发，由于一些原因我们不修复某些缺陷。 没有足够的时间，不是真正的缺陷，修复的风险太大了，不值得修复。
四、缺陷严重等级：
致命：软件无法运行，主要功能丢失，或者可能产生严重的负面影响
严重：软件的次要功能丢失，或者主要功能在某些情况下出现错误
一般来说：软件有时会出错，但对结果的影响很小； 有些软件可能会发生错误，但对结果的影响很小。
优化建议：软件的微小优化或推荐类。
五、缺陷的优先次序：
即时解决、高、中、低
六、缺陷管理程序：
1、发现者填写《缺陷跟踪单》并提交审核负责人；
2、审核负责人进行初步判断，将清单交给开发者进行问题定位；
3、开发者找出问题的原因，进行缺陷修复；
4、开发者将修复的代码提交给审查负责人；
5 .审查负责人决定将该修复纳入哪个版本并存档；
6 .测试经理组织测试，测试人员对此修复进行验证-回归测试。
七、缺陷报告注意事项：
1 .编号、标题、重要度、紧急度、软件版本、说明、再现步骤附属物(屏幕截图、视频、前后台日志) )。
2 .说明(Description )简洁、准确、完整、整齐
3 .检查拼写和语法的错误
4 .尽量使用行业短语
5、每个步骤尽量只记录一个操作，保证所用的表达用语和表达方法简洁；
6 .每个错误报告只包含一个错误。