JIRA的BUG管理规范.docx

1、XXXXXXXXXXXXXXXXXXXXXXXXXX测试组 BUG 管理规范文件标识当前版本 V1.0.0编 写 者文件状态： 草稿 正式发布 正在修改 完成日期 2015-3-5版 本 历 史版本 /状态 编写者 参与者 起止日期 备注V1.0.0/草稿目录1 BUG 管理工具介绍 .32 BUG 定义 .32.1 BUG 分类 .32.2 Bug 等级 .42.3 Bug 状态 .42.4 Bug 优先级 .53 BUG 的生命周期 .54 BUG 管理规范 .64.1 项目的创建 74.1.1 项目名称及代号规范 74.1.2 项目的模块及版本划分规范 74.1.3 用户角色权限分配规范

2、 84.2 BUG 提交规范 .84.2.1 BUG 的报告内容 84.2.2 问题类型选择 94.2.3 BUG 简要描述 114.2.4 优先级选择 114.2.5 模块及版本选择 124.2.6 BUG 详细描述 124.2.7 其他规范 134.3 BUG 分配及处理 .144.3.1 BUG 的分配 144.3.2 BUG 处理 144.4 BUG 验证及关闭 .151 BUG 管理工具介绍常用的 BUG 管理工具有 JIRA、BugFree、Bugzilla、Mantis、XPWeb 等。我们公司采用的是 JIAR，JIRA 是 Atlassian 公司出品的项目与事务跟踪工具，被

3、广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。2 BUG 定义2.1 BUG 分类 BUG 就是指系统存的各种缺陷，可以从很多角度对 BUG 进行分类。 1、从功能方面分，产生 BUG 的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B.缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。3、从 安全性方面分，BUG 可以划分为以下几类：

4、A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理；D.数据产生缺乏随机性； E网络安全性：开放端口、服务； F系统日志、审计。 4、从 可靠性方面分，BUG 可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C硬件可靠性：如打印机；D.应急处理措施； E数据备份、恢复。5、从性能方面考虑，BUG 可划分为三种： A并发量； B吞吐量； C响应时间。 6、从兼容性方面考虑，BUG 有两种： A硬件兼容性； B软件兼容性。 7、从可维护性方面考虑，可划分为两种原因： A可扩展性； B方便升级。 2.2 Bug 等级BUG 等级是根据 B

5、UG 出现在系统中的严重程度来分的，主要定义如下 5 级： 1 级轻微的（Low）：不影响正常使用，轻微、微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字。修改优先级为低，该级别建议程序员修改。 2 级一般的（Medium）：系统能够正常使用，但有潜在风险；系统业务受到轻微影响。如提示信息不完整。该级别需要程序员修改。 3 级较高的（High ）：系统次要功能无法实现；主要功能部分失效；系统业务受到影响；导致用户利益受到一定损失。该级别需求程序员修改。 4 级严重的（Very High）：系统主要功能无法正常实现，系统业务受到严重影响；导致用户利益受到损失。该级别需要程序员修改

6、。 5 级致命的（Fatal）：系统重要功能无法正常使用，系统崩溃；系统设计存在重大隐患；导致用户利益受到重大损失。该级别需要程序员修改。 2.3 Bug 状态BUG 状态标记 BUG 当前所处的状态，是用来处理 BUG 流程的主要参数，JIRA 缺陷管理平台有以下一些状态： 新增（New）：测试人员新发现的系统 Bug； 打开（Open）：测试人员通知开发人员需要修改的 BUG； 修改（Modify）：开发人员正在修改的 BUG； 固定（Fixed）：开发人员通知测试人员已修复的 BUG；跟踪（Trace）：测试人员短时间内很难确定是否已经修复的 BUG； 已关闭（Close）：测试人员经回

