CMM5定义BUG等级

bug严重程度或等级划分(教学应用)

bug严重程度或等级划分（urgent 致命,high 严重,medium 中等,low 轻微，低级)
致命urgent：
通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。

比如：
1.内存泄漏
2.系统容易崩溃
3.功能设计与需求严重不符
4.系统无法登陆
5.循坏报错，无法正常退出。

严重\高high：
通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性
比如：
1.功能未实现；
2.功能存在报错；
3.数值轻微的计算错误
一般/中等medium：
通常表现为：界面、性能缺陷
比如：
1.边界条件下错误
2.大数据下容易无响应
3.大数据操作时，没有提供进度条
轻微/低low：
通常表现为：易用性及建议性问题比如：
1.界面颜色搭配不好
2.文字排列不整齐
3.出现错别字，但是不影响功能
4.界面格式不规范。

缺陷等级划分规定

缺陷等级划分规定１．缺陷等级划分规范１．１Bug等级种类及定义:Bug等级可分为:致命,严重,一般的,微小的四种.致命（critical）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失严重（major）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明一般的（normal）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。

如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等１．２等级划分步骤:1) 功能方面结合”缺陷发生率”(Exposure Risk)和”影响强度”(Impact Intensity)对Bug进行等级划分.”缺陷发生率”是指在运用产品过程中,出现某个缺陷的频率, 可分为四种:不可避免,经常,偶尔,很少.不可避免(Unaviodable):只要运行系统或应用程序,或者使用软件主要功能,该缺陷就能出现. 经常(Frequent):在使用软件过程中,需要通过几步操作出现,或者是一些不常用的非主要功能的缺陷,或者出现该缺陷的频率在30-70%的.偶尔(Occasional):缺陷出现的前提是通过多次操作或多个步骤,或者缺陷出现的概率在2%-30%.很少(Rare):低频率操作,或者出现的前提是通过N次操作或N个步骤,或者缺陷出现的概率低于2%的.“缺陷影响强度”是指在运用产品过程中,某个缺陷影响产品使用的程度,可分为三种:灾难性,障碍性,干扰性.灾难性(Disastrous):测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现；关键性能指标达不到要求；障碍性(Obstruction):系统的次要功能点或需求点没有实现；数据丢失或损坏。

bug级别定义及流转说明

Bug说明文档2015年6月25日修订历史记录（A-添加，M-修改，D-删除）目录1.简介 (4)1.1.编写目的 (4)1.2.文档范围 (4)1.3.预期读者 (4)2.BUG优先级(PRIORITY) (4)2.1.I MMEDIATE（立刻）——P1 (4)2.2.U RGENT（紧要、优先）——P2 (4)2.3.V ERY H IGH(高度重视)——P3 (5)2.4.H IGH（重视）——P4 (5)2.5.N ORMAL（正常）——P5 (5)2.6.L OW（稍缓）——P6 (5)3.BUG严重程度(SEVERITY) (5)4.BUG状态及流转 (6)4.1.B UG状态及说明 (6)4.2.B UG状态流转方式 (7)5.BUG内容 (8)1. 简介1.1. 编写目的本文档主要确定bug优先级、bug严重程度、bug流转方式、bug内容。

1.2. 文档范围Bug优先级和bug严重程度的定义，bug流转方式和bug内容的确定。

1.3. 预期读者本文档阅读人员包括项目经理、开发人员、测试人员以及其他相关人员。

2. Bug优先级(Priority)优先级大致分为6个级别P1~P6，P1~P6分别为： Immediate（立刻）、Urgent （紧要、优先）、Very High（高度重视）、High（高度重视）、Normal（正常）、Low （稍缓）。

2.1. Immediate（立刻）——P1即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。

2.2. Urgent（紧要、优先）——P2即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。

2.3. Very High(高度重视)——P3即“高度重视”，表示有时间就要马上解决，否则系统主要功能偏离需求较大或者不能正常工作。

2.4. High（重视）——P4即“重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。

Bug严重程度分类

