缺陷严重级别的定义

严重级别越高的BUG不一定优先级越高；严重级别越低的BUG不一定优先级越低；

缺陷严重程度分类的定义(精)

缺陷严重程度分类的定义： Critical：An observation is defined as“Critical”when any one or more of the following four conditions apply： ● Any non-conformance or non-compliance that will or already has adversely affected product performance meeting specification，safety，therapeutic efficacy，or regulatory requirements。 ● Any non-conformance or non-compliance that if allowed to continue，may result in product rejection，field action，or serious regulatory action(e.g. Warning Letter or similar) ● The observation is a repeat“Critical”or“Major”observation,or relates to failure to meet a commitment made to a regulatory authority。 ● The observation represents the complete absence of one or more quality system elements or system components necessary to meet regulatory requirements. Ma jor:An observation is defined as“Major” when any one or more of the following two conditions apply： ● Any non-conformance or non-compliance that may or may have adversely affected product performance meeting specification，safety，therapeutic efficacy，or regulatory requirements。 ● Any isolated non-compliance in not reporting or reporting late any required regulatory/health authority reports notifications.(Note:frequent occurrences represent a “Critical”observation.)

缺陷等级划分

缺陷严重级别定义: 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 ：测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现。严重(Serious) BUG：系统的次要功能点或需求点没有实现；数据丢失或损坏。执行软件主要功能的测试用例导致系统出错，程序无法正常继续执行；程序执行过于缓慢或是占用过大的系统资源。一般(Minor) BUG：软件的实际执行过程与需求有较大的差异；系统运行过程中偶尔（<10%）有出错提示或导致系统运行不正常。微小(Information) BUG：软件的实际执行过程与需求有较小的差异；程序的提示信息描述容易使用户产生混淆。

bug级别定义及流转说明

Bug说明文档2015年6月25日

修订历史记录（A-添加，M-修改，D-删除）

目录 1.简介 (4) 1.1.编写目的 (4) 1.2.文档范围 (4) 1.3.预期读者 (4) 2.BUG优先级(PRIORITY) (4) 2.1.I MMEDIATE（立刻）——P1 (4) 2.2.U RGENT（紧要、优先）——P2 (4) 2.3.V ERY H IGH(高度重视)——P3 (5) 2.4.H IGH（重视）——P4 (5) 2.5.N ORMAL（正常）——P5 (5) 2.6.L OW（稍缓）——P6 (5) 3.BUG严重程度(SEVERITY) (5) 4.BUG状态及流转 (6) 4.1.B UG状态及说明 (6) 4.2.B UG状态流转方式 (7) 5.BUG内容 (8)

1. 简介 1.1. 编写目的本文档主要确定bug优先级、bug严重程度、bug流转方式、bug内容。 1.2. 文档范围 Bug优先级和bug严重程度的定义，bug流转方式和bug内容的确定。 1.3. 预期读者本文档阅读人员包括项目经理、开发人员、测试人员以及其他相关人员。 2. Bug优先级(Priority) 优先级大致分为6个级别P1~P6，P1~P6分别为： Immediate（立刻）、Urgent （紧要、优先）、Very High（高度重视）、High（高度重视）、Normal（正常）、Low （稍缓）。 2.1. Immediate（立刻）——P1 即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。2.2. Urgent（紧要、优先）——P2 即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。

测试缺陷等级定义

缺陷等级定义目录缺陷等级定义 (1) B/S架构(Web)测试的缺陷等级定义： (1) C/S架构(Client)测试的缺陷等级定义： (2) 服务器及接口测试的缺陷等级定义： (4) B/S架构(Web)测试的缺陷等级定义： A: 致命 1.正常的用户操作导致浏览器崩溃或无响应 2.产品核心功能没有实现或无法使用 3.程序实现与需求严重不符 4.其他导致无法测试的错误 5.严重的数值计算错误 6.存在致命的安全漏洞 7.Bug被重开3次以上含3次 8.上线前最后一个版本配置管理出现问题 B: 严重 1.产品功能实现不正确 2.主业务流程对应的功能未实现，阻碍测试继续进行 3.严重的兼容性问题和页面样式问题，如：页面样式严重错乱，导致页面控件无法正常定位； 4.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率20%以上） 5.程序实现与需求功能上不符 6.其他导致部分模块无法测试的错误 7.主要数值计算错误 8.严重的功能逻辑错误 9.Bug被重开2次 10.上线前进入最后一轮测试时版本配置管理出现问题 C: 较严重 1.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率10%以下） 2.用户非常规操作导致浏览器崩溃或影响系统性能的问题

