BUG分类标准和考核办法

BUG等级划分标准

B U G等级划分标准标准化工作室编码[XX968T-XX89628-XJ668-XT689N]B U G等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。

功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。

3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。

bug等级和标准（转）

致命程序无法正常运行或程序无法跑通无法正常启动异常退出crash资源不足死循环崩或严重资源不足等
bug等级和标准（转）
来源：网络一级bug：致命程序无法正常运行或程序无法跑通-无法正常启动、异常退出、crash、资源不足、死循环、崩溃或严重资源不足等二级bug：严重核心功能无法完成、功能报错、数据错误等，但不会影响程序运行三级bug：缺陷一般功能性Bug，产品中的不符合产品需求或用户使用的缺陷四级bug：瑕疵操作不方便，布局不合理等一类的易用性相关的缺陷五级bug：建议对产品的改进优化型建议

bug分级管理制度

bug分级管理制度随着软件产品的复杂度和功能的不断增加，软件开发过程中出现Bug已经成为一种常态。

对于软件开发团队来说，如何有效地管理Bug，快速定位和解决Bug，是提高软件质量和用户体验的关键。

因此，建立一个科学有效的Bug分级管理制度至关重要。

2. 目的和意义Bug分级管理制度的目的主要包括：(1) 有效区分Bug的优先级，保证高优先级Bug得到及时处理；(2) 提高Bug解决效率，减少因为Bug而引起的软件发布延迟；(3) 帮助开发团队更好地了解软件中存在的问题，为后续版本的优化改进提供参考。

3. 制度内容Bug分级管理制度主要包括Bug的分级标准、Bug的处理流程和Bug的跟踪和反馈机制。

1) Bug的分级标准Bug的分级标准主要包括Bug的优先级和严重程度两个方面。

一般来说，Bug的优先级可以分为4个等级：紧急（Critical）、高（High）、中（Medium）和低（Low）；Bug的严重程度可以分为5个等级：致命（Fatal）、严重（Serious）、一般（Normal）、轻微（Minor）和建议（Suggestion）。

根据不同的Bug的影响范围、影响程度和解决的难易程度，将Bug分为不同的优先级和严重程度，并制定相应的处理标准。

2) Bug的处理流程Bug的处理流程包括Bug的提交、审核、跟踪、解决和验证等环节。

具体流程如下：a. Bug的提交：Bug可以由开发人员、测试人员或用户提交，需要填写Bug报告，包括Bug的描述、复现步骤、截图等信息，并指定Bug的优先级和严重程度。

b. Bug的审核：Bug报告会交由Bug管理员或项目经理审核，确认Bug是否有效。

若Bug 无效，则关闭；若Bug有效，则分配给相应的开发人员处理。

c. Bug的跟踪：开发人员接受Bug后，需要及时跟进Bug的处理进度，并更新Bug的状态和解决情况。

d. Bug的解决：开发人员需要按照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标准文库1.目的对BUG类型划分、BUG 状态、BUG 严重程度、BUG优先级别等内容进行定义和规范，以便进一步指导我们的软件测试工作。

2.BUG 的类型划分类型名称类型描述功能类1.重复的功能2.多余的功能3.功能实现与设计要求不相符4.功能使用性、方便性、易用性不够界面类1.界面不美观2.控件排列、格式不统一3.焦点控制不合理或不全面数据类1.数据有效性检测不合理2.数据来源不正确3.数据处理过程不正确4.数据处理结果不正确流程类1.流程控制不符和要求2.流程实现不完整信息类1.提示信息重复或出现时机不合理2.提示信息格式不符和要求3.提示框返回后焦点停留位置不合理建议类1.功能性建议2.操作建议3.校检建议4.说明建议性能类1.并发量2.数据量3.压缩率4.响应时间安全类1.安全性漏洞2.系统漏洞常识类 1.违背正常习俗习惯的，比如日期/ 节日等特殊类 1.不符合OEM 版本或DEMO 版本特殊要求的3.Bug状态：指缺陷通过一个跟踪修复过程的进展情况状态名称状态描述新建为测试人员新问题提交所标志的状态。

