JIRA的BUG管理规范

XXXXXXXXXXXXXXXXXXXXXXXXXX测试组BUG管理规范文件状态：[√]草稿[]正式发布[]正在修改文件标识当前版本V1.0.0编写者完成日期2015-3-51版本历史版本/状态编写者参与者起止日期备注V1.0.0/草稿2目录1BUG管理工具介绍....................................................................................................................32BUG定义....................................................................................................................................32.1BUG分类............................................................................................................................32.2Bug等级............................................................................................................................42.3Bug状态............................................................................................................................42.4Bug优先级........................................................................................................................53BUG的生命周期........................................................................................................................54BUG管理规范............................................................................................................................64.1项目的创建.......................................................................................................................64.1.1项目名称及代号规范.......................................................................................74.1.2项目的模块及版本划分规范...........................................................................74.1.3用户角色权限分配规范...................................................................................74.2BUG提交规范....................................................................................................................74.2.1BUG的报告内容.............................................................................................84.2.2问题类型选择...................................................................................................94.2.3BUG简要描述...............................................................................................114.2.4优先级选择.....................................................................................................114.2.5模块及版本选择.............................................................................................114.2.6BUG详细描述...............................................................................................114.2.7其他规范.........................................................................................................124.3BUG分配及处理..............................................................................................................124.3.1BUG的分配...................................................................................................124.3.2BUG处理.......................................................................................................134.4BUG验证及关闭..............................................................................................................1331BUG管理工具介绍常用的BUG管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb等。我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。2BUG定义2.1BUG分类BUG就是指系统存的各种缺陷，可以从很多角度对BUG进行分类。1、从功能方面分，产生BUG的原因大体可以归结为以下四种：A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。2、从易用性方面分，可以归结为三点：A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；B.缺少帮助信息，或者帮助信息不完全；C.功能操作复杂，提示信息不合理，易产生歧义。3、从安全性方面分，BUG可以划分为以下几类：A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或认证不合理；D.数据产生缺乏随机性；E．网络安全性：开放端口、服务；F．系统日志、审计。4、从可靠性方面分，BUG可划分为以下几类：A.数据存贮的可靠性；B.业务处理的可靠性；C．硬件可靠性：如打印机；D.应急处理措施；E．数据备份、恢复。5、从性能方面考虑，BUG可划分为三种：A．并发量；B．吞吐量；C．响应时间。6、从兼容性方面考虑，BUG有两种：4A．硬件兼容性；B．软件兼容性。7、从可维护性方面考虑，可划分为两种原因：A．可扩展性；B．方便升级。2.2Bug等级BUG等级是根据BUG出现在系统中的严重程度来分的，主要定义如下5级：1级——轻微的（Low）：不影响正常使用，轻微、微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字。修改优先级为低，该级别建议程序员修改。2级——一般的（Medium）：系统能够正常使用，但有潜在风险；系统业务受到轻微影响。如提示信息不完整。该级别需要程序员修改。3级——较高的（High）：系统次要功能无法实现；主要功能部分失效；系统业务受到影响；导致用户利益受到一定损失。该级别需求程序员修改。4级——严重的（VeryHigh）：系统主要功能无法正常实现，系统业务受到严重影响；导致用户利益受到损失。该级别需要程序员修改。5级——致命的（Fatal）：系统重要功能无法正常使用，系统崩溃；系统设计存在重大隐患；导致用户利益受到重大损失。该级别需要程序员修改。2.3Bug状态BUG状态标记BUG当前所处的状态，是用来处理BUG流程的主要参数，JIRA缺陷管理平台有以下一些状态：新增（New）：测试人员新发现的系统Bug；打开（Open）：测试人员通知开发人员需要修改的BUG；修改（Modify）：开发人员正在修改的BUG；固定（Fixed）：开发人员通知测试人员已修复的BUG；跟踪（Trace）：测试人员短时间内很难确定是否已经修复的BUG；已关闭（Close）：测试人员经回归测试后确定已修复的BUG；已否决（Rejected）：被开发人员否决了的BUG；重新打开（Reopen）：Bug未被修复，重新出现在新的测试版本中；5延迟修改（Wait）：因为种种原因需要等待延期修复的Bug。2.4Bug优先级危机(Blocker)：要求立即修改，作为修改最高等级；紧急(Critical)：要求重点修改，产品发布前必须修复；中等(Major)：需要尽快进行修改，产品发布前必须修复；尽快(Minor)：需要修改，如果时间允许应该修改；不急(Trivial)：可能要修复，时间空余情况下进行修改。3BUG的生命周期1、测试人员在测试中发现BUG需要将其添加记录到JIRA中，然后由相关人员对BUG进行分配（一般由项目经理分配）给对应的开发人员进行处理。2、开发人员修改好BUG后需要在注释框中填写说明信息，并将BUG的状态设为“已修正”状态，同时开发人员如果认为有的缺陷没有必要修改、无法重现、延期修改等，可将其设置为对应的“被拒绝”、“重复的”、“信息不足”、“无法重现”、“延期修改”等状态。3、开发人员处理完毕BUG后需要测试人员对BUG进行验证，验证通过后就把其状态设置为“已关闭”状态，若验证不通过则把状态设置为“重现开启”状态。4、对被置为‘被拒绝’状态的BUG，测试人员与开发人员协商后同意关闭，则置为‘已关闭’；若测试人员不同意关闭则提交到项目负责人处，由他来决定是否要修改，若要修改，则把BUG状态置为“重新开启”，然后开发人员继续修改；若不用再修改则置为‘已关闭’；若延期处理则置为‘延迟修改’。5、对被置为“信息不足”状态的BUG需要测试人员补全信息；然后重新开启让开发人员继续修复。64BUG管理规范合理的BUG流程管理有助于提高整个项目的效率与质量。BUG管理规范要求在BUG提交、BUG分配、BUG处理、BUG验证、