下载文档原格式
缺陷的等级：严重问题、中等问题、轻微问题、建议问题
严重问题：
1. 程序致命错误(fatal类型的错误)，跳转到红色错误页面；
2. 功能没有按照需求中完成；
3. 服务器因程序问题报服务器内部错误；
4. 发布版本不能正常测试，因服务器环境或者程序问题；
中等问题：
1. 在IE7,8和火狐浏览器报JS错误；
2. 页面存在变形和样式问题（跨行，跨列）；
3. 由于隐含需求导致程序问题；
4. 服务器缓存无及时更新导致的数据不一致；
5. 只有管理员才能操作的功能在没有按照正确步骤操作导致的错误；轻微问题：
1. 不影响正常使用、提示中存在错别字；
2. 不明确的错误提示。
如：非法请求等，不能给用户明确的提示；
3. 系统中英文不统一，除专业术语；
4. 必填项没有加(*)或者其他必填项的标记说明；
5. 界面存在错别字；
6. 页面中元素在原位置有很小的偏差；
7. 按钮及页面的风格不统一；
建议问题：
1. IE6及非必要浏览器中出现的JS和页面问题；
2. 外部插件中本身存在的问题。
如：编辑器插件，弹出窗口插件等。
3. 界面协调美观、更符合计算机操作习惯等；
4. 需求、设计中建议加入，但不加入不影响整体全面性问题；
5. 由于页面没加载完成导致的样式和JS的问题；。
缺陷严重级别定义:o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等. o 紧急---事件非常重要,并且需要马上给予关注.o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决. o 低级---事件不重要,可以在时间和资源允许的情况下再解决.o 建议性缺陷.更为详细的划分如下:A类——严重错误，包括：o 由于程序所引起的死机,非法退出o 死循环o 导致数据库发生死锁o 数据通讯错误o 严重的数值计算错误B类——较严重错误，包括：o 功能不符o 数据流错误o 程序接口错误o 轻微的数值计算错误C类——一般性错误，包括：o 界面错误(详细文档)o 打印内容、格式错误o 简单的输入限制未放在前台进行控制o 删除操作未给出提示D类——较小错误，包括：o 辅助说明描述不清楚o 显示格式不规范o 长时间操作未给用户进度提示o 提示窗口文字未采用行业术语o 可输入区域和只读区域没有明显的区分标志o 系统处理未优化E类——测试建议（非缺陷）软件公司对软件缺陷级别的定义不尽相同，一般可以分为4种：1. 致命（fatal）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失2. 严重（critical）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明3. 一般的（major）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。
如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等4. 微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等Bug严重程度定义：致命(Critical)BUG ：测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现。
产品质量缺陷判定及分级标准（IATF16949-2016）1.0目的对来料、制程、出货等环节产品质量检测,根据接收质量限<AQL抽样表>执行抽样检查,同时给出明确有效的缺陷判定等级,使产品缺陷判定标准统一,特制定本标准。
2.0适用范围适用于本公司质量管控各环节。
3.0定义3.1缺陷Defect:未满足预期或规定用途有关的要求;即为不良,是产品质量不良等级的严重性的划分点,是产品质量没有达到标准程度的描述;缺陷可分为四个等级:致命缺陷、严重缺陷、一般缺陷、轻微缺陷；生产过程中极少出现或不会出现“致命缺陷”，为了加严产品质量管理，引起各环节、各部门的重视，通常把缺陷分三级来管理，把“严重缺陷”称为“致命缺陷CRI”“一般缺陷”称为“严重缺陷MAJ”“轻微缺陷”称为“轻微缺陷MIN”来进行管理。
3.2致命缺陷Fatal影响质量安全的所有缺陷，影响难以纠正的非正常的情况，全影响寿命的，会造成产品故障的或造成产品使用困难的或造成下道工序混乱的缺陷都称为致命缺陷。
3.3严重缺陷Critical可以引起易于纠正的异常情况，可能影响寿命，可能引起易于修复的故障，肯定会造成使用困难，产品外观3.4一般缺陷Major3.5轻微缺陷Minor4.0职责4.1品控部：负责本标准编制并执行。
4.2各部门：负责遵守本标准的判定结果。
5.0判定条件5.1外观检测：目视(视力1.0及以上)自然光照条件下，目视距离50cm，产品置于目视角度正前方，特殊情况需从不角度观测对比。
5.1.1外观检验依据GB7707进行判定。
5.2物理力学及化学性能：根据产品使用性能依据相应标准进行判定。
6.0质量缺陷分级为：。
软件缺陷管理之缺陷严重等
级分类
标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-
A类——严重错误，包括：
由于程序所引起的死机,非法退出
死循环
导致数据库发生死锁
数据通讯错误
严重的数值计算错误
需求未实现
文档与软件不符、文档严重不足、系统文档关键错误B类——较严重错误，包括：
功能不符
数据流错误
程序接口错误
轻微的数值计算错误
C类——中等错误。
包括：
程序非正常终止但可通过其它输入来避免
系统边界错误
显示报表错误
数据处理、需求理解错误
系统文档一般错误
D类——一般性错误，包括：
界面错误(详细文档)
打印内容、格式错误
简单的输入限制未放在前台进行控制
删除操作未给出提示
系统操作不方便
E类——较小错误，包括：
辅助说明描述不清楚
显示格式不规范、查询报告格式错误
长时间操作未给用户进度提示
提示窗口文字未采用行业术语
可输入区域和只读区域没有明显的区分标志系统处理未优化
F类——测试建议（非缺陷）。
缺陷的等级评定
缺陷的等级评定通常根据其严重程度和影响范围进行评定。
以下是常见的缺陷等级评定：
1. 严重缺陷（Critical）：这些缺陷会导致系统崩溃、数据丢失或无法使用，且不具备可用的替代方案。
这类缺陷需要立即修复，否则系统无法正常运行。
2. 主要缺陷（Major）：这些缺陷会导致系统功能性的问题，
但可通过绕过或使用备用方案来解决。
这类缺陷对系统正常运行的影响较大，需要尽快修复。
3. 次要缺陷（Minor）：这些缺陷通常是一些界面问题、行为
不一致或用户体验不佳等，对系统整体运行影响较小。
这类缺陷应该在合适的时机进行修复，以提高系统的质量。
4. 提示缺陷（Suggestion）：这些缺陷不影响系统的正常运行，但可能会对用户的操作产生困惑或导致一些不必要的操作。
这类缺陷通常是一些改进性的建议，可以在后续的版本中进行修复。
缺陷的等级评定可根据具体的项目和组织而有所区别，因此有时还可能存在其他等级评定。
最终评定缺陷等级时，需要综合考虑缺陷的严重程度、影响范围和修复的难度等因素。
缺陷严重级别定义：o最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.o紧急---事件非常重要,并且需要马上给予关注.o高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.o中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决.o低级---事件不重要,可以在时间和资源允许的情况下再解决.o建议性缺陷.更为详细的划分如下：A类——严重错误，包括：o由于程序所引起的死机,非法退出o死循环o导致数据库发生死锁o数据通讯错误o严重的数值计算错误B类——较严重错误，包括：o功能不符o数据流错误o程序接口错误o轻微的数值计算错误C类——一般性错误，包括：o界面错误(详细文档)o打印内容、格式错误o简单的输入限制未放在前台进行控制o删除操作未给出提示D类——较小错误，包括：o辅助说明描述不清楚o显示格式不规范o长时间操作未给用户进度提示o 提示窗口文字未采用行业术语o可输入区域和只读区域没有明显的区分标志o 系统处理未优化E类——测试建议（非缺陷）软件公司对软件缺陷级别的定义不尽相同，一般可以分为4种：1.致命（fatal）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失2.严重（critical）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明3.一般的（major）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。
如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等4.微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等Bug严重程度定义：致命(Critical)BUG：测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现。
缺陷等级划分规定１．缺陷等级划分规范１．１Bug等级种类及定义:Bug等级可分为:致命,严重,一般的,微小的四种.致命（critical）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失严重（major）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明一般的（normal）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。
如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等１．２等级划分步骤:1) 功能方面结合”缺陷发生率”(Exposure Risk)和”影响强度”(Impact Intensity)对Bug进行等级划分.”缺陷发生率”是指在运用产品过程中,出现某个缺陷的频率, 可分为四种:不可避免,经常,偶尔,很少.不可避免(Unaviodable):只要运行系统或应用程序,或者使用软件主要功能,该缺陷就能出现. 经常(Frequent):在使用软件过程中,需要通过几步操作出现,或者是一些不常用的非主要功能的缺陷,或者出现该缺陷的频率在30-70%的.偶尔(Occasional):缺陷出现的前提是通过多次操作或多个步骤,或者缺陷出现的概率在2%-30%.很少(Rare):低频率操作,或者出现的前提是通过N次操作或N个步骤,或者缺陷出现的概率低于2%的.“缺陷影响强度”是指在运用产品过程中,某个缺陷影响产品使用的程度,可分为三种:灾难性,障碍性,干扰性.灾难性(Disastrous):测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现；关键性能指标达不到要求；障碍性(Obstruction):系统的次要功能点或需求点没有实现；数据丢失或损坏。
缺陷等级定义在工业设备管理中有专门的缺陷管理，缺陷是指设备或系统存在安全隐患，有专门负责检查和消除设备缺陷的人员。
缺陷等级定义缺陷等级一般分为四种，表示缺陷的程度。
缺陷等级划分规范Bug等级可分为:致命,严重,一般的,微小的四种.致命（critical）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失严重（major）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明一般的（normal）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。
如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等等级划分步骤:1)功能方面结合”缺陷发生率”(Exposure Risk)和”影响强度”(Impact Intensity)对Bug进行等级划分.”缺陷发生率”是指在运用产品过程中,出现某个缺陷的频率,可分为四种:不可避免,经常,偶尔,很少.不可避免(Unaviodable):只要运行系统或应用程序,或者使用软件主要功能,该缺陷就能出现.经常(Frequent):在使用软件过程中,需要通过几步操作出现,或者是一些不常用的非主要功能的缺陷,或者出现该缺陷的频率在30-70%的.偶尔(Occasional):缺陷出现的前提是通过多次操作或多个步骤,或者缺陷出现的概率在2%-30%.很少(Rare):低频率操作,或者出现的前提是通过N次操作或N个步骤,或者缺陷出现的概率低于2%的.“缺陷影响强度”是指在运用产品过程中,某个缺陷影响产品使用的程度,可分为三种:灾难性,障碍性,干扰性.灾难性(Disastrous):测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现；关键性能指标达不到要求；障碍性(Obstruction):系统的次要功能点或需求点没有实现；数据丢失或损坏。
缺陷严重等级细分标准致命：定义：导致运行中断(应用程序崩溃)，导致整个程序不能使用，或者存在重大风险、隐患。
场景：1.客户端、服务器死机或者不响应2.数据库死锁3.客户端异常退出4.客户端无法正常连接服务器5.需求未实现，或者实现的功能与需求完全不符6.核心功能出现异常：A.数据备份时,漏备份表B.日终流程报错,无法继续正常运行C.日终数据处理时,对不该处理的数据进行了处理,对应该处理的数据没有进行处理D.核心菜单或功能按钮一点就报异常,导到无法继续进行操作或提交申请;E.引起用户无法登录的问题,如验证码无法获取.一进入登录页面就报客户异常.用户输入正确的信息也不能正常登录.F.多导出或导入申请数据或少导出或导入申请数据;G.页面上缺少关键功能按钮,导到申请不能提交或不能查询;7.严重的数值计算或插入数据表错误A.金额,份额,申请日期,清算日期,划款状态,扣款状态,基金帐号,交易帐号等关键字段值写入数据库错误8.提交的测试包问题A.后台服务不能正常启动B.程序无法正常编译通过9.页面问题A.A基金公司的页面或提示信息或签订的协议内容上出现了B基金公司的名称严重：定义：预期的功能没有得到实现,测试工作无法继续进行等，导致某些重要功能不能使用，或可能带来一些安全性问题场景：1.实现的功能与需求不符2.核心功能的性能较差3.非核心功能出现异常A.查询或报表一点就报错;B.导入,导出的数据信息总数正确,但数据信息中的数据错误.如业务代码转译,交易帐号重新获取等;C.传给接口的数据不正确;4.安全性问题5.轻微的数值计算错误6.脚本问题A.脚本漏提交;B.脚本运行报错;C.脚本运行后,将数据库中的数据修改错误;7.页面或界面问题A.页面显示混乱,如大篇幅的文字或图片重叠.头尾位置颠倒等B.页面数据显示与数据库中的不一致;如金额,份额,清算日期,申请日期,扣划款状态等;C.页面或界面上的数据出现乱码.一般：定义：影响某些功能的使用，功能实现不完善,对产品使用影响不大.场景：1.非核心功能的性能较差2.核心功能的TAB键顺序不对3.容错性差在应该输入数字的地方输入了字母，系统没有给出提示，导致最终的操作失败4.易用性差下拉框中的数据有成百上千个，程序可以过滤一些无效数据而未进行过滤，造成用户操作不方便5.显示不完整字段的显示宽度不够，不能完整显示信息6.界面问题A.文字描述混乱，用户无法做出合理的判断7.简单的输入限制未放在前台进行控制8.删除操作未给出提示次要：定义：界面显示/相关提示信息/文字描述等有误,且不影响产品功能使用，场景：1.非核心功能的TAB键顺序不对2.长操作没有进度提示3.输入区域和只读区域没有明显区分4.提示信息不准确，显示格式不规范5.颜色刺眼6.文字在高亮之后看不清楚7.页面或界面问题A.页面上控件不对齐B.数据显示不对齐C.报表数据写到表格外,但不影响阅读D.可输入区域和只读区域没有明显的区分标志优化：定义：建议，不存在错误，但在功能、实用性、美观性等方面需要完善场景：1.界面风格不统一2.布局不合理3.字体与界面不协调4.图片和图标的含义不明确5.按钮大小不一致6.文字的对齐方式不合理7.数据显示的先后顺序不合理缺陷打回准则3个一般缺陷或者1个严重易现缺陷需求不明确，需求与设计不符合或者其他影响测试的情况修改内容不清晰不完整或者与设计需求不符合要进行代码审核的单子未执行代码审核约定开发组要进行内部联测的修改单没有同步提交相应联测说明修改单测试建议退回准则场景：1）需求、设计、测试建议及附件文档无法形成完整的测试资料，导致测试项遗漏或需确认才清晰；2）测试建议遗漏、错误和存在误导；3）需求、设计、测试建议，存在不符合情况，但并未作说明。
BUG等级划分方法
一、四级的划分方式：
1.BUG等级划分建议：
目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。
根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。
● 致命(可对应目前BUG体系中的“非常严重”)：
致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
具体基本上可分为：
○严重花屏
○内存泄漏
○用户数据丢失或破坏
○系统崩溃/死机/冻结
○模块无法启动或异常退出
○严重的数值计算错误
○功能设计与需求严重不符
○其它导致无法测试的错误
● 严重(可对应目前BUG体系中的“严重”)
严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
具体基本上可分为：
○功能未实现
○功能错误
○系统刷新错误
○语音或数据通讯错误
○轻微的数值计算错误
○系统所提供的功能或服务受明显的影响
● 一般(可对应于目前BUG体系中的“普通”)
一般性问题主要为：界面、性能缺陷
具体基本上可分为：
○操作界面错误(包括数据窗口内列名定义、含义是否一致) ○边界条件下错误
○提示信息错误(包括未给出信息、信息提示错误等)
○长时间操作无进度提示
○系统未优化(性能问题)
○光标跳转设置不好，鼠标(光标)定位错误
● 提示(可对应于目前BUG体系中的“轻微及建议”)
提示性问题主要为：易用性及建议性问题
具体基本上可分为：
○ 界面格式等不规范
○ 辅助说明描述不清楚
○ 操作时未给用户提示
○ 可输入区域和只读区域没有明显的区分标志
○ 个别不影响产品理解的错别字
○ 文字排列不整齐等一些小问题
○ 建议
注意：对于结构及硬件问题，由于产品测试部仅是进行辅助测试，碰到此类问题时，均将于定位于等级“致命”，具体情况由结构及硬件部门相关人员确认。
2.BUG发生率划分建议：
目前通用的对BUG发生率的划分主要有两种划分方法：一种是测试发生率：即按照特定步骤执行多次的BUG重现率;另外一种是用户使用发生率：即模拟用户在使用产品发生此问题的概率。
第一种方法计量精确简单，可操作性高，但不太符合产品的实际使用情况。
第二种方法，则需要推断用户使用某一业务的频率，因此计量相对没有第一种精确，操作性高，但比较符合产品的实际使用情况。
由于产品的最终使用总是用户，因此建议我司的BUG发生率采用第二种方法——即用户使用发生率。
用户使用发生率=用户类别*业务类别*测试发生率
● 用户类别：
我们公司的主要客户群有生产人员、客服人员、最终用户。
根据其对公司产品的生产、销量、声誉、维护的不同可以分配不同的权重(权重范围为0-1之间)。
如：生产人员——>0.3
客服人员——>0.5
最终用户——>1.0
● 业务类别：
业务类别根据具体项目的业务情况分为主要业务、次要业务及辅助业务。
业务类别的确认具有人为的主观因素，若需求文档有明确说明各个业务功能的优先级(业务功能优先级由“风险”，“复杂度”及“用户需要”在撰写需求时确认)，那么一般可参考此优先级来确认。
优先级高的为主要业务，优先级其次的为次要业务，其它为辅助业务(注：仅可作为参考，确认业务类别最好由市场相关人员来确认。
如产品经理，市场分析人员等。
)
若需求中没有明确说明各业务功能的优先级，哪么应当在测试开始前，召开由产品，研发及测试部门一同出席的会议，确认各业务功能的分类，并将其记录于需求文档中。
● 测试发生率
测试发生率为按照特定步骤执行多次的BUG重现率
测试发生率=BUG重现次数/按照特定步骤执行的总次数。
其中：对于概率性问题，执行的总次数应结果BUG的复杂程度执行(20-50次)
用户使用发生率等级划分：
如上所述，用户使用发生率=用户类别*业务类别*测试发生率，根据最终得到的用户使用发生率的值的不同，可以将用户使用发生率划分为如下几个等级(也可沿用旧等级划分，将<2%的问题划入等级“低”)：
二、四级划分方式
A类——严重错误，包括：
o 由于程序所引起的死机,非法退出
o 死循环
o 导致数据库发生死锁
o 数据通讯错误
o 严重的数值计算错误
B类——较严重错误，包括：
o 功能不符
o 数据流错误
o 程序接口错误
o 轻微的数值计算错误
C类——一般性错误，包括：
o 界面错误(详细文档)
o 打印内容、格式错误
o 简单的输入限制未放在前台进行控制
o 删除操作未给出提示
D类——较小错误，包括：
o 辅助说明描述不清楚
o 显示格式不规范
o 长时间操作未给用户进度提示
o 提示窗口文字未采用行业术语
o 可输入区域和只读区域没有明显的区分标志o 系统处理未优化
E类——测试建议（非缺陷）。