3.程序上非主要功能与需求上功能描述不符 4.功能实现错误但不影响主要流程 5.轻微的数值计算错误 6.页面出现JS错误且导致某功能不可用 7.兼容性导致的主要功能问题 8.系统中用户权限实现有误 9.初始化错误 10.Bug被重开1次 11.上线前进入测试时，提交测试的过程版本配置管理出现问题 12.操作界面UI类的严重错误，易造成大量投诉，产生较坏影响力 D: 一般性问题主要为：界面类、容错类缺陷 1.操作界面UI类的一般性错误 2.边界条件下错误 3.提示信息错误（包括未给出信息、信息提示错误等） 4.界面中操作焦点错误（如按Tab键未顺序操作，弹出其他窗口后主界面焦点位置错误等） 5.输入域的相关问题，如：输入框长度判断错误； E:易用性和建议类缺陷 1.界面格式等不规范 2.辅助说明描述不清楚 3.操作时未给用户提示 4.可输入区域和只读区域没有明显的区分标志 5.个别不影响产品理解的错别字 6.文字排列不整齐等一些小问题 7.建议类型的缺陷 C/S架构(Client)测试的缺陷等级定义： A: 致命 1.程序无法运行/模块无法启动/异常退出 2.程序导致操作系统崩溃/死机/蓝屏 3.程序实现与需求严重不符 4.程序实现与技术文档严重不符 5.程序实现与开发规范严重不符 6.导致产品无法继续进行测试的缺陷 7.程序占用资源高（比同类产品高出50%以上） 8.内存、GDI等泄漏 9.Bug被重开3次以上含3次 10.上线前最后一个版本配置管理出现问题

缺陷级别定义和优先级定义

附件一：缺陷级别定义和优先级定义1、缺陷级别定义

2、缺陷优先级定义

注：当缺陷被Reopen时，建议通过有效途径通知相关人员，特别是严重级别为high和view high。 3、缺陷报告规范 ?在项目执行阶段，发现的所有问题都需要提交缺陷管理库－CQ中相应的Project库中，主要包括软件需求、开发程序缺陷、各种需要审核的文档等方面的内容； ?缺陷报告的填写，需要将问题的重现步骤写清晰，建议安1、2、3...形式提交，且缺陷的相关外部测试条件需要说明详细，缺陷标题要简明、扼要，不要用过于笼统和模糊的语言加以描述，根据需要适当的将出现的场景、日志等信息以附件形式提交； ?对于缺陷的回归，应在CQ中的Comments中注明回归的版本号，并依据问题的严重级别对回归的结果做相应的描述。 ●具体的缺陷提交流程如下(针对测试人员)

在缺陷的管理中，对于新增的Rejected和Suspend的缺陷，需要定期时常整理确认，对于未经项目经理、开发组长、测试组长和产品经理确认的缺陷，开发人员无权Rejected/Suspend，同时对于达成共识的Rejected缺陷一定要将意见写入CQ 库中的comments,对于Suspend状态的缺陷，建议要注明由于什么原因被刮起，在什么时间和条件下在处理等信息。在测试任务完成以后，缺陷库中的缺陷状态应只以三种状态存在：Closed、经过确认并达成共识的Rejected/Suspend。 4、缺陷跟踪测试人员对其发现的缺陷有义务和责任进行全程的跟踪。从缺陷的提交一直到缺陷的关闭，在这一整套的过程中，测试人员应该一丝不苟的进行把关，不要让错误轻易的从手边遛走。要定期的向开发组通报缺陷状态，同时及时的更新缺陷库中缺陷的状态。在一定的条件和时间内，还要对以关闭的缺陷做回归测试。制定有效而可行的回归测试时间表，尽可能的减少由回归测试间隙产生的测试逃逸。5、缺陷分析对于缺陷数据库，测试人员应该经常维护更新，并对缺陷的状态，数量，分布

BUG级别定义标准

文件编号：TDdoc-bug 杭州网阔信息科技有限公司 BUG级别定义标准拟制部门：测试部版本号：V1.6.0 修改日期：2015-05-24 版本修改记录版本号修改描述作者日期