7、归测试后确定已修复的 BUG； 已否决（Rejected ）：被开发人员否决了的 BUG； 重新打开（Reopen ）：Bug 未被修复，重新出现在新的测试版本中； 延迟修改（Wait）：因为种种原因需要等待延期修复的 Bug。 2.4 Bug 优先级 危机(Blocker) ：要求立即修改，作为修改最高等级； 紧急(Critical) ：要求重点修改，产品发布前必须修复； 中等(Major) ：需要尽快进行修改，产品发布前必须修复； 尽快(Minor)：需要修改，如果时间允许应该修改； 不急(Trivial)：可能要修复，时间空余情况下进行修改。 3 BUG 的生命周期1、测试人员在测试中发

8、现 BUG 需要将其添加记录到 JIRA 中，然后由相关人员对BUG 进行分配（一般由项目经理分配）给对应的开发人员进行处理。2、开发人员修改好 BUG 后需要在注释框中填写说明信息，并将 BUG 的状态设为“已修正”状态，同时开发人员如果认为有的缺陷没有必要修改、无法重现、延期修改等，可将其设置为对应的“被拒绝” 、 “重复的” 、 “信息不足” 、 “无法重现” 、 “延期修改”等状态。3、开发人员处理完毕 BUG 后需要测试人员对 BUG 进行验证，验证通过后就把其状态设置为“已关闭”状态，若验证不通过则把状态设置为“重现开启”状态。4、对被置为被拒绝状态的 BUG，测试人员与开发人员协

9、商后同意关闭，则置为已关闭 ；若测试人员不同意关闭则提交到项目负责人处，由他来决定是否要修改，若要修改，则把 BUG 状态置为“ 重新开启” ，然后开发人员继续修改；若不用再修改则置为已关闭 ；若延期处理则置为延迟修改 。 5、对被置为“信息不足”状态的 BUG 需要测试人员补全信息；然后重新开启让开发人员继续修复。4 BUG 管理规范合理的 BUG 流程管理有助于提高整个项目的效率与质量。BUG 管理规范要求在 BUG提交、BUG 分配、BUG 处理、BUG 验证、BUG 跟踪等环节都要进行规范。以下为各个环节的具体规范要求。4.1 项目的创建在使用 JIRA 进行 BUG 管理时，首先需要

10、我们创建一个项目，并划分项目的相关模块、版本及配置不同角色用户的权限等。在创建项目的名称、代号及项目模块的划分、不同角色用户权限的都要求按照严格规范。提 交 bug分 配 bug处 理 bug验 证 bug关 闭 bug1、 测 试 人 员 提 交 bug2、 开 发 人 员 提 交3、 bug的 owner可 以 由 提 交 者 指 定 项 目 经 理 或 开 发 者1、 正 确 Bug是 由 项 目 负 责 人 进 行 分 派 ， 分 派 给 对 应 的 处理 人 ；2、 Bug处 理 人 认 为 Bug不 属 于 自 己 退 回 给 项 目 负 责 人 ，再 由 项 目 负 责 人 进

11、行 分 配 。1、 Bug的 属 主 处 理 问 题 后 ， 提 交 解 决 结 论 及 方 法 ；2、 要 求 必 须 填 写 产 生 原 因 及 解 决 的 方 法 等 ；3、 Bug已 解 决 状 态 设 为 已 解 决 (Resolve)状 态 ；4、 同 时 可 将 Bug状 态 设 置 为 延 期 、 拒 绝 等 状 态 ， 但 是 要求 必 须 填 写 原 因 。测 试 人 员 验 证 已 修 改 的 Bug1、 测 试 人 员 查 询 开 发 者 已 修 改 的 bug， 即 状 态 为 “已 解决 ”， 进 行 重 新 测 试 。2、 经 验 证 无 误 后 ， 将 Bug状

12、 态 设 为 置 为 已 关 闭 ”状态 ；3、 若 还 有 问 题 ， 则 重 新 开 启 Bug， 要 求 处 理 人 重 新 处理 。Bug确 定 验 证 通 过 后 才 可 进 行 关 闭 ， 如 果 没 有 验 证 通 过则 不 允 许 关 闭 ， 且 只 有 提 交 Bug者 才 允 许 关 闭 。如 还 有 问 题 ， Reopned 不 是 自 己 的 bug New bug4.1.1项目名称及代号规范在创建项目时要求项目的名称要与实际项目名称保持一致，例如 JIRA 中的项目“安徽质监局新 OA”，在创建时完全可根据项目的名称改为“ 安徽省质量技术监督局办公平台”；如果有的项

