Bug的优先级是bug管理过程中必须考虑的问题。对于优先级的划分，不同的软件公司有自身的一套制度，因此笔者介绍的也仅仅是自己比较喜欢的一种方式。
为了便于bug的提交和管理，也为了方便于与开发人员进行交流，笔者倾向于在项目中将bug划分为三个等级，而不是网络上流传的五等级版本甚至七等级版本（在成熟的软件组织中，使用更细的bug等级划分有利于bug分类，质量评审等工作的顺利进行）。这三个优先级分别即优先级1（严重的），优先级2（比较严重的）和优先级3（一般的）。
笔者划分bug等级的指导思想很简单，严重影响测试执行的bug是最严重的，即优先级1 的bug，除此之外所有导致应用程序崩溃掉的bug也列入到优先级1中；其他功能性bug列入比较严重的bug的队伍，即优先级2；界面上的bug列为一般的，即优先级3。
作者在实践过程中推行的就是这种bug分级制度。这种分级制度看起来过于主观，而不像网络上流传的各个bug优先级划分的版本中，将每个优先级的bug的表现都一五一十列出来，如下是笔者以前使用到一个bug优先级划分文档中列出的优先级1的bug特征：
a）应用程序某个模块功能未实现（包括整个模块不能运行）
b）用户的信息被破坏或者丢失
c）可重现的不可避免的崩溃，死锁
d）功能和性能急剧衰退
e）严重的内存泄漏
f）导致功能无法正常使用的UI设计（UI响应迟缓）
g）其他
的确，这些bug优先级划分很明确，让人一目了然并且觉得很有道理，可是拿到实际中一用，麻烦开始来了。因为某些描述仍然不够详细，含混不清的描述诸如“功能和性能急剧衰退”，碰到这种描述，不同的人会有不同的理解，而不同的理解必然会带来各种各样的问题。因此，笔者在实践中逐渐摒弃了这种做法（当然，笔者并不排除将来可能还是会回到一些比较正规的管理方法上来，但是目前这种“标准”方法并不适合笔者所在的公司~），并开始逐步推广笔者自己刚才提到的粗放式bug优先级划分方法。
对于该划分方法，笔者还需要进一步的说明。笔者刚才提到的“严重影响测试执行的bug”其实也是指系统的基本功能或者核心功能，比如新建编辑删除功能中，对于同样是信息为保存到数据库——即新建后记录未添加到数据库，编辑后记录未更新，删除后数据仍然存在于数据库中——这时候笔者仅仅将新建功能的该bug置于优先级1中，编辑删除bug则置于优先级2中。这种方法与很多正统的方法很不一致，因为在很多划分方法中“信息未保存”都是优先级1的bug。但是笔者自认为这样做是有理由的：当新建功能发生该类型bug而编辑删除功能正常时，编辑删除功能仍然无法测试或者实现（因为没有数据啊），这在客户的江渡看来会直接视为新建编辑删除功能均未实现。新建功能正常而编辑或者删除功能失效，则不会影响到其他功能的使用（当仅编辑功能失效的时候，新建和删除功能并不会受到影响），测试人员仍然进行新建删除功能的功能测试，客户依然可以使用新建和删除功能。
当然，笔者使用上面的划分方式还有其他的原因——基于bug管理和测试开发工作的顺利推进。读者可能会注意到，使用上面的bug划分方式会减少优先级1的bug的数量，笔者这样做是因为笔者在bug管理中推介的方式是优先级1的bug不允许推迟到下一个工作日修改。试想，如果优先级1的bug的数量如果过多自然会导致这种管理方式推行的极大阻力——没有哪个开发人员会喜欢让自己一整天的时间花费在修复bug上。当我们提交的优先级1的bug都是非常紧急的，会影响到开发或者测试的进度的话，开发人员就自知理亏不得不去修复这些bug了，这就保证了即使到了项目很急迫的时间，我们项目的主体功能还是稳定可用的，并有效遏制了严重bug的生存期。
对于优先级2与优先级3 的划分点，只是笔者个人看法，因为笔者目前所经历的项目都是功能性为主，因此对于UI相关的要求相对较低，因此笔者采取了这种粗放的方式（将UI相关bug归纳为优先级3，其他的非UI的非优先级1的bug全部塞到优先级2 的集装箱中~）。
PS：感谢下面一位同仁的回复，优先级1类的bug还应该包括功能严重不符合产品说明书这种类型的bug。
以上为个人意见，如有意见建议，欢迎一起交流。