我们缺陷的分类可以按严重程度分类、按优先级划分、按测试种类划分、按功能模块划分、按缺陷生命周期划分。

按严重程度划分(Severity)，这个是我们最常用的一个分类。

致命级
系统崩溃，数据丢失，由于程序所引起的死机、非法退出，死循环，数据库发生死锁，错误操作导致的程序中断 ，严重的计算错误，与数据库连接错误，数据通讯错误。

严重级
系统功能错误或遗漏；程序接口错误 、数据流错误 、轻微数据计算错误。

主要级（一般级)
错误操作提示，界面错误，打印内容、格式错误，简单的输入限制未放在前台进行控制，删除操作未给出提示，数据输入没有边界值限定或不合理。

次要级
不影响系统功能，更好的操作方式，罕见的错误，辅助说明描述不清楚，显示格式不规范，系统处理未优化，时间操作未给用户进度提示，提示窗口文字未采用行业术语。

建议级
不影响系统功能，影响界面美观等。

（缺陷模板中缺陷的定义）

按优先级划分(Priority)

最高优先级：指的是一些关键性错误，必须立即修复。

高优先级：在产品发布之前必须修复。

中优先级：如果时间允许应该修复。

低优先级：可能会修复，但是也能发布软件。

需要注意的是严重程度高的Bug其优先级就高吗？Bug的严重程度和优先级一定成正比吗?不一定。 严重程度高优先级不一定高：

如果某个严重的软件缺陷只在非常极端的条件下产生，没有必要马上解决。

如果修正一个软件缺陷,需要重新修改软件的整体架构，可能会产生潜在的缺陷,而软件又必须尽快发布，是否需要修正，需要全盘考虑。


按Bug生命周期划分

我们可以把Bug看作一个有生命的小虫子，每一个Bug都有其生存和死亡的生命周期。可以这样划分: 新建(New)，确认(Confirmed)，解决(Fixed)，关闭(Closed)，重新打开(Reopen)。
新建(New)：一个Bug由测试人员发现并提交，我们将状态标注为新建;

确认(Confirmed)：项目经理分配Bug ,开发人员接收了该Bug, 将Bug的状态修改为已分配表示已经认可(Confirmed);

解决(Fixed)：开发人员解决了该Bug后,就将Bug的状态修改为解决(Fixed),并发给测试人员回归测试;

关闭(Closed）：测试人员对Bug进行回归测试,如果确实已经解决,就将Bug的状态修改为关闭(Closed),否则的话则发给开发人员重新修改,直到关闭为止。

重新打开(Reopen) ：Bug是可以“死而复生”的,以前版本已经关闭的Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开(Reopen)。