BUG等级划分标准
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
BUG等级划分方法
一、测试 BUG等级划分标准
1、Blocker (崩溃):阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致
数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。
2、 Critical (严重):系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,
一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。
如:软件中数据保存后数据库中显示错误,用
户所要求的功能缺失,程序接口错误,数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)。
3、 Major (一般):功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响
系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错
误,删除没有确认框、数据库表中字段过多等 ( 该问题实际测试中存在最多,合理安排解决 BUG,解决率关系版本的优化程度 )
4、 Minor (次要):界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化
性能的方案等。如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正
确,用户体验感受不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)
二、BUG状态标准
1、待处理( new):测试人员或用户发现新问题后提交的状态
2、已确认( open):经测试人员及研发人员讨论后确认是BUG,提交的状态,
由测试人员来设置。
3、已处理(fixed ):经研发人员确认是BUG后修复的状态,修改还没有验证,
由开发人员来设置。
4、已修改( closed ):测试人员认为问题已经修改,通过验证,由测试人员
设置。
5、仍存在( reopened):测试人员认为BUG未修复成功,问题仍然存在,由
测试人员设置。
6、不是问题( reject ):研发人员确认不是BUG,或者建议与意见决定不采
纳。
7、暂不处理( hold ):当前版本不做修改,后续版本再考虑,由研发人员或测试人
员设置。
三、BUG处理流程
1、紧急:崩溃、严重 BUG处理流程( 1-2 天内解决)
中断测试工
BUG 提出
作
填写重要 BUG 项目总监审制定 BUG 解不影响其它测试
核签字决的时间
跟踪表
是,结束。测试人员验证研发优先解BUG 分配至研
跟踪表签字BUG 是否解决决 BUG发人员
否
2、优先:一般 BUG处理流程(尽快处理)
BUG提出
汇总缺陷跟
总监审核
分配研发人踪表员
是,结束。
跟踪表签字
测试人员验证
BUG是否解决
合理安排解
决BUG
否
3、普通:次要 BUG处理流程(项目结束前处理)
否,结束建议是否采纳
BUG 提出汇总缺陷跟
总监审核
是,分配研
踪表发人员
当前版本是测试人员验证
否解决
否
BUG 是否解决
否,附加具
体版本时限
是,结束。
跟踪表签字