当前位置：文档库 › bug类型：警告

bug类型：警告

Bx DM_BOXED_PRIMITIVE_TOSTRING 用。

Bx DM_NUMBER_CTOR 因为Number 构造函数的效率不高，推荐使用static 方法valueOf。

DB DB_DUPLICATE_BRANCHES 分支语句中的代码是相同的。因为代码重复，推荐删除分支语句的判断。

DLS DLS_DEAD_LOCAL_STORE 局部变量被赋值，但是之后赋的值没有被使用，所以推荐不对该局部变量赋值。

DLS DLS_DEAD_STORE_OF_CLASS_LITER

https://www.wendangku.net/doc/8411015698.html,ng.Class 的实例被保存到局部变量。因为这个

实

例不会被使用，推荐删除该实例。

Dm DM_BOOLEAN_CTOR 使用方法valueOf()比使用Boolean 的构造函数生成Boolean 对象更有效率，所以推荐使用方法

valueOf()。

Dm DM_STRING_CTOR 因为使用String（String）构造函数生成新字符串会浪费内存，推荐使用原有字符串。

Dm DM_STRING_TOSTRING 由于类型变换前后的类型都是String，所以推荐不进行类型变换。

Dm DM_STRING_VOID_CTOR 生成空字符串时使用了new String()构造函数。由于直接赋值空字符串「""」的效率较高，推荐直接赋值空字符串。

IP IP_PARAMETER_IS_DEAD_BUT_OVER

WRITTEN 由于对参数的修改会被忽视掉，所以推荐删除该代码。

