选择软件测试纯属一个意外，这个意外对我来说不悲不喜，既然已经开始了，那就持续的做下去吧。
原创缺陷管理过程分享，带流程图
上一篇 / 下一篇 2011-12-15 15:15:46 / 个人分类：每日记录
一、缺陷定义
缺陷：与需求文档不一致或系统本身出现的报错均视为缺陷。
二、缺陷类型和状态
Open(新建)
缺陷：与需求文档不一致或系统本身出现的报错均视为缺陷。
二、缺陷类型和状态
Open(新建)
- 实现效果与需求要求效果不一致或者系统本身报错，测试工程师则可选择Open；
- 开发工程师将一个已知的缺陷修改成功并自测效果正确后方可选择Resolved-Fix；
- 开发组长将一个已知缺陷分配给开发工程师或开发工程师自己领取修改这个问题，可以选择Distribution；
- 缺陷评审会中确定的，由产品经理、开发工程师、测试工程师三方统一确认可以延迟的缺陷，则标记为Delay；
- 技术上无法实现或者环境异常造成的非缺陷，开发工程师可以选择拒绝并将缺陷状态修改为Refused；
- 开发工程师在修复缺陷过程中，遇到的无法重新出现的问题，可以选择标记为Disappearred；
- 开发工程师标记Resolved -Fix的缺陷重复出现则需要Reopen；
- 开发工程师标记为Disappearred但测试人员重现缺陷的需要Reopen；
- 未经过开发工程师、测试工程师、产品经理三方共同确认的缺陷，如果标记为Delay，测试工程师需将缺陷Reopen；
- 开发工程师可以进行修复的，但标记为Refuse的缺陷，则测试工程师需将缺陷Reopen；
- 开发工程师标记为Resolved -Fix的缺陷，经过测试工程师测试，确认无误且没有其他问题的则可以标记Confirmed；
- 开发工程师标记为Disappearred的缺陷，经过测试工程师测试，确认无法重现则可以标记Confirmed；
- 开发工程师标记为Refuse的缺陷，经过测试工程师测试，确认不是缺陷则可以标记Confirmed；
- 产品上线前的最后一次测试中，测试工程师需将所有已经标记为confirmed的缺陷进行校验关闭，如果问题仍然存在，则需要Reopen；如果验证通过，则将缺陷标记为Close。
四、缺陷维护—评审会形式
缺陷评审会说明
缺陷评审会说明
- 每月每项目进行一次缺陷评审会，没有更新的项目，可进行邮件评审；按照以上标准执行，以保证缺陷更新及产品质量。
- 评审通知：评审通知需要提前2个工作日发送，收件人应当包含项目组相关的产品经理、开发、测试、运营。
- 评审内容：必须包含以下5种缺陷的合集：Open、Reopen、Delay、Refused、Disappearred
- 评审纪要：需包含时间、地点、参会人员以及缺陷变动情况
TAG:
