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

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

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

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

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

这种方法与很多正统的方法很不一致，因为在很多划分方法中“信息未保存”都是优先级1的bug。

但是笔者自认为这样做是有理由的：当新建功能发生该类型bug而编辑删除功能正常时，编辑删除功能仍然无法测试或者实现（因为没有数据啊），这在客户的江渡看来会直接视为新建编辑删除功能均未实现。

新建功能正常而编辑或者删除功能失效，则不会影响到其他功能的使用（当仅编辑功能失效的时候，新建和删除功能并不会受到影响），测试人员仍然进行新建删除功能的[url=javascript.:;]功能测试[/url]，客户依然可以使用新建和删除功能。

当然，笔者使用上面的划分方式还有其他的原因——基于bug管理和测试开发工作的顺利推进。

读者可能会注意到，使用上面的bug划分方式会减少优先级1的bug的数量，笔者这样做是因为笔者在bug管理中推介的方式是优先级1的bug不允许推迟到下一个工作日修改。

试想，如果优先级1的bug的数量如果过多自然
会导致这种管理方式推行的极大阻力——没有哪个开发人员会喜欢让自己一整天的时间花费在修复bug上。

当我们提交的优先级1的bug都是非常紧急的，会影响到开发或者测试的进度的话，开发人员就自知理亏不得不去修复这些bug了，这就保证了即使到了项目很急迫的时间，我们项目的主体功能还是稳定可用的，并有效遏制了严重bug的生存期。

对于优先级2与优先级3的划分点，只是笔者个人看法，因为笔者目前所经历的项目都是功能性为主，因此对于UI相关的要求相对较低，因此笔者采取了这种粗放的方式（将UI相关bug归纳为优先级3，其他的非UI的非优先级1的bug全部塞到优先级2的集装箱中~）。