本人在测试项目实践中经过总结，制定了一份供测试人员提交BUG时给BUG的严重程度定级的参考标准。

　　这里首先强调缺陷的严重程度与优先级的区别。严重程度是测试人员提交BUG时给BUG定性，以便给开发组一个参考。而优先级则是项目经理根据项目进度和缺陷的严重程度来决定缺陷处理的先与后。

　　我曾经在测试论坛看到过一份传播较广的缺陷严重程度定级标准，感觉不太规范，因为其中的描述太过于具体，不够抽象。比如文中这样描述：出现XXXX情形时，将严重程度定为“致命”。XXXX描述的是一些很具体的情形，不具有概括性和全面性。所以我在定制这份《软件缺陷严重程度定级标准》时，尽量使描述具有抽象性。

　　有的软件公司，将软件缺陷的严重程度定了4个级别：致命、严重、一般、较小。我觉得没有必要。因为致命和严重之间的差距不会太大，且无论是致命还是严重的缺陷，肯定都得让开发组修复，这些缺陷往往影响用户使用系统。在这两者间再做细分，感觉没必要。所以，我只将缺陷的严重程度划分为三级：严重 、中等、轻微。

　　1、 严重(urgent)：

　　①   用户需求未实现（影响到用户完成业务）；

　　②   用户需求实现错误（影响到用户完成业务）；

　　③   导致被测软件响应明显很慢（假死）、死机、非法退出、崩溃；

　　④   用户使用频繁的功能，响应时间超出忍耐限度（不影响其他功能模块）；

　　⑤   导致后台数据受损或丢失

　　2、 中等(medium)：

　　①   用户需求未实现（不影响用户完成业务、用户使用不频繁)；

　　注：用户执行删除操作时系统应弹出确认提示将固定视为用户需求，无删除确认提示的缺陷归属本类

　　②   用户需求实现错误（不影响用户完成业务、用户使用不频繁)；

　　③   用户操作过程中系统出现异常报错，但不影响系统功能的使用。

　　④   用户使用不频繁的功能，响应时间超出忍耐限度；

　　注：忍耐限度根据实际软件系统的特点而定

　　⑤   UI上存在错误引导用户的信息。

　　⑥   UI上信息缺失、无法显示完整或出现乱码从而给用户造成疑惑的。

　　⑦   用户频繁使用的功能易用性差（操作起来麻烦、复杂、效率低）

　　3、 轻微(low)：

　　①   UI控件不符合界面规范。

　　②   影响UI友好性。

　　③   用户不频繁使用的功能易用性差

　　这套标准启用后，我所在的测试团队成员反映不错，基本上能覆盖测试项目中可能遇到的各种性质缺陷。但本人发现还有一种情况：开发人员实现了需求说明书里未规定实现的功能，即多余的功能，这也属于软件 BUG 。但如何对其严重程度进行定性，无法一概而论。倘若这个多余的功能，给系统带来不好的影响，比如使得系统死机、响应很慢，崩溃等导致用户无法继续操作的现象，那严重程度就归属为严重；倘若对系统毫无影响，但无法正常使用、提示出错，那严重程度可以归属为中等；倘若对系统无影响，也能正常使用，仅相当于一个摆设，那严重程度可以归属为轻微。