目录一、主要分类 (4) 二、主要内容 (4) 1.依据优先级分类标准 (4) 1.1定义 (4) 1.2.分类标准 (4) 1.1.1 紧急................................................................................. 错误！未定义书签。 1.1.2 高..................................................................................... 错误！未定义书签。 1.1.3 中..................................................................................... 错误！未定义书签。 1.1.4 低..................................................................................... 错误！未定义书签。 2.依据严重程度分类标准 (5) 2.1 定义 (5) 2.2.分类标准 (5) 2.2.1 紧急................................................................................. 错误！未定义书签。 2.2.2 非常高............................................................................. 错误！未定义书签。 2.2.3 高..................................................................................... 错误！未定义书签。 2.2.4 中..................................................................................... 错误！未定义书签。 2.2.5 低..................................................................................... 错误！未定义书签。 2.3注意事项 (6) 三、错误分类具体说明条例 (6) 3.1文案错误 (6) 3.2图片错误 (6) 3.3链接错误 (7) 3.4前后模块不一致 (7) 3.5需求问题 (7) 3.6实现与需求不符 (7) 3.7功能性错误 (7) 3.8出现调试代码 (8) 3.9页面格式错误 (8) 3.10关联性错误 (8) 3.11程序性能低下 (8) 3.12缺少容错性处理 (8) 3.13配置问题 (8) 3.14兼容性问题 (8) 3.15校检错误 (9) 3.16程序引起的安全问题 (9) 3.17功能易用程度低 (9) 3.18遗留问题 (9) 3.19暂时无法实现技术问题 (9) 3.20数据流 (9)

出生缺陷的定义分类和危害

出生缺陷的定义、分类及危害一、出生缺陷的定义出生缺陷又称先天缺陷，是指由于先天性、遗传性和不良环境等原因引起的出生时存在的各种结构性畸形和功能性异常的总称。是导致流产、死胎、死产、新生儿死亡和婴儿夭折的重要原因。出生缺陷包括形态上的畸形(如脊柱裂)、细胞的异常(如先天性白血病)、染色体异常(如21-三体综合征)、分子的异常(如苯丙酮尿症)等。也包括精神、行为等方面的异常。二、出生缺陷的分类根据出生缺陷特点分为变形缺陷，裂解缺陷，发育不良，畸形缺陷四类。根据出生缺陷的严重程度可将其分为重大和轻微的缺陷两类，前者是指需进行较复杂的内科、外科及矫形处理的出生缺陷，后者则不需进行复杂处理。根据发生情况出生缺陷可分为三类：①三胚层形成紊乱，多发生在胚胎第15-18天，常见神经管与肠管相通、内脏反位、连体畸胎等三种；②神经管闭合过程紊乱，导致脑、脊髓发育不全，进而引起椎弓、颅骨及邻近皮肤出现异常，常见于无脑畸形、脑膨出、脊柱裂等畸形；③器官系统发生和形成过程中的紊乱，种类多，可分为胚体升高过程紊乱、器官原基发生过程紊乱、器官发生过程后期紊乱、性别决定和分化过程中的紊乱等几类。

在常见的出生缺陷有： 1．神经系统畸形：无脑畸形、脑膨出、脊柱裂、先天性脑积水、小头畸形、脑性瘫痪； 2．头部器官畸形：先天性白内障、小眼畸形、小耳畸形、副耳及耳凹、小下颌； 3．腹壁缺损及疝：腹裂畸形、脐膨出、膀胱外翻、膈疝、脐疝、腹股沟斜疝； 4．消化系统畸形：腭裂、唇裂、食道闭锁、狭窄和食道气管瘘、先天性肥大性幽门狭窄、先天性肠闭锁和先天性肠狭窄、先天性巨结肠、直肠或肛门闭锁；概论-常见的出生缺陷 5．先天性心脏病：房间隔缺损、室间隔缺损、动脉导管未闭、法洛四联症、完全性大动脉转位、肺动脉狭窄； 6．泌尿生殖系统畸形：尿道下裂、先天性肾囊肿、隐睾、外生殖器两性畸形。 7．四肢畸形：足变形、多指（趾）畸形、并指（趾）畸形、肢体短缺畸形、先天性髋关节脱位； 8．皮肤畸形：血管瘤、色素痣； 9．遗传代谢病及多发畸形：21-三体综合征、苯丙酮尿症、肝糖原累积病、软骨营养障碍。三、危害出生缺陷是世界范围内围产儿、婴儿死亡的主要原因，并导致大

BUG生命周期及优先级、严重级划分

黑盒测试用例的设计方法第一章BUG生命周期对BUG处理开发负责人：对每条BUG进行分配，标注处理意见，给定优先级。问题分配时，应可能将咨询类、理解错误类等问题处理掉，而不是直接打开，分配给开发人员。有可能是需求问题，分配给需求人员。把状态置为：Open或者Rejected. 开发人员：分析BUG，写出问题原因，修改BUG；实行BUG优先原则，严重程度高优先修改，修改完成后，把BUG状态置为：Fixed.