13、目是升级改造的项目我们在创建的时候可以合理的命名来区分，例如：“安徽省经信委财政专项资金项目申报系统（一期） ”、 “安徽省经信委财政专项资金项目申报系统（二期） ”等。每个项目都会有自己的代号，例如安徽质监局的代号是 AHQI、安徽经信委是AHEIC、安徽高速集团是 AEHG，所有我们在创建项目的时候，代号可以他们的单位代号为基础来进行标识，而不是随意的乱写。4.1.2项目的模块及版本划分规范在项目创建后，我们要根据项目的实际情况对其进行模块拆分，这样我们在提交 BUG的时候，可将 BUG 划分到对应的模块下，以便后期做统计，以判断不同模块的 BUG 数等。在拆分模块时，要按照一定的依据不能

14、随意的划分，可依据项目使用的不同角色、模块类型、前端后端、项目不同部分的负责人等。同时项目创建后要配置对应的版本，因为在测试时候会根据发布的不同版本进行测试的，配置好版本后，这样在提交 BUG 的时候可方便 BUG 的版本归类，以便统计管理。4.1.3用户角色权限分配规范在项目创建后，我们要对不同角色用户进行权限分配，一般有测试人员、开发人员、项目经理、管理员等。所以在分配权限的时候，要根据每个角色的不同进行权限分配，例如开发人员不允许分配关闭、删除 BUG 的权限等，以确保 BUG 的规范管理。4.2 BUG 提交规范BUG 描述的清楚与否，可以很好的帮助开发人员快速定位、解决问题，而且还可

15、以提高测试人员基本测试技能。因此，建立标准的 BUG 描述规范是十分重要、也是十分必要的。首先清晰的 BUG 描述可以帮助开发人员快速定位、解决问题。软件测试部门中员工的水 平各有不一，对于 bug 的认知、描述侧重面也会存在不同。因此，如同一个问题，由不同测试人员描述 bug，就有可能会存在描述不一致的问题。这就会造成让开发人员理解不清晰，从而延误解决问题的周期。 其次标准的 BUG 描述可以提供测试人员的基本测试技能。如有新入职员工，他可以先从 BUG 库中查找 BUG 了解公司产品的整个开发、 研制中产生的问题。 而标准清晰的BUG 描述可方便快速的使其尽早、尽快的融入我测试部门。另外，

16、对于 BUG 的追踪验证时， 由于是不同测试人员进行验证，所以规范的 BUG 描述，可以提高测试人员验证问题的效率。4.2.1BUG 的报告内容在 JIRA 中，BUG 的内容主要包括以下要素，具体可参看表格：缺陷 ID BUG 的唯一标识，由 BUG 管理工具自动生成。项目名称 每个要测试的软件项目都有唯一的名称。问题类型（严重程度） BUG 所属的类型（即严重程度） ，包括致命问题、严重问题、一般问题、优化建议等。缺陷标题 简明的对 BUG 进行概要描述。优先级 BUG 解决的优先级。所属模块 项目的各个组成模块。测试版本 提交 BUG 时，一定要正确填写产生 BUG 的软件版本号。分派人

17、 BUG 需要指派处理的人员，如果不清楚统一给项目负责人。报告人 报告 BUG 的人员。测试环境 可根据实际描述当前测试的软硬件环境，以作为参考。详细描述在详细描述中，可对 BUG 产生的前提条件、操作的步骤、实际结果、预期结果等进行描述。文字注释与附图 在提交 BUG 时，可上传必要的附图，便于确认错误的表现形式和错误位置等。4.2.2问题类型选择我们在提交一个 BUG 的时候，首先会让我们选择“项目”和“问题类型” ，项目选择即是选择当前问题所出的项目名称；“问题类型”这边定义了致命错误、错误、缺陷、优化四个类型，所以在选择类型的时候一定要能够判断出你所选的问题属于那种类型，并且进行选择。