已分配当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“已分配打开的一旦开发人员开始处理bug的时候，他（她）就将这个bug 的状态设置为“打开的”，这表示开发人员正在处理这个“bug”已修复为开发人员修改问题后所标志的状态，修改后还未测试。

再测试测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“再测试”已拒绝开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。

由Bug分配人或者开发人员来设置。

已关闭为测试人员对修改问题进行验证后通过所标志的状态。

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分类标准和考核办法V0.12010年7月一、背景随着公司不断得发展壮大，原来小作坊式的软件开发模式也经历着转变，产品质量亟待加强。

公司已做出了规划，明确了测试岗位和职责。

为了更好的落实测试岗位的职责，规范测试结果的管理和考核，提升公司产品质量，特制定测试BUG分类标准和考核办法，使得公司对研发测试结果有个明确的评估。

二、BUG分类标准测试BUG按照严重等级分为严重、普通、轻微、优化四类，按照BUG类别分为功能、界面、数据处理、流程、优化建议、性能、常识七类，对应各种BUG情形如下：（1）严重BUG情形：（1）由于程序造成系统崩溃、自身程序崩溃、网络中断、系统内存或文件资源耗尽、破坏或丢失数据库数据（2）功能类：需求功能未达到或与需求功能明显不一致的（3）数据类：数据处理造成后台数据冲突或不一致的（4）数据类：程序运行过程中出现数据丢失的或后台数据乱码的（5）流程类：分支流程不完整或相悖造成分支流程处理错误的；无限循环类的（6）性能类：造成数据库连接资源耗尽的（非大并发量下的情形）（2）普通BUG情形：（1）功能类：查看、查询、分页、排序显示数据不正常的（2）界面类：页面编译错误、JavaScript错误、跳转错误、出现javaException页面（3）界面类：页面超时未响应、数据显示不完整或错位、页面未鉴权、页面显示乱码（4）界面类：输入校验不完整及造成的数据处理错误、页面操作提示信息与实际不符（5）性能类：处理大数据量出现程序错误的（6）常识类：明显违背正常习俗习惯的（3）轻微BUG情形：（1）功能类：重复或多余的功能，操作不直观、易用性不够（2）界面类：界面排版混乱、控件排列和格式不统一、焦点控制不合理、页面文字和提示信息表达不清晰、不完整或错别字的（4）优化BUG情形：凡以上未提及的不影响正常使用的情形。

三、BUG考核办法BUG考核遵循简单务实原则，规定如下：一个严重BUG扣除当月绩效项目完成质量项2分一个普通BUG扣除当月绩效项目完成质量项1分一个轻微BUG扣费当月绩效项目完成质量项0.5分优化BUG不扣分附：（1）绩效考核表中项目完成质量项的分值不能低于20分（2）每月最多扣除项目完成质量分20分（3）当一个BUG不在以上定义范围内时，若影响用户正常使用则视为轻微BUG，若不影响用户正常使用则视为优化BUG （4）由于测试项目一般由项目组协作开发完成，因此项目测试汇总的BUG对应的各项目成员的扣分，应由该项目的项目经理执行，质量管理人员负责监督执行。

软件测试工程师考核标准

软件测试工程师考核标准在系统运行中出现错误导致应用程序崩溃的Bug。

这类Bug会影响系统的正常使用，但是可以通过重启应用程序来恢复正常。

比如，应用程序无响应、应用程序崩溃等。

考核权数：0.5Ø三级Bug（功能缺陷）在系统运行中出现的功能缺陷，影响了系统的正常使用，但是可以通过其他方式绕过或者使用其他功能来解决。

比如，某些功能无法使用、功能不完整、功能错误等。

考核权数：0.3Ø四级Bug（界面缺陷）在系统运行中出现的界面缺陷，影响了系统的美观度或者易用性，但是不影响系统的正常使用。

比如，界面样式不美观、界面操作不方便等。