测试人员：对修改问题进行验证后，验证通过后把BUG状态置为：Closed；验证不通过，把BUG状态置为：Reopen。第二章严重级别划分 Urgent：致命错误致命错误通常有如下情况： 1、需求书中的重要功能未实现； 2、造成系统崩溃、死机,并且不能通过其它方法实现功能； 3、常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。 Very High：严重错误严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，如： 1、重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误； 2、重要功能不能按正常操作实现，但可通过其它方法可实现； 3、错误的波及面广，影响到其它重要功能正常实现； 4、密码明文显示； 5、C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的。 High：一般错误程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，如： 1、次要功能不能正常实现； 2、操作界面错误（包括数据窗口内列名定义、含义不一致）； 3、打印内容、格式错误； 4、查询错误，数据错误显示；

软件质量BUG等级定义

有限公司软件质量BUG等级定义版本<1.1>

修订历史记录

1、对Bug严重程度的分级缺陷级别定义 A类――致命BUG 包括以下各种错误： 1．由于程序所引起的死机,非法退出。 2．程序死循环。 3．数据库发生死锁。 4．与数据库连接错误。 5．主要功能没有实现。 6．因错误操作导致的程序中断。 B类――严重BUG 包括以下各种错误： 1.程序错误但不影响系统和其它程序运行的。 2.程序接口错误。 3.数据库的表、业务规则、缺省值未加完整性等约束条件。 4.次要功能没有实现或间接发生的（经过几步不相关操作后发生的）导致主要需求不能实现。 5.主要界面的文字错误等。 6.功能错误。 C类—一般性错误包括以下各种错误： 1．非主要操作界面错误（包括数据窗口内列名定义、含义是否一致） 2．间接发生的（经过几步不相关操作后发生的）导致次要需求不能正常实现。 3．打印内容、格式错误 4．简单的输入限制未放在前台进行控制 D类—较小错误包括以下各种错误：不影响软件的功能，但影响软件的品质。 1．界面不规范 2．辅助说明描述不清楚 3．输入输出不规范 4．长操作未给用户提示 5．提示窗口文字未采用行业术语 6．可输入区域和只读区域没有明显的区分标志 E类—测试建议测试人员从测试角度对软件提出的合理化的改进建议，由项目经理决定是否采纳。 2、对Bug现在程度的分级

每次出现：出现概率100%；经常出现：出现概率大于20%；很少出现：出现概率小于20%；出现一次：在整个测试工作中只出现一次。 3、测试人员对软件的评估测试人员对软件的评估主要依据测试计划中所制定的输出准则和最后遗留的Bug状况。 A类－－致命Bug，一般认为发布的软件中不允许存在。 B类－－严重Bug，每一万行代码中允许遗留2－3条。 C类－一般性Bug，每一万行代码中允许遗留3－6条。 D类－一较小Bug，由项目经理决定注销或遗留。 E类－一测试建议，由项目经理决定注销或遗留。

软件缺陷相关的标准-V1.0

目录 1前言 (2) 2文档范围 (2) 3文档对象 (2) 4.用例级别 (2) 5.BUG等级划分 (3) 6.BUG发生率 (4) 7.Bug修改优先级 (5) 8.BUG修改优先级与BUG严重性的分别 (7)

1前言为了使技术平台开发的软件测试更加规范，STE组制定了一系列和缺陷相关的标准。制定此标准的另一目的是便于平台和产品的相关人员对STE在平台中提出的软件缺陷的等级和修改优先级达成共识。 2文档范围描述了技术平台开发中和软件缺陷相关的内容。内容包括：用例级别、Bug等级、Bug 发生率、Bug修改优先级。 3文档对象技术开发全体软件成员及其他组的相关人员。 4.用例级别用例级别表明该用例的重要程度。用例的重要性并不对应用例可能造成的后果，而是对应用例的基本程度，一个可能导致死机的用例未必是高级别的，因为其触发条件可能相当生僻。测试用例的级别分4级，如下表。下面是用例级别的具体分类和内容： Level 1-级别“1”：基本该类用例涉及系统正常的基本功能。该用例执行的失败会导致多处重要功能无法运行的。如果不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试都是没有意义的，因为他们大多数肯定要失败。此级别用例用于版本提交时作为“版本冒烟测试通过准则”。如存在不通过的项目时可考虑重新提交版本，例如“申请书不能添加成功”或者“WIFI不能连接”等。1级用例的数量应受到控制。 Level 2-级别“2”：重要该类测试用例涉及系统的重要功能。主要包括一些功能交互相关、各种应用场景、使用频率较高的正常功能测试用例。该类用例最常执行以保证功能是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。该类测试用例在非回归的系统测试版本（即在新Feature和TPM版本计划中的正式版本）中基本上都需要进行验证，以保证系统所有的重要功能都能够正常实现。在测试过程中可以根据版本当前的具体情况进行安排是否进行测试。

