软件缺陷管理之缺陷严重等级分类

软件缺陷管理之缺陷严重等

级分类

标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-

A类——严重错误，包括：

由于程序所引起的死机,非法退出

死循环

导致数据库发生死锁

数据通讯错误

严重的数值计算错误

需求未实现

文档与软件不符、文档严重不足、系统文档关键错误B类——较严重错误，包括：

功能不符

数据流错误

程序接口错误

轻微的数值计算错误

C类——中等错误。包括：

程序非正常终止但可通过其它输入来避免

系统边界错误

显示报表错误

数据处理、需求理解错误

系统文档一般错误

D类——一般性错误，包括：

界面错误(详细文档)

打印内容、格式错误

简单的输入限制未放在前台进行控制

删除操作未给出提示

系统操作不方便

E类——较小错误，包括：

辅助说明描述不清楚

显示格式不规范、查询报告格式错误

长时间操作未给用户进度提示

提示窗口文字未采用行业术语

可输入区域和只读区域没有明显的区分标志系统处理未优化

F类——测试建议（非缺陷）

缺陷等级划分

缺陷严重级别定义: 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： 软件的实际执行过程与需求有较小的差异；程序的提示信息描述容易使用户产生混淆。

软件缺陷管理流程图

软件缺陷管理办法 1.目的 本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。 2.适用范围 适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。 3.定义 3.1 术语 缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。 Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。 3.2 缺陷定义 （1）软件未达到需求规格说明书的功能； （2）软件出现了需求规格说明书指明不会出现的错误； （3）软件功能超出需求规格说明书的范围； （4）软件未达到需求规格说明书未指出但应达到的目标； （5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。 4.缺陷生命周期

4.1 缺陷生命周期图 4.2 缺陷状态说明 5. 缺陷处理过程 5.1 正常处理过程 （1）创建问题 在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。

（2）指派问题 创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。 如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。 （3）确认问题 通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。 当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。 如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。 （4）解决问题 此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。 开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。 如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。 （5）验证问题 创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。

测试缺陷等级定义

缺陷等级定义 目录 缺陷等级定义 (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.上线前最后一个版本配置管理出现问题

缺陷管理工具jira与mantis比较修订版

缺陷管理工具j i r a与 m a n t i s比较修订版 IBMT standardization office【IBMT5AB-IBMT08-IBMT2C-ZZT18】

Mantis与Jira对比 hjjlearning 一、安装对比 1、M antis安装 Mantis安装稍微比较麻烦一点，需要做多项配置，具体参考编写的“缺陷管理工 具Mantis搭建手册.doc”。 2、J ira安装 JIRA官方网站有制定好的安装包，只要一步一步next就可以安装完备，默认安 装的数据库为自带的HSQL，可以自己配置外置数据库，支持MySql， Sql2000,Orcale等主流数据库。 更换数据库可以参考官方文档。 注意一点：在用安装包进行安装JIRA，如果选中了安装成服务，好像在局域网其他电脑就访问不了，暂时没找到原因。如下图 图1 安装成服务 总体来说，在安装过程中，Mantis要比JIRA复杂一点。 二、JIRA介绍 1.JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。JIRA创建 的问题类型包括New Feature、Bug、Task和Improvement四种，还可以自己定义，

所以它也一是过程管理系统。Jira融合了项目管理、任务管理和缺陷管理，许多着名的开源项目都采用了JIRA。 JIRA 是目前比较流行的基于Java架构的管理系统，由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务，因此在开源领域，其认知度比其他的产品要高得多，而且易用性也好一些。同时，开源则是其另一特色，在用户购买其软件的同时，也就将源代码也购置进来，方便做二次开发。正因为其开放性，价格上自然也相当不菲，对于中小型的软件企业做项目管理，则又要另寻出路。 功能列表： 问题追踪和管理（问题类型包括New Feature-新功能、Bug-缺陷、Task-任务、Improvement-改进四种），可自定义； 问题跟进情况的分析报告； 对不同项目配置不同管理功能； 组件/模块负责人功能； 项目email地址功能； 无限制的工作流，可以自己定制工作流； 子任务功能； 邮件通知功能； CVS、SVN以及LDAP的集成功能；

几种常见缺陷管理工具

集中常见缺陷管理工具 （1）Mantis Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统，其功能与JIRA系统类似，都是以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上可能没有JIRA那么专业，界面也没有JIRA漂亮，但在实用性上足以满足中小型项目的管理及跟踪。 https://www.wendangku.net/doc/353373025.html,/TrackBack.aspx?PostId=1455738

作者：龚云卿 2005年8月 1 简介 缺陷管理贯穿于整个软件开发生命周期中, 是不可缺少的环节。Mantis是 PHP/MySQL/Web-based缺陷跟踪系统，Mantis当前版本为1.0.0a3。关于产品详细信息和支持，请访问主页。 2 基本特性 1) 个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件； 2) 支持多项目、多语言； 3) 权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动； 4) 主页可发布项目相关新闻，方便信息传播； 5) 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷； 6) 缺陷报告可打印或输出为CSV格式：支持可定制的报表输出，可定制用户输入域； 7) 有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel中进一步分析； 8) 流程定制不够方便，但该流程可满足一般的缺陷跟踪； 9) 可以实现与CVS集成：缺陷和CVS仓库中文件实现关联； 10) 可以对历史缺陷进行检索。 3 功能详细 3.1 概要 问题跟踪系统主要功能包括： 1) 多项目管理 2) 问题录入 3) 问题查询和关键词检索 4) 问题更新 5) 问题讨论

