BUG等级分类参考
bug等级划分
bug等级划分
一、Bug等级划分
严重程度：1-fatal(致命),2-critical（严重）,3-major（一般）,4-Minor（微小）
1-fatal: 系统出现瘫痪、服务中断或数据丢失，非正常返回操作系统、要求重启系统、关键功能缺乏并无法绕道，存在严重稳定性隐患, 重要或常用功能缺乏且不能绕过(10)
实例：【anroid-关于】点击“关于”后，应用闪退
步骤：⑴点击清除图片缓存
⑵点击自定义板块选择
⑶选择一板块-确认
⑷重复步骤1-3
⑸点击关于
实际结果：应用闪退
期望结果：正常进入关于页面
备注：操作步骤一般控制在6步以内
2-citical: 缺陷存在导致系统严重不稳定、数据出现错误用户体验带来极大不便。
（3）3-major 基本功能不能顺利实现，或其他辅助功能缺失。
存在不明确或不完整的错误提示信息。
缺陷的存在对用户产品使用影响较小且大都有绕道方法(1)
4-Minor基本或者辅助功能工作不稳定，缺陷的存在不会导致客户误解的显示或描述性错误，用户通常不易体察到。
(0.5)
5.建议性的问题，可提到级别为4中（目前禅道只有4），提交建议时，最好标明建议
类的字样
二、优先级别p1,p2,p3,p4分别与以上等级对应。
P1:对产品影响非常大，找出产品无法移交
P2:对产品影响比较大，如果发布给用户将会产生麻烦
P3:对产品影响一般，如果bug被解决，产品会更好
P4:对产品影响较小，其他bug解决后，在解决该类bug。
BUG的分类和等级
BUG的分类和等级
一、B UG类型（重点标红的地方）
1、代码错误
2、设计缺陷
3、界面优化
4、性能问题
5、配置相关
6、安装部署
7、安全相关
8、标准规范
9、测试脚本
10、其他划分：功能类、界面类、性能类、易用性类、兼容性类、其他
二、BUG等级
1级bug，必须优先要改
致命错误：
1、常规操作引起的系统崩溃、死机、死循环
2、造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
3、涉及金钱，如支付类软件，金钱计算错误
2级bug
严重错误：
1、重要功能不能实现（例如：微信没有实现语音聊天、朋友圈，等）
2、错误的波及面广，影响到其他重要功能正常实现
3、非常规操作导致的程序崩溃、死机、死循环(非常规操作：用户使用软件时不会进行的操作）
4、外观难以接受的缺陷（例如：直播平台的封面图片的失真、压缩，完全变形）
5、密码明文显示
3级bug
一般错误：
不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷
1、次要功能不能正常实现
2、操作界面错误（包括数据窗口内列名的定义，含义不一致）
例如：列名与列名下的内容不一致
3、查询错误、数据错误显示
4、简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可由前端判断）
5、删除操作未给出提示
4级bug
程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误
1、界面不规范
2、辅助说明描述不清楚
3、提示窗口文字未采用行业术语
4、界面存在文字错误
5、改进意见：可以提高产品质量的建议，包括新需求和对需求的改进。
Bug严重程度分类
系统存在较严重的安全隐患和性能问题；
系统易用性较差；
系统描述易引起较严重的误会或较严重的影响；
系统的某些功能没有实现而引起后续次要功能不能继续进行； 系统的次要功能没有实现；
由于设计的缺陷，导致软件使用中存在较明显的障碍，或者局 部功能错误，但可以采取其他变通的操作实现。
系统存在严重的安全隐患和性能问题；
系统易用性很差；
系统描述易引起严重的误会或带来严重的影响；
系统的某些功能没有实现而引起后续主要功能不能继续进行； 软件规范严重不合理等。
2级：尽快修改
B类：较严重
指造成系统功能严重破坏或崩溃的，复位或重灌系统可以继续 运行；
严重地影响系统要求或基本功能的实现，且没有更正办法（重 新安或重新启动该软件不属于更正办法）；
3级：正常修改
C类：一般
指造成系统功能失效、会引起操作上重大误解的；
严重地影响系统要求或基本功能的实现，但存在合理的更正办 法（重新安装或重新启动该软件不属于更正办法）；
系统性能或响应时间变慢、产生错误的中间结果但不影响最终 结果等影响有限的问题；
由于编码不够完善，使某个小功能无法使用，或者对特殊的操 作与要求不能支持
存在隐含的安全漏洞，可以利用快捷方式、成批处理，以及权
限的组合应用中的安全漏洞进行未经授权的操作。
4级：稍后修改
D类：轻微
指系统功能在设计和开发中由于考虑不周所引起的问题，即可 能会造成系统在使用中会岀错的隐患或造成使用中会产生歧义 的；
使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要 功能；
BUG等级划分标准
B U G等级划分标准 Prepared on 22 November 2020BUG等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。
功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。
3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。
测试BUG等级划分标准
测试BUG等级划分标准
BUG类型缺陷
S级bug，优先级最高
致命缺陷：
1、代码存在巨大缺陷（代码结构有巨大问题）
2、数据库存在巨大隐患（如恶意攻击造成的账户私密信息泄露）
3、充值存在问题（如金钱计算错误、充值不到账）
4、具体功能未实现
5、系统不稳定等（如常规操作会引发系统崩溃、死机、死循环）
A级bug，优先级次高
严重缺陷：
1、重要功能未实现（例如：更新的功能为实现，功能设计与需求严重不符）
2、功能操作影响多个其他功能
3、代码有错误（非常规操作会导致的崩溃、死机、死循环等）
4、UI界面存在影响功能实现的问题（封面图片的失真、压缩、完全变形等）
5、前端的安全问题等（密码明文显示等）
B级bug，优先级一般
一般缺陷：
1、次要功能不能正常实现
2、操作UI显示错误（增删改查等）
3、部分操作未给出提示（例如：删除、修改等）
4、UI兼容性问题等
建议修改类型缺陷
优化建议，优先级最低（建议修改）
程序在一些显示上不美观，不符合用户习惯，用户体验不佳或者是一些文字的错误
1、界面格数等不规范
2、辅助说明描述不清楚
3、提示窗口文字未采用行业术语
4、界面存在文字错误等等
需求
测试过程中发现的一些为实现功能，但不属于本次版本内容，下个版本增加的内容，缺陷记录为：需求。
bug缺陷等级划分
引言编写的目的为了规范测试等级的评定标准，使软件测试规范化、标准化、统一开发人员和测试人员对bug等级评定的认知标准，特拟定《软件测试bug等级评定规范》预期读者本文档预期读者为经理、开发人员、测试人员，以便能尽快熟悉bug等级评定标准，属于公司内部文档使用范围本文档试用于公司各个软件系统的文档测试、功能测试、安全性测试、性能测试等评定规范bug等级标准依据产生错误对客户使用造成的后果严重性将抽测出的问题按五个等级划分，即（A类、B 类、C类、D类、E类）分级方法及简要说明A类：致命缺陷1、数据库发生死锁，致使用户无法登录系统或已登录用户无法运行正常的操作；（例：IE浏览器无响应、IE浏览器自动关闭）2、死循环，导致程序无法运行3、由于程序所引起的系统无法启动、死机、蓝屏、非法退出4、在数据或安全方面存在重大问题，导致软件不具可用性，或核心功能项无法使用；5、由于设计的缺陷，导致软件使用过程中出现内存不足、死机、重启、系统崩溃或软件使用过程中存在较明显的障碍，局部功能错误等；B类：严重缺陷（严重错误）1、数据操作未对数据生效；生效后影响其他正常数据（数据冗余）；出现错误或没有对事物进行回滚；数据计算、数据约束、数据输入、数据输出错误、数据丢失；（例：边界值、特殊字符、数据乱码、数据库表中有过多的空字段）2、程序设计中未考虑到安全问题，正式上线后将造成系统、数据安全隐患；（例：1、输入url可以查看到系统根目录；2、地址存在跨站点脚本编制的安全隐患；3、存在sql注入造成的安全隐患；4、系统存在重复用户登录；5、存在Xpath注入的安全隐患；6、信息泄露；7、系统未实现session验证功能）3、功能错误、功能输入非预期结果、功能遗漏、功能冗余、系统功能没有满足需求说明书的要求；4、页面没有刷新功能5、页面出现500、400、404等错误或页面抛出异常（例：页面显示sql语句异常）6、连接页面错误；（例：页面跳转错误、死连接）7、流程上的逻辑错误（例：流程控制不符合要求；流程实现不完整）8、系统运行速度缓慢；（例：根据2-8原则，运行速度缓慢，等待时间过长）；9、查询错误，规定的查询条件不能得到预期结果，开始日期晚于结束日期可查询10、页面出现脚本错误提示信息，影响正常功能实现11、排序错误，按照排序条件后没有得到预期的结果；12、附近上传、下载内容及名称不一致13、页面改变字体大小功能没有实现14、图片显示错误、按钮。
(完整版)BUG 等级划分标准
BUG等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。
功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。
3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。
4、已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。
bug等级划分
一、致命（一级bug）
通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。
比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。
二、严重（二级bug）
通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。
三、一般（三级bug）
通常表现为：界面、性能缺陷。
比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。
四、提示（四级bug）
通常表现为：易用性及建议性问题
比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
BUG 等级分类参考
一．ＢＵＧ等级分类
1.崩溃：阻碍开发、测试工作；造成系统崩溃、死机、数据丢失；主要功能、基本模块丢失、一级菜单不能使用；
2.严重：功能设计与需求严重不符；数据数值计算出错；程序接口调用出错；
3.一般：功能未实现但不影响使用；操作时间较长；数据库表字段过多；页面样式（如错别字、界面格式不规范、页面显示重叠、不该显示未隐藏、描述不清楚、提示语丢失、文字排列不整齐、光标位置不正确）
4.次要：页面建议性问题不影响正常使用；用户体验感觉不好；
(注：对应禅道类型严重程度1.2.3.4)
二．ＢＵＧ状态
1.待处理：测试人员与网站使用人员发现问题提交的状态。
2.已确认：由开发人员确认。
（此步可省略）
3.已处理：经测试人员与开发人员讨论确认ＢＵＧ，修改后未验证。
由开发人员来设置。
4.已修改：测试人员验证ＢＵＧ已修改。
由测试人员来设置。
（在禅道关闭ＢＵＧ）
5.仍存在：测试人员验证ＢＵＧ修改不通过。
由测试人员来设置。
（在禅道激活ＢＵＧ）
6.暂不处理：当前版本不作修改，后续版本再作处理。
由测试人员与开发人员讨论后设置。
三．ＢＵＧ处理流程 验证ＢＵＧ是
否解决（测试）
指定ＢＵＧ修改人
员（开发）
分配ＢＵＧ修
改人员（开发）
当前版本是否
解决（开发） 提出ＢＵＧ（测试）
汇总ＢＵＧ（总监） 否
是
是
否。