Bug等级分类定义

不能完全满足系统要求，系统停止运行，系统的重要功能无法运行，系统崩溃或者挂起等导致系统不能继续运行。修改优先级为最高，该级别问题需要立即修改。 1、系统崩溃； 2、导致程序重启、死机或者非法退出； 3、关键功能不能实现使得后续工作无法进行； 4、死循环； 5、数据丢失或异常。高级问题：严重的影响系统要求或基本功能的实现，且没有更正方法（重新安装或重新启动该软件不属于更正方法）。使系统不稳定、或破坏数据、或产生错误结果、或部分功能无法执行，而且常规操作中经常发生或非常规操作中不可避免的主要问题，系统无法满足主要的业务要求，性能、功能或可用性严重降低。修改优先级为高，该级别需要程序员尽快修改。 1、功能不符合需求、实现不正确； 2、数据计算错误； 3、程序接口错误； 4、误操作迫使程序中断或者报错。中级问题：系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。修改优先级为中，该级别需要程序员修改。 1、数据长度不一致； 2、内容或格式错误； 3、响应速度较慢； 4、提示不正确但输出结果正确； 5、操作界面错误（包括数据窗口内列名定义、含义是否一致）； 6、简单的输入限制未放在前台进行控制； 7、虽然正确性不受影响，但系统性能和响应时间受到影响。

使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方面等需要完善的小问题。修改优先级为低，该级别需要程序员修改或不修改。 1、界面不规范； 2、辅助说明描述不清楚； 3、输入输出不规范； 4、长时间的操作未给用户提示； 5、提示用语不规范； 6、可输入区域和只读区域没有明显的区分标志； 7、必填项与非必填项没有加以区别； 8、界面不能及时刷新，影响功能实现； 9、功能模块名称、标题等不一致； 10、界面、网页、图片出现错别字。建议优化：希望提出的建议进行但不强制进行的修改。不会给发布的准确性或可用性带来任何严重影响。修改优先级为低，该级别需要程序员修改或不修改。 1、各种提示框信息使用不统一； 2、界面显示或描述建议； 3、光标跳转设置不好，光标定位错误； 4、其他建议性问题。

BUG级别定义标准v1.1

BUG级别定义标准

目录一、主要分类 (3) 二、主要内容 (3) 1.依据优先级分类标准 (3) 1.1定义 (3) 1.2.分类标准 (3) 1.1.1 Urgent等级 (3) 1.1.2 High等级 (3) 1.1.3 Medium等级 (3) 1.1.4 Low等级 (3) 2.依据严重程度分类标准 (3) 2.1 定义 (3) 2.2.分类标准 (4) 2.2.1 Blocker等级 (4) 2.2.2 Major等级 (4) 2.2.3 Normal等级 (4) 2.2.4 Minor等级 (4) 2.2.5 Trivial等级 (4) 2.3注意事项 (4) 三、错误分类具体说明条例 (5) 3.1文案错误 (5) 3.2图片错误 (5) 3.3链接错误 (5) 3.4前后模块不一致 (5) 3.5需求问题 (5) 3.6实现与需求不符 (6) 3.7功能性错误 (6) 3.8出现调试代码 (6) 3.9页面格式错误 (6) 3.10关联性错误 (6) 3.11程序性能低下 (6) 3.12缺少容错性处理 (7) 3.13配置问题 (7) 3.14兼容性问题 (7) 3.15校检错误 (7) 3.16程序引起的安全问题 (7) 3.17功能易用程度低 (7) 3.18遗留问题 (8) 3.19暂时无法实现技术问题 (8) 3.20数据流 (8)

一、主要分类 BUG类型标准主要分两类：依据优先级分类。依据严重程度分类。二、主要内容 1.依据优先级分类标准 1.1定义优先级：指一个BUG相对于其他BUG对于公司的影响，解决的及时性。 1.2.分类标准 1.1.1Urgent等级 ?系统无法工作 ?测试无法继续正常工作 ?特殊情况：如重要客户（项目重要性） 1.1.2High等级 1.1.3Medium等级 1.1.4Low等级 2.依据严重程度分类标准 2.1定义严重程度：指一个BUG对于用户造成的影响，风险和可视性。

出生缺陷的定义分类和危害

出生缺陷的定义分类和危害集团企业公司编码：（LL3698-KKI1269-TM2483-LUI12689-ITT289-