使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题；
系统存在较严重的安全隐患和性能问题；
系统易用性较差；
系统描述易引起较严重的误会或较严重的影响；
系统的某些功能没有实现而引起后续次要功能不能继续进行；系统的次要功能没有实现；
由于设计的缺陷，导致软件使用中存在较明显的障碍，或者局部功能错误，但可以采取其他变通的操作实现。
系统存在严重的安全隐患和性能问题；
系统易用性很差；
系统描述易引起严重的误会或带来严重的影响；
系统的某些功能没有实现而引起后续主要功能不能继续进行；软件规范严重不合理等。
2级：尽快修改
B类：较严重
指造成系统功能严重破坏或崩溃的，复位或重灌系统可以继续运行；
严重地影响系统要求或基本功能的实现，且没有更正办法（重新安或重新启动该软件不属于更正办法）；
3级：正常修改
C类：一般
指造成系统功能失效、会引起操作上重大误解的；
严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）；
系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题；
由于编码不够完善，使某个小功能无法使用，或者对特殊的操作与要求不能支持
存在隐含的安全漏洞，可以利用快捷方式、成批处理，以及权
限的组合应用中的安全漏洞进行未经授权的操作。
4级：稍后修改
D类：轻微
指系统功能在设计和开发中由于考虑不周所引起的问题，即可能会造成系统在使用中会岀错的隐患或造成使用中会产生歧义的；
使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能；

BUG级别（优先级、严重级）定义

BUG级别（优先级、严重级）定义⼀、主要分类BUG类型标准主要分两类：Ø 依据优先级分类。

Ø 依据严重程度分类。

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

分类标准紧急² 系统⽆法⼯作² 测试⽆法继续正常⼯作² 特殊情况：如重要客户（项⽬重要性）⾼² 需求问题² 实现与需求不符² 出现调试代码² 功能性错误² 关联性错误² 前后模块不⼀致² 链接错误² 特殊性的程度性能低下² 程序引起的安全问题注：涉及所有关于数据流的错误中² 页⾯格式错误² 兼容性问题² 校检错误² 图⽚错误² ⽂案错误² 程序性能低下² 缺少容错性处理² 功能易⽤程度低² 配置问题注：涉及的所有关于⽂本的错误低² 遗留问题² 暂时⽆法实现技术问题² 合理建议依据严重程度分类标准定义严重程度：指⼀个BUG对于⽤户造成的影响，风险和可视性。

分类标准紧急² 程序⽆法运⾏的错误² 测试⽆法执⾏的错误⾮常⾼² 链接错误² 前后模块不⼀致² 需求问题² 实现与需求不符² 出现调试代码² 功能性错误² 程序性能低下² 程序引起的安全问题⾼² 页⾯格式错误² ⽂案错误² 图⽚错误² 兼容性错误² 校检错误中² 关联性错误² 配置问题² 功能易⽤程度低低² 合理建议² 遗留问题² 暂时⽆法实现技术问题注意事项1) ⼀些错误可以分在多个级别中，但总的标准以此为准，具体的问题具体分析后再确定其等级数。

bug划分标准

○ 功能未实现
○ 功能错误
○ 系统刷新错误
○ 语音或数据通讯错误
○ 轻微的数值计算错误
○ 系统所提供的功能或服务受明显的影响
● 一般(可对应于目前BUG体系中的“普通”)
一般性问题主要为：界面、性能缺陷
具体基本上可分为：
○ 操作界面错误(包括数据窗口内列名定义、含义是否一致)
○ 模块无法启动或异常退出
○ 严重的数值计算错误
○ 功能设计与需求严重不符
○ 其它导致无法测试的错误
● 严重(可对应目前BUG体系中的“严重”)
严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
具体基本上可分为：
1.BUG等级划分建议：
目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。
● 致命(可对应目前BUG体系中的“非常严重”)：
致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
具体基本上可分为：
○ 严重花屏
○ 内存泄漏
○ 用户数据丢失或破坏
○ 系统崩溃/死机/冻结信息、信息提示错误等)
○ 长时间操作无进度提示
○ 系统未优化(性能问题)
○ 光标跳转设置不好，鼠标(光标)定位错误
● 提示(可对应于目前BUG体系中的“轻微及建议”)

CMM的五个等级

CMM1：初始级，Inltial，不可预测并且缺乏控制；
CMM2：可重复级：Repeatable，可重复以前的主要经验；
（关键过程区域：需求管理；软件项目计划；软件项目跟踪和监督；软件子合同管理；软件质量保证；软件配置管理。