缺陷管理工具jira与mantis比较

Mantis与Jira对比 hjjlearning 一、安装对比 1、Mantis安装 ●Mantis安装稍微比较麻烦一点，需要做多项配置，具体参考编写的“缺陷管理工具 Mantis搭建手册.doc”。 2、Jira安装 ●JIRA官方网站有制定好的安装包，只要一步一步next就可以安装完备，默认安装的 数据库为自带的HSQL，可以自己配置外置数据库，支持MySql，Sql2000,Orcale 等主流数据库。 ●更换数据库可以参考官方文档。 ●注意一点：在用安装包进行安装JIRA，如果选中了安装成服务，好像在局域网其他电 脑就访问不了，暂时没找到原因。如下图 图1 安装成服务 总体来说，在安装过程中，Mantis要比JIRA复杂一点。 二、JIRA介绍 1.JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。JIRA创建的问 题类型包括New Feature、Bug、Task和Improvement四种，还可以自己定义，所以它也一是过程管理系统。Jira融合了项目管理、任务管理和缺陷管理，许多着名的开源项目都采用了JIRA。 JIRA 是目前比较流行的基于Java架构的管理系统，由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务，因此在开源领域，其认知度比其他的产品要高得多，而且易用性也好一些。同时，开源则是其另一特色，在用户购买其软件的同时，也就将源代码也购置进来，方便做二次开发。正因为其开放性，价格上自然也相当不菲，对于中小型的软件企业做项目管理，则又要另寻出路。

功能列表： ●问题追踪和管理（问题类型包括New Feature-新功能、Bug-缺陷、Task-任务、 Improvement-改进四种），可自定义； ●问题跟进情况的分析报告； ●对不同项目配置不同管理功能； ●组件/模块负责人功能； ●项目email地址功能； ●无限制的工作流，可以自己定制工作流； ●子任务功能； ●邮件通知功能； ●CVS、SVN以及LDAP的集成功能； ●丰富的自配置项目； ●丰富的插件配置； ●易用性良好； 2.JIRA优点与缺点 ●优点 a)用它管理项目，跟踪任务、bug，通过JIRA的邮件通知功能进行协作通知，在实 际工作中使工作效率提高很多，效果非常不错！安全性、可扩展性方面发挥到了 极致！ b)JIRA不仅仅是一个缺陷跟踪系统，通过Jira，可以整合客户、开发人员、测试人 员，各人各司其职，信息很快得到交流和反馈，让大家感到软件开发在顺利快速 的进行，朝意想的目标迈进。 c)丰富的插件及界面自定义功能，基本上可以满足项目的需要。