出生缺陷的定义、分类及危害一、出生缺陷的定义出生缺陷又称先天缺陷，是指由于先天性、遗传性和不良环境等原因引起的出生时存在的各种结构性畸形和功能性异常的总称。是导致流产、死胎、死产、新生儿死亡和婴儿夭折的重要原因。出生缺陷包括形态上的畸形(如脊柱裂)、细胞的异常(如先天性白血病)、染色体异常(如21-三体综合征)、分子的异常(如苯丙酮尿症)等。也包括精神、行为等方面的异常。二、出生缺陷的分类根据出生缺陷特点分为变形缺陷，裂解缺陷，发育不良，畸形缺陷四类。根据出生缺陷的严重程度可将其分为重大和轻微的缺陷两类，前者是指需进行较复杂的内科、外科及矫形处理的出生缺陷，后者则不需进行复杂处理。根据发生情况出生缺陷可分为三类：①三胚层形成紊乱，多发生在胚胎第15-18天，常见神经管与肠管相通、内脏反位、连体畸胎等三种；②神经管闭合过程紊乱，导致脑、脊髓发育不全，进而引起椎弓、颅骨及邻近皮肤出现异常，常见于无脑畸形、脑膨出、脊柱裂等畸形； ③器官系统发生和形成过程中的紊乱，种类多，可分为胚体升高过程紊乱、器官原基发生过程紊乱、器官发生过程后期紊乱、性别决定和分化过程中的紊乱等几类。

bug分级及优先级定义

Bug分级及优先级定义文档编号：{文档编号} 当前版本号：0.1 最初发布日期：2013-4-5 最新修订日期：2013-6-21 公司名称：深圳市海亚科技发展有限公司地址：深圳市龙岗区宝龙工业城诚信路8号亚森创新科技产业园办公楼9楼邮编：518000

版本历史版本/状态作者起止日期备注 0.1 揭亮华2013-4-5 0.2 揭亮华2013-6-21 添加blocker级bug严重程度

第1章文档介绍 (4) 1.1 文档目的 (4) 1.2 文档范围 (4) 1.3 读者对象 (4) 1.4 参考资料 (4) 1.5 术语表 (4) 第2章 Bug严重程度分级 (5) 第3章 Bug优先级划分 (8) 第4章 Bug修改优先级划分 (9)

第1章文档介绍 1.1 文档目的确定Bug严重程度分级以及优先级划分 1.2 文档范围 Bug严重程度和优先级划分定义 1.3 读者对象研发中心 1.4 参考资料序号文档名称版本1 1.5 术语表序号术语解释 1.数据数据库内的数据。我们的班级管理系统有用到数据库管理班级、学生、教师、试卷、成绩等信息，白板软件也有用到数据库管理软件用户 2.内存泄漏内存泄漏也称作“存储渗漏”，用动态存储分配函数动态开辟的空间，在使用完毕后未释放，结果导致一直占据该内存单元。直到程序结束 3.漏洞系统中的安全缺陷。软件或协议的具体实现或系统安全策略上存在的缺陷，从而可以使攻击者能够在未授权的情况下访问或破坏系统

第2章 Bug严重程度分级 BUG类型BUG现象举例0级1级2级3级4级5级功能类软件崩溃、死机√ 功能设计与需求规格说明书不一致,实现0-50% √ 功能设计与需求规格说明书不一致,实现51%-80% √ 功能设计与需求规格说明书不一致,实现81%-99% √ 数据类数据丢失√ 获取数据的路径不符要求,但操作成功√边界值未做限制√ 数据存储、读取、处理错误√ 内存泄漏√ 电脑资源使用过高√ 长时间事务处理,无提示√ 界面类安装、卸载界面图片文字的错误√ 公司名称、软件名称、版权、版本文本、图片信息错误√ 进入软件不做操作就能发现的文字、颜色、图形错误√ 进入软件需要一步操作才能发现的文字、颜色、图形错误√ 进入软件需要两步操作才能发现的文字、颜色、图形错误√ 进入软件需要两步以上操作才能发现的文字、颜色、图形错误 √软件UI与设计不一致√ 界面设计不规范,没有考虑易用性问题√ 信息类提示信息不正确√必填信息无提示√必要操作无提示信息√ 安全类一般用户正常使用就能发现的软件漏洞√ 程序员深入分析后才能发现的软件漏洞√用户权限问题√ 随机类随机产生的软件崩溃bug，很难重现√ 随机产生的软件功能性bug，很难重现√ 建议类测试人员对软件提出的建议√

设备缺陷范围及分类标准

