Priority()和Severity(严重程度)是的两个重要属性。很多新人经常混淆这两个概念。通常，人员在提交Bug时，只定义Bug的Severity, 即该Bug的严重程度，而将Priority交给Project Leader 或Team Leader来定义，由他们来决定该Bug被修复的优先等级。某种意义上来说，Priority的定义要依赖于Severity，在大多数情况下，Severity越严重，那这个Bug的Priority就越高。你知道如何合理定义bug的Sevrity么？
通常Bug管理系统里Severity分为四个等级Blocker, Critical, Major, Minor/Trivial（也可自定义，但通常是这四个）, 而priority分为五个等级：Immediate, Urgent, High, Normal, Low。
Severity

1. Blocker: 即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。

• 严重花屏

• 内存泄漏

• 用户数据丢失或破坏

• 系统崩溃/死机/冻结

• 模块无法启动或异常退出

• 严重的数值计算错误

• 功能设计与需求严重不符

• 其它导致无法测试的错误, 如服务器500错误

2.Critical：即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

• 功能未实现

• 功能错误

• 系统刷新错误

• 数据通讯错误

• 轻微的数值计算错误

• 影响功能及界面的错误字或拼写错误

• 安全性问题

3. Major：即界面、性能缺陷、兼容性。

• 操作界面错误（包括数据窗口内列名定义、含义是否一致）

• 边界条件下错误

• 提示信息错误（包括未给出信息、信息提示错误等）

• 长时间操作无进度提示

• 系统未优化（性能问题）

• 光标跳转设置不好，鼠标（光标）定位错误

• 兼容性问题

4.Minor/Trivial:即易用性及建议性问题。

• 界面格式等不规范

• 辅助说明描述不清楚

• 操作时未给用户提示

• 可输入区域和只读区域没有明显的区分标志

• 个别不影响产品理解的错别字

• 文字排列不整齐等一些小问题

Priority

1. 1.Immediate

即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。 
2. Urgent
即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。 

3. High
即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
4. Normal
即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
5. Low即”低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。

分享：

• 　　最高级-- 阻止对后续功能的测试，通常适用于一下情况：

　　1. 软件不能运行

　　2. 界面/功能 Crash 导致一系列测试部能运行

　　3. 出错的 Case 为冒烟测试的 Case

• 　　次最高级- 在当前发布版本中必须修复

　　1. Bug 的出现导致软件没有完成用户的需求

• 　　一般-- 在时间许可的范围内修复

　　1. 只有在极端条件下才会重现的 Bug

　　2. 在特定配置情况下不会出现的 Bug

• 　　低 -- 不影响当前发布，可以推迟到下一个发布中修复

　　1. 不能稳定重现的 Bug

　　2. 因为电脑上装有其他干扰软件产生的 Bug

　　3. 非功能性 Bug, 如日志，错误回复等

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

2.  Urgent 即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。

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

4.  Normal 即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。

5.  Low 即“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。

 Priority(优先级)和Severity(严重程度)是提交bug的两个重要属性。通常，。人 员在提交 Bug时，只定义Bug的Severity,即该Bug的严重程度，而将Priority交给Project Leader 或Team Leader来定义，由他们来决定该Bug被修复的优先等级。某种意义上来说，Priority的定义要依赖于Severity，在大多数情况下，Severity 越严重，那这个Bug的Priority就越高。 

• 　最高级-- 阻止对后续功能的测试，通常适用于一下情况：

　　1. 软件不能运行

　　2. 界面/功能 Crash 导致一系列测试部能运行

　　3. 出错的 Case 为冒烟测试的 Case

• 　　次最高级- 在当前发布版本中必须修复

　　1. Bug 的出现导致软件没有完成用户的需求

• 　　一般-- 在时间许可的范围内修复

　　1. 只有在极端条件下才会重现的 Bug

　　2. 在特定配置情况下不会出现的 Bug

• 　　低 -- 不影响当前发布，可以推迟到下一个发布中修复

　　1. 不能稳定重现的 Bug

　　2. 因为电脑上装有其他干扰软件产生的 Bug

　　3. 非功能性 Bug, 如日志，错误回复等

在测试工程师的日常工作中,最经常做的也是必须做的就是提交缺陷报告.在提交Bug的时候,我们要给出这个Bug的优先级(Priority),开发人员会根据Bug的优先级来决定
先修那个Bug,后修哪个Bug.所以优先级的正确与否会影响到Bug的解决时间进而可能会影响测试和开发的进度.对于一个Bug的优先级也往往是QA和RD争论的焦点.
在我们的公司中Bug的优先级根据其严重度和发生的频率和环境来决定.首先一个Bug有5种严重程度的定义:

严重度A--系统Crash,不能进行安装等;

严重度B--需求说明书中要求的重要功能没有实现;

严重度C--功能存在缺陷;

严重度D--功能可以进一步改进;

严重度E--建议

优先级的定义如下:

Priority 1--必须立即修复;

Priority 2--在Beta前必须修复;

Priority 3--在release前必须修复;

Priority 4--在下一版修复;

Priority 5--可以修复或不修;

接下来根据Bug发生的频率和环境建立一张优先级Mapping表.

重现频率

Always
Sometimes
Hardly
In User Environment

严重度A

P1
P1
P2
P1

严重度B
P1
P2
P3
P2

严重度C
P2
P3
P4
P3

严重度D

P4
P4
P4
P4

严重度E
P5
P5
P5
P5

根据这张表就可以很容易定义Bug的优先级了.

一 严重程度

致命：系统无法正常运行

严重：很明显的错误性的bug

较重：相对明显的错误性的bug

一般：常见的bug

建议类：（暂时保留，可能去掉）

二 优先级

说明：紧急相当于执行前的准备工作，重要相当于后续的工作

重要且紧急：优先级最高，一定要做的

重要不紧急：暂时可以先缓一缓 但一定要做的

紧急不重要：可以先准备下，随时准备做的

不紧急不重要：可忽略不计的

三 bug类型：

功能错误：功能上的错误性bug

代码错误：一般很少出现，通常在自测时出现（对白盒测试、自测的比较适合）

内容相关：业务逻辑方面以及业务描述等相关问题

表单相关：表单逻辑、样式、内容问题

用户界面：UI表现，包括对话框样式和文字描述问题

需求变动：原有的需求基础上的更改

新增需求：会议上提出的新需求，非正式会议提出的不属于该项

设计文档：数据库设计文档、概要/详细设计文档

建议：功能已满足但待改善，属于改良性建议

配置相关：如web服务器或者数据库服务器配置等问题

安装部署：项目部署时出现的错误，可能不是程序本身的问题而是工具本身和人为因素引起

安全相关：加密和水印等安全信息

性能压力：负载、压力测试

标准规范：根据国际标准或者公司内部制定的某标准

测试脚本：如用工具LR编写并执行脚本进行测试

事务跟踪：产品缺陷/bug跟踪（Defect/bug Tracking） 
工作任务跟踪（Task Tracking） 
问题解决过程跟踪（Problem Tracking） 
产品需求管理（Request Management） 
客户服务过程跟踪（Customer Support Tracking

Bad Case：和用例没有关联起来，所以暂时不用

其他：尽量避免用该项，不便于统计但仍保留