考核权数：0.1所有Bug的总分=（一级Bug数量×0.8）+（二级Bug数量×0.5）+（三级Bug数量×0.3）+（四级Bug数量×0.1）4、测试执行的质量测试执行的质量是测试工程师能力的直接体现，测试执行的好坏将直接影响到测试结果的可靠性，测试执行的考核将从测试用例执行情况、测试结果的准确性、测试执行过程中的问题处理能力等方面来评价。

测试执行的考核权数为0.3测试执行总分=测试用例执行情况×0.1+测试结果的准确性×0.1+问题处理能力×0.15、个人能力的考核除了以上四个方面的考核之外，我们还将根据测试工程师的个人能力来进行考核，主要考核方面包括：研究能力、沟通能力、团队合作能力、自我驱动能力等。

个人能力的考核权数为0.1个人能力总分=研究能力×0.025+沟通能力×0.025+团队合作能力×0.025+自我驱动能力×0.025为了更科学、更合理地考核部门测试工程师，我们制定了以上几个指标，并对其进行了权重分配。

每个测试工程师的最终得分将由以上五个指标的得分相加得出。

同时，我们将对测试工程师的得分进行排名，以此来评价测试工程师的工作表现。

我们相信，通过这样的考核方式，可以更好地评价测试工程师的工作能力，提高部门测试工作的质量和效率。

(完整版)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单定级标准在软件开发过程中，Bug单是用于记录和追踪软件缺陷的重要工具。

为了有效地管理和解决Bug，Bug单的定级标准非常重要。

下面是一些常见的Bug单定级标准的参考内容，以帮助团队制定适合自己项目的标准。

1. 严重程度：- 致命（Critical）：该Bug会导致系统崩溃或无法正常运行，无法绕过或忽视此问题。

- 严重（Major）：该Bug会导致系统某些重要功能无法正常使用，但该功能可以通过其他方式绕过。

- 一般（Normal）：该Bug会导致系统的某些功能受限，但整体上不会影响系统的主要功能。

- 轻微（Minor）：该Bug只会对系统的一些辅助功能产生轻微影响，对系统的核心功能没有明显影响。

2. 优先级：- 高（High）：该Bug对用户体验产生严重影响或系统功能无法正常运行，需要优先处理。

- 中（Medium）：该Bug会对用户体验产生一定程度的影响，但功能仍然可以正常使用，需在合理的时间内处理。

- 低（Low）：该Bug对系统功能无影响或只产生轻微影响，可以在后续版本中修复。

3. 影响范围：- 用户范围（User Impact）：该Bug对用户体验直接造成的影响程度。

- 功能范围（Function Impact）：该Bug对系统功能的影响程度。

- 代码范围（Code Impact）：该Bug对代码的影响程度，是否需要修改核心逻辑或大量重构。

4. 复现频率：- 必现（Always）：该Bug每次操作都能必现，非常容易复现。

- 偶现（Intermittent）：该Bug不是每次操作都能复现，需要特殊条件或概率性事件触发。

- 很难复现（Difficult）：该Bug非常难以复现，需要特殊环境或条件，因此难以调试和解决。

5. 解决时间：- 紧急（Immediate）：该Bug需要立即解决，不能等待下一个版本发布。

- 优先（High）：该Bug需要在下一个版本发布前解决。

- 正常（Normal）：该Bug需要在有限的时间内解决。

测试bug等级划分标准

测试bug等级划分标准嘿，Bug 也有“江湖等级”，你知道吗？嘿，你知道吗？在神秘的代码世界里，就像仙侠世界有不同的修仙等级一样，测试中出现的 Bug 也有它们自己的“等级江湖”！要是搞不清这些等级，那开发人员在修复 Bug 的路上就像盲人摸象，找不到重点还干着急！**一、“小喽啰”级 Bug：不疼不痒的小麻烦**“在 Bug 的江湖里，‘小喽啰’级 Bug 就像偶尔飞过的小蚊子，虽然烦人但不至于要命！”这类 Bug 通常表现为一些界面上的小瑕疵，比如字体大小不一致、颜色搭配不太协调，或者某个按钮的点击响应稍微有点延迟。