18、以下为几种类型的定义：（1）致命错误致命错误通常有如下情况：1、需求书中的重要功能未实现；2、造成系统崩溃、死机，并且不能通过其它方法实现功能；3、常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。（2）严重错误严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，通常有如下情况：1、重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致 run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误；2、重要功能不能按正常操作实现，但可通过其它方法可实现；

19、3、错误的波及面广，影响到其它重要功能正常实现；4、密码明文显示；5、C/S、 B/S 模式下，利用客户端某些操作可造成服务端不能继续正常工作的。（3）一般错误程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，通常有如下情况：1、次要功能不能正常实现；2、操作界面错误（包括数据窗口内列名定义、含义不一致） ；3、打印内容、格式错误；4、查询错误，数据错误显示；5、简单的输入限制未放在前台进行控制；6、删除操作未给出提示；7、数据库表中有过多的空字段；8、因错误操作迫使程序中断；9、找不到规律的时好时坏；10、数据库的表、业务规则、缺省值未加完整性等约束条件；11

20、、经过一段时间运行后，系统性能或响应时间会变慢；12、重要资料，如密码未加密存放（包括配置文件中的密码） ，或其它存在安全性隐患的；13、 硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多的人工干预才行） ；14、系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；或者由于使用了非常规技术或第三方组件造成不能使用自动化测试 工具进行测试的。（4）优化建议可以提高产品质量的建议，包括新需求和对需求的改进，以及程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误，通常有如下情况：1、界面不规范；2、辅助说明描述不清楚；3、输入输出不规范；4、长

21、操作未给用户提示（或长操作结束后提示没有消失） ；5、提示窗口文字未采用行业术语；6、可输入区域和只读区域没有明显的区分标志；7、界面存在文字错误；8、在功能实现方式上如果需求中没有明确定义，而没有按常规实现，并且不比常规方式实现优越的；( 如用户名第一位用数字或特殊字符 )4.2.3BUG 简要描述在 BUG 的简要描述中，要求描述内容清晰、简介、易懂，让用根据简要描述就可以大致了解问题所在。例如以下描述方式：1、 资料库我的资料库中，删除一个上传的文件失败，报白页2、 【IPad 版】通知公告待发通知修改通知，信息没有带入到修改页面4.2.4优先级选择在提交 BUG 时，提交人可根据提交

22、BUG 的紧急程度，选择对应的“优先级” ，同时建议开发人员在处理 BUG 的时候能够根据优先级进行处理，优先级别较高的可以最先进行处理。具体的优先级别有以下几种： 危机(Blocker) ：要求立即修改，作为修改最高等级； 紧急(Critical) ：要求重点修改，产品发布前必须修复； 中等(Major) ：需要尽快进行修改，产品发布前必须修复； 尽快(Minor)：需要修改，如果时间允许应该修改； 不急(Trivial)：可能要修复，时间空余情况下进行修改。 4.2.5模块及版本选择JIRA 中，项目在创建的时候已经配置了对应的模块和版本，所以我们在提交 BUG 的时候，一定要根据 BUG

23、 出现的地方将其归类到对应的模块下，同时选择 BUG 出现所属的版本。如果在不确定 BUG 所属的模块时，可将其归类到“其他”模块中，最后由测试负责人或项目经理对其进行归类。模块的选择及版本的规范选择，有利用后期做统计及项目缺陷评估，我们可根据统计查看出某个模块或者某个版本所出现的缺陷较多，最后都能够成为衡量开发人员的能力及产品质量的一个重要依据。4.2.6BUG 详细描述在 BUG 详细描述中，可在从 BUG 产生的前提条件、操作的步骤、实际结果、预期结果等方面进行描述。1、 前提条件：有些 BUG 的产生是需要在一定条件下才会出现，例如浏览器、分辨率、Office 版本等，所以就要求在描述