软件缺陷相关的标准-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版本计划中的正式版本）中基本上都需要进行验证，以保证系统所有的重要功能都能够正常实现。在测试过程中可以根据版本当前的具体情况进行安排是否进行测试。

缺陷分类分级管理

缺陷分类分级管理-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII

附录E： 缺陷分类分级管理 根据输变电设备运行管理标准中设备缺陷的分类原则，设备缺陷按其严重程度分为紧急、重大、一般。 1.一般缺陷：是指对近期安全运行影响不大的缺陷，可列入年、季检修计划或日常维护工作中去消除 2.重大缺陷：是指缺陷比较严重，但设备仍可短期继续安全运行，该缺陷应在短期内消除，消除前应加强监视 3.紧急缺陷; 是指严重程度以使设备不能继续安全运行，随时可能导致发生事故或危及人身安全的缺陷，必须尽快消除或采取必要的安全技术措施进行临时处理根据供电系统常用电气设备运行状况中的缺陷进行整理，对缺陷现状进行分类分级管理，并制定缺陷处理计划及措施，跟踪缺陷处理进度、完成情况，对已处理缺陷及时进行关闭，规范化管理设备缺陷，参照设备缺陷分类分级实施细则。

1 变电站设备缺陷分类标准 1.1 变压器（消弧线圈、接地变、站用变、电抗器参照执行）4 1.2 断路器5 1.3 隔离开关6 1.4 母线7 1.5 防雷设备8 1.6 电力电缆8 1.7 控制电缆9 1.8 继电器9 1.9 表计10 1.10 电力电容器11 1.11 电压、电流互感器、耦合电容器、阻波器11 1.12 继电保护及自动装置12 1.13 直流设备14 1.14 土建部分15 1.15 变电其它设备15 2 通讯、计算机、远动、消防系统分类标准16 2.1 通讯16 2.2 计算机系统17 2.3 远动部分18 2.4 消防系统18 3 电力线路设备缺陷分类标准19 3.1 导线及架空地线19 3.2 绝缘子及金具20 3.3 杆塔21 3.4 横担22 3.5 拉线22 3.6 柱上开关23 3.7 配电变压器及令克23 3.8 避雷器24 3.9 接地装置24 3.10 线路电力电缆25附件1：设备缺陷记录 25 附件2：线路缺陷记录26

缺陷等级划分

缺陷严重级别定义: 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）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现 功能，没有达到预期的效果。如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等

电力设备缺陷的分类标准

电力设备缺陷的分类标准 1、紧急缺陷 1、1变电部分 设备接头发热烧红、变色。 设备瓷件有明显裂缝。 设备内部有明显的放电声或异音。 设备的绝缘、温升等技术参数超过极限值。 主设备与地网没有可靠连接。 外绝缘有严重放电现象。 高、低压室、开关柜防小动物措施失效。 1、1、1变压器 冷却装置故障严重,影响出力或威胁安全运行。 分接开关操作卡阻或跳档。 铁芯接地电流不合格,串接电阻后仍不能满足运行要求,并有发展的趋势。 本体漏油严重或大量喷油。 套管漏油,套管油位超过下限,密封失效。 主变油箱进水。 潜油泵损坏,金属物可能进入油箱。 电气及油试验结果严重超标。 1、1、2高压断路器 操动机构有卡涩,运行中有拒合、拒分或误合、误分的现象,储能元件损坏, 液(气)压机构的压力超出闭锁限额,油开关严重漏油或大量喷油,不能保

