6 新媒传信_手机客户端开发部_规范和指南_缺陷分级与处理规范1.0.doc

缺陷分级与处理规范 目录 1 编写目的 3 2 名词解释 3 3 Bug Serverity分级标准 3 4 Bug Priority分级标准 4 5 BUG处理时间的约束 4 6 REOPEN的限制 5 编写目的 规范Bug分级标准，及时解决和反馈bug处理情况。 名词解释 Reopen 为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。 Bug严重级(Serverity) 指缺陷的严重程度 Bug优先级(Priority) 指缺陷必须被修复的紧急程度。 核心功能： 基本的正常操作场景下的功能点 非核心功能 扩展的异常操作场景下的功能点 Bug Serverity分级标准 Low 【准则3-1-1】不影响功能的、有关易用性以及UI细节方面的bug 菜单、提示信息、标题等文字描述、文字排版信息错误 UI界面布局、图标显示等错误 Medium 【准则3-2-1】非核心功能的问题，且复现率较低（10%） 【准则3-2-2】边界条件下错误(添加好友，上限为200，添加201个以后系统没有提示任何信息) High 【准则3-3-1】核心功能问题，非常规业务逻辑 【准则3-3-2】非核心功能，业务逻辑、功能性错误 【准则3-3-3】影响用户体验的性能问题 【准则3-3-4】菜单、提示信息等缺失 【准则3-3-5】复现率低（10%）的Very high 或 Urgent问题 Very High 【准则3-4-1】功能模块缺失 【准则3-4-2】核心功能问题，正常业务流程相关 【准则3-4-3】严重影响用户体验的性能问题 【准则3-4-4】用户数据受到破坏(例如：找不到聊天记录) Urgent 【准则3-4-5】导致程序崩溃、抛出异常 【准则3-4-6】导致手机死机、程序挂起 【准则3-4-7】重要功能模块缺失 【准则3-4-8】影响可测性的严重性能Bug（登录时间较长、好友列表不显示） Bug Priority分级标准 Low 【准则4-1-1】可以在发布的版本中存在的问题 Medium 【准则4-2-1】如果时间允许应该修复的问题 High 【准则4-3-1】在产品发布之前必须修复的问题 Very High 【准则4-4-1】每个里程碑结束前必须修正的Bug Urgent 【准则4-5-1】应立即修复的Bug： BUG处理时间的约束 Bug优先级及处理时间 BUG优先级 处理时间 Urgent Very High 【规范 5-1-1】2个工作日内解决；2个工作日内不能解决的Bug，需给出处理意见或反馈，而且在fix之前在TD-Comments每天更新进展 High 【规范 5-1-2】3个工作日内解决，3个工作日内不能解决的Bug，需给出处理意见或反馈 High以下 【规范 5-1-3】5个工作日内解决，5个工作日内不能解决的Bug，需给出处理意见或反馈 注释： 【建议 5-1-4】时间从缺陷提交日算起，对于不进行修改的Bug，需要进行评审，评审干系人包括：产品，开发，测试，项目经理。 【建议 5-1-5】测试人员汇总遗留缺陷，由项目经理负责发起评审会议邀请。 【规范 5-1-6】处理意见及反馈内容直接在TD注释中说明。 【规范 5-1-7】处理意见及反馈的内容格式：n个工作日内未解决的原因、计划问题解决时间、如果不解决给出不解决的原因。 REOPEN的限制 【建议 6-1-1】建议一个Bug最多的Reopen 2次--督促测试和开发在Bug修改时的沟通。 鉴于目前TD库中的Bug 被Reopen的次数比较多，现做如下规定： 【规范 6-1-2】Reopen Bug的处理时间：1个工作日内，需给出处理意见或反馈。 【建议 6-1-3】Reopen2次及2次以上的需单独列出，并给出被多次reopen的原因。 注：对于由于开发人员修改Bug而引发的新问题，测试人员需提交新Bug。 同时质量人员，将在质量状态报告中对Bug的Reopen次数进行抽查。 第1页 缺陷处理规范 共4页 2009.09.10