设备缺陷范围及分类标准 A.1 设备缺陷管理范围 ——变电站一、二次设备； ——防止电气误操作的闭锁装置； ——通讯、远动、计量系统及其辅助设备； ——变电设备构架、基础、电缆沟道； ——生产性建筑物、照明、给排水、通风、消防、保安系统； ——电力电缆及附件； ——架空线路、架空地线、绝缘子、金具、杆塔、拉线及基础； ——线路防护及交叉跨越； ——防雷保护装置、接地引下线和接地装置； ——配电设备； ——可能影响系统安全运行的其它因素术语和定义。 A.2 设备缺陷的分类设备紧急缺陷重大缺陷一般缺陷变电通用部分1.设备瓷件有明显裂缝。 2.设备内部有明显的放电声或异常声响。 3.主设备与地网连接线断裂。 4.外绝缘有严重放电现象。 5.设备接头发热严重、变红、变色。 1.35kV及以上电压等级设备试验超周期且无相应的批准手续。 2.高、低压室、开关柜防小动物措施失效。 3.基础下沉。 4.设备接头发热。 1.设备接头温度超过同类运行设备的温度（无明显变化）。 2.其他不影响设备运行的缺陷主变压器（消弧线圈、接地变、站用变、电抗器参照执行）1.绝缘油色谱试验重要指标超标。 2.油中烃类、氢气产气速率超过 10%/月。 3.电气预防性试验主要项目不合格。 4.套管破损、裂纹，并有严重放电声。 5.测温装置全部损坏或失灵。 6.主变压器强油循环冷却器全停。 7.油浸变压器油位异常。 8.有载调压开关动作异常，极限位置不能闭锁。 9.内部有异常响声。 10.铁芯接地电流超过规定，串接电阻后仍不能满足运行要求，并有发展趋势。 12.铁芯或外壳接地不良。 1.引线桩头螺丝松动连接处发热。 2.绝缘油化学、电气性能不良，气相色谱数据指示可能有潜伏故障。 3.温度指示不准确，超温信号异常（失灵）。 4.基础下沉。 5.冷却设备不全，尚不影响出力。 6.油位指示与温度监视线不对应。 7.达不到铭牌或上级批准的出力，温升及上层油温超过容许的数值。 8.本体漏油（五分钟内有油珠垂滴）。 9.铁芯多点接地致使接地电流超标。 1.变压器渗油。（1min以上一滴或未见滴油但油迹非常大，超过主变表面积1/10以上） 2.附件震动大。 3.引线或接线桩头有严重电晕。 4.预试数据合格，但与历史数据比较有明显变化。 5.变压器绕组轻微变形。 6.其他不影响变压器运行的缺陷。 7.呼吸器变色达 2/3以上有载调压开关油室内渗漏

CMM5定义BUG等级

按照CMM5中定义的规范：致命是严重影响产品的BUG，比如操作手册的错误，需求的错误等。严重是产品中使功能无法实现的BUG，比如某个功能无法运行，GUI长时间僵死没有响应。一般是某个BUG的发生，只影响了一个功能，而其他功能可以正常运行。提示就是一些GUI的问题，或者友好性的问题。执行的bug是最严重的，即优先级1的bug，除此之外所有导致应用程序崩溃掉的bug也列入到优先级1中；[url=javascript.:;] 其他[/url]功能性bug列入比较严重的bug的队伍，即优先级2；界面上的bug列为一般的，即优先级3 实践过程中推行的就是这种bug分级制度。这种分级制度比较主观，使用到一个bug优先级划分文档中列出的优先级1的bug特征：优先级1类的bug还应该包括功能严重不符合产品说明书这种类型的bug a) 应用程序某个模块功能未实现（包括整个模块不能运行） b) 用户的信息被破坏或者丢失 c) 可重现的不可避免的崩溃，死锁 d) 功能和性能急剧衰退 e) 严重的内存泄漏 f) 导致功能无法正常使用的UI设计（UI响应迟缓） g) 其他的确，这些bug优先级划分很明确，让人一目了然并且觉得很有道理，可是拿到实际中一用，麻烦开始来了。因为某些描述仍然不够详细，含混不清的描述诸如“功能和性能急剧衰退”，碰到这种描述，不同的人会有不同的理解，而不同的理解必然会带来各种各样的问题。因此，笔者在实践中逐渐摒弃了这种做法，并开始逐步推广笔者自己刚才提到的粗放式bug优先级划分方法。对于该划分方法，笔者还需要进一步的说明。笔者刚才提到的“严重影响测试执行的bug”其实也是指系统的基本功能或者核心功能，比如新建编辑删除功能中，对于同样是信息为保存到[url=javascript.:;]数据库[/url]——即新建后记录未添加到数据库，编辑后记录未更新，删除后数据仍然存在于数据库中——这时候笔者仅仅将新建功能的该bug置于优先级1中，编辑删除bug则置于优先级2中。这种方法与很多正统的方法很不一致，因为在很多划分方法中“信息未保存”都是优先级1的bug。但是笔者自认为这样做是有理由的：当新建功能发生该类型bug而编辑删除功能正常时，编辑删除功能仍然无法测试或者实现（因为没有数据啊），这在客户的江渡看来会直接视为新建编辑删除功能均未实现。新建功能正常而编辑或者删除功能失效，则不会影响到其他功能的使用（当仅编辑功能失效的时候，新建和删除功能并不会受到影响），测试人员仍然进行新建删除功能的[url=javascript.:;]功能测试[/url]，客户依然可以使用新建和删除功能。当然，笔者使用上面的划分方式还有其他的原因——基于bug管理和测试开发工作的顺利推进。读者可能会注意到，使用上面的bug划分方式会减少优先级1的bug的数量，笔者这样做是因为笔者在bug管理中推介的方式是优先级1的bug不允许推迟到下一个工作日修改。试想，如果优先级1的bug的数量如果过多自然