ITA ITA_INEFFICIENT_TO_ARRAY 如果象「myCollection.toArray(new

Foo[myCollection.size()」一样传入指定长度的数组参数内部处理中不会生成新的数组，处理效率会提高。推荐传入和变换前Collection 的大小一样的数组。

J2EE J2EE_STORE_OF_NON_SERIALIZABLE

_OBJECT_INTO_SESSION

向本地变量进行了代入、后面没有使用过这値、建议避

开这个代入。

LI LI_LAZY_INIT_STATIC 在类String的方法equals()，空文字列被check了、建议在方法length（length() == 0）进行check。

LI LI_LAZY_INIT_UPDATE_STATIC 参数的変更内容、不是覆盖，只是去掉、所以建议削除。

ML ML_SYNC_ON_FIELD_TO_GUARD_CH

ANGING_THAT_FIELD

交给方法Collection.toArray()长度为0的数组。

「myCollection.toArray(new

Foo[myCollection.size()」那样、根据指定変換源的

Collection的长度、内部的処理中不生成新的数组、

処理効率会提高。建议修改为把长度和変換源的

Collection的size相同的数组交给方法。

Nm NM_CLASS_NAMING_CONVENTION 未使用分配的变量，建议将相应变量删除。

NP NP_ALWAYS_NULL 调用了値可能为null的局部变量，可能会例外发生NullPointerException，建议在调用前追加null检查。

NP NP_ALWAYS_NULL_EXCEPTION null可能的变量被参照、因为有例外NullPointerException発生的可能性、建议参照之前进行null check。

NP NP_LOAD_OF_KNOWN_NULL_VALUE DB接続関連的资源没有被发布。建议追加发布资源処理。

NP NP_UNWRITTEN_FIELD 例外発生時DB接続相关的资源未发布。建议将发布DB 接続相关的资源的処理追加到finally中。

NS NS_DANGEROUS_NON_SHORT_CIRCU

对象的参照明显不是null，建议将针对该参照的null

检查删除。

ODR ODR_OPEN_DATABASE_RESOURCE 由于DB 连接相关的资源没被释放，推荐追加释放资源的处理。

ODR ODR_OPEN_DATABASE_RESOURCE_E

XCEPTION_PATH

由于例异常发生时DB 连接相关资源没被释放，推荐把

DB连接相关的资源释放处理追加到finally 中。

OS OS_OPEN_STREAM 一直使用的是値为null的局部变量，建议使用定量null，代替局部变量。

OS OS_OPEN_STREAM_EXCEPTION_PAT

由于例外发生时，流没被关掉，所以推荐把流关闭的处

理追加到finally。

RCN RCN_REDUNDANT_NULLCHECK_OF_

NONNULL_VALUE

只是为了调用interrupted()方法而调用

Thread.currentThread()的。由于interrupted()方法

是static方法，因此，建议修改为

Thread.interrupted()的调用。

RCN RCN_REDUNDANT_NULLCHECK_OF_

NULL_VALUE

循环中，字符串是用String连接的，但是使用

StringBuffer连接更有効率，因此，建议使用

StringBuffer。

RCN RCN_REDUNDANT_NULLCHECK_WO

ULD_HAVE_BEEN_A_NPE

由于当对象是null 的情况下，对该对象的使用会导致

异常NullPointerException 的抛出，推荐在对象被使

用前进行null 检查。

RE RE_BAD_SYNTAX_FOR_REGULAR_EX

PRESSION

目前是使用String构造器由String对象生成新的

String对象，但是，由于原来的String对象可以使

用，所以，建议不生成没用的String对象，而使用原

来的String对象。

SA SA_LOCAL_SELF_ASSIGNMENT 由于局部变量对自身赋值没有意义，所以推荐删除该语句。

STI STI_INTERRUPTED_ON_CURRENTTHR

EAD

因为方法interrupted()是static，所以推荐修改成

Thread.interrupted()。

UCF UCF_USELESS_CONTROL_FLOW 因为控制语句没被使用，推荐删除该语句。

WMI WMI_WRONG_MAP_ITERATOR 和keySet 相比，使用entryKey 效率较高，推荐修改成entryKey。

缺陷等级划分

缺陷严重级别定义: 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等级划分方法一、测试 BUG等级划分标准 1、Blocker （崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。 2、 Critical （严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。 3、 Major （一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等 ( 该问题实际测试中存在最多，合理安排解决 BUG，解决率关系版本的优化程度 ) 4、 Minor （次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准 1、待处理（ new）：测试人员或用户发现新问题后提交的状态 2、已确认（ open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。 3、已处理（fixed ）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。 4、已修改（ closed ）：测试人员认为问题已经修改，通过验证，由测试人员设置。 5、仍存在（ reopened）：测试人员认为BUG未修复成功，问题仍然存在，由测试人员设置。 6、不是问题（ reject ）：研发人员确认不是BUG，或者建议与意见决定不采纳。 7、暂不处理（ hold ）：当前版本不做修改，后续版本再考虑，由研发人员或测试人员设置。三、BUG处理流程

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分类标准和考核办法

内蒙古华腾科技BUG分类标准和考核办法 V0.1 2010年7月

一、背景随着公司不断得发展壮大，原来小作坊式的软件开发模式也经历着转变，产品质量亟待加强。公司已做出了规划，明确了测试岗位和职责。为了更好的落实测试岗位的职责，规范测试结果的管理和考核，提升公司产品质量，特制定测试BUG分类标准和考核办法，使得公司对研发测试结果有个明确的评估。二、BUG分类标准测试BUG按照严重等级分为严重、普通、轻微、优化四类，按照BUG类别分为功能、界面、数据处理、流程、优化建议、性能、常识七类，对应各种BUG情形如下：（1）严重BUG情形：（1）由于程序造成系统崩溃、自身程序崩溃、网络中断、系统内存或文件资源耗尽、破坏或丢失数据库数据（2）功能类：需求功能未达到或与需求功能明显不一致的（3）数据类：数据处理造成后台数据冲突或不一致的（4）数据类：程序运行过程中出现数据丢失的或后台数据乱码的（5）流程类：分支流程不完整或相悖造成分支流程处理错误的；无限循环类的

（6）性能类：造成数据库连接资源耗尽的（非大并发量下的情形）（2）普通BUG情形：（1）功能类：查看、查询、分页、排序显示数据不正常的（2）界面类：页面编译错误、JavaScript错误、跳转错误、出现javaException页面（3）界面类：页面超时未响应、数据显示不完整或错位、页面未鉴权、页面显示乱码（4）界面类：输入校验不完整及造成的数据处理错误、页面操作提示信息与实际不符（5）性能类：处理大数据量出现程序错误的（6）常识类：明显违背正常习俗习惯的（3）轻微BUG情形：（1）功能类：重复或多余的功能，操作不直观、易用性不够（2）界面类：界面排版混乱、控件排列和格式不统一、焦点控制不合理、页面文字和提示信息表达不清晰、不完整或错别字的（4）优化BUG情形：凡以上未提及的不影响正常使用的情形。

缺陷等级的划分

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

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

BUG等级划分标准

B U G等级划分标准 Prepared on 22 November 2020

正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准 1、待处理（new）：测试人员或用户发现新问题后提交的状态 2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。 3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。 4、已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。 5、仍存在（reopened）：测试人员认为BUG未修复成功，问题仍然存在，由测试人员设置。 6、不是问题（reject）：研发人员确认不是BUG，或者建议与意见决定不采纳。 7、暂不处理（hold）：当前版本不做修改，后续版本再考虑，由研发人员或测试人员设置。三、BUG处理流程 1、紧急：崩溃、严重BUG处理流程（1-2天内解决） 2、优先：一般BUG处理流程（尽快处理） 3、普通：次要BUG处理流程（项目结束前处理）

BUG严重程度及优先级的划分

Bug严重程度及优先级的划分 Bug时，只定义Bug的Severity, 即该Bug的严重程度，而将Priority交给Project Leader 或Team Leader来定义，由他们来决定该Bug被修复的优先等级。某种意义上来说，Priority的定义要依赖于Severity，在大多数情况下，Severity越严重，那这个Bug的 Priority就越高。你知道如何合理定义bug的Sevrity么？通常Bug管理系统里Severity分为四个等级Blocker, Critical, Major, Minor/Trivial（也可自定义，但通常是这四个）, 而priority分为五个等级：Immediate, Urgent, High, Normal, Low。 Severity（严重程度） 1.Blocker（有妨碍的）:即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。 ?严重花屏 ?内存泄漏 ?用户数据丢失或破坏 ?系统崩溃/死机/冻结 ?模块无法启动或异常退出 ?严重的数值计算错误 ?功能设计与需求严重不符 ?其它导致无法测试的错误, 如服务器500错误 ? 2.Critical（紧要的）：即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。 ?功能未实现 ?功能错误 ?系统刷新错误 ?数据通讯错误 ?轻微的数值计算错误 ?影响功能及界面的错误字或拼写错误 ?安全性问题 ? 3. Major（严重的）：即界面、性能缺陷、兼容性。 ?操作界面错误（包括数据窗口内列名定义、含义是否一致） ?边界条件下错误

BUG发现率及严重程度重定义

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

● 一般（可对应于目前BUG体系中的“普通”）一般性问题主要为：界面、性能缺陷具体基本上可分为： ○ 操作界面错误（包括数据窗口内列名定义、含义是否一致） ○ 边界条件下错误 ○ 提示信息错误（包括未给出信息、信息提示错误等） ○ 长时间操作无进度提示 ○ 系统未优化（性能问题） ○ 光标跳转设置不好，鼠标（光标）定位错误 ● 提示（可对应于目前BUG体系中的“轻微及建议”）提示性问题主要为：易用性及建议性问题具体基本上可分为： ○ 界面格式等不规范 ○ 辅助说明描述不清楚 ○ 操作时未给用户提示 ○ 可输入区域和只读区域没有明显的区分标志 ○ 个别不影响产品理解的错别字 ○ 文字排列不整齐等一些小问题 ○ 建议注意：对于结构及硬件问题，由于产品测试部仅是进行辅助测试，碰到此类问题时，均将于定位于等级“致命”，具体情况由结构及硬件部门相关人员确认。 2．BUG发生率划分建议：目前通用的对BUG发生率的划分主要有两种划分方法：一种是测试发生率：即按照特定步骤执行多次的BUG重现率；另外一种是用户使用发生率：即模拟用户在使用产品发生此问题的概率。第一种方法计量精确简单，可操作性高，但不太符合产品的实际使用情况。第二种方法，则需要推断用户使用某一业务的

bug管理规范及流程

bug管理规范及流程 1、概述本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决； 2、关键角色及职责

3、Bug生命周期 4、Bug书写规范 4.1 BUG标题 1)以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问题； 2)描述问题时要简练、直接切入主题，但是要抓住要点；

3)偶现bug在主题前标注出现的次数； 4)有些模块功能比较多，可以在主题描述前标注上具体得操作；示例：【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息【偶现2次】添加载体库时程序停止运行 4.2重现步骤说明区域包括：步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志 1) 用数字编号，一步步的描述问题的重现步骤； 2) 不同的操作步骤产生不同的问题，需分别报bug；尽量做到一个bug汇报一个问题； 3) 偶现问题必须明确bug出现的时间、提供截图以及日志； 5、Bug解决方案当天提交的新建状态bug，对应的开发人员需在2天内全部审核一遍，将bug分成以下3类：拒绝、进行中、延期、反馈（给产品）；开发已修复的bug：将bug状态置为已解决；同时添加说明验证版本号、错误原因、解决办法；示例：验证版本：V1.0.1.1101（1101表示在11月1号可以验证）问题原因：未作条件判断解决方法：进行合理边界判断开发认为不是bug：将bug状态置为已拒绝；指派给bug提出者；同时注明拒绝理由；示例：