它们就像是衣服上的小线头，虽然不影响整体穿着，但看着就是有点别扭。

比如说，在一个购物 APP 里，商品图片的加载速度比正常慢了那么一两秒。

这对于用户的购物体验来说，不会造成太大的影响，但总归是有点不爽。

**二、“精英怪”级 Bug：影响部分功能的小阻碍**“‘精英怪’级 Bug 就像游戏里的小 BOSS，能给你使点绊子，让你前进的脚步稍微停顿一下。

”这种等级的 Bug 会影响到部分功能的正常使用。

比如在一个社交软件中，发送图片的功能偶尔会失败，或者在某个特定的操作流程中，会出现数据丢失的情况。

举个例子，在一个在线学习平台上，用户在观看视频课程时，进度条无法准确记录学习时间，这可能会导致用户无法准确掌握自己的学习进度。

**三、“大魔王”级 Bug：系统崩溃的噩梦**“‘大魔王’级 Bug 一出现，那简直就是代码世界的末日灾难，整个系统都要抖三抖！”这是最严重的 Bug 等级，会导致整个系统崩溃、数据严重错误或者关键功能完全无法使用。

想象一下，一个银行系统出现了数据混乱，或者一个电商平台在购物高峰时无法下单，那可真是让人抓狂！比如说，一个在线支付系统突然无法完成交易，用户的钱被扣了但订单却没有生成，这绝对是能让用户和开发者都崩溃的大问题。

**四、“隐藏刺客”级 Bug：难以察觉的潜在威胁**“‘隐藏刺客’级 Bug 就像藏在暗处的杀手，平时看不到，一旦出现就能给你致命一击！”这类 Bug 通常很难被发现，它们可能在特定的条件下或者经过长时间的使用后才会暴露出来。

bug单定级标准

bug单定级标准
Bug的单定级标准可以根据不同的情况和需求进行定义。

以下是一些常见的Bug定级标准：
1.致命Bug：这类Bug会导致系统崩溃、数据丢失或损坏，严重影响用户体
验或业务运行。

例如，服务端崩溃、数据库死锁等。

2.严重Bug：这类Bug会导致系统功能严重受限或异常，影响大部分用户的
使用。

例如，重要功能无法实现、操作功能异常退出等。

3.一般Bug：这类Bug对系统功能有一定影响，但不会严重影响用户体验或
业务运行。

例如，界面显示错误、部分功能使用不便等。

4.轻微Bug：这类Bug对系统功能影响较小，通常不会影响用户体验或业务
运行。

例如，小部分文字或图片错误、操作小细节上的不便等。

需要注意的是，Bug的定级标准并不是绝对的，需要根据具体情况进行判断。

同时，对于不同的项目或产品，Bug的定级标准也可能会有所不同。

BUG等级划分标准

BUG等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。

功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。

3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。

4、已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。

BUG等级划分标准

B U G等级划分标准 Document number：NOCG-YUNOO-BUYTT-UU986-1986UTBUG等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。

功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。

3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。

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管理规范标准Bug管理规一、概述本规是常规的bug管理流程，适用于项目过程中的bug管理二、BUG周期三、Bug的分类、状态、级别3.1 bug分类1. 功能A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。

2. 易用性A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；B.缺少帮助信息，或者帮助信息不完全；C.功能操作复杂，提示信息不合理，易产生歧义。

3. 安全性A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或认证不合理；4. 可靠性 A.数据存贮的可靠性；B.业务处理的可靠性；5. 性能 A.并发量；B.吞吐量；C.响应时间。

6. 兼容性不同厂商的浏览器以及浏览器的不同版本，手机app指不同操作系统3.2 bug状态Bug的状态主要分为新建、已分派、已解决、重新打开、已关闭、挂起。

新建状态（NEW ）：Bug创建后的初始状态。

已分派状态（ASSIGNED）：经过确认为有效问题后分配给开发人员的状态。

已解决状态（RESOLVED）：开发人员对软件问题进行处理或修改后的状态。

重新打开状态（REOPENED）：对开发人员修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。