缺陷等级的划分

BUG等级划分方法一、四级的划分方式： 1.BUG等级划分建议：目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。 ● 致命(可对应目前BUG体系中的“非常严重”)：致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。具体基本上可分为： ○严重花屏 ○内存泄漏 ○用户数据丢失或破坏 ○系统崩溃/死机/冻结 ○模块无法启动或异常退出 ○严重的数值计算错误 ○功能设计与需求严重不符 ○其它导致无法测试的错误 ● 严重(可对应目前BUG体系中的“严重”) 严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。具体基本上可分为： ○功能未实现 ○功能错误

○系统刷新错误 ○语音或数据通讯错误 ○轻微的数值计算错误 ○系统所提供的功能或服务受明显的影响 ● 一般(可对应于目前BUG体系中的“普通”) 一般性问题主要为：界面、性能缺陷具体基本上可分为： ○操作界面错误(包括数据窗口内列名定义、含义是否一致) ○边界条件下错误 ○提示信息错误(包括未给出信息、信息提示错误等) ○长时间操作无进度提示 ○系统未优化(性能问题) ○光标跳转设置不好，鼠标(光标)定位错误 ● 提示(可对应于目前BUG体系中的“轻微及建议”) 提示性问题主要为：易用性及建议性问题具体基本上可分为： ○ 界面格式等不规范 ○ 辅助说明描述不清楚 ○ 操作时未给用户提示 ○ 可输入区域和只读区域没有明显的区分标志 ○ 个别不影响产品理解的错别字

Bug定义规范

BUG定义规范Revision History

1.目的对BUG概念、BUG提交和验证、BUG状态、BUG严重程度等内容进行定义和规范，以便进一步指导我们的测试工作 2.概念 BUG:软件中存在的瑕疵，可能会导致软件失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷 3.BUG管理工具以Quality Center 9.0为提交、跟踪等工具 4.BUG提交和验证要求以QC中的字段为准提交时必选字段有：摘要，跟踪类型，检测者，检查日期，计划关闭版本，可重现，分派给，严重程度，状态，描述验证后，需要修改字段：关闭于版本，关闭日期，状态BUG描述模板如下： [问题概要]: [重现步骤]: 步骤1. 步骤2. [隔离分析]: [期望结果]: [重现概率]: [Test Case No.]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） [Test Case]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） QC中优先级和严重程度的区别：优先级由软件开发人员填写，严重程度由测试人员填写计划关闭版本定义：有2重含义：1.由测试人员填写当前发现bug的版本号；2.开发人员必须在此版本上修改 5.BUG验证开发人员必须提供修改此bug会涉及到的功能点列表，并将此信息填写到bug描述中。测试人员除验证此bug外，还需要将开发列出的功能点逐一验证，同时写入自己考虑到的功能点验证情况来自需求和测试自己提交的问题，测试人员都需要验证，并填写测试结果，其中来自自己的bug，若验证通过，则修改状态为“关闭”；来自需求人员的bug，则修改状态为“验证完毕”，由需求人员来关闭（适用于胜算组）。 6.BUG状态流程在正在BUG生命周期中，可能会经历很多状态，如：新建、提交验证、已关闭、重新打开、已挂起、重复提交等。新建：新发现的问题提交验证：开发修改bug后，会将状态变为提交验证，让测试工程师来执行验证操作已关闭：测试工程师经过验证后，发现此问题已经被修复，则修改状态为已关闭