bug严重程度和优先级分类文档

bug严重级别和优先级别定义 Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。如下：最高级(1类)-- 阻止对后续功能的测试，通常适用于以下情况 1 模块无法启动或异常退出 2界面/功能Crash 导致一系列测试不能运行 3严重花屏 4数据丢失（用户数据，服务器数据） 5系统崩溃/死机/冻结 6 业务逻辑错误（数据计算错误：例如支付错误，业务流程缺失或者走错） 7功能设计和需求严重不符 8服务器400，500等错误次最高级（2类）- 在当前发布版本中必须修复，即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性 1 Bug 的出现导致软件没有完成用户的需求 2 系统刷新错误 3数值计算错误

4影响功能及界面的错误字或拼写错误 5 安全性问题 6 兼容性问题（用户群体大，影响严重）一般（3类）-- 在时间许可的范围内修复，即界面、性能缺陷 1 只有在极端条件下才会重现的Bug 2 在特定配置情况下不会出现的Bug 3 操作界面错误（包括数据窗口内列名定义、含义是否一致） 4 边界条件下错误 5 提示信息错误 6系统未优化，性能问题 7 兼容性问题（有一定用户群体，影响较大）低（4类）-- 不影响当前发布，可以推迟到下一个发布中修复，即易用性及建设性问题 1 不能稳定重现的Bug 2 因为电脑上装有其他干扰软件产生的Bug 3 非功能性Bug, 如日志，错误回复等 4 界面规格不规范

