优先级：根据软件缺陷的严重性，使修正处理缺陷有了先后顺序，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。
确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。
但是，缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。 但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。 修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。例如，如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。另外，如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。 另一方面，如果软件缺陷的严重性很低，例如，界面单词拼写错误，但是如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。
Bug定级示例
1级：无法进行测试
定义：严重阻碍测试和开发工作。
分类：
功能没有完全实现。
应用闪退或崩溃无法运行。
应用必现安全模式，无法运行（系统不兼容此应用）。
其他功能导致功能无法测试的问题。
优先级：最高
2级：至关重要
定义：非阻碍测试用例执行的严重问题。
分类：
简单操作错后应用闪退、崩溃、卡死。
数据丢失。
严重影响系统，自身功能无法运行。
严重数值计算错误。
数据库损坏或无法保存配置。
安全性问题（数据加密等）
优先级：高
3级：主要
定义：功能存在缺陷，但不影响应用和系统稳定性。
分类：
轻微数值计算错误。
功能实现逻辑覆盖不全面。
复现概率超过50%的闪退、崩溃和安全模式。
优先级：中
4级：一般
定义：对应用然悉度高才能感知到的问题，对应用基本功能实现无影响。
分类：
轻微数值计算错误。
功能实现有误，与产品文档不完全贴切。
用户简单操作，即可明显感知的UI问题。
优先级：中
5级：较小
定义：界面，性能缺陷
分类：
操作界面错误(提示显示规则，刷新规则是否与文档一致)
边界条件显示错误
提示信息和界面效果展示错误（包括未给出信息、信息提示错误等）
复现率低于5%的闪退/崩溃和安全模式
插件兼容和性能未优化问题
非正常操作导致UI显示异常
优先级：低
6级：建议
定义：对于产品的意见或者建议。
分类：
对于产品设计方面的意见和建议
对于产品界面优化方面的意见和建议
对于产品需要优化增强用户体验方面的意见和建议
优先级：低
软件缺陷处理流程：
缺陷状态标记方法：
一个 Bug由测试人员发现并提交,我们将状态标注为新建；开发人员接收了该Bug,将Bug的状态修改为已分配(Assigned),表示已经认可;开发人员解决了该Bug后,就将Bug的状态修改为解决,并发给测试人员回归测试:测试人员对Bug进行回归测试，如果确实已经解决,就将Bug的状态修改为关闭。否则的话则发给进行回归测试，如果确实已经解决,就将Bug的状态修改为关闭。否则的话则发给开发人员重新修改。还要说明的是,Bug是可以“死而复生”的，以前版本已经关闭的Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开。
测试缺陷excel表，【玩安卓】为例：点击 ☞ 查看
