JIRA的BUG管理规范概要1.docxVIP

XXXXXXXXXXXXXXXXXXXXXXXXXX测试组BUG管理规范文件状态：[√] 草稿[ ] 正式发布[ ]正在修改文件标识当前版本V1.0.0编写者完成日期2015-3-5版本历史版本/状态编写者参与者起止日期备注V1.0.0/草稿BUG管理工具介绍常用的BUG管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb等。我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。BUG定义BUG分类?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有两种：??A．硬件兼容性；??B．软件兼容性。????7、从可维护性方面考虑，可划分为两种原因：??A．可扩展性；???B．方便升级。??Bug等级BUG等级是根据BUG出现在系统中的严重程度来分的，主要定义如下5级：??1级——轻微的（Low）：不影响正常使用，轻微、微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字。修改优先级为低，该级别建议程序员修改。??2级——一般的（Medium）：系统能够正常使用，但有潜在风险；系统业务受到轻微影响。如提示信息不完整。该级别需要程序员修改。??3级——较高的（High）：系统次要功能无法实现；主要功能部分失效；系统业务受到影响；导致用户利益受到一定损失。该级别需求程序员修改。??4级——严重的（Very?High）：系统主要功能无法正常实现，系统业务受到严重影响；导致用户利益受到损失。该级别需要程序员修改。??5级——致命的（Fatal）：系统重要功能无法正常使用，系统崩溃；系统设计存在重大隐患；导致用户利益受到重大损失。该级别需要程序员修改。??Bug状态BUG状态标记BUG当前所处的状态，是用来处理BUG流程的主要参数，JIRA缺陷管理平台有以下一些状态：??新增（New）：测试人员新发现的系统Bug；??打开（Open）：测试人员通知开发人员需要修改的BUG；??修改（Modify）：开发人员正在修改的BUG；??固定（Fixed）：开发人员通知测试人员已修复的BUG；?跟踪（Trace）：测试人员短时间内很难确定是否已经修复的BUG；??已关闭（Close）：测试人员经回归测试后确定已修复的BUG；??已否决（Rejected）：被开发人员否决了的BUG；??重新打开（Reopen）：Bug未被修复，重新出现在新的测试版本中；???延迟修改（Wait）：因为种种原因需要等待延期修复的Bug。??Bug优先级危机(Blocker) ：要求立即修改，作为修改最高等级；紧急(Critical)：要求重点修改，产品发布前必须修复；中等(Major)：需要尽快进行修改，产品发布前必须修复；尽快(Minor)：需要修改，如果时间允许应该修改；不急(Trivial)：可能要修复，时间空余情况下进行修改。BUG的生命周期1、测试人员在测试中发现BUG需要将其添加记录到JIRA中，然后由相关人员对BUG进行分配（一般由项目经理分配）给对应的开发人员进行处理。2、开发人员修改好BUG后需要在注释框中填写说明信息，并将BUG的状态设为“已修正”状态，同时开发人员如果认为有的缺陷没有必要修改、无法重现、延期修改等，可将其设置为对应的“被拒绝”、“重复的”、“信息不足”、“无法重现”、“延期修改”等状态。3、开发人员处理完毕BUG后需要测试人员对BUG进行验证，验证通过后就把其状态设置为“已关闭”状态，若验证不通过则把状态设置为“重现开启”状态。4、