MANTIS缺陷管理规范.doc

MANTIS缺陷管理规范 TOC \o 1-1 \h \z \u 1、引言 3 2、缺陷管理角色和职责 3 3、缺陷管理流程图 4 4、缺陷管理过程 4 5、缺陷属性和分类方法 5 6、缺陷属性填写原则 7 7、统计报表 7  1、引言 1．1目的 缺陷管理规范说明对产品缺陷的录入、分派、处理、关闭以及统计分析的流程或操作规范。 1．2适用范围 本文档的适用范围为公司所有正在开发、生产和使用的机器、程序或工具中出现的产品缺陷。 使用的工具为Mantis。 2、缺陷管理角色和职责 Bug报告人：反馈使用、生产、测试、设计过程中发现的缺陷。报告人不不限于测试人员。 测试人员：验证缺陷及缺陷解决方案是否合理，并对bug状态进行处理。 修改人：分析缺陷产生原因及提交缺陷修复方案。修改人不限于开发人员。 3、缺陷管理流程图 分发( Assign)开发/PM处理bug开发/PM解决完成(Resolve)开发 分发( Assign) 开发/PM 处理bug 开发/PM 解决完成(Resolve) 开发/PM 验证确认(fixed) 测试 关闭(close) 报告bug( New) 测试/开发/PM 4、缺陷管理过程 4.1 报告bug： 录入bug，报告人不限于测试人员。 4.2 分发bug： 如果是测试部以外人员提交的bug，由测试部负责复现后，确认bug； bug由测试部经理分派，当不能明确分派修改人时，将直接分派给项目经理或部门经理；由项目经理、部门经理再分派给最终修改人。 4.3 处理bug： 修改人员提交bug产生原因及解决办法，如果此缺陷相关多个项目，由修改人员统一提交关联关系，部门经理根据问题重新分派人员。 对于不能解决或暂时不解决的问题，需详细说明原因。 修改人员填写原因及解决办法时要填写在“原因及解决办法”栏目。 4.4 解决完成： 修改人员问题处理后，需修改问题对应的完成度； 4.5 验证确认： 测试人员对bug进行验证，无问题则可以关闭；如果不能确定，则邮件通知部门经理，在发布评审会议上讨论决定。 5、缺陷属性和分类方法 5．1 Bug出现频率： 总是Always：每次尝试都会出现。 有时Sometimes：有时出现。 随机Random ：出现几率较小。 没有试验Have not tried：即发现bug的操作只进行了一次。 无法重现Unable to reproduce：只发现一次，之后的尝试都无法再现。 不适用N/A ：Not Applicable/Acceptable 即再次尝试的时候，出现bug的功能不能用了。 5．2 bug等级 建议Feature Idea：不影响使用，但可以优化。 不合理/别扭Tweak：如： ￥123.345等。 一般错误Minor：不能用上述分类界定的，报告人认为是严重程度比较轻的问题。 严重问题Major：不属于系统崩溃和死锁类的，但报告人认为比较严重的，一般情况为功能缺失。 系统崩溃Crash：引起系统崩溃、死锁的错误。 5．3 Bug优先级 无None：相关的bug已经resolve、不存在了或者觉得优先级没有必要体现。 低Low：低优先级,留到最后解决，如果项目的进度很紧张可以在产品发布以前不解决。 中Normal：中等优先级。 高High：将处于Immediate和Urgent优先级的bug修改完毕后要进行修改。 紧急Urgent：一到两天之内必须进行修改。 特急Immediate：需要立即进行修改。 5．4 bug状态 新建New：报告人报告一个新bug并且没有指派给具体的修改人修改时的状态。 打回Feedback：测试人认为此bug不需要修改，就将其反馈。测试人员和报告人讨论评估后，决定是否将其关闭。 已确认Confirmed：测试人确认存在此bug，将其设为confirmed。 已分派Assigned：将新建bug指派给某个指定的修改人后，状态变为Assigned。 已解决Resolved：测试人员确认bug已经解决。 已关闭Closed：测试人员验证测试后，确认bug已解决，可以关闭，不能确定的，会议决定。 挂起postponed：以下情况可能使用到次状态，问题不能重现，暂时不做修改，问题不能修复。 5．5 bug完成度 未处理Open：bug没有被解决 已修正Fixed：bug的修改已经登记并经过自测试。 重新打开Reopen：bug曾经被解决,但是解决方案被认为不正确，一般有测试人员或项目经理填写。 无法重现Unable to reproduce：无法重现,被指派的修改人员想要再现bug进行修改的时候，发现bug始终不能再现的时候，将bug的resolution设置为此项。 无法修复Not fixable：