）
CMM3：已定义级：Defined，过程被描述，并得到良好理解；
（关键过程区域：组织过程定义；组织过程焦点；培训大纲；集成软件管理；软件产品工程；组际协调；同行评审。

）
CMM4：已管理级：Managed，过程被测量并受控；
（关键过程区域：定量的过程管理；软件质量管理。

）
CMM5：优化级，Optimizing，关注过程改进。

（关键过程区域：缺陷预防；技术变更管理；过程变更管理。

）。

BUG发现率及严重程度重定义

1．BUG等级划分建议：目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。

根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。

● 致命(可对应目前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）：测试人员认为问题已经修改，通过验证，由测试人员设置。

CMM5级标准

导论：第一级：初始级在初始级，企业一般不具备稳定的软件开发与维护的环境。

常常在遇到问题的时候，就放弃原定的计划而只专注于编程与测试。

第二级：可重复级在这一级，建立了管理软件项目的政策以及为贯彻执行这些政策而定的措施。

基于过往的项目的经验来计划与管理新的项目。

第三级：定义级在这一级，有关软件工程与管理工程的一个特定的、面对整个企业的软件开发与维护的过程的文件将被制订出来。

同时，这些过程是集成到一个协调的整体。

这就称为企业的标准软件过程。

第四级：定量管理级在这一级，企业对产品与过程建立起定量的质量目标，同时在过程中加入规定得很清楚的连续的度量。

作为企业的度量方案，要对所有项目的重要的过程活动进行生产率和质量的度量。

软件产品因此具有可预期的高质量。

第五级：（不断）优化级在这个等级，整个企业将会把重点放在对过程进行不断的优化。

企业会采取主动去找出过程的弱点与长处，以达到预防缺陷的目标。

同时，分析有关过程的有效性的资料，作出对新技术的成本与收益的分析，以及提出对过程进行修改的建议。

CMM第一级：初始级◆ 特征(1)软件过程的特点是杂乱无章，有时甚至混乱，几乎没有定义过程的规则或步骤。

(2)过分的承诺，常作出良好的承诺：如“按照软件工程方式，有序的工程来工作”；或达到高目标的许诺。

但实际上却出现一系列问题。

(3)遇到危机就放弃原计划过程，反复编码和测试。

(4)成功完全依赖个人努力和杰出的专业人才，取决于超常的管理人员和杰出有效的软件开发开发人员。

具体的表现和成果都源于或者说是决定于个人的能力和他们先前的经验、知识以及他们的进取心和积极程度。

(5)能力只是个人的特性，而不是开发组织的特性。

依靠着个人的品质或承受着巨大的压力；或找窍门取得成果。

但此类人一旦离去，对组织的稳定作用也消失。

(6)软件过程是不可确定的和不可预见的。

软件成熟性程度处于第一级软件组织的软件过程在实际的工作过程中被经常的改变（过程是随意的）。

Bug等级和定义

Bug等级/定义
等级修改完成时长验证完成时长
紧急2工作日1工作日
非常高3工作日2工作日
高4工作日3工作日
中5工作日4工作日
低6工作日4工作日
5级分类
A类（紧急）---导致系统崩溃、死机；出现不可挽救的数据丢失或损坏、内存泄露
1.系统崩溃。

如：应用程序死掉、应用程序异常退出
2.无法正常安装
3.升级脚本错误，升级失败
4.主要功能无法实现或遗漏，流程执行受阻等
……
B类（非常高）---导致程序模块丢失或未实现；软件错误导致数据丢失；用户需求未实现
1.基本功能存在部分问题或基本功能无法实现或遗漏
2.程序抛出异常
3.安装后文件不全、文件错误造成基本功能无法实现
4.用户需求未实现
……
C类（高）---影响被测功能正确实现的问题
1.次要功能存在部分问题
2.需求理解错误
3.计算错误/取值错误等
……
D类（中）---一般性错误或者功能实现不完善等
1.界面错误(详细文档)
2.打印内容、格式错误
3.删除操作未给出提示
4.系统操作不方便
……
E类（低）---较低级错误/一些建议性的错误
1.辅助说明描述不清楚
2.错字/别字
3.可输入区域和只读区域没有明显的区分标志
4.提示窗口文字未采用行业术语
5.长时间操作未给用户进度提示
6.显示格式不规范、查询报告格式错误
7.优化/建议性的错误
……。

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

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

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

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

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

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

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

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

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

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

软件千行缺陷率

关于CMMI 级别中和BUG率相关的信息如下：
千行代码缺陷率（软件一千行代码中的bug率）：
CMM1级11.95‰
CMM2级 5.52‰
CMM3级 2.39‰
CMM4级0.92‰
CMM5级0.32‰
本来像软件这样的逻辑产品，开发过程中出现缺陷（BUG）不可避免，但随着CMM级别的提高，软件可靠性将有数量级的改进，目前业界通常的标准是：每千行源代码所含的BUG数，CMM1级为11.95个，CMM2级为5.52个，CMM3级为2.39个，CMM4级为0.92个，而到了CMM5级则只有0.32个。

也就是说CMM5级的可靠性比CMM1提高近40倍。

在CMM1，大多数的BUG通常都会在测试阶段出现，随着CMM级别的提高，BUG出现的高峰也随之提前，从而使软件开发的进度得到可靠的保证。

在可靠性提高的同时，CMM5的软件开发周期是CMM1的36%，而生产成本是CMM1的19%，平均每个软件开发人员的生产率会提高4倍。

基本属于成倍递减。

国内通过CMMI 5 级评定的IT行业公司如下（信息来源互联网，如有出入，欢迎指正）：
我看了一下乐牛家庭版的千行缺陷率：26个bug，3.3万行有效代码，经过计算得出结论0.78，按照软件成熟度的计算咱们公司都可以在CMMI4了，但是我,觉得咱们公司的软件开发成熟度也就在CMMI1，因为各种流程都不成熟。

还有根据咱们的软件质量来看，怎么算也应该是在CMMI1级的11.95，可是最后咱们测出来竟然是CMM4的标准，我觉得应该不是咱们软件做的特别好，而是测试出来的bug不够。

CMM5定义BUG等级按照CMM5中定义的规范：致命是严重影响产品的BUG，比如操作手册的错误，需求的错误等。

严重是产品中使功能无法实现的BUG，比如某个功能无法运行，GUI长时间僵死没有响应。

一般是某个BUG的发生，只影响了一个功能，而其他功能可以正常运行。

提示就是一些GUI的问题，或者友好性的问题。

执行的bug是最严重的，即优先级1的bug，除此之外所有导致应用程序崩溃掉的bug也列入到优先级1中；[url=javascript.:;] 其他[/url]功能性bug列入比较严重的bug的队伍，即优先级2；界面上的bug列为一般的，即优先级3实践过程中推行的就是这种bug分级制度。

这种分级制度比较主观，使用到一个bug优先级划分文档中列出的优先级1的bug特征：优先级1类的bug还应该包括功能严重不符合产品说明书这种类型的buga)应用程序某个模块功能未实现（包括整个模块不能运行）b)用户的信息被破坏或者丢失c)可重现的不可避免的崩溃，死锁d)功能和性能急剧衰退e)严重的内存泄漏f)导致功能无法正常使用的UI设计（UI响应迟缓）g)其他的确，这些bug优先级划分很明确，让人一目了然并且觉得很有道理，可是拿到实际中一用，麻烦开始来了。

因为某些描述仍然不够详细，含混不清的描述诸如“功能和性能急剧衰退”，碰到这种描述，不同的人会有不同的理解，而不同的理解必然会带来各种各样的问题。

因此，笔者在实践中逐渐摒弃了这种做法，并开始逐步推广笔者自己刚才提到的粗放式bug优先级划分方法。

对于该划分方法，笔者还需要进一步的说明。

笔者刚才提到的“严重影响测试执行的bug”其实也是指系统的基本功能或者核心功能，比如新建编辑删除功能中，对于同样是信息为保存到[url=javascript.:;]数据库[/url]——即新建后记录未添加到数据库，编辑后记录未更新，删除后数据仍然存在于数据库中——这时候笔者仅仅将新建功能的该bug置于优先级1中，编辑删除bug则置于优先级2中。