证安全运行者; 开关短路开断电流不能满足运行要求,又无保证安全运行的措施,额定电流小于负荷电流者。 SF6开关设备的SF6气体质量不合格,或有严重漏气,其压力低于制造厂 规定的下限。 真空开关的真空泡有裂纹或严重漏气者。 真空开关的真空泡失去光泽、发红。 液(气)压机构油(气)泵频繁启动,打压间隔时间小于10分钟,连续5次及以上者。 断路器辅助接点、液(气)压闭锁接点失灵。 断路器绝缘拉杆脱落。 1、1、3 刀闸、母线 瓷件有破裂,刀闸触头铸铝件部分有裂纹。 刀闸严重锈蚀,以致操作卡阻,不能正常停送电。 母线一串绝缘子串上零值或破损瓷瓶片数110kV 3片、220kV 4片、500kV 4片及以上者。 1、1、4 电压互感器、电流互感器、电容式电压互感器、耦合电容器、阻波器 漏(气)油严重或大量喷油。 电压互感器二次回路失压、电流互感器二次回路开路。 电容式电压互感器、耦合电容器本体滴油。 阻波器拉杆脱落。

缺陷管理工具比较

缺陷管理工具比较 现在缺陷管理工具比较多，由于项目需要，我对一下几种缺陷工具做了以下比较：TestDirector：MI公司的缺陷管理工具，优点是：B/S构架模式；Windows平台；.可以定制流程；可以定制查询；可以定制功能域；可以定制用户角色，可以定制角色权限；可Email 通知；可以生产各种报表；支持多种数据库；可以与其他MI公司测试工具集成；安装配置较为简单，有可优化的工作流，可使用C改进优化系统。缺点是：价格太贵（呵呵，死结）；除与微软的Access接口比较好，其他数据库接口不是太完善；没有中文版（虽然有破解汉化版），缺少角色可视窗口配置，版本更新，但功能没有改进。 Mantis：优点，开源，不收费，B/S构架模式；Windows平台；可邮件通知，操作较为灵活。缺点：安装配置复杂，不收费的东西，界面也不够美观，有很多功能根本只是架子，没法真正使用，比如说添加附件。 BugFree:这款缺陷管理工具跟Mantis一样开源的，缺点优点也跟Mantis相近。 QAMonitor：这个工具很小巧，优点是操作简单，直观，对只有几个人的开发测试团队内部测试用很适合，并且是中文的。缺点是：基于C/S结构，项目配置需要到底层数据库中去配置，缺少项目定制客户界面，因为适合内部测试，所以没有全面的报表分析，没有Email通知。 Bugzero：安装配置比较复杂，需要单独安装java和tomcat。B/s 版本，价格还可以，国产软件，试用版是英文版，并且页面出现乱码，通过在线试用，流程不太清晰，界面不够客户（测试人员的职业病对每个软件的使用都已发现缺陷为目标）。 迅捷缺陷跟踪系统：安装配置简单，中文使用方便，流程控制较清晰，缺少邮件通知功能，缺陷参数少，界面粗糙，没有独立可管理的数据库。

缺陷等级的划分

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

