软件缺陷管理流程
目录
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、数据库表中有过多的空字段。
三、一般性缺陷
1、界面不规范；
2、辅助说明描述不清楚；
3、输入输出不规范；
4、长操作未给用户提示；
5、提示窗口文字未采用行业术语；
6、可输入区域和只读区域没有明显的区分标志。
四、建议性缺陷：
1、界面重构、描述更改、流程改进；
2、外观色彩、字体大小显示更适合长时间使用；
3、提示音不应有特别刺耳或者容易让人疲劳的情况；
4、增加一些简单功能使软件更人性化。
文件编号： 缺陷管理流程
修改履历 修改编号版本修改条款及内容修改日期 1 V0.1 初稿
目录 1.概述 (4) 1.1目的 (4) 1.2适用范围 (4) 1.3角色职责 (4) 1.4入口标准 (4) 1.5输入 (4) 1.6输出 (4) 1.7出口标准 (4) 2.流程 (5) 2.1流程图 (5) 2.2流程说明 (5) 2.2.1提交问题 (5) 2.2.2分析定位缺陷 (6) 2.2.3修改缺陷 (6) 2.2.4验证缺陷 (6) 2.2.5统计数据 (6) 2.2.6测试监控 (6) 3.缺陷定义 (7) 3.1.1缺陷状态 (7) 3.1.2缺陷类型 (7) 3.1.3缺陷严重级别 (7) 3.1.4缺陷优先级别 (8) 4.度量指标 (8) 5.沟通机制 (9)
1.概述 1.1目的 本文为缺陷管理模块缺陷跟踪处理流程介绍及操作指南，目的是对测试室在进行缺陷管理的过程中提供参考。 1.2适用范围 本流程适用于银行测试缺陷管理工作。 1.3角色职责 角色（岗位）职责 测试执行岗1.执行测试工作，负责提出新问题，并对开发岗已修改的 问题进行验证 开发岗 1.负责对待修改的问题进行修复 需求分析岗1.分析缺陷，并为测试方和开发方在缺陷有效性的分歧 上，进行仲裁 测试主管岗 1.测试执行过程中，对缺陷提交情况、修复情况进行监控 1.4入口标准 正式执行测试，测试方发现问题 1.5输入 测试用例 1.6输出 含结果测试用例 缺陷跟踪表 1.7出口标准 完成测试，所有问题进行修复验证或其他方式处理 缺陷数量按版本呈明显收敛趋势 遗留缺陷不能大于有限缺陷的8%
缺陷管理流程 1
缺陷管理流程 -04-18
文档修订记录 文档审批信息 1
目录 1. ............................................................................................................... 概述 错误!未定义书签。 1.1. 编写目的 ......................................................................... 错误!未定义书签。 1.2. 适用范围 ......................................................................... 错误!未定义书签。 1.3. 读者对象 ......................................................................... 错误!未定义书签。 2. 登记缺陷流程........................................................................... 错误!未定义书签。 3. 缺陷管理流程说明 .................................................................. 错误!未定义书签。 3.1. 发现阶段 ......................................................................... 错误!未定义书签。 3.2. 测试类型 ......................................................................... 错误!未定义书签。 3.3. 严重级别 ......................................................................... 错误!未定义书签。 3.4. 缺陷状态 ......................................................................... 错误!未定义书签。 3.5. 上线版本 ......................................................................... 错误!未定义书签。 3.6. 缺陷类型 ......................................................................... 错误!未定义书签。 3.7. 缺陷优先级 ..................................................................... 错误!未定义书签。 3.8. 缺陷引入阶段 ................................................................. 错误!未定义书签。 4. 附:缺陷登记注意事项............................................................. 错误!未定义书签。 4.1. 验证测试规则 ................................................................. 错误!未定义书签。 4.2. 历史遗留问题处理规则 ................................................. 错误!未定义书签。 4.3. 缺陷优先级流程 ............................................................. 错误!未定义书签。 2
软件缺陷管理办法 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.目的 本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。 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 BUG管理流程 (1) 2 报告缺陷注意事项 (2) 3 需要注意的地方 (3) 4 Bug的严重级别 (3) 1BUG管理流程
2报告缺陷注意事项 1．测试人员提交新缺陷时，尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、（建议），并尽量截图； 2.测试人员在精简语句的同时，应该再仔细检查BUG描述是否会产生误解的地方。测试人 员应该尽量避免使用模糊的，会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的，不会产生争执的词语； 3 不要使用感叹号或其它表现个人感情色彩的词语或符号； 4. 不要使用含糊的词语（例如，好像，似乎）来描述发现的现象； 5. 当BUG指派给你，在下一个版本发布之后，第一时间跟踪BUG的修复情况。
3需要注意的地方 当你发现一个BUG时，请考虑如下问题： 1. 同一软件中的相似功能是否有相同的问题？ 2. 其他的浏览器是否有相同的问题？ 3. 其他的软硬件配置是否有相同的问题？ 4. 其他的区域是否有相同的问题？ 5. 以前的版本是否有相同的问题？ 4Bug的严重级别 目前，BUG严重级别分为：严重缺陷、较严重缺陷、一般性缺陷、建议性缺陷。 一、严重缺陷主要包括： 1、由于程序所引起的死机,非法退出； 2、死循环； 3、数据库发生死锁； 4、因错误操作导致的程序中断； 5、功能错误； 6、与数据库连接错误； 7、程序错误； 8、程序接口错误。 二、较严重缺陷 1操作界面错误（包括数据窗口内列名定义、含义是否一致）； 2、打印内容、格式错误； 3、简单的输入限制未放在前台进行控制； 4、删除操作未给出提示； 5、数据库表中有过多的空字段。 三、一般性缺陷
Bug状态流程图 对Bug的处理 开发组长/经理 每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出错的模块，进行代码审查 开发人员 分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度3-High 类以上（包含）bug5个或5个以上，停止新功能的开发。 需求人员 解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计划 测试人员 不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解决 测试组长/经理 审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见 产品人员 可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺
Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed及Rejected等 Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。 Bug优先级(Priority)：指缺陷必须被修复的紧急程度。由Bug分配者（开发组长/经理）指定。 功能模块(Subject)：TD中需在Test Plan页中定义好Subject，才能在Defects页中使用。 问题描述、附件附图请参见后面第四部分‘Bug描述要求’的有关内容。
软件缺陷管理制度 软件项目测试组 文档编号： 编写人：编写日期：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
自动化系统设备缺陷管理制度示范文本 In The Actual Work Production Management, In Order To Ensure The Smooth Progress Of The Process, And Consider The Relationship Between Each Link, The Specific Requirements Of Each Link To Achieve Risk Control And Planning 某某管理中心 XX年XX月
自动化系统设备缺陷管理制度示范文本使用指引：此管理制度资料应用在实际工作生产管理中为了保障过程顺利推进，同时考虑各个环节之间的关系，每个环节实现的具体要求而进行的风险控制与规划，并将危害降低到最小，文档经过下载可进行自定义修改，请根据实际需求进行调整与使用。 1、设备缺陷管理制度 1.1、设备缺陷管理的目的 缺陷管理的目的是为了掌握正在运行的自动化系统存 在的问题，以便按轻、重、缓、急消除缺陷，提高自动化 系统的健康水平，保障自动化系统的安全运行。另一方 面，对缺陷进行全面分析，总结其变化规律，为大修、更 新改造自动化系统提供依据。 2、设备缺陷的分类 设备缺陷根据其严重程度，一般分为三类： 2.1、一般缺陷：指设备状况不符合规程要求，但近期 内不影响设备安全运行。 2.2、重大缺陷：指设备有明显损坏、变形，近期内可
能影响设备安全运行。 2.3、紧急缺陷：指设备缺陷直接影响设备安全运行，随时有可能发生事故，必须迅速处理的缺陷。 3、设备缺陷的处理 建立设备缺陷记录簿，远动人员在巡视中发现的缺陷应及时记录在设备缺陷记录簿上，写明缺陷情况，提出处理意见。重大及以上缺陷应立即向主管领导回报，并根据缺陷严重程度进行处理。自动化设备存在缺陷但不影响安全运行，应加强监视，针对缺陷发展做出分析和事故预想。 4、设备缺陷消除的期限 缺陷消除的期限一般规定为：紧急缺陷应予24H内消除；重大缺陷视其严重程度在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) 5.12 处理记录（解决的办法） (7) 第6章附录 (7)
第1章总则 为了加强部门管理工作，建立规范的缺陷管理制度，提高工作水平，根据公司和部门的有关规定，制定缺陷管理制度。 本缺陷管理制度适用于工程技术部。各测试，研发人员应当依据本制度的规定，规范工作，保证软件质量。 软件缺陷又被叫做Bug。所谓软件缺陷，即为软件中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。 软件缺陷的管理分为四个阶段。包括：缺陷提交、明确指明缺陷类型、缺陷修复、缺陷回归验证。 第2章职责 项目人员应对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到一定标准。包含内容如下： 2.1测试人员在提供的缺陷模板中新建或重新打开缺陷。 2.2测试人员提交的缺陷将反馈给项目负责人，由项目负责人安排开发人员修复缺 陷。 2.3开发人员修复缺陷后，记录处理时间及处理结果，并将文档及时反馈给测试人 员验证。 2.4测试人员验证缺陷后，记录验证时间及验证结果，并提交给项目负责人。 第3章缺陷类型 缺陷类型是指根据缺陷的自然属性划分的缺陷种类。共分为九类，包括：文档缺陷、设计缺陷、配置缺陷、界面交互缺陷、数据校验缺陷、查询统计缺陷、功能缺陷、性能缺陷、安全性缺陷。 3.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问题中 ?为问题设置到期日，可以在搜索或在图表中展示即将到期的问题
软件缺陷管理流程 目录 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、数据库表中有过多的空字段。
缺陷处理流程 1缺陷处理流程 1.缺陷处理流程图如下：
2.缺陷处理流程图中判定说明： 1)是否打开缺陷：开发组长/经理查阅缺陷，确认为缺陷后，指定优先级、估计修复 日期再指派给相关开发人员；如果确认为不是缺陷的，注释中说明理由，予以否决。 2)处理缺陷：开发处理缺陷；如果缺陷短期内进行修复存在困难，且该缺陷对于功能 实现影响不大的，应该给开发组长/经理说明情况，让开发组长/经理与缺陷相关人 员协调后延期处理该缺陷，并在注释中说明理由，估计修复日期和指明计划关闭版 本。 3)是否关闭：测试人员对回归通过的缺陷进行关闭；否则重新打开缺陷。并在注释中 说明重新打开理由。 3.缺陷处理流程图中流程说明： 1)新建缺陷：测试人员（其他人员）根据缺陷填写说明，新建缺陷。 2)已否决：对已否决的缺陷，最后由测试发起会议（形式可以根据情况而定），找到缺陷 相关人员进行确认。如果确认为是无效的缺陷，保持“已否决”状态，否则重新打开缺陷，并指派给相关处理人员。 3)（重新）打开：开发人员应该处理自己手上“打开”和“重新打开”的缺陷。 4)延期处理：开发组长/经理根据情况，对缺陷进行延期处理。 5)已经修复：开发人员处理完缺陷后，把缺陷状态改为“已修复”状态。并通知测试人员 进行回归。 6)回归测试：测试人员对已经修复的缺陷进行回归。 7)关闭缺陷：测试人员回归测试通过后，对缺陷进行关闭。 4.为了说明各个角色在缺陷处理流程中的职责，据测试流程所画泳道图如下：
如果上面判定和流程中，某一方存在异议的，应及时反馈上级。然后上级根据缺陷优先级、实际情况等，找恰当的时间发起会议（或其他）的方式找到缺陷相关人员进行沟通、协调和处理。
[模拟] 软件测试过程和管理(二) 选择题 第1题： 下列哪个不是测试环境的组成要素______。 A.软、硬件 B.技术文档 C.测试工具 D.网络环境 参考答案：B 第2题： 以下活动中，不属于测试计划的内容是______。 A.为测试各项活动制定一个实现可行的综合的计划 B.确定测试过程中每个测试阶段的测试完成标准 C.识别测试活动中各种风险，并给出风险应对措施 D.分析测试需求，并制定测试方案 参考答案：D 第3题： 下列有关测试过程抽象模型的描述中正确的是______。 A.V模型指出，软件测试要尽早准备，尽早执行，只要某个测试达到了准备就绪点，测试执行活动就可开展 B.W模型强调，测试伴随着整个软件开发周期同步进行，而且测试的对象不仅仅是程序，需求、设计也同样需要测试 C.H模型指出，单元测试和集成测试应检测程序的执行是否满足软件设计的要求 D.X模型提出针对完整的程序进行集成的编码和测试 参考答案：B 第4题： 下列哪个选项不属于测试计划要达到的目标______。 A.为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的
对象、范围、方法、进度和预期结果 B.为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容 C.为测试执行活动设计测试方案，编制测试用例 D.确定测试需要的时间和资源，以保证其可获得性和有效性 参考答案：C 第5题： 下列有关软件测试设计的说法中，正确的是______。 A.测试方案应考虑是否可行、是否有效和是否能够达到预期的测试目标 B.基于判定表的测试用例设计方法是白盒测试用例设计方法 C.测试方案设计中可以忽略软件系统的实际使用环境 D.测试开发不是测试用例设计的工作内容 参考答案：A 第6题： 下列有关测试项目结束与定稿测试报告的说法中，正确的是______。 A.测试执行完成，测试人员向测试负责人提交测试报告后，测试项目就可以结束了 B.对当前软件产品存在的缺陷进行逐个分析，认定剩余缺陷对产品质量无重大影响后，即可定稿测试报告 C.审查测试全过程，检查测试计划和内容无遗漏后，即可定稿测试报告 D.当所有测试计划内容完成，测试覆盖率达到要求及产品质量达到定义的标准，即可定稿测试报告 参考答案：D 第7题： 下列哪项工作与软件缺陷管理和追踪无关______。 A.对缺陷应该包含的信息条目、状态分类等进行完善设计 B.通过软件系统自动发送通知给相关开发和测试人员，使缺陷得到及时处理 C.对测试用例的执行结果进行记录和追踪 D.通过一些历史曲线和统计曲线来分析和预测未来的缺陷发展情况 参考答案：C
软件缺陷管理制度 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的复现、修改和修改验证。
软件缺陷管理制度 编制 审核 批准 发布日期
1.目的 为了加强部门管理工作，建立规范的缺陷管理制度，提高工作水平，根据公司和部门的有关规定，制定缺陷管理制度。 2.适用范围 本缺陷管理制度适用于软件部。各开发、测试人员应当依据本制度的规定，规范工作，保证软件质量。 3.术语 软件缺陷：又称Bug，即软件中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。 4.职责 4.1软件部负责制定、维护本缺陷管理过程。 4.2质量部负责审核及发布本管理过程。 4.3开发组长/经理 每天对Bug进行分配，标注处理意见，给定优先级。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出错的模块，进行代码审查 4.4开发人员 分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程3-High类以上（包含）bug5个或5个以上，停止新功能的开发。 4.5需求人员 解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计划。 4.6测试人员 不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解决 4.7测试组长/经理 审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见。
5.1缺陷管理流程图 5.2缺陷状态 指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed及Rejected等New 为测试人员新问题提交所标志的状态。 Open 为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。Bug解决中的状态，由任务分配人改变。对没有进入此状态的Bug，程序员不用管。 Reopen 为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。由测试人员改变。 Fixed 为开发人员修改问题后所标志的状态，修改后还未测试。 Closed 为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。 Rejected 开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由Bug分配人或者开发人员来设置。
工程质量缺陷消缺制度 Company number：【0089WT-8898YT-W8CCB-BUUT-202108】
引汉济渭工程黄金峡水利枢纽 工程质量缺陷消缺制度 1总则 为加强施工过程中的质量缺陷管理，规范施工中质量缺陷管理工作的管理职能、管理内容和要求特制定本制度，工程质量缺陷管理实行公司、项目部、班组三组管理，各级管理与工作人员“责、权”分明，做到“凡事有章可循、凡事有据可查、凡事有人负责、凡事有人监督”，和“责任到位、操作到位、监督到位”。同时建立、健全质量缺陷管理的全过程管理机制。即缺陷的定义、分类、提出、消除、验收、评价、统计、考核，形成闭环管理。 2范围 本制度适用于中电建建筑集团有限公司引汉济渭工程黄金峡枢纽砂石混凝土系统建设及运行工程项目经理部的所有人员。 3工作内容与要求 工作职责 各班组检查施工过程中的质量情况，并及时保质保量的消除施工中发现的质量缺陷。 实施细则 班组根据人员结构和施工情况，定出施工质量的第一、第二负责人，负责施工时的巡检工作。
施工质量第一负责人离开工地时，工作交由施工质量第二负责人，当施工质量第一、二负责人同时离开工地时，班组指定施工质量临时负责人，并进行工作的交接。 施工质量负责人每天应检查施工过程中的缺陷记录单。 项目质检机构及班组负责人每天应查阅施工质量缺陷记录单，安排班组人员处理缺陷，并对暂时无法处理的缺陷签置意见和安排完成时间。 项目质检机构瞎发的缺陷通知单填写内容不属实，应会同有关施工人员或发现人到施工现场确认、检查，由施工人员或发现人签字后缺陷通知单才能报废。 班组有误时，应向施工人员或发现人解释，建议重新填写。如施工质量缺陷需多个班组配合才能处理时上报项目部协调处理。 施工质量缺陷处理应坚持"小缺陷不过天，大缺陷抓到底"的原则，当日缺陷当日消除，对不及时处理将影响施工质量安全、明显影响性的缺陷，施工人员随时发现，随时通知项目部技术人员处理。 4施工质量缺陷分类 一类缺陷：施工过程中造成的重伤3人以上或经济损失10万元以上的质量事故。 二类缺陷：施工过程中造成的重伤2人以下或经济损失5000元以上10万元以下的质量事故。 三类缺陷：施工过程中造成的经济损失5000元以下的质量事故。5施工质量缺陷管理
集中常见缺陷管理工具 （1）Mantis Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统，其功能与JIRA系统类似，都是以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上可能没有JIRA那么专业，界面也没有JIRA漂亮，但在实用性上足以满足中小型项目的管理及跟踪。 Mantis基本功能介绍 https://www.doczj.com/doc/441647850.html,/TrackBack.aspx?PostId=
作者：龚云卿 2005年8月 1 简介 缺陷管理贯穿于整个软件开发生命周期中, 是不可缺少的环节。Mantis是 PHP/MySQL/Web-based缺陷跟踪系统，Mantis当前版本为1.0.0a3。关于产品详细信息和支持，请访问主页https://www.doczj.com/doc/441647850.html,/。 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 目的 缺陷是产品与规定要求不相符的部分。软件缺陷是开发、评审、测试和使用的过程中，发现的软件产品与用户需求，设计要求不符的部分，这些部分造成使用不方便或在某种程度上不能满足用户的要求。 软件缺陷的同义词有：bug，issue，defect，问题等，这里通称为缺陷。 缺陷会存在于软件产品的整个生命周期中：可以是软件代码的问题、系统文档（开发文档和测试文档等）存在的问题，或者是用户的帮助文档和使用指南方面的问题等。 本文规定了软件缺陷登记跟踪处理的完整过程规范。 2 范围 适用于软件的整个生命周期。 不限于测试过程发现的缺陷。评审，用户使用等过程中发现的缺陷都是应当按照本流程进行登记跟踪管理。 3 职责 3.1 测试工程师：在这里主要是指发现和报告缺陷的测试人员。在一般流程中，他需要对这个缺陷后续相关的状态负责：包括相关人员对这个缺陷相关信息的询问回答，以及验证测试。 3.2 开发工程师：这里主要指对这个缺陷进行研究和修改的开发人员。同时，他需要对修改后的缺陷在提交测试人员正式测试验证之前需要进行验证测试。 3.3 其他参与人：主要有项目负责人、测试经理、用户等组成。他们对缺陷进行优先级划分，负责人进行确认并调解争议。 3.4 配置管理员：负责缺陷库的创建和权限管理，并监督指导缺陷库的定制。
4 缺陷管理流程 缺陷管理流程图，下图描述缺陷管理的工作程序，缺陷的生命周期状态。 4.1 登记 缺陷发现后，由测试人员登记到缺陷库。具体项目也可以允许用户向缺陷库提交缺陷。 缺陷登记后，提交前可以反复编辑，补充缺陷记录的信息。
测试人员必须保证登记的缺陷信息可以被处置负责人员理解，具体要求参见5.10 登记后的缺陷状态是“新”。 4.2 提交 测试人员确认缺陷已经表述清楚，可以提交缺陷。 提交后的缺陷状态是“已提交” 缺陷提交前必须分配一个具体的开发人员负责，如果测试人员不确定谁负责，可以把缺陷分配给测试经理或项目负责人，再由他们重新分配负责人。 4.3 处置 开发人员确认缺陷是自己负责后，开始着手处理，并修改缺陷的状态为“打开”，表示缺陷正在处理中。 已经打开的缺陷也可以修改负责人。 4.4 解决 问题解决后，填写解决处置记录，写明造成缺陷的原因和解决方案，改变缺陷状态为“已解决”。 处置记录必须符合5.12 规定的要求。 4.5 验证 测试人员对“已解决”状态的缺陷进行重新测试，测试步骤应当按照登记的