软件缺陷的分类与管理
通常大家发现软件缺陷时会对软件缺陷进行分类，可分类的方式只有一种，就是严重极别,难道没有其它的分法吗。比如我们碰到下面这种情况，测试人员发现有一种功能是必需加入进去的，这时他与程序员说，程序员说没有时间或是不必要，这时这种情况则会形成两者的扯皮，最终的结果也就不了了知了，这样会戳伤了测试人员的积极性，下次他们再也不会尽心的考虑产品的问题，只要可以运行就可以了。其实这种情况是可以解决的,下面我会提到一个新的软件缺陷分类概念，从而有效的解决这个问题。在软件缺陷中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行？这就是我下面想说的。在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug，处理的流程如图。
图1
这样处理有以下好处，首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是最好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是最好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可
以通过这种方法来有效的推行，这样工作的积极性才会有保障。
不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量是要加大的，不过广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期，因为有些需求会在下一版实现，这时测试人员需要延长对这些需求Bug的管理，不过我想这些需求是他们提出的，会有兴趣对这些Bug进行管理的。
设备缺陷管理规定 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】
设备缺陷管理办法 1目的：为加强项目设备缺陷管理，分清业主、供货厂家、施工单位的责任，维护项目部的经济利益，特制定本管理办法。 2 适用范围：适用于顾客提供的设备出现缺陷的处理。 3职责 质量部负责设备缺陷的确认及缺陷处理后的检验，并登记入帐，汇总设备的质量问题。 工程部负责组织设备缺陷的处理，计划部核算处理设备缺陷的费用，资料管理人员负责设备缺陷单的传递、发放。 4管理规定： 设备开箱、检修及安装过程中，发现设备缺陷，发现人应填写缺陷认证单（表1），报质量管理部质检工程师确认。 质量管理部质检工程师对缺陷认证核实，并登记后由资料管理人员送业主相应的资料管理部门。 业主工程部组织监理、设备厂家对设备缺陷进行认证，如业主认为不是设备缺陷，发回设备缺陷发现人处理。 如业主确认为设备缺陷，由业主确定缺陷处理单位。 如果业主委托项目部处理，由监理工程师组织确定设备缺陷处理方案。 计划部长组织专业工程师核对工程量，预算经济师编制处理费用，报业主技经部门审批，确定处理费用或规定费用计算办法。
工程部专业工程师组织处理设备缺陷。填写设备缺陷告处理签证单（表2）报质量部审核。 质检工程师检查缺陷处理情况，经检查不合格，由工程部专业工程师重新组织处理，如合格报监理工程师组织验收。 监理工程师（或甲方）验收不合格，由工程部专业工程师重新组织处理，验收合格，签证设备缺陷处理签证单。 质检工程师将设备缺陷认证单、设备缺陷处理签证单送资料管理人员。 资料管理人员负责分发、存档。 计划部长组织同业主结算设备缺陷处理费。 如业主确认由厂家处理，厂家自派施工人员处理完工后，监理工程师组织验收合格，监理工程师签证设备缺陷处理签证单，质检工程师报资料管理人员存档。 如厂家没有施工能力，委托项目部进行设备缺陷处理。 由工程部专业工程师核算工程量，计划部长组织测算工程款，同厂家进行合同谈判，签订施工合同。 设备缺陷的处理、验收、结算及归档按本办法至条执行。 计划部长组织同厂家结算设备缺陷处理费。 5质量管理部汇总本工程中出现的设备缺陷，填写设备质量问题情况表（表3），每年年底报公司工程部。 6附表 设备缺陷认证单 设备缺陷处理签证单
软件缺陷管理办法 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中延期处理部分。
江苏龙源风力发电有限公司 缺陷管理规定 第一章总则 第一条为加强江苏龙源风力发电有限公司（以下简称“公司”）生产管理管理，及时发现和消除缺陷，保证发电设备稳定运行，结合公司风电场实际情况，特制定本规定。 第二条本制度规定了公司所有设备设施缺陷发现、处理、验收等流程。 第二章缺陷定义及分类 第三条以下四种现象称为缺陷： （一）凡不符合设备设计、制造、安装、调试技术规范的现象； （二）在设备运行过程中设备构件（仪器、组件）发生的各种异常情况，影响设备安全、经济运行或正常备用的现象，如振动超限、位移超限、摩擦、卡涩、松动、断裂、变色、过热、变形、变音、泄漏、缺油、失灵、不准、不亮等； （三）影响环境卫生及设备“跑冒滴漏”等； （四）所有办公场所、构建筑物不符合安全文明生产规范的现象； 第四条缺陷管理范围 （一）输、变电设备缺陷：是指风电场升压站一、二次设备及架空/电缆线路、电缆桥架缺陷； （二）风电机组设备缺陷：是指风电机组及箱式变压器缺陷； （三）文明生产类缺陷：主要指风电场所属的建、构筑物等设备设施缺陷。包括：建、构筑物（门窗、上下水、屋顶、墙面、地面、设备基础等）及辅助设施、照明、各类设备标识牌及安全警示划线、管道着色及介质流向标志，保温、油漆、安全防护设施、生产设备和设施的清洁，场区道路、
场站绿化、卫生、防冻与防雨设施、设备设施防腐情况、电缆桥架及沟道、管道、综合管架及沟道、设备“跑冒滴漏”等缺陷； 第五条缺陷按其严重程度可分为三类：紧急缺陷、重大缺陷和一般缺陷。 （一）紧急缺陷是指威胁人身、设备安全，随时可能酿成事故，严重影响设备继续运行而必须尽快进行处理的缺陷； （二）重大缺陷是指对设备使用寿命或出力有一定影响或可能发展成为紧急缺陷，但尚允许短期内继续运行或对其进行跟踪分析的缺陷，如风力发电机、齿轮箱渗漏油、偏航异声等； （三）一般缺陷是指对设备安全运行影响较小，且一般不致于发展成为上述两类缺陷，并能维持其铭牌额定值继续运行，允许列入月、季（年）度检修计划中安排处理的缺陷； 第三章管理职责 第六条经济运行（生产技术、市场营销）部（以下简称：经生部）职责 （一）经生部是设备维护和消缺管理部门，负责制定公司缺陷管理办法。 （二）经生部检修专职负责公司缺陷管理工作，负责对各风电场缺陷的统计、分析和考核等管理工作，协助风电场对出现紧急缺陷、重大缺陷的设备设施编制企业、风场和班组三级整治计划，及时安排消缺工作。 （三）检修专职负责每月对各风电场缺陷进行统计分析，形成分析报告。每半年对所有识别的缺陷风险及影响情况进行评估，在每月的运行分析会上通报本规定的执行情况及缺陷管理考核情况。同时根据评估情况，总结分析生产设备的健康状况、缺陷发生的规律。 （四）检查监督各风电场缺陷消除计划和技术措施的执行情况。
缺陷管理工具JIRA入门到精通 缺陷管理工具JIRA入门到精通
目录 1、JIRA介绍 (1) 2、JIRA安装 (2) 3、JIRA管理使用 (5) 3.1、Projects：项目 (5) 3.2、Users&Groups (6) 3.3、Global Settings (8) 3.3.1、附件设置： (8) 3.3.2、首页面板设置： (8) 3.3.3、一般性设置 (9) 3.3.4、全局性权限 (9) 3.3.5、问题链接 (10) 3.3.6、外观与样式： (11) 3.3.7、邮件服务设置： (12) 3.3.8、子任务设置： (12) 3.3.9、事件跟踪设置 (13) 3.3.10、用户默认设置 (13) 3.3.11、工作流 (14) 3.4、Schemes (20) 3.4.1、安全策略： (20) 3.4.2、权限设置 (21) 3.4.3、通知设置 (22) 3.4.4、工作流计划 (23) 3.5、Issue Fields： (24) 3.5.1、自定义字段 (24) 3.5.2、字段设置： (26) 3.5.3、字段设置策略 (27) 3.5.4、问题导航栏 (27) 3.6、Issue Settings (27) 3.6.1、Issue Types：问题类型 (27)
3.6.2、Priorities：优先级 (28) 3.6.3、Resolutions：操作决策 (28) 3.6.4、Statuses：问题状态 (29) 3.7、Import & Export (29) 3.7.1、数据备份为xml文件： (29) 3.7.2、从XML文件恢复数据： (30) 3.7.3、外部导入数据 (31) 3.8、Options & Settings (31) 3.9、System (32)
软件缺陷管理办法 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条为了加强设备缺陷管理，保持设备健康水平，及时跟踪并消除设备存在的缺陷，提高设备完好率，保证设备安全、稳定、经济运行，特制定监控缺陷管理制度。 第2条本制度规定了设备缺陷管理的职责、管理要求，规范设备缺陷定义与分类，适用于监控缺陷管理工作。 二、缺陷定义与分类 第3条设备缺陷系运行及备用设备存在有影响安全、经济运行或设备健康水平的一切异常现象。 第4条按设备缺陷的性质和轻重程度可分为危急缺陷、严重缺陷及一般缺陷三类。 1、危急缺陷：指设备己不能继续运行，随时可能导致事故发生，必须立即处理的缺陷。 2、严重缺陷：缺陷比较重大，短期内仍可继续运行，但应加强监视，需要积极组织力量在短期内消除者。 3、一般缺陷：对近期安全运行影响不大，可列入年度或大、小修计划消除的缺陷。 第5条重复缺陷是指同类设备或设施在规程规定的检修周期内发生两次及以上性质相同的缺陷。
三、缺陷管理职责 第6条监控专业职责 1、负责及时发现设备在运行和备用中发生的缺陷并汇报。 2、如实做好设备缺陷的记录、统计、分析，每月3日前汇总上月缺陷。 3、配合自动化或检修单位进行设备消缺工作，对处理好的缺陷进行记录验收。 4、对未按时消除的设备缺陷监视运行。 第7条自动化专业职责 1、负责采取措施及时消除调度主站存在的各类缺陷，并对消缺质量负责。 2、负责做好设备缺陷的分析，含缺陷情况、处理情况、形成原因、应对措施，确定处理监控发现的缺陷单位，并及时将信息反馈到缺陷管理专责人。 3、对未及时消除的设备缺陷告知监控运行人员，加强设备的监视运行。第8条检修单位职责 1、负责采取措施及时消除站端存在的各类缺陷，并对消缺质量负责。 2、对未及时消除的设备缺陷告知监控运行人员，加强设备的监视运行。 四、缺陷管理要求 第9条设备缺陷管理实行公司、部门、班组三级管理，归口管理部门为生技部。 第10条设备缺陷采取专管与群管、执行全员全过程的管理。运行人员、检修人员、各级工程技术人员都有责任发现、汇报设备存在的缺陷。 第11条设备缺陷管理人员应经常深入现场，掌握设备缺陷情况，及时安排消缺工作，并按月统计、分析设备缺陷，找出缺陷形成原因，制定应对措施，搞好设备消缺管理。
软件缺陷管理制度 软件项目测试组 文档编号： 编写人：编写日期：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
编订：__________________ 单位：__________________ 时间：__________________ 生产设备缺陷管理制度 (正式) Standardize The Management Mechanism To Make The Personnel In The Organization Operate According To The Established Standards And Reach The Expected Level. Word格式 / 完整 / 可编辑
文件编号：KG-AO-6161-60 生产设备缺陷管理制度(正式) 使用备注：本文档可用在日常工作场景，通过对管理机制、管理原则、管理方法以及管理机构进行设置固定的规范，从而使得组织内人员按照既定标准、规范的要求进行操作，使日常工作或活动达到预期的水平。下载后就可自由编辑。 1. 总则 1.1 为了加强设备缺陷管理，提高设备健康水平，保证设备的安全、稳定、经济运行，特制定本制度； 1.2 本制度适用于公司各风电场。 2. 生产设备缺陷定义 2.1生产设备缺陷是指风电场生产设备发生的对安全、经济、稳定运行有直接影响的各种异常情况。 2.2本制度所指设备包括： 风力发电机组、110kV系统及设备、35kV系统及设备、10kV供电系统、380V供电系统、接入系统设备、消防报警系统、消防水系统、站内监视系统、变电站生产区域内建（构）筑物等。 3. 设备缺陷的分类 3.1一类缺陷：
在发现缺陷后24小时内，可以消除的缺陷； 3.2二类缺陷： 在发现缺陷后24小时内，无法消除的缺陷。 4.设备缺陷的汇报与记录 4.1风电场发现、消除设备缺陷后，应在《缺陷管理台帐》内登记； 4.2登记为二类的缺陷，应经安全生产部同意； 4.3二类缺陷的信息通过OA系统呈报总工程师及安全生产部。 5.设备缺陷的处理 5.1 风电场发生任何威胁人身、设备安全的缺陷应立即布置安全防护措施，并由安全生产部负责检查； 5.2 设备缺陷由风电场自行组织及时处理（特殊天气情况除外）； 5.3 对于风电场无法自行处理且需要对外联系的缺陷应及时汇报安全生产部，安全生产部协助处理。 6 缺陷转类 风电场在消缺过程中发现无法自行组织处理时，
软件缺陷管理制度 软件项目测试组
修订历史记录
目录 软件缺陷管理制度 (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绝缘油不合格或呈酸性、水份严重超标、气相色谱分析重要指标超标或有明显
JIRA培训手册（缺陷跟踪管理流程） 引言： 为了提高软件开发日常中的工作效率，增进开发人员与项目经理、测试人员等的沟通频率，引入JIRA项目管理与缺陷跟踪管理工具。本篇意在阐述JIRA在缺陷跟踪管理中的运用。
目录 第一章何为JIRA？ (3) 1.1 JIRA的简介 (3) 1.2 JIRA的特性 (3) 第二章JIRA的应用配置 (6) 2.1 用户组及人员的创建 (6) 2.2 权限配置 (8) 2.2.1 全局权限 (8) 2.2.2 权限方案 (8) 2.2.3 工作流中执行固定操作的权限 (9) 2.3 工作流配置 (10) 第三章具体操作 (12) 3.1 工作流程图 (12) 3.2详细操作流程 (13) 3.3批量操作及查找 (21) 第四章结束语 (25)
第一章何为JIRA？ 1.1 JIRA的简介 JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA中配置灵活、功能全面、部署简单、扩展丰富，其超过150项特性得到了 全球115个国家超过19,000家客户的认可。 1.2 JIRA的特性 工作流 ?开箱即用，提供用于缺陷管理的默认工作流工作流可以自定义，工作流数量不限 ?每个工作流可以配置多个自定义动作和自定义状态 ?每一个问题类型都可以单独设置或共用工作流 ?可视化工作流设计器，使工作流配置更加直观 ?自定义工作流动作的触发条件 ?工作流动作执行后，自动执行指定的操作 项目
?每个项目都有自己的概览页面包括：项目详细信息、最新更新情况以及一些报告的快捷方式 ?在项目界面中查看按照状态、是否解决等条件设置的分类统计报告 ?查看项目最新的活动情况 ?查看项目的热门问题 ?可以设置项目类别，将项目分组管理 ?可以为每个项目设置单独的邮件通知发件地址 ?自定义安全级别，指定用户对问题的访问 ?指定组件/模块负责人 问题管理 ?自定义问题类型，适应组织管理的需要 ?自定义字段，可选择字段类型超过20种，在此基础上还支持插件进一步扩展 ?自定义问题安全级别，可以限制指定用户访问指定的问题 ?如果多个问题需要同时修改同一字段值或执行同一工作流动作，你可以使用批量操作功能一次性完成 ?登记问题预计完成时间、实际工作时间，就可以了解该问题预计还剩多长时间才能解决。甚至可以出具时间跟踪报告，了解用户的工作效率 ?支持远程创建问题，通过多种方式在JIRA中创建问题，如电子邮件、移动设备客户端 ?如果一个问题需要多人协作，可以将问题分解为多个子任务，分配给相关的用户 ?将相关或有依附关系的问题建立链接，以便于用户快速了解 ?为JIRA的问题添加附件，可以帮助技术人员快速解决问题，当上传图像文件时，JIRA自动显示图像缩略图。你也可以直接将剪切板中的图像粘贴到JIRA问题中 ?为问题设置到期日，可以在搜索或在图表中展示即将到期的问题
缺陷管理规程 版权信息 本文件涉及之信息，属江西省通信产业服务有限公司所有。 未经江西省通信产业服务有限公司允许，文件中的任何部分都不能以任何形式向第三方散 发。
文档修订记录 修订状态：A--增加，M--修改，D--删除日期格式：YYYY-MM-DD
目录
1.目的 缺陷管理的最终目标是最大限度地减少缺陷的出现率，从而提高软件产品的质量。细分为： 1)从缺陷发生到结束的全生命周期进行跟踪管理，尽可能发现所有的缺陷，确保每个被发 现的缺陷都能够被解决； 2)收集缺陷数据并根据缺陷趋势图识别测试过程的阶段；可以通过缺陷趋势图来确定测试 过程是否结束； 3)在已收集到的缺陷数据的基础上进行统计分析。总结缺陷出现的原因、类型和规律，采 取相应措施避免该类型缺陷再次出现，并在开发过程的早期阶段予以确定，起到缺陷预防的作用，并作为组织的过程财富。 本规程规定了缺陷管理流程以及缺陷统计分析要求，项目组必须严格遵循本规程要求保证在较短的时间内高效率地解决所有缺陷，缩短软件开发测试进程，提高软件质量，减少开发和维护成本。 2.角色与职责 3.入口准则 缺陷发生时 4.输入 无
5.主要步骤 5.1. 定义缺陷 是对软件产品预期属性的偏离现象，它包括检测缺陷和残留缺陷。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。 缺陷属性 缺陷类型 缺陷严重程度
缺陷优先级 一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。例如，公司名字和软件产品徽标是重要的，一旦它们误用了，这种缺陷是用户界面的产品缺陷，并不影响用户使用。但是它影响公司形象和产品形象，因此这也是优先级高的软件缺陷。 缺陷状态
一、登录TD8.0的运行环境 1：启动Test Director，如下图所示，地址：http://20120117-1626/TDBIN/default.htm 备注：当访问服务器上的TD或者是通过外网访问TD时，提示下载插件失败，或者是下载插件的滚动条走不动的话，就要设置IE浏览器：工具---internet选---高级---将启用内存保护减少联机攻击的勾去掉，重启电脑。 2：点击site administrator ，第一次运行TD的时候，组件将会被下载到你的计算机上 3：组件下载完后，显示输入密码的界面，登录
二、创建测试域及项目及用户 其实TD的操作并不难，没有代码，不会有太多文字，也全部都是很常用的控件组合。只要你熟悉这个测试流程，使用TD没有问题！ 整体流程可概括为：创建项目，明确需求；根据需求生成测试计划；按照计划设计并执行测试；发现问题记录问题。 1：点击project → create domain,输入域名即可 产品部，产品测试部，开发部，金融部，在这些域下面创建其各自负责的项目。 2：创建项目，在刚创建的测试域上创建具体部门的具体项目，右击→创建项目 备注：创建测试域或项目时，名称中有‘（）’，create的时候就报错‘Failed to build tester director database’
3：选择一个系统已经装上的数据库，点击下一步，直到出现下图所示，点击create 三、添加用户及设置用户属性 1：重新连接TD，并进入TD页面，点自定义，在弹出的提示框中域选择刚定义的测试域，项目选择刚创建的项目，用户名Admin，首次进入是密码为空。
软件缺陷管理流程 目录 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片及以上者。
款缺陷管理系统介绍
————————————————————————————————作者：————————————————————————————————日期：
对某个项目来说，最重要的一件事情就是需要跟踪和梳理各种bug 和问题，找到并解决问题，否则，项目就会花费超多的时间，导致整个项目的重心偏移。而且，用户总想标记未解决的问题，保证项目的进度等等。团队会花费一部分的精力去跟踪bug，并且找出问题所在，解决问题。 如果你使用一个 bug 和问题跟踪系统，那么会得到更好的最终结果，除此之外，还能打打提高工作效率，加快项目的进度，更好的完成任务。在这里，我们收集了最好的 15 款 bug 跟踪应用程序，提供给用户更舒适更方便的开发环境 JIRA JIRA 是个团队规划和构建伟大项目的跟踪器，上千个团队选择了 JIRA 来捕获和管理问题，分配工作和追踪团队的活动。无论是在桌面环境还是在新的移动端界面，JIRA 都能很好的帮助团队做好每一项工作。 额外补充: MantisBT 是个开源问题跟踪器，提供一个简单和强大之间的一种微妙平衡。用户启动只需要几分钟，然后就可以开始和他们的团队成员和客户协作，管理他们的项目。一旦你开始使用它，就会一发不可收拾的喜欢上它! 1、Snowy Evening Snowy Evening
这是个问题跟踪应用程序，功能非常强大，而且易于使用。它提供了很好的 GitHub 和 jsFiddle 集成，同时也拥有一个非常简洁的界面。用户可以访问一个仪表盘，它就会提供用户参与的每一个开放项目的汇总，从而帮助用户很好的跟踪和修复可能出现的问题。 2、Pivotal Tracker 这是个非常快速的项目管理工具，用户可以分解自己的项目，然后找到任何可能存在的问题和bug 的源头。它的 API 非常全面，除此之外还有超过 100 的插件。 3、Trac Trac 是个为软件开发者设计的增强 wiki 和问题的跟踪系统。它使用非常简约的方法来管理基于 web 的软件项目管理。团队的任务是编写出杰出的软件，更好的帮助其他开发者平和的进行开发。此应用完全免费! 4、Bugify
集中常见缺陷管理工具 （1）Mantis Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统，其功能与JIRA系统类似，都是以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上可能没有JIRA那么专业，界面也没有JIRA漂亮，但在实用性上足以满足中小型项目的管理及跟踪。 https://www.doczj.com/doc/a02115338.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) 问题讨论
设备缺陷管理规定 第一章总则 第一条为了适应公司生产发展的需要，进一步规范设备缺陷管理，结合实际，制定本规定。 第二条设备缺陷管理的范围包括： （一）运行异常：设备运行过程中，系统的各种参数偏离正常状态（标准值）的情况。 （二）设备劣化：设备使用过程中，由于零部件磨损、疲劳、变形、腐蚀、老化等原因使原有性能降低的情况。 （三）设备故障：设备使用过程中，由于性能降低不能满足生产要求而造成的被迫停机的情况。 第三条设备缺陷管理的基本任务是：掌握设备状态，及时消除隐患，提高完好率，降低故障率，延长使用寿命，防止事故发生，为生产装置的“长、安、稳、满、优”运行创造条件。 第四条本规定适用于中国石化股份有限公司齐鲁分公司和中国石化齐鲁股份有限公司。 第二章职责分工 第五条公司设备动力部的主要职责是：
（一）贯彻执行国家、地方及上级部门颁布的各项有关法律、法规、规章和规范； （二）负责制定公司设备缺陷管理的有关制度和规范； （三）负责对公司各直属单位设备缺陷管理进行业务指导，对制度的执行情况进行监督检查； （四）建立公司设备缺陷管理档案，定期进行设备完好状况评定和设备缺陷分析； （五）组织开展全公司的设备隐患普查和专项治理活动。 第六条各生产厂设备动力管理部门的主要职责是： （一）贯彻执行公司设备缺陷管理的有关制度和规范； （二）负责制定本厂设备缺陷管理的具体实施办法或实施细则； （三）建立本厂的设备缺陷管理档案，定期进行设备完好状况评定和设备缺陷分析； （四）负责缺陷管理的有关技术报告和统计报表编制上报工作； （五）组织开展本厂的设备隐患普查和专项治理活动。 第三章设备检查 第七条对设备的各类检查要按照《中国石化集团齐鲁石油
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)丰富的插件及界面自定义功能，基本上可以满足项目的需要。
文件编号：RHD-QB-K5220 （管理制度范本系列） 编辑：XXXXXX 查核：XXXXXX 时间：XXXXXX 设备缺陷管理制度标准 版本
设备缺陷管理制度标准版本 操作指导：该管理制度文件为日常单位或公司为保证的工作、生产能够安全稳定地有效运转而制定的，并由相关人员在办理业务或操作时必须遵循的程序或步骤。，其中条款可根据自己现实基础上调整，请仔细浏览后进行编辑与保存。 一、一般规定 1、站领导、检修技术人员、检修班长是具体抓好设备管理负责人。 2、凡是设备在运行备用中出现缺陷，运行人员有责任采取必要的运行措施，防止缺陷扩大，出现故障要通知有关人员及时消除。 3、各运行、检修班应将发现的设备缺陷及时记录，以利于查阅和作出处理。 4、设备缺陷消除后，消除者应在记录簿上交代清楚。 5、记录簿应保持整洁，并存档，以备查考。
二、缺陷分级管理权限 1、运行任务 （1）巡视检查及时发现设备缺陷，并作好记录和报告有关人员。 （2）及时消除属于运行维护工作范围的设备缺陷，应及时采取必要运行措施消除缺陷。防止缺陷扩大，并向有关人员汇报。 （3）凡本班有权调度停用或不停用也能消除的缺陷，应通知检修人员及早消除。 （4）参加设备缺陷消除后的验收。 2、检修班任务 （1）负责从运行、试验、检验方面及时了解所管辖设备的缺陷并作出记录。 （2）了解运行情况，查阅记录簿，及时发现和主动消除设备缺陷，做到小缺陷不过班，大缺陷不过
天。 （3）在运行中无法消除缺陷，应记入本班的记录簿内，在大小修或临时予以消除。 3、站领导的任务 （1）领导督促各班认真搞好设备缺陷的消除工作，负责质量验收的组织工作。 （2）定期巡视设备，掌握设备存在的缺陷。 （3）分析造成缺陷的原因，总结经验教训，不断提高业务水平。 （4）拟定消除重大设备缺陷的技术组织、措施，结合小修计划使其实现。 这里写地址或者组织名称 Write Your Company Address Or Phone Number Here