○系统刷新错误 ○语音或数据通讯错误 ○轻微的数值计算错误 ○系统所提供的功能或服务受明显的影响 ● 一般(可对应于目前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以上有载调压 开关油室内渗漏

缺陷等级分类

1.1bug定义表 缺陷等级详细含义： 一级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。系统崩溃或挂起等导致系统不能继续运行。 包括以下各种错误： 1.由于程序所引起的死机,非法退出 2.死循环 3.数据库发生死锁 4.因错误操作导致的程序中断 5.重大功能错误 6.与数据库连接错误 7.数据通讯错误 二级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。 包括以下各种错误： 1.程序接口错误 2.因错误操作迫使程序中断

3. 系统可被执行，但操作功能无法执行（含指令） 4. 单项操作功能可被执行，但在此功能中某些功能（含指令参数的使用）无法被执行（对系统非致命的） 5. 在功能项的某些项目（选项）使用无效（对系统非致命的） 6.业务流程不正确 7.功能实现不完整，如删除时没有考虑数据关联 8.功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现 9. 报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误） 三级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。 包括以下各种错误： 1.操作界面错误（包括数据窗口内列名定义、含义是否一致） 2.打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误） 3.简单的输入限制未放在前台进行控制 4.删除操作未给出提示 5.虽然正确性不受影响，但系统性能和响应时间受到影响 6.不能定位焦点或定位有误，影响功能实现 7. 显示不正确但输出正确 8. 增删改功能，在本界面不能实现，但在另一界面可以补充实现。 四级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题。 包括以下各种错误： 1.界面不规范 2.辅助说明描述不清楚 3.输入输出不规范

软件缺陷管理

软件缺陷管理

————————————————————————————————作者：————————————————————————————————日期：

软件缺陷管理 1.什么是缺陷管理 世间万物都有着自己的生命历程,任何产品在生产过程中,从一开始创建它的过程中,产品缺陷就会逐惭产生,并可能缺陷数量越来越多,若在产品生命周期过程中不建立缺陷检测制度,对已发现的缺陷不采取有效的控制措施,最终可能导致产品无法具有相应的使用功能,产品生命周期就会提前结束,产品的生产是失败的.因此,必须建立一套完整的产品缺陷管理制度,针对具体的产品生产特征制定相应的缺陷检测、缺陷签定、缺陷处理、缺陷验收等一系列技术措施，不断的避免或纠正产品缺陷，使终使产品在其生命周期中处于可控状态。 2．缺陷管理的过程及方法 2．1缺陷的检测：由检测人员在产品的生产加工过程中，按照本行业的质量要求及检测手段随时对产品的全部或某项设计功能进行检查，如果不能达到设计要求（可能要求在某一范围内可认为是合格的），则认定这一环节存在缺陷，缺陷生命周期开始。 2．2 缺陷的签定：对部份产品的缺陷，由于检测人员还不能确定缺陷的全部相关信息，这时就应该组织缺陷的签定，通过采用专家评审、使用先进技术手段或设备等，得到缺陷的全部信息，为缺陷处理提供原始数据。 2．3缺陷的处理：生产人员从测试人员处得到缺陷信息后，就应根据缺陷所列内容结合产品的生产过程，检查缺陷可能出现在哪一个环节，应作如何改正，避免类似缺陷再度出现。已出现测试人员提出的缺陷的产品可否采用一定的方法可予纠正，并落实这些处理措施到生产过程中。 2．4缺陷的验收：生产人员将测试人员提现的缺陷处理完毕后，又反馈信息给测试人员，报告缺陷的处理情况，并请缺陷复测。测试人员根据以前的缺陷记录信息，对该缺陷再进行一次测试，如果测试结果在设计偏差范围内，则可认为该缺陷处理完毕，同时删除本产品的主条缺陷记录，该项缺陷的生命周期到此结束。若还不能达到设计偏差范围内，则将当前检测的信息形成新的缺陷记录提供给生产人员要求处理。 3．软件缺陷管理 软件测试管理的一个核心内容就是对软件缺陷生命周期进行管理。软件缺陷生命周期控制方法是在软件缺陷生命周期内设置几种状态，测试员、程序员、管理者从每一个缺陷产生开始，通过对这几种状态的控制和转换，管理缺陷的整个生命历程，直至它走入终结状态。 缺陷生命状态的定义: 每一个软件缺陷都规定了6个生命状态：Open、Working、Verify、Cancel、Close、Defer，它们的基本定义是： Open态---缺陷初试状态，测试员报告一个缺陷，缺陷生命周期开始； Working态---缺陷修改状态，程序员接收缺陷，正在修改中； Verify态---缺陷验证状态，程序员修改完毕，等待测试员验证； Close态---缺陷关闭状态，测试员确认缺陷被改正，将缺陷关闭； Cancel态---缺陷删除状态，测试员确认不是缺陷，将缺陷置为删除状态（不做物理删除）； Defer态---缺陷延期状态，管理者确认缺陷需要延期修改或追踪，将缺陷 置为延期状态；

缺陷等级划分规定

缺陷等级划分规定 １．缺陷等级划分规范 １．１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):系统的次要功能点或需求点没有实现；数据丢失或损坏。执行软件主要功能的测试用例导致系统出错，程序无法正常继续执行；程序执行过于缓慢或是占用过大的系统资源。 干扰性(Disturbing):一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等软件的实际执行过程与需求有较小的差异；程序的提示信息描述容易使用户产生混淆。 具体等级划分参照表如下:

测试文档二 bug严重程度和优先级(缺陷管理)

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

6 兼容性问题（用户群体大，影响严重） 7 数据不准，建单据报错 8 引发性新BUG（说明此单BUG是由于前面修改BUG或做的新需求导致其它模块出现新的错误。 一般（3类）一般级别-- 在时间许可的范围内修复，即界面、性能缺陷 1 只有在极端条件下才会重现的Bug 2 在特定配置情况下不会出现的Bug 3 操作界面错误（包括数据窗口内列名定义、含义是否一致） 4 边界条件下错误 5 提示信息错误 6系统未优化，性能问题 7 兼容性问题（有一定用户群体，影响较大） 低（4类）轻微-- 不影响当前发布，可以推迟到下一个发布中修复，即易用性及建设性问题 1 不能稳定重现的Bug 2 因为电脑上装有其他干扰软件产生的Bug 3 非功能性Bug, 如日志，错误回复等 4 界面规格不规范 5 辅助说明描述不清 6 操作时未给用户提示信息 7 个别不影响产品功能的错别字 8 文字排列不整齐

软件缺陷管理规范

软件缺陷管理规范 （ISO9001：2015） 1.目的 本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。 2.适用范围 适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。 3.定义 3.1 术语 缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。 3.2 缺陷定义 （1）软件未达到需求规格说明书的功能； （2）软件出现了需求规格说明书指明不会出现的错误； （3）软件功能超出需求规格说明书的范围； （4）软件未达到需求规格说明书未指出但应达到的目标； （5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。

4.缺陷生命周期4.1 缺陷生命周期图 4.2 缺陷状态说明

5. 缺陷处理过程 5.1 正常处理过程 （1）创建问题 在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。（2）指派问题 创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。 如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。 （3）确认问题 通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。 当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。 如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。 （4）解决问题 此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。

禅道系统_BUG流程分析

Bug的属性 Bug重现环境 这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本就无从下手。 操作系统 这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这就需要有真对性的设计与开发。对于不同的操作系统，其可能存在差异（如：win xp 与 win 7）或本质的区别（如 win 7 与 CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。浏览器 对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。 不同的浏览器之间（IE、 firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug 前提条件之一。 其它（这个“其它”非常重要） 对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。 对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本

软件的安装和使用造成影响。这些都是重现问题的必须描述的环境。 问题类型 根据JIRA的管理系统的划分，bug 只是问题的一种，它可以用于跟踪多种不同类型的问题（其实，他只是将bug做为一子类而已）。 JIRA系统缺省提供的问题类型（大部分的系统都可以自定义类型的，这样就增加了灵活性。） Bug : 测试过程、维护过程发现影响系统运行的缺陷。（这就是一般测试人员所提交的bug）New Feature : 对系统提出的新功能。（单个的小需求可以，如果大的话，就相当于一个需求，放到这里是不合理的。） Task : 需要完成的一任务。（开发或测试任务指派。） Improvement : 对现有系统功能的改进。（一般产品经理或产品体验师做的事）当然，不同的公司，他们的人员定位与职责是不太相同的，按照上面的分类，JIRA就不是简单的缺陷管理系统了，它涵盖一项目（或产品）所需要处理的任务、需求与缺陷。 Bug 类型： 这里缩小范围，单指我们测试人员在测试过程中发现的缺陷，发现产品缺陷其实就是测试人员工作的主要目的。当然，你要确定一个问题的类型，也需要对项目（或产品）有比较深的理解。是代码缺陷还是设计缺陷有时候就不太容易区分，当然，这个划分，对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。 下面看一些常见的分类：