5 辅助说明描述不清 6 操作时未给用户提示 7 个别不影响产品功能的错别字 8 文字排列不整齐 9兼容性问题（用户群体不大，影响相对较小） Priority（优先级） 1 Immediate（立刻，一类）即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。 2 Urgent（紧要、优先，二类）即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。 3 High（高度重视，二类或者三类）即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。 4 Normal（正常，三类）即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。

BUG的严重级别分类

BUG的严重级别分类 Severity This field describes the impact of a bug. Blocker: Blocks development and/or testing work Critical: crashes, loss of data, severe memory leak Major: major loss of function Minor: minor loss of function, or other problem where easy workaround is present Trivial: cosmetic problem like misspelled words or misaligned text Enhancement: Request for enhancement Difference between priority and severity? "Priority" is associated with scheduling, and "severity" is associated with standards. "Piority" means something is afforded or deserves prior attention; a precedence established by order of importance (or urgency). "Severity" is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles, e.g. a severe code of behavīor. The words priority and severity do come up in bug tracking. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, give the team complete information so developers can understand the bug, get an idea of its 'severity', reproduce it and fix it. The fixes are based on project 'priorities' and 'severity' of bugs. The 'severity' of a problem is defined in accordance to the customer's risk assessment and recorded in their selected tracking tool. A buggy software can 'severely' affect schedules, which, in turn can lead to a reassessment and renegotiation of 'priorities'

bug等级及优先级定义

一维 BUG等级及优先级定义版本V1.0 编制单位：东莞市中科一维大数据有限公司编制日期：2016年6月28日

日期版本修订说明修订人 2015-10-20 V1.0 创建文档黄敏飞

目录第一章介绍 (4) 1.1 文档目的 (4) 1.2 文档范围 (4) 1.3 读者对象 (4) 1.4 参考资料 (4) 1.5 术语表 (4) 第二章 BUG严重程度分级 (5) 2.1 宕机__毁灭BUG (5) 2.2 崩溃__致命BUG (6) 2.3 很严重__严重BUG (6) 2.4 小错误__一般性BUG (6) 2.5 文字__较小BUG (6) 2.6 细节__建议 (7) 第三章 BUG优先级划分 (7)

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

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

bug缺陷等级划分

