背景：由于公司各个产品线项目在不断的版本迭代中遗留了越来越多的未关闭缺陷，导致项目中的遗留缺陷没得到及时的重视和修复，于每次阶段统计时，缺陷关闭率过低。做成这种结果，一方面的是开发人员及相关领导没能重视的原因；而另一方面，作为测试人员，有责任和义务去督促缺陷的及时处理，加强对缺陷管理方面把控。
【缺陷处理机制】制定的主要目的如下：
1、 定期通过3方（需求、开发和测试）沟通，处理遗留未关闭的缺陷。
2、 会议中将需要修复的缺陷经沟通后落实在版本规划中修复。
3、 通过面对面沟通解决在QC系统中缺陷沟通时间过长或沟通失效的问题。
4、 加强项目成员对缺陷的重视，加快缺陷的修复进度，提高项目的缺陷关闭率。
具体时序图如下：
转载于:https://www.cnblogs.com/whylaughing/p/6069318.html
1. 文档简介
1.1 编写目的
l 规范缺陷上报及处理流程
l 规范缺陷版本维护流程
l 提高缺陷质量
l 提高工作效率
对于测试人员，要严格按照“提案填报规范”中的要求填写上报缺陷；
开发人员和测试人员，要严格按照“提案处理原则”中对于各种状态缺陷的处理约定，及时对缺陷进行相应处理；
对于测试负责人，要严格按照“提案版本维护”中的要求对提案版本进行相应处理。
1.2 定义、首字母缩写词和缩略语
无
2. 缺陷填报规范
2.1 缺陷填报步骤
（用红色标识的是提案的必填项）
A． 选择项目和提案类型
【项目】选择所要填入的缺陷库
【提案类型】缺陷方面的提案选择“问题”
用户体验方面的提案选择“增进建议”
B. 输入提案的详细信息
【概要】缺陷或建议的标题，是对提案具体描述的概括，应言简意赅
【优先级】ABCDE五级区分，严重级别由A到E递减。
l 划分标准见<2.2 提案优先级的判定>
【预期日期】提案解决的日期，最长为下一轮测试开始的日期。可以不填写
【组件】问题所在部件
【影响版本】第一次发现问题的项目版本
【修正版本】该问题的解决版本
l 新报提案时，修正版本与影响版本选择一致
【被分配人】提案的解决人：
l 需求无异议的缺陷直接分配给开发负责人，由开发负责人安排解决
l 需要产品确认的缺陷分配给产品负责人，经确认确实是bug的提案，分配给开发负责人，否则分给测试负责人
【环境】测试环境：操作系统+浏览器版本
【描述】对问题或建议的具体描述，格式参见<2.2. 提案的描述格式>
2.2 缺陷优先级的判定
l A级故障：系统运行中出现的死机、系统瘫痪、关键数据无法获得、系统的关键功能 在某些情况丧失、系统关键性能不能达到设计指标等。
l B级故障：基本功能不稳定或者丧失、系统重要性能不能达到设计指标等。
l C级故障：主要功能不稳定或者丧失，但对系统其他功能没有严重影响。
l D级故障：系统的主要和基本功能都已实现，Bug 可以绕过，但功能实现不合理，存在某些界面问题，或者操作不方便，容易引起用户歧义或误操作，对系统功能实现没有大的影响的故障。
l E级故障：说明性，建议性的问题。系统功能、性能、界面、操作等各方面存在的需改进的地方。
2.3 缺陷描述的格式
【四个要素】测试帐号/url、操作步骤、预期结果、时间结果
举例：
2.4 缺陷提案的补充内容
【附加截屏】上传发现bug时的截屏到提案中，上报 Bug 时建议多采用粘贴截图附件的方式来形象呈现发现的缺陷
【附加文件】上传与提案相关的文件到提案中，该文件能够为提案的解决起到帮助作用
3. 缺陷提案的版本维护
提案版本维护由测试负责人，在每轮缺陷评审会议之后，进行操作
3.1 影响版本
影响版本是指，某缺陷的发现版本，至该缺陷验证关闭的所有版本
后期版本维护，不修改提案的影响版本。
3.2 修正版本
修正版本是指，该问题的解决版本。
后期版本维护需修改修正版本：
l 若经三方会议确认，某提案必须在本次项目中解决，则该提案的修正版本在保持原修改版本的基础上，添加新的修正版本。
举例：
此提案原修正版本为：Sina-Space-1.1第一轮系统测试
增加修正版本：Sina-Space-1.1第二轮系统测试
l 若上述提案在第二轮中被重开，则需继续添加修正版本，直到该提案验证通过，关闭为止。
l 若经三方会议确认，某提案可以不在本次项目中解决，则将该提案的修正版本改为“规划中版本”。
4. 缺陷处理原则
4.1 缺陷处理流程
A．
新报的提案，状态为“开放中”。
“已重开”提案，由开发人员处理。
点击【解决提案】
【Bug已修正】已解决此提案描述的Bug。
【Bug无法修正】此提案描述的Bug出于技术原因，无法解决。
【任务达成】完成任务类型的提案。
【是重复的】此提案描述的问题，之前已另有提案阐明，需注释重复的提案号。
【不完整】提案的描述内容不清楚，关键步骤缺失。
【无法再现】提案描述的Bug无法重现。
【Not a Bug】经产品人员确认后，确定提案描述的Bug不是Bug，产品定义就是如此。
【延迟处理】提案由于时间进度、上线等原因，经三方确认后，不在当前解决。
【放弃处理】提案由于技术、时间进度等原因，经三方确定后，放弃处理。
B．
回归测试不通过的提案，状态为“已重开”
“已重开”提案，由开发人员处理。
点击【解决提案】
【Bug已修正】已解决此提案描述的Bug。
【Bug无法修正】此提案描述的Bug出于技术原因，无法解决。
【任务达成】完成任务类型的提案。
【是重复的】此提案描述的问题，之前已另有提案阐明，需注释重复的提案号。
【不完整】提案的描述内容不清楚，关键步骤缺失。
【无法再现】提案描述的Bug无法重现。
【Not a Bug】经产品人员确认后，确定提案描述的Bug不是Bug，产品定义就是如此。
【延迟处理】提案由于时间进度、上线等原因，经三方确认后，不在当前解决。
【放弃处理】提案由于技术、时间进度等原因，经三方确定后，放弃处理。
C．
“已解决”提案，由测试人员处理。
回归验证不通过，点击【重开提案】，按照<4.3 提案注释原则>给予注释。
回归验证通过，点击【关闭提案】，按照<4.3 提案注释原则>给予注释。
4.2 缺陷关闭原则
开发人员不得关闭提案。
提案只能由测试人员关闭。
若发现开发人员关闭提案，应及时沟通，之后予以“重开提案”等操作。
4.3 缺陷注释原则
关闭提案，注释为：XXX第X轮系统测试（之冒烟测试X）验证通过
重开提案，注释为：XXX第X轮系统测试（之冒烟测试X）验证失败，原因XXXXX
缺陷密度
基本的缺陷测量是以每千行代码的缺陷数（个/KLOC）来测量的称为缺陷密度，其测量单位是defects/KLOC。可按照以下步骤来计算一个程序的缺陷密度：
- 累计开发过程中每个阶段发现的缺陷总数
- 统计程序中新开发的和修改的代码行数
- 计算每千行的缺陷数=1000*缺陷总数/代码行数
缺陷数据分析的重要性
- 统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布
- 分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进
- 根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能
- 根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合
缺陷数据分析的数据指标
- 每天/周报告的新缺陷数目
- 每天/周修复的缺陷数
- 累计报告的缺陷数目
- 累计修复的缺陷数
- 不同严重性类型的缺陷数
- 程序模块与发现的缺陷的对应关系