关闭状态（CLOSED）：Bug解决后测试人员验证通过，则将其状态修改为已关闭挂起状态：经过项目经理确认延期修改的bug3.3 bug严重等级和优先级定义bug的严重级别定义：D 轻微的错误，不至于影响软件的使P3用，而且应该很容易解决BUG优先级定义：优先级描述备注P1 需要马上修复的bug。

P2 应该尽快修复的bug,但不是很急P3 可以以后修复的bug四bug描述规bug描述要简洁明了，方便开发人员重现和后续跟踪。

版本：当前测试的版本号平台：测试使用的平台说明摘要：概要描述问题。

描述：应该描述问题发现的步骤、期望结果和实际结果描述可分为“步骤”、“结果”（含：期望结果、实际结果）、“补充说明”三部分，各部分之间用空行隔开。

BUG级别定义标准

B U G级别定义标准内部编号：（YUUT-TBBY-MMUT-URRUY-UOOY-DBUYI-0128）文件编号：TDdoc-bug杭州网阔信息科技有限公司BUG级别定义标准拟制部门：测试部版本号：修改日期：2015-05-24版本修改记录目录一、主要分类BUG类型标准主要分两类：依据优先级分类。

依据严重程度分类。

二、主要内容1.依据优先级分类标准定义优先级：指一个BUG相对于其他BUG对于公司的影响，解决的及时性。

.分类标准1.1.1紧急系统无法工作测试无法继续正常工作特殊情况：如重要客户（项目重要性）1.1.2高特殊性的注：涉及所有关于的错误1.1.3中注：涉及的所有关于文本的错误1.1.4低合理建议2.依据严重程度分类标准2.1定义严重程度：指一个BUG对于用户造成的影响，风险和可视性。

.分类标准2.2.1紧急程序无法运行的错误测试无法执行的错误2.2.2非常高2.2.3高2.2.4中2.2.5低合理建议注意事项2.3.1一些错误可以分在多个级别中，但总的标准以此为准，具体的问题具体分析后再确定其等级数。

2.3.2为了错误数量的准确性，测试人员提交的每一条BUG报告中只记录一个错误，如果有各个模块中有同类错误的问题，作为多个模块的记录提交，即需要提交多条相同的错误记录，而不是一条记录。

三、错误分类具体说明条例文案错误出现错误文字出现错别字图片错误出现图片地址的错误图片不能正常显示页面缺图链接错误菜单栏/文字/图片点击链接后出现该页面无法显示菜单栏/文字/图片点击链接后进入其他模块的页面菜单栏/文字/图片点击后没有任何反应上下页分页出现错误前后模块不一致在显示页面上缺少字段的显示（后台有该字段，但前台没有显示出来）后台有该模块，前台却没有任何模块前后台模块的名称不一致需求问题在前台需求上要求显示的方式为图+的形式的，却显示了文+的形式。

多加一个按钮或者缺少一个按钮（如：多了返回按钮，少了取消按钮等）字段名称与需求不一致下拉框中显示的内容不正确需求遗漏变更未通知开发测试需求描述不清晰需求描述错误需求之间冲突实现与需求不符实现的功能与需求不符功能性错误添加，修改，删除操作不成功查询结果错误添加，修改，删除成功后，但前台没有显示出来或者显示不正确无法正常登录后退，前进，刷新功能不正确下拉框中无法正常显示统计结果不正确（成绩统计，金额，数量统计）功能串位按钮功能操作不成功（保存，取消，导入，导出等）本来应该有的权限，现在进入后没有该权限（高坐进入后，却没有显示高坐模块）其他等不能实现具体的操作，出现错误出现调试代码出现代码错误页面格式错误页面设计风格与需求不符风格不一致字体，图片的大小不协调界面凌乱界面不协调，如：一个按钮过大关联性错误一模块出错导致另外一个模块出错程序性能低下特殊情况下直接影响软件的使用统计数据非常缓慢页面响应速度缓慢多用户操作时，响应速度很慢缺少容错性处理当该页面没有任何功能时，出现该页无法显示运行错误时，直接出现不友好的报错页面。