引言编写的目的为了规范测试等级的评定标准，使软件测试规范化、标准化、统一开发人员和测试人员对bug等级评定的认知标准，特拟定《软件测试bug等级评定规范》预期读者本文档预期读者为经理、开发人员、测试人员，以便能尽快熟悉bug等级评定标准，属于公司内部文档使用范围本文档试用于公司各个软件系统的文档测试、功能测试、安全性测试、性能测试等评定规范bug等级标准依据产生错误对客户使用造成的后果严重性将抽测出的问题按五个等级划分，即（A类、B 类、C类、D类、E类）分级方法及简要说明 A类：致命缺陷 1、数据库发生死锁，致使用户无法登录系统或已登录用户无法运行正常的操作；（例：IE浏览器无响应、IE浏览器自动关闭） 2、死循环，导致程序无法运行 3、由于程序所引起的系统无法启动、死机、蓝屏、非法退出 4、在数据或安全方面存在重大问题，导致软件不具可用性，或核心功能项无法使用； 5、由于设计的缺陷，导致软件使用过程中出现内存不足、死机、重启、系统崩溃或软件使用过程中存在较明显的障碍，局部功能错误等； B类：严重缺陷（严重错误） 1、数据操作未对数据生效；生效后影响其他正常数据（数据冗余）；出现错误或没有对事物进行回滚；数据计算、数据约束、数据输入、数据输出错误、数据丢失；（例：边界值、特殊字符、数据乱码、数据库表中有过多的空字段） 2、程序设计中未考虑到安全问题，正式上线后将造成系统、数据安全隐患；（例：1、输入url可以查看到系统根目录；2、地址存在跨站点脚本编制的安全隐患；3、存在sql注入造成的安全隐患；4、系统存在重复用户登录；5、存在Xpath注入的安全隐患；6、信息泄露；7、系统未实现session验证功能） 3、功能错误、功能输入非预期结果、功能遗漏、功能冗余、系统功能没有满足需求说明书的要求； 4、页面没有刷新功能 5、页面出现500、400、404等错误或页面抛出异常（例：页面显示sql语句异常） 6、连接页面错误；（例：页面跳转错误、死连接）

Bug等级划分

五级分类法 Urgent（紧急）----严重错误，包括以下各种错误： 1、由于程序所引起的死机，非法退出 2、死循环 3、数据库发生死锁 4、因错误操作导致的程序中断 5、功能错误（需求未实现） 6、与数据库连接错误 7、数据通讯错误 Very high（非常高）----较严重错误，包括以下各种错误： 1、程序错误 2、程序接口错误 3、数据库的表、业务规则、缺省值未加完整性等约束条件High（高）----一般性错误，包括以下各种错误： 1、操作界面错误（包括数据窗口内列名定义、含义是否一致） 2、打印内容、格式错误 3、简单的输入限制未放在前台进行控制 4、删除操作未给出提示 5、数据库表中有过多的空字段 Medium（中）----较小错误，包括以下各种错误： 1、界面不规范 2、辅助说明描述不清楚 3、输入输出不规范 4、长操作未给用户提示 5、提示窗口文字未采用行业术语 6、可输入区域和只读区域没有明显的区分标志七级分类法 Blocker----中断缺陷： 1、客户端程序无响应，无法执行下一步操作 Critical----临界缺陷： 1、功能点缺失，客户端无效页

Major----较严重缺陷： 1、功能点没有满足需求 Normal----普通缺陷： 1、数值计算错误 2、javascript错误 Minor----次要缺陷： 1、界面错误与UI需求不符 2、打印内容、格式错误 3、程序不健壮，操作未给出明确提示 Trivial----轻微缺陷： 1、辅助说明描述不清楚 2、显示格式不规范、数字、日期等格式 3、长时间操作未给用户进度提示 4、提示窗口文字未采用行业术语 5、可输入区域和只读区域没有明显的区分标志 6、必输项无提示，或者提示不规范Enhancement----测试建议、其它（非缺陷） 1、以客户角度的易用性测试建议 2、通过测试挖掘出来的潜在需求

BUG等级划分标准

BUG等级划分方法一、测试BUG等级划分标准 1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。 2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。 3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度) 4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准 1、待处理（new）：测试人员或用户发现新问题后提交的状态 2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。 3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。 4、已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。 5、仍存在（reopened）：测试人员认为BUG未修复成功，问题仍然存在，由测试人员设置。 6、不是问题（reject）：研发人员确认不是BUG，或者建议与意见决定不采纳。 7、暂不处理（hold）：当前版本不做修改，后续版本再考虑，由研发人员或测试人员设置。三、BUG处理流程

BUG等级划分标准

B U G等级划分标准 Document number：NOCG-YUNOO-BUYTT-UU986-1986UT