A类——严重错误，包括：
? 由于程序所引起的死机,非法退出
? 死循环
? 导致数据库发生死锁
? 数据通讯错误
? 严重的数值计算错误
? 需求未实现
? 文档与软件不符、文档严重不足、系统文档关键错误B类——较严重错误，包括：
? 功能不符
? 数据流错误
? 程序接口错误
? 轻微的数值计算错误
C类——中等错误。包括：
? 程序非正常终止但可通过其它输入来避免
? 系统边界错误
? 显示报表错误
? 数据处理、需求理解错误
? 系统文档一般错误
D类——一般性错误，包括：
? 界面错误(详细文档)
? 打印内容、格式错误
? 简单的输入限制未放在前台进行控制
? 删除操作未给出提示
? 系统操作不方便
E类——较小错误，包括：
? 辅助说明描述不清楚
? 显示格式不规范、查询报告格式错误
? 长时间操作未给用户进度提示
? 提示窗口文字未采用行业术语
? 可输入区域和只读区域没有明显的区分标志? 系统处理未优化
F类——测试建议（非缺陷）
软件缺陷管理办法 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，系统将自动指派回给解决者。
缺陷严重级别定义: 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中延期处理部分。
缺陷等级定义 目录 缺陷等级定义 (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.上线前最后一个版本配置管理出现问题
缺陷管理工具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的集成功能；
软件缺陷管理制度 软件项目测试组 文档编号： 编写人：编写日期：2018年3月20日 审核人：审核日期： 审批人：审批日期： 1
修订历史记录 日期版本说明作者 1
目录 软件缺陷管理制度 (1) 修订历史记录 (1) 目录 (1) 第1章总则 (1) 第2章职责 (1) 第3章缺陷类型 (1) 3.1 文档缺陷 (1) 3.2 设计缺陷 (2) 3.3 配置缺陷 (2) 3.4 界面交互缺陷 (2) 3.5 数据校验缺陷 (3) 3.6 查询统计缺陷 (3) 3.7 功能缺陷 (3) 3.8 性能缺陷 (3) 3.9 安全性缺陷 (4) 第4章缺陷管理流程 (4) 4.1 新增（提交） (4) 4.2 定位 (4) 4.4 解决 (4) 4.5 否决 (4) 4.6 推迟处理 (4) 4.7 回归验证 (5) 4.8 再打开 (5) 4.9 关闭 (5) 第5章缺陷记录 (5) 5.1编号 (5) 5.2项目 (5) 5.3发布版本 (5) 5.4 功能模块 (5) 5.5 缺陷描述 (5) 5.6 重现步骤 (5) 5.7严重程度 (6) 5.8 优先级 (6) 5.9 状态 (6) 5.10 负责人 (6) 5.11 处理意见 (7) 1
5.12 处理记录（解决的办法） (7) 第6章附录 (7) 2
第1章总则 为了加强部门管理工作，建立规范的缺陷管理制度，提高工作水平，根据公司和部门的 有关规定，制定缺陷管理制度。 本缺陷管理制度适用于工程技术部。各测试，研发人员应当依据本制度的规定，规范工 作，保证软件质量。 软件缺陷又被叫做Bug。所谓软件缺陷，即为软件中存在的某种破坏正常运行能力的问 题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的 需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护 过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的 失效或违背。 软件缺陷的管理分为四个阶段。包括：缺陷提交、明确指明缺陷类型、缺陷修复、缺 陷回归验证。 第2章职责 项目人员应对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到一定 标准。包含内容如下： 2.1测试人员在提供的缺陷模板中新建或重新打开缺陷。 2.2测试人员提交的缺陷将反馈给项目负责人，由项目负责人安排开发人员修复缺陷。 2.3开发人员修复缺陷后，记录处理时间及处理结果，并将文档及时反馈给测试人员验 证。 2.4测试人员验证缺陷后，记录验证时间及验证结果，并提交给项目负责人。 第3章缺陷类型 缺陷类型是指根据缺陷的自然属性划分的缺陷种类。共分为九类，包括：文档缺陷、设 计缺陷、配置缺陷、界面交互缺陷、数据校验缺陷、查询统计缺陷、功能缺陷、性能缺陷、 安全性缺陷。 3.1 文档缺陷 文档缺陷是指软件相关文档不满足其完整性、正确性、一致性、易理解性、易浏览性的要求。 1
集中常见缺陷管理工具 （1）Mantis Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统，其功能与JIRA系统类似，都是以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上可能没有JIRA那么专业，界面也没有JIRA漂亮，但在实用性上足以满足中小型项目的管理及跟踪。 https://www.doczj.com/doc/4d13392262.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) 问题讨论
软件缺陷管理制度 软件项目测试组
修订历史记录
目录 软件缺陷管理制度 (1) 修订历史记录 (1) 目录 (1) 第1章总则 (1) 第2章职责 (1) 第3章缺陷类型 (1) 3.1 文档缺陷 (1) 3.2 设计缺陷 (2) 3.3 配置缺陷 (2) 3.4 界面交互缺陷 (2) 3.5 数据校验缺陷 (3) 3.6 查询统计缺陷 (3) 3.7 功能缺陷 (3) 3.8 性能缺陷 (3) 3.9 安全性缺陷 (4) 第4章缺陷管理流程 (4) 4.1 新增（提交） (4) 4.2 定位 (4) 4.4 解决 (4) 4.5 否决 (4) 4.6 推迟处理 (4) 4.7 回归验证 (5) 4.8 再打开 (5) 4.9 关闭 (5) 第5章缺陷记录 (5) 5.1 编号 (5) 5.2 项目 (5) 5.3 发布版本 (5) 5.4 功能模块 (5) 5.5 缺陷描述 (5) 5.6 重现步骤 (5) 5.7 严重程度 (6) 5.8 优先级 (6) 5.9 状态 (6) 5.10 负责人 (6) 5.11 处理意见 (7) 5.12 处理记录（解决的办法） (7) 第6章附录 (7)
第1章总则 为了加强部门管理工作，建立规范的缺陷管理制度，提高工作水平，根据公司和部门的有关规定，制定缺陷管理制度。 本缺陷管理制度适用于工程技术部。各测试，研发人员应当依据本制度的规定，规范工作，保证软件质量。 软件缺陷又被叫做Bug。所谓软件缺陷，即为软件中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。 软件缺陷的管理分为四个阶段。包括：缺陷提交、明确指明缺陷类型、缺陷修复、缺陷回归验证。 第2章职责 项目人员应对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到一定标准。包含内容如下： 2.1测试人员在提供的缺陷模板中新建或重新打开缺陷。 2.2测试人员提交的缺陷将反馈给项目负责人，由项目负责人安排开发人员修复缺 陷。 2.3开发人员修复缺陷后，记录处理时间及处理结果，并将文档及时反馈给测试人 员验证。 2.4测试人员验证缺陷后，记录验证时间及验证结果，并提交给项目负责人。 第3章缺陷类型 缺陷类型是指根据缺陷的自然属性划分的缺陷种类。共分为九类，包括：文档缺陷、设计缺陷、配置缺陷、界面交互缺陷、数据校验缺陷、查询统计缺陷、功能缺陷、性能缺陷、安全性缺陷。 3.1 文档缺陷 文档缺陷是指软件相关文档不满足其完整性、正确性、一致性、易理解性、易浏览性的要求。满足以下一或多种情况：
输变电设备缺陷分类参考标准－-变电站设备缺陷分类标准 ?根据中国南方电网有限责任公司的有关输变电设备运行管理标准中设备缺陷的分类原则，设备缺陷按其严重程度分为紧急、重大、一般三类。本参考根据供电系统常用电气设备运行状况中的缺陷进行整理。各公司可以根据所管辖设备的特点引用此附件,发电厂可以结合所管辖设备的特点,参照制定相应的设备缺陷分类实施细则。 目次 1 变电站设备缺陷分类标准 3 1．1?变压器(消弧线圈、接地变、站用变、电抗器参照执行）3? １.2?断路器?４ 1.3?隔离开关5? 1.4?母线?６ １.5?防雷设备7? 1.6?电力电缆7 1.7 控制电缆８ 1.8 继电器8 1．9 表计9 １．10?电力电容器10? １.1１?电压、电流互感器、耦合电容器、阻波器10? 1.1２继电保护及自动装置11? 1.13 直流设备12 1.1４?土建部分13 1.1５变电其它设备１４
2 通讯、计算机、远动、消防系统分类标准14 2.1?通讯1?４ 2.2 计算机系统1?６ 2．３远动部分16 2．４?消防系统1７3 电力线路设备缺陷分类标准1８ 3.1?导线及架空地线18 ３．2?绝缘子及金具19? 3．3 杆塔20? 3．4?横担20 3.5 拉线2?１ 3．6 柱上开关21 3.7?配电变压器及令克2?２ 3.8 避雷器22 3.9 接地装置2?３ 3.10?线路电力电缆23 ?1 变电站设备缺陷分类标准 1.1 变压器(消弧线圈、接地变、站用变、电抗器参照执行） 1.1.1紧急缺陷 1.1.1.1绝缘油不合格或呈酸性、水份严重超标、气相色谱分析重要指标超标或有明显
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)丰富的插件及界面自定义功能，基本上可以满足项目的需要。
软件缺陷管理流程 目录 1 、BUG管理流程 (1) 2 、报告缺陷注意事项 (2) 3 、需要注意的地方 (3) 4 、Bug的严重级别 (3) 1、BUG管理流程
2、报告缺陷注意事项 1．测试人员提交新缺陷时，尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、（建议），并尽量截图； 2.测试人员在精简语句的同时，应该再仔细检查BUG描述是否会产生误解的地方。测试人 员应该尽量避免使用模糊的，会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的，不会产生争执的词语； 3 不要使用感叹号或其它表现个人感情色彩的词语或符号； 4. 不要使用含糊的词语（例如，好像，似乎）来描述发现的现象；
5. 当BUG指派给你，在下一个版本发布之后，第一时间跟踪BUG的修复情况。3、需要注意的地方 当你发现一个BUG时，请考虑如下问题： 1. 同一软件中的相似功能是否有相同的问题？ 2. 其他的浏览器是否有相同的问题？ 3. 其他的软硬件配置是否有相同的问题？ 4. 其他的区域是否有相同的问题？ 5. 以前的版本是否有相同的问题？ 4、Bug的严重级别 目前，BUG严重级别分为：严重缺陷、较严重缺陷、一般性缺陷、建议性缺陷。 一、严重缺陷主要包括： 1、由于程序所引起的死机,非法退出； 2、死循环； 3、数据库发生死锁； 4、因错误操作导致的程序中断； 5、功能错误； 6、与数据库连接错误； 7、程序错误； 8、程序接口错误。 二、较严重缺陷 1操作界面错误（包括数据窗口内列名定义、含义是否一致）； 2、打印内容、格式错误； 3、简单的输入限制未放在前台进行控制； 4、删除操作未给出提示； 5、数据库表中有过多的空字段。
电力设备缺陷的分类标 准 Document serial number【NL89WT-NY98YT-NC8CB-NNUUT-NUT108】
电力设备缺陷的分类标准1、紧急缺陷 变电部分 设备接头发热烧红、变色。 设备瓷件有明显裂缝。 设备内部有明显的放电声或异音。 设备的绝缘、温升等技术参数超过极限值。 主设备与地网没有可靠连接。 外绝缘有严重放电现象。 高、低压室、开关柜防小动物措施失效。 变压器 冷却装置故障严重，影响出力或威胁安全运行。 分接开关操作卡阻或跳档。 铁芯接地电流不合格，串接电阻后仍不能满足运行要求，并有发展的趋势。 本体漏油严重或大量喷油。 套管漏油，套管油位超过下限，密封失效。 主变油箱进水。 潜油泵损坏，金属物可能进入油箱。 电气及油试验结果严重超标。 高压断路器
操动机构有卡涩，运行中有拒合、拒分或误合、误分的现象，储能元件损坏， 液（气）压机构的压力超出闭锁限额，油开关严重漏油或大量喷油，不能保 证安全运行者； 开关短路开断电流不能满足运行要求，又无保证安全运行的措施，额定电流 小于负荷电流者。 SF6开关设备的SF6气体质量不合格，或有严重漏气，其压力低于制造厂规定的下限。 真空开关的真空泡有裂纹或严重漏气者。 真空开关的真空泡失去光泽、发红。 液(气)压机构油(气)泵频繁启动，打压间隔时间小于10分钟，连续5次及以 上者。 断路器辅助接点、液(气)压闭锁接点失灵。 断路器绝缘拉杆脱落。 刀闸、母线 瓷件有破裂，刀闸触头铸铝件部分有裂纹。 刀闸严重锈蚀，以致操作卡阻，不能正常停送电。 母线一串绝缘子串上零值或破损瓷瓶片数110kV 3片、220kV 4片、500kV 4片及以上者。
缺陷严重级别定义: 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）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现 功能，没有达到预期的效果。如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等
缺陷管理工具比较 现在缺陷管理工具比较多，由于项目需要，我对一下几种缺陷工具做了以下比较：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 版本，价格还可以，国产软件，试用版是英文版，并且页面出现乱码，通过在线试用，流程不太清晰，界面不够客户（测试人员的职业病对每个软件的使用都已发现缺陷为目标）。 迅捷缺陷跟踪系统：安装配置简单，中文使用方便，流程控制较清晰，缺少邮件通知功能，缺陷参数少，界面粗糙，没有独立可管理的数据库。
电力设备缺陷的分类标准 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 电压互感器、电流互感器、电容式电压互感器、耦合电容器、阻波器 漏（气）油严重或大量喷油。 电压互感器二次回路失压、电流互感器二次回路开路。 电容式电压互感器、耦合电容器本体滴油。 阻波器拉杆脱落。
软件缺陷管理
————————————————————————————————作者：————————————————————————————————日期：
软件缺陷管理 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):一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等软件的实际执行过程与需求有较小的差异；程序的提示信息描述容易使用户产生混淆。 具体等级划分参照表如下:
软件缺陷管理制度 XX软件有限公司 软件项目测试组
修订历史记录
目录 软件缺陷管理制度 (1) 修订历史记录 (1) 目录 (1) 第1章总则 (1) 第2章缺陷提交 (1) 第3章缺陷分析定位 (1) 第4章缺陷修复 (2) 第5章缺陷回归验证 (2) 第6章缺陷管理 (2) 第7章缺陷类型 (3) 第8章缺陷严重程度 (5) 第9章缺陷优先级 (5) 第10章缺陷状态 (6) 第11章附录 (6)
第1章总则 为了加强部门管理工作，建立规范的缺陷管理制度，提高工作水平，根据公司和部门的有关规定，制定缺陷管理制度。 本缺陷管理制度适用于研发二部。各测试，研发人员应当依据本制度的规定，规范工作，保证软件质量。 软件缺陷又被叫做Bug。所谓软件缺陷，即为软件中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。 软件缺陷的管理分为四个阶段。包括：缺陷提交、明确指明缺陷类型、缺陷修复、缺陷回归验证。 第2章缺陷提交 缺陷提交阶段需要提交缺陷报告，缺陷报告必须详细描述缺陷内容。缺陷描述的内容包含缺陷操作步骤，实际结果和期望结果，明确指明缺陷类型，缺陷严重程度，缺陷优先级，缺陷状态，以及软件版本，提交人，提交日期等信息。 第3章缺陷分析定位 缺陷分析定位阶段需要根据缺陷报告的内容对缺陷进行分析和定位。缺陷分析和定位是相关人员根据缺陷报告中对缺陷的详细描述查找重现缺陷，确定缺陷产生的原因，明确缺陷所处的位置，以便修改缺陷。
软件缺陷管理规范 （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的复现、修改和修改验证。
医院医疗缺陷分类判断 标准 Company number：【WTUT-WT88Y-W8BBGB-BWYTT-19998】
医院医疗质量缺陷判定标准 医疗工作缺陷是指医务人员在医疗活动中，由于各种主观、客观原因造成诊疗工作中的不足，甚至产生一定的不良后果；根据其对患者的影响程度，分为轻、中、重三度。 本缺陷判定标准仅适用于我院内部的医疗质量管理，具体行为是否构成医疗差错或医疗事故，根据医疗卫生管理法律、行政法规由相应的鉴定部门裁定。 轻度缺陷：对患者不造成影响或对患者有轻微影响而无不良后果。 中度缺陷：影响疗效，延长疗程，造成组织器官的可愈性损害；或违反操作规程，增加患者痛苦与医疗费用，但无严重后果。 重度缺陷：严重影响疗效或造成重要组织器官损害致功能障碍；甚至造成残废、死亡等严重不良后果。 1、病历书写缺陷 轻度缺陷： （1）首页、楣栏及相关表格填写不全； （2）整份病历有3处以上无上级医师签名； （3）病历排列顺序或检查单粘贴不规范； （4）医学术语不当或有明显文字错误； （5）连续三天以上（慢性病五天）无病程记录； （6）除上述缺陷外的其他书写不规范； （7）各项检查不及时； （8）上级医生查房不能指导病例诊断与治疗，对住院医师不能起到指导作用； （9）未及时打印住院病历（普通患者满页打印，危重病人随时打印）。中度缺陷： （1）既往史、个人史、婚育史、月经史、家族史缺一项；
（2）入院48小时内或手术病人术前无上级医师查房意见； （3）本科室连续住院超过30天无阶段小结； （4）新入院患者及手术后三天无连续病程记录； （5）首次病程记录无诊断依据、鉴别诊断或诊疗计划； （6）专科患者病历无专科情况记录； （7）转科患者无转科及接收记录； （8）会诊单和各种检查单有缺失； （9）缺交接班记录、上级医师查房记录和特殊治疗记录之一项；（10）病危、病重患者未及时下病危、病重通知或过早停病危、病重医嘱者； （11）申请单书写不规范，申请目的不明确，导致误检、漏检者；（12）不规范修改三处及以上，或关键点不规范修改一处者； （13）病历记录缺页造成病历不完整； （14）出院诊断错误； （15）由实习医师代替住院医师书写入院记录； （16）病历中有涂改、刀刮、粘贴、涂黑，或医嘱有涂改； （17）病危、病重病人缺主（副主）任医师或科主任查房记录； （18）病情变化未按要求随时记录（时间具体到小时、分钟），病危患者每天至少记录一次，病重患者每两天至少记录一次； （19）缺法定传染病的疫情报告记录； （20）抢救病人缺抢救记录； （21）抢救记录记述不清（病情变化情况，抢救时间及措施）或缺参加抢救人员的姓名及专业技术职称； （22）缺死亡讨论综合意见记录； （23）缺交接班记录； （25）缺整页病历记录，造成病案不完整；