Q-YF-QP-5.1-2011缺陷管理子过程.docVIP

文件编号: Q-YF-WI-5.1-2011 密级：□公开使用 ■内部使用 主管部门：产品中心 受控状态：受控文件 缺陷管理子过程 版本号 版本说明/变更理由/变更内容 审批人/日期 备注 0.1 创建文档 袁培茹 1.0 修改为标准格式，添加静态代码及单元测试等级定义 袁培茹/2011-9-27 林雪焰/2011-9-27 1.1 修改缺陷来源、添加优先级、测试类型 袁培茹/2012-1-16 林雪焰/2012-1-16 1.2 修改静态代码测试缺陷等级，分为fortify和checkmarx进行描述，并填写了处理意见。 袁培茹/2013-4-10 侯鹏亮/2013-4-10 1.3 修改缺陷状态处理部分 袁培茹/2014-4-28 侯鹏亮/2013-4-28 变更说明分为四个部分：初始创建；增加内容；修改；删除 目 录 1．目的 3 2．缺陷管理 3 2.1总体流程图 3 2.2活动说明 3 2.2缺陷状态流转说明 4 3．缺陷关键属性 4 3.1缺陷状态 5 3.2缺陷等级 5 3.2.1系统测试缺陷等级 5 3.2.1单元测试缺陷等级 6 3.2.1静态代码测试缺陷等级 6 3.3缺陷来源 6 3.4新缺陷根源 6 3.5无效缺陷原因 6 3.6优先级 7 3.7测试类型 7 1．目的 此文档对缺陷管理和缺陷等级进行了定义，详细说明了缺陷管理的流程和活动、缺陷等级的具体含义，目的在于规范测试和指导测试活动。 2．缺陷管理 本章节对缺陷管理的过程过程进行了介绍，以便指导具体测试工作的进行。 2.1总体流程图 2.2活动说明 活动名称 操作人员 具体活动 提交缺陷 测试人员 发现缺陷后，填写缺陷报告，将缺陷分配给具体的开发人员，对于不清楚缺陷该分配给谁修改的情况，可以分配给项目经理，由项目经理确认，缺陷状态默认为Open。 对于回归测试返现的新问题，需要选择“新缺陷根源”，当选择其他时，需要具体说明。 开发确认缺陷 开发人员 对发现的缺陷进行确认，确认是否为缺陷，对于确认不是缺陷的进行拒绝处理，缺陷状态设置为Reject，并写明拒绝的原因；确认是缺陷的进入进一步确认是否要修复活动。 审批是否为缺陷 技术经理/项目经理 对开发拒绝Reject状态的缺陷，进行审批，审批通过状态不变。审批不通过分为三种情况： 需要马上修复，重新打开缺陷，将缺陷状态处理为Reopen. 暂遗留可以后续版本修改，将缺陷状态处理为Leave 遗留，将缺陷状态处理为Delay。 是否修复 开发人员 对于确认为缺陷的进一步判定是否修复，对于确定不修复将缺陷处理为遗留状态Leave，并写明具体修复版本，对于本发布版本不做修改的缺陷，需要写明建议处理delay状态，选择“缺陷来源”，并写明遗留原因；对于确认要修复的，进入修改活动 审批是否遗留 技术经理/项目经理 对遗留缺陷进行审批，审批通过的意见分为两种： 暂遗留，缺陷状态不变。 本发布版本遗留，将缺陷处理为Delay。 确认“缺陷来源”，缺陷处理流程结束；审批不通过的将缺陷处理为Reopen，进入修复缺陷活动。 修复缺陷 开发人员 对缺陷进行修复，选择“缺陷来源”，填写修复记录，将缺陷处理为Fixed状态 验证和确认缺陷 测试人员 对修复的缺陷进行验证,对于验证通过的填写确认意见，将缺陷处理为Close缺陷处理流程结束；对于确认缺陷还存在的将缺陷处理为Reopen。 2、对对开发拒绝Reject状态的缺陷根据回复的意见进行进一步确认，确认结果是不是缺陷的处理为Nobug，并选择“无效缺陷原因”， 当选择其他时，需要具体说明缺陷处理过程结束；对于确认为缺陷，填写确认说明，状态处理为Reopen. 缺陷仲裁 项目经理/产品负责人、质量管理部经理 对测试和开发存在异议的缺陷（一般为是否为缺陷、是否能够遗留）进行仲裁。 是否为缺陷的仲裁：仲裁结果为是缺陷的，填写仲裁意见，将缺陷处理为Reopen；仲裁结果为不是缺陷的，填写仲裁意见，将缺陷处理为Nobug，缺陷处理过程结束。 是否遗留的仲裁：仲裁结果为遗留，填写仲裁意见，缺陷状态不变；仲裁结果为不能遗留，写仲裁意见，将缺陷处理为Reopen，缺陷处理过程结束。 说明：当测试对象为项目时“仲裁是否为缺陷”和“审批是否遗留”的操作者为项目经理；当测试对象为产品时操作者为产品负责人和质量管理部经理。 2.2缺陷状态流转说明 “绿色”标识为测试人员操作状态 3．缺陷关键属性 3.1缺陷状态 编号 状态 状态操