客户端BUG优先级的定义

Posted 2020-11-14 testor

　　前言：经常将BUG优先级，BUG等级，BUG分类 搞混淆，作为一名测试人员，简直惭愧惭愧，今天抽时间整理一下，方便以后使用，毕竟经验是需要是时间和实践的，在此之前莫过于好笔头了。

　　Priority： 所提交的bug应该被修复的优先级；通俗点说：就是测试出来的BUG，哪个更重要就去改哪个。

　　Priority共分为4级，P0、P1、P2、P3  重要程度：P0>P1>P2>P3   P1&P3是在上线前必须修复的，详细说明如下：

　　P=0表示：主功能（核心）的大部分BUG，比如该实现的没有实现，或者实现和需求差异非常大，或者这个bug修复后会导致相关的功能全部都要回归；

　　P=1表示：发生在一些重点模块或者block了少部分case的bug；

　　P=2表示：其基本上不会对其他case产生block或者修复不会影响其他功能的bug；

　　P=3表示：一些可修可不修的bug。

　　BUG优先级细化定义

　　P0定义：完全不能满足产品要求，基本功能明显未实现或完全不可用。产品发布后，出现此类问题，将导致产品必须下线或发小版本修复。

　　<一> 性能及稳定性

　　1. 严重crash, 闪退，黑屏, ANR(Application Not Responding)，无法启动

　　2. 严重性能问题: CPU长期占用不释放(后台服务死循环); 后台或杀死进程后, 依然占用系统资源

　　3. 严重流量问题: 请求过大/不断重复请求(偷跑流量问题)

　　4. 页面FPS(每秒传输帧数)低, 不可忍受的卡顿(反射出内存问题)

　　5. 首页启动/页面加载/图片加载/退出页面时间超过3s或明显可感知的变慢

　　<二>数据错误

　　1. 用户信息丢失或错误，如升级及覆盖安装后数据异常

　　2. 核心数据

　　3. 影响结算的金额错误

　　<三>功能和视觉

　　1. 核心功能实现错误或未实现

　　2. 严重视觉问题: 核心页面

　　3. 页面明显bug且严重影响用户使用(元素不可点、核心页面错乱)

　　4. 操作系统兼容性问题导致的核心功能异常/Crash等

　　<四>其他

　　1. 严重线上问题并且影响用户使用, 或大量用户反馈

　　2. 严重编码规范及CR问题修复, RD提交测试代码

　　3. BOSS发现的问题/影响外卖形象的问题

　　P1定义：产品的功能实现和需求不符合，没有达到预期的效果，或是性能问题、安全性问题。产品出现此类问题，可能会导致用户投诉，或者转入竞争对手的产品。

　　<一>性能及稳定性

　　1. 复现概率极低的闪退、crash、ANR

　　2. 严重性能问题: 内存使用过多且没有正常回收; listview等控件没有重用导致GC严重;

　　3. 严重流量问题: 异常请求数据或者多次重复请求数据导致流量损耗

　　4. UE大尺寸切图带来的内存增长

　　<二> 功能及视觉

　　1. 主要模块的主要使用路径上的bug，非核心流程，不block测试或仅block少量case

　　2. 次要功能实现错误，或未实现

　　3. 严重视觉问题: 非核心页面, 但是用户体验很差

　　4. 操作系统兼容性问题导致的次要功能异常

　　P2定义：比较小的功能、UI或交互问题，用户可以绕过此类问题来使用产品。出现此类问题，用户可能会抱怨，但是并不一定导致用户流失。经常可能是界面布局有问题、用户不常使用的情景发现的问题。

　　<一> 性能及稳定性

　　1. 复现概率极低的闪退，且无crash日志.

　　2. 占比率极低的非主流系统兼容性闪退.

　　<二> 功能及视觉

　　1. 非常规操作或非常规路径、如多步复合操作后才能复现的问题（用户一般不这样操作）

　　2. 异常情况处理缺失，如断网、弱网、中断操作(电话中断、后台前台切换)

　　3. 视觉效果与UE设计不完全一致

　　4. 文案过长被遮盖、未截断或未折行

　　5. 交互体验类bug: 与系统交互或常人认知不符的交互问题

　　6. UI兼容性/适配问题

　　<三>其他

　　1. 安全保护代码: 参数检查, 判空，数组越界保护, 类型溢出

　　P3定义：极少众机型适配问题，建议类bug，可修可不修，修了最好，不修不影响发版.
?      如果有任何疑问，欢迎添加qq群测试入门到大神 755431660 共同学习~
?