修改记录
缺陷的定义
软件没有实现需求规格说明书中要求的功能
软件出现了需求规格说明书中指明不要的功能
软件功能超出了需求规格说明书的要求
软件没有达到需求规格说明书虽未指出但应该达到的目标
软件很难理解，不宜使用，速度很慢，或者是最终用户认为不好
缺陷管理的目的
确保已发现的缺陷被及时处理
– 修复缺陷的优先级要高于一般的任务安排
确保已处理的缺陷被及时关闭
– 及时复测，及时关闭
预防缺陷的发生
– 分析缺陷的来源，确定引入缺陷的原因，提出针对性的解决方法
缺陷的作用
体现测试人员的工作成果
提高缺陷的修复率
加快缺陷的修复速度
降低开发与测试之间的沟通成本
方便今后进行数据度量与分析
缺陷的生命周期
缺陷的相关字段说明
参见QC缺陷管理操作手册
当开发人员准备修复缺陷时，建议先把缺陷状态置为“处理中”，等到把程序修改完成后并准备递交给配置管理员时，再把处理结果置为“已经修复”
如果开发人员发现缺陷与以前的重复了，则把处理结果置为重复缺陷，并在“备注”中写明与哪一个缺陷重复
如果开发人员无法重现缺陷，要先找对应的测试人员进行确认，确认后还是无法重现的，则把处理结果置为没有发现。特别的，如果无法重现的缺陷本来就是偶然再现或难以再现的，此时开发人员要认真分析代码，在确认代码无误后才能把处理结果置为没有发现，并且在QC中备注好。
结果为不需解决、无法解决、延期处理的QC，开发人员需要在备注中进行说明。在对应的版本发放前，测试负责人与产品经理/技术经理对相关QC进行评估是否需要进行修复，若的确不需解决、无法解决的，需要产品经理/技术经理在QC中进行备注说明。测试对相关QC才能予以关闭。并且在测试报告中需要列入遗留缺陷清单/风险项中。
对于延期处理的QC，存在两种情况：
开发修复缺陷的流程和要求
1. 此版本不修复，安排在下一版本/主版本修复的，则要备注好具体原因，然后联系测试负责人，在对于修复的版本上复制一份QC，然后将暂不解决版本上的QC进行关闭。
2. 缺陷需要转需求进行跟踪处理的，结果可以置为延期处理，经产品经理/技术经理在QC上备注好对应的需求编号。然后测试负责人可以将对应的QC进行关闭。
开发修复BUG时注意事项
如果开发人员觉得缺陷记录填写不够清楚或者不够准确，请及时与测试人员进行沟通，也可以向测试主管反馈。
开发人员认为不是缺陷或者无法解决时，要向开发主管提出来，由开发主管来判断和决定。如果开发人员仅仅对缺陷备注一下自己的意见，然后就不管了，会导致此缺陷被遗忘在那里，迟迟得不到最终的处理。
QC责任人界定问题
可以定位到引入QC的开发责任人，程序员和责任人均填写对应人员即可（如脚本问题）；
无法定位到引入QC的开发责任人，默认提给对应的模块负责人；
如果是修改表结构导致历史脚本执行报错的，责任人一律提给修改表结构的开发人员，由该开发人员统一进行排查是否还存在其他遗漏的问题。（修改表结构时就要做好排查和自测工作）
开发对历史遗留缺陷分析规范要求
对于测试主管与开发主管指定要进行遗漏分析的缺陷需要开发人员认真分析，找出导致此缺陷的原因、引入版本，并正大填写开发遗漏分析到QC中。
开发改进措施必须是可落实跟踪的措施，不能是“加强…”“多细心”等
分析缺陷
版本发布后，技术经理和测试经理等组织相关人员对缺陷进行分析，确定每一个缺陷的来源，进行归因分析，然后找出针对性的解决办法，预防类似缺陷的再次出现
修改记录
缺陷的定义
软件没有实现需求规格说明书中要求的功能
软件出现了需求规格说明书中指明不要的功能
软件功能超出了需求规格说明书的要求
软件没有达到需求规格说明书虽未指出但应该达到的目标
软件很难理解，不宜使用，速度很慢，或者是最终用户认为不好
缺陷管理的目的
确保已发现的缺陷被及时处理
– 修复缺陷的优先级要高于一般的任务安排
确保已处理的缺陷被及时关闭
– 及时复测，及时关闭
预防缺陷的发生
– 分析缺陷的来源，确定引入缺陷的原因，提出针对性的解决方法
缺陷的作用
体现测试人员的工作成果
提高缺陷的修复率
加快缺陷的修复速度
降低开发与测试之间的沟通成本
方便今后进行数据度量与分析
缺陷的生命周期
缺陷的相关字段说明
参见QC缺陷管理操作手册
当开发人员准备修复缺陷时，建议先把缺陷状态置为“处理中”，等到把程序修改完成后并准备递交给配置管理员时，再把处理结果置为“已经修复”
如果开发人员发现缺陷与以前的重复了，则把处理结果置为重复缺陷，并在“备注”中写明与哪一个缺陷重复
如果开发人员无法重现缺陷，要先找对应的测试人员进行确认，确认后还是无法重现的，则把处理结果置为没有发现。特别的，如果无法重现的缺陷本来就是偶然再现或难以再现的，此时开发人员要认真分析代码，在确认代码无误后才能把处理结果置为没有发现，并且在QC中备注好。
结果为不需解决、无法解决、延期处理的QC，开发人员需要在备注中进行说明。在对应的版本发放前，测试负责人与产品经理/技术经理对相关QC进行评估是否需要进行修复，若的确不需解决、无法解决的，需要产品经理/技术经理在QC中进行备注说明。测试对相关QC才能予以关闭。并且在测试报告中需要列入遗留缺陷清单/风险项中。
对于延期处理的QC，存在两种情况：
开发修复缺陷的流程和要求
1. 此版本不修复，安排在下一版本/主版本修复的，则要备注好具体原因，然后联系测试负责人，在对于修复的版本上复制一份QC，然后将暂不解决版本上的QC进行关闭。
2. 缺陷需要转需求进行跟踪处理的，结果可以置为延期处理，经产品经理/技术经理在QC上备注好对应的需求编号。然后测试负责人可以将对应的QC进行关闭。
开发修复BUG时注意事项
如果开发人员觉得缺陷记录填写不够清楚或者不够准确，请及时与测试人员进行沟通，也可以向测试主管反馈。
开发人员认为不是缺陷或者无法解决时，要向开发主管提出来，由开发主管来判断和决定。如果开发人员仅仅对缺陷备注一下自己的意见，然后就不管了，会导致此缺陷被遗忘在那里，迟迟得不到最终的处理。
QC责任人界定问题
可以定位到引入QC的开发责任人，程序员和责任人均填写对应人员即可（如脚本问题）；
无法定位到引入QC的开发责任人，默认提给对应的模块负责人；
如果是修改表结构导致历史脚本执行报错的，责任人一律提给修改表结构的开发人员，由该开发人员统一进行排查是否还存在其他遗漏的问题。（修改表结构时就要做好排查和自测工作）
开发对历史遗留缺陷分析规范要求
对于测试主管与开发主管指定要进行遗漏分析的缺陷需要开发人员认真分析，找出导致此缺陷的原因、引入版本，并正大填写开发遗漏分析到QC中。
开发改进措施必须是可落实跟踪的措施，不能是“加强…”“多细心”等
分析缺陷
版本发布后，技术经理和测试经理等组织相关人员对缺陷进行分析，确定每一个缺陷的来源，进行归因分析，然后找出针对性的解决办法，预防类似缺陷的再次出现
QC与修改单的测试结果问题
● 测修改单时，发现模块相关的问题，记录QC的，若测试人员可以判定是对应开发在该修改单引入的，修改单测试结果直接置为N，QC任务编号中填写对应的任务编号/修改单编号
● 若无法定位是否为该开发在该修改单引入的，但是在修改单涉及模块中发现的，QC默认提给对应的开发人员，修改单结果默认置为N，除非开发人员提出异议，可以具体问题具 体分析，是否需要调整修改单测试结果。
● 若实在无法判断的，直接和测试主管反馈，协助判断。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