24、时描述清楚前提条件；2、 BUG 的操作步骤：详细的、有次序的、每一步的操作步骤，包括输入的数据，尽可能的重新操作的步骤；3、 实际结果：指的我按照以上的操作步骤，最后得出的结果是什么，例如我点击“增加”按钮后出现白页，这就是实际结果；4、 预期结果：指的我按照以上的操作步骤，我想要得到的结果是什么，例如我点击“增加”按钮想要得到的预期结果是提示我“增加成功”提示；5、 图文描述：在必要的情况下可上传截图并注释文字，这样更便于确认错误的表现形式和错误位置等。BUG 的描述的基本要求是：需要让开发人员能根据描述理解这个 BUG，最好能让开发人员能明确这个 BUG 在哪可以找到（定位） 、需要怎样

25、修复，BUG 描述要简单明了，条件清晰，步骤分明，重点明确。4.2.7其他规范1、 所有 BUG 统一记录在 JIRA 中，测试人员在测试过程中发现的 BUG，不建议用其他文本记录，同时不允许以口头方式直接告知开发人员，统一记录在 JIRA 中以方便管理，同时避免造成记录丢失或遗忘。2、 避免提交重复 BUG， BUG 的重复提交容易增加测试人员的工作量，同时也容易增加开发人员的工作和心里压力，所以在提交 BUG 时出现重复问题，可在对应已提交 BUG 的批注中填写。3、 BUG 描述清晰、简介、易懂，在描述 BUG 的时候，标题尽量简介、易懂让，在详细描述中尽可能的描述完整或上传截图描述。4

26、.3 BUG 分配及处理4.3.1BUG 的分配一般情况下，开发人员在提交 BUG 时， “分派人”可指定对应的处理人员，如果无法确定“分派人” ，可分派给项目的负责人，然后由项目负责人进行二次分派给对应的开发人员进行处理。在分派时可以添加一些对应的批注信息。项目负责人可对正常流程应该是测试人员提交 BUG 后，直接分派给项目的负责人，然后由项目负责人进行二次分派给对应的开发人员进行处理。在分派时可以添加一些对应的批注信息。4.3.2BUG 处理开发人员应该及时对分配给自己的 BUG 进行修改，在修改 BUG 时要注意以下几个方面：1、 按“优先级”修改，在修改 BUG 时可根据 BUG 的“

27、优先级”去修改，级别越高的要求优先修改。2、 “同类问题一并处理” ，在修改 BUG 的时候开发人员应该有“同类问题一并处理”的意识，因为有的问题不止一个页面会出现其他页面也会存在，测试人员也无法做到所有页面都一一记录下来，所以就要求开发人员有这方面的意识。3、 开发人员在处理 BUG 的时候应该注意，有的 BUG 中描述的问题可能会是多个，应该全部解决了才能设为“已解决” 。BUG 解决后要给出对应的解决方式及批注信息，针对不同的情况给出的解决方式如下： 已修改的 Bug：解决方式选择“已修正” ，并填写 BUG 产生原因、BUG 解决方案等批注信息； 被拒绝的 Bug：解决方式选择“被拒绝” ，并给出拒绝的原因； 重复的 Bug：解决方式选择“重复的” ，并给出与那条 BUG 重复了； 信息不足的 Bug：解决方式选择“信息不足” ，并要求补齐信息； 无法重现的 Bug：解决方式选择“无法重现” ，并给出无法重现原因 ； 延期修改的 Bug：解决方式选择“延期修改” ，并给出延期修改的原因； 4.4 BUG 验证及关闭当 Bug 由状态“未解决”变为 “已解决” ，且最新版本更新后，应及时对 BUG 进行验证测试，如果验证通过后，则关闭该 BUG，并在注释中填写验证通过信息。如果 BUG 验证不通过，则重新开启该 BUG，并在注释中填写重新开启的原因。