如何对所发现的缺陷进行严密的等级划分?（获奖名单已经公布）

lsekfe

本周的问题为“本周的问题为：如何对所发现的缺陷进行严密的等级划分?”
此话题由会员真实的追求者提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	mandy.wang	50元京东礼品卡	#10
二等奖	千里	300论坛积分	#11
三等奖	土土的豆豆	100论坛积分	#6

土土的豆豆

LS wuzhenwu和MLove都回答很充分了，这里还是引用官方国标GB/T 16260体系中要求进行分类吧。
一般我们针对软件问题进行缺陷划分，主要是根据软件/程序/产品的业务、系统功能来说的。

简单说明如下：
一、问题类型：（泛指定义为2大类）
①类. 应改正（A、B、C）；②类. 宜改进（D、E、F）

二、问题级别：
A级：例如：导致死机，或程序无法控制，或程序夭折等；
B级：例如：功能点未实现，或误删信息，或流程错误等；
C级：例如：数据结果错误，或界面信息错误等；
D级：例如：其它错误（文档缺陷、版本问题、中文符合性问题）；
E级：建议的改进性意见；
F级：待确认的问题（TBD）。

三、问题处理：
对于测试中发现的问题，根据问题不同的级别，将按下列方法处理：
-要求客户进行修正，并对修正后的软件进行回归测试，直至测试通过；
-要求客户进行修正，在完成修正并自测通过后，提交《软件问题整改报告》；
-建议客户进行改进，以完善和提高该软件产品的质量。

综上，在各等级中前3级为主要问题因素，一般发现后应该立即修复解决，以免造成重大损失；后3级为次要问题因素，在日益增长的用户体验为先的今天，能力范围内，也适当应该修订或进行合理解决。注：这里我增加了最后一级F，/TBD，待定，现实项目和产品研发测试中，未确认的需求很普遍，我们应该积极主动的参与需求分析和问题解决，让F级问题迅速渗入到各研发环节，替换前面的不同等级，这样才能让我的客户满意，不是么？！^_^

千里

对于如何划分缺陷的等级，测试资料中都有细致详细的说明，只要引经据典就能回答好该问题，而且得分为100分。可是，有多少人能背下来，只要背不下来，那就说明答案只存在于理论而不能用于实战。我们需要理解，只有理解的缺陷等级划分才是切实可行，也正是我们需要的。

在划分缺陷等级之前，我们需要先思考为什么需要进行等级划分？很遗憾，百度中我没有找到相关的答案。我的观点是缺陷的等级是用以评估该缺陷对软件使用的潜在影响，对软件质量评估的直接依据之一，测试准出的主要指标，影响修复优先级的主要参考。越是影响软件使用，越是降低质量评分，越是需要开发尽快修改的缺陷其严重级别都会越高，同样缺陷严重等级也是依据这些情况来制定的。

回到问题，我的疑问是：等级划分需要严密的进行吗？也许会回答，当然了，这是个严肃的活儿。执行法律还三审五判，没有严密的等级划分标准又该如何定夺缺陷的等级呢，没有标准就没有执行。但这不是执法，没有那么高的要求，何况除了法还有理、情，而且职场上是先理后法同时还讲感情，碰到一个缺陷在事先定义的等级划分标准中不存在的时候，你会怎么办？这时候估计你不会完善标准，而是我觉得某个级别更有“理”，正因为这个“理”甚至让测试人员连等级划分标准都给记不住了，谈何严密。

在不同的缺陷工具中，缺陷的等级划分是不一样的。QC中的级别是4级，某些开源工具中定了5级，甚至某些公司定了7级，不同的级别在事先定义的时候是通过什么依据来制定呢？制定这些级别的初衷是什么呢？这是我们需要优先考虑的问题。这个问题明确之后，剩下的就是执行如何确定缺陷等级了，我的观点：心里有一个理在，法在肚子里面当伏案，嘴巴适当讲情，只要合理，一切和谐。若要严密，首先将等级制定得再多一些，标准制定再细100倍，然后在发现缺陷后在堆积如山的“法律”中找到对应的那一条即可“严密”

索契冬奥会都开始了，用一句中国运动精神：比赛第二，友谊第一。

海里的幸福

错过一个人最可怕的方式就是：坐在她的身旁，你却知道永远都不会拥有她。

lipan9122

受教了，感谢千里和mandy.wang!

mandy.wang

测试过程中发现的缺陷一般分为如下几类
功能问题（FunctionError）：对产品、项目质量有影响，但尚难以确定是否是错误，暂时无法解决
功能缺陷（FunctionDefect）：不满足用户需求等bug的总称
页面缺陷（UIDefect）：页面美观性、协调性、错别字等
建议类（Suggestion）：对产品、项目的建议性意见，不强制要求修改
硬件性能：进行性能测试时使用，暂定：网络延时、内存问题、CPU占用、硬盘问题
安全性问题：进行系统安全测试时使用，暂不订具体标准
业务流程问题：进行业务流程测试时进行
数据库性能：暂不执行
模块间接口问题:涉及有模块间数据传递时使用
其他(Other):其它

根据各类缺陷的严重程度将缺陷分为5个等级，具体如下：


1）低（Low）
建议类错误，对软件的改进意见或者建议。如：
a）功能建议
b）操作建议
c）校验建议
d）说明建议
e）UI建议

2）中（Medium）
使操作者不合理或者不方便或操作遇到麻烦，但它不影响执行工作功能或重要功能，次要功能，对产品使用影响不大。如：
界面错误
a）使操作者不方便或者遇到麻烦，但不影响执行工作功能的实现
b）界面、控件的摆布、图标、输入输出不规范

提示类错误
a）删除操作未给出提示
b）长时间操作未给出提示
c）提示窗口文字未采用行业术语
d）出错没有提示
其他错误
a）不符合编码标准
b）辅助说明描述不清楚、不规范
c）快捷键无效，快捷键错误操作
d）打印内容、格式错误

3）高（High）
影响系统正常运行的缺陷，主要功能出现错误，影响到产品的使用。如：
数据库缺陷：数据库设计未达到第三范式的要求或需求规格说明的格式水平
操作错误：因错误操作迫使程序中断
功能错误：
a）程序功能无法实现
b）程序功能实现错误
其他错误：
a）脚本错误
b）软件产品的编译，打包，安装，卸载错误

4）非常高（Very High）
规定的功能没有实现或不完整或产生错误结果；设计不合理造成性能低下，影响系统的运营；使系统不稳定、或破坏数据；而且是常规操作中经常发生或非常规操作中不可避免的主要问题，且没有办法更正（重新安装或重新启动软件不属更正办法），须尽快修正，如：
数据缺陷
a）数据计算错误
b）数据约束错误
c）数据输入、输出错误
数据库缺陷
a）数据库发生死锁
b）数据库的表、业务规则、缺省值未加完整性等约束条件
c）数据库连接错误
d）数据通讯错误
接口缺陷
a）程序接口错误
b）硬件接口、通讯错误
功能错误：
a）程序功能无法实现
b）程序功能实现错误

5）紧急（Critical）
不能执行正常工作或重要功能，使系统崩溃或资源严重不足，数据丢失（金币，包子）非常死机等导致系统不能继续运行须马上修正，如：
a）由于程序所引起的死机，非法退出
b）程序死循环
c）性能与需求不一致（压力测试）
d）存在安全性与保密性问题
e)文件打开与保存错误

总结：
1级-建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。
2级—较小错误的软件缺陷（Minor），使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚。
3级—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。
4级—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
5级—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。

ruiny

以上各位的回复很精细了，如果公司测试的管理的相当规范一点，会在规范中提出缺陷的划分等级，根据所使用的工具和应用软件的不同，有相关的分类要求，遵循即可

ruiny

以上各位的回复很精细了，如果公司测试的管理的相当规范一点，会在规范中提出缺陷的划分等级，根据所使用的工具和应用软件的不同，有相关的分类要求，遵循即可

IUHK

单纯用等级划分也有些困难。
根据不同系统的不同模块，同样的问题的等级不应该一样，对于这个维度应该如何控制呢？比如一个客户经常使用的前台页面的低级文字错误，是否应该比一个只用非常少的特定用户在某些很特殊的操作页面的异常页面格式等级高呢？

Miss_love

一般情况下bug分为5级：
一、紧急：
1、程序引起的死机，程序非法退出
2、功能错误：脱离用户需求
3、数据库数据交换出现错误
4、数据库发生死锁
二、非常高：
1、程序无故出现崩溃
2、业务逻辑出现错误
三、高：
1、输入未进行格式限制
2、不可逆操作，未给出相应的提示信息
3、数据库表字段布局不合理
四、中
1、页面不规范
2、输入输出不规范
3、帮助等信息描述不清晰
五：低
1、优化、建议类。
2、页面布局
3、界面上的错别字

写的不全，呵呵。

wuzhenwu

BUG等级划分，一般划分为：严重BUG、较严重BUG、一般性BUG、建议性BUG

A类—严重错误，包括以下各种错误：
1． 由于程序所引起的死机,非法退出
2． 死循环
3． 数据库发生死锁
4． 因错误操作导致的程序中断
5． 功能错误
6． 与数据库连接错误
7． 数据通讯错误

B类—较严重错误，包括以下各种错误：
1． 程序错误
2． 程序接口错误
3． 数据库的表、业务规则、缺省值未加完整性等约束条件

C类—一般性错误，包括以下各种错误：
1． 操作界面错误（包括数据窗口内列名定义、含义是否一致）
2． 打印内容、格式错误
3． 简单的输入限制未放在前台进行控制
4． 删除操作未给出提示
5． 数据库表中有过多的空字段

D类—较小错误，包括以下各种错误：
1． 界面不规范
2． 辅助说明描述不清楚
3． 输入输出不规范
4． 长操作未给用户提示
5． 提示窗口文字未采用行业术语
6． 可输入区域和只读区域没有明显的区分标志

以上引用
http://hi.baidu.com/lzgang304/item/3fa3734b322b5ae01281da03

另外，各个缺陷管理工具对BUG等级的定义也不一样，如bugzilla、JIRA等。
我觉得无论BUG的等级程度如何，我们都要认真分析、解决。
有很多人容易忽视较小错误或者建设性意见（如一些UI问题），觉得这些问题并不影响软件功能，进而忽视这些问题；但我觉得小问题更能体现软件质量程度。俗话说：细节决定成败！

淑君NJ

多多参与~！！

lsekfe

新年的第一期，希望大家踊跃参与，参与的人多的话。更新的越快，那也就是奖品也就越多！！