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

  1. 1、本文档共8页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
Q-YF-QP-5.1-2011缺陷管理子过程

文件编号: 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缺陷状态 编号 状态 状态操

文档评论(0)

有一二三 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档