JIRA的BUG管理标准规范专业资料.doc

XXXXXXXXXXXXXXXXXXXXXXXXXX
测试组BUG管理规范

文献状态：
[√] 草稿
[ ] 正式发布
[ ] 正在修改
文献标记

当前版本
V1.0.0
编 写 者

完毕日期
-3-5

版 本 历 史

版本/状态
编写者
参加者
起止日期
备注
V1.0.0/草稿

目录
1 BUG管理工具介绍 3
2 BUG定义 3
2.1 BUG分类 3
2.2 Bug等级 4
2.3 Bug状态 4
2.4 Bug优先级 5
3 BUG的生命周期 5
4 BUG管理规范 6
4.1 项目的创建 7
4.1.1 项目名称及代号规范 7
4.1.2 项目的模块及版本划分规范 7
4.1.3 用户角色权限分配规范 8
4.2 BUG提交规范 8
4.2.1 BUG的报告内容 8
4.2.2 问题类型选择 9
4.2.3 BUG简要描述 11
4.2.4 优先级选择 11
4.2.5 模块及版本选择 12
4.2.6 BUG详细描述 12
4.2.7 其他规范 13
4.3 BUG分配及处理 14
4.3.1 BUG的分配 14
4.3.2 BUG处理 14
4.4 BUG验证及关闭 15

1 BUG管理工具简介
惯用BUG管理工具备JIRA、BugFree、Bugzilla、Mantis、XPWeb等。咱们公司采用是JIAR，JIRA是Atlassian公司出品项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

2 BUG定义
2.1 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．以便升级。  
2.2 Bug级别
BUG级别是依照BUG出当前系统中严重限度来分，重要定义如下5级：  
1级——轻微（Low）：不影响正常使用，轻微、微小问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字。修改优先级为低，该级别建议程序员修改。 
 2级——普通（Medium）：系统可以正常使用，但有潜在风险；系统业务受到轻微影响。如提示信息不完整。该级别需要程序员修改。  
3级——较高（High）：系统次要功能无法实现；重要功能某些失效；系统业务受到影响；导致顾客利益受到一定损失。该级别需求程序员修改。 
 4级——严重（Very High）：系统重要功能无法正常实现，系统业务受到严重影响；导致顾客利益受到损失。该级别需要程序员修改。  
5级——致命（Fatal）：系统重要功能无法正常使用，系统崩溃；系统设计存在重大隐患；导致顾客利益受到重大损失。该级别需要程序员修改。  
2.3 Bug状态
BUG状态标记BUG当前所处状态，是用来解决BUG流程重要参数，JIRA缺陷管理平台有如下某些状态：  
新增（New）：测试人员新发现系统Bug；  
打开（Open）：测试人员告知开发人员需要修改BUG；  
修改（Modify）：开发人员正在修改BUG；  
固定（Fixed）：开发人员告知测试人员已修复BUG；
 跟踪（Trace）：测试人员短时间内很难拟定与否已经修复BUG；  
已关闭（Close）：测试人员经回归测试后拟定已修复BUG；  
已否决（Rejected）：被开发人员否决了BUG；  
重新打开（Reopen）：Bug未被修复，重新出当前新测试版本中；   
延迟修改（Wait）：由于种种因素需要等待延期修复Bug。  
2.4 Bug优先级
Ø 危机(Blocker) ：规定及时修改，作为修改最高级别；
Ø 紧急(Critical)：规定重点修改，产品发布前必要修复；
Ø 中档(Major)：需要尽快进行修改，产品发布前必要修复；
Ø 尽快(Minor)：需要修改，如果时间容许应当修改；
Ø 不急(Trivial)：也许要修复，时间空余状况下进行修改。
3 BUG生命周期
1、测试人员在测试中发现BUG需要将其添加记录到JIRA中，然后由有关人员对BUG进行分派（普通由项目经理分派）给相应开发人员进行解决。
2、开发人员修改好BUG后需要在注释框中填写阐明信息，并将BUG状态设为“已修正”状态，同步开发人员如果以为有缺陷没有必要修改、无法重现、延期修改等，可将其设立为相应“被回绝”、“重复”、“信息局限性”、“无法重现”、“延期修改”等状态。
3、开发人员解决完毕BUG后需要测试人员对BUG进行验证，验证通过后就把其状态设立为“已关闭”状态，若验证不通过则把状态设立为“重现启动”状态。
4、对被置为‘被回绝’状态BUG，测试人员与开发人员协商后批准关闭，则置为‘已关闭’；若测试人员不批准关闭则提交到项目负责人处，由她来决定与否要修改，若要修改，则把BUG状态置为“重新启动” ，然后开发人员继续修改；若不用再修改则置为‘已关闭’；若延期解决则置为‘延迟修改’。  
 5、对被置为“信息局限性”状态BUG需要测试人员补全信息；然后重新启动让开发人员继续修复。

4 BUG管理规范
合理BUG流程管理有助于提高整个项目效率与质量。BUG管理规范规定在BUG提交、BUG分派、BUG解决、BUG验证、BUG跟踪等环节都要进行规范。如下为各个环节详细规范规定。
4.1 项目创立
在使用JIRA进行BUG管理时，一方面需要咱们创立一种项目，并划分项目有关模块、版本及配备不同角色顾客权限等。在创立项目名称、代号及项目模块划分、不同角色顾客权限都规定按照严格规范。
4.1.1 项目名称及代号规范
在创立项目时规定项目名称要与实际项目名称保持一致，例如JIRA中项目“安徽质监局新OA”，在创立时完全可依照项目名称改为“安徽省质量技术监督局办公平台”；如果有项目是升级改造项目咱们在创立时候可以合理命名来区别，例如：“安徽省经信委财政专项资金项目申报系统（一期）”、“安徽省经信委财政专项资金项目申报系统（二期）”等。
每个项目都会有自己代号，例如安徽质监局代号是AHQI、安徽经信委是AHEIC、安徽高速集团是AEHG，所有咱们在创立项目时候，代号可以她们单位代号为基本来进行标记，而不是随意乱写。

4.1.2 项目模块及版本划分规范
在项目创立后，咱们要依照项目实际状况对其进行模块拆分，这样咱们在提交BUG时候，可将BUG划分到相应模块下，以便后期做记录，以判断不同模块BUG数等。在拆分模块时，要按照一定根据不能随意划分，可根据项目使用不同角色、模块类型、前端后端、项目不同某些负责人等。
同步项目创立后要配备相应版本，由于在测试时候会依照发布不同版本进行测试，配备好版本后，这样在提交BUG时候可以便BUG版本归类，以便记录管理。
4.1.3 顾客角色权限分派规范
在项目创立后，咱们要对不同角色顾客进行权限分派，普通有测试人员、开发人员、项目经理、管理员等。因此在分派权限时候，要依照每个角色不同进行权限分派，例如开发人员不容许分派关闭、删除BUG权限等，以保证BUG规范管理。

4.2 BUG提交规范
BUG 描述清晰与否，可以较好协助开发人员迅速定位、解决问题，并且还可以提高测试人员基本测试技能。因而，建立原则BUG描述规范是十分重要、也是十分必要。
 一方面清晰BUG 描述可以协助开发人员迅速定位、解决问题。软件测试部门中员工水 平各有不一，对于 bug 认知、描述侧重面也会存在不同。因而，犹如一种问题，由不同测试人员描述 bug，就有也许会存在描述不一致问题。这就会导致让开发人员理解不清晰，从而延误解决问题周期。
另一方面原则BUG描述可以提供测试人员基本测试技能。如有新入职工工，她可以先从BUG库中查找BUG理解公司产品整个开发、研制中产生问题。 而原则清晰BUG描述可以便迅速使其尽早、尽快融入我测试部门。此外，对于BUG追踪验证时， 由于是不同测试人员进行验证，因此规范BUG描述，可以提高测试人员验证问题效率。
4.2.1 BUG报告内容
在JIRA中，BUG内容重要涉及如下要素，详细可参看表格：
缺陷ID
BUG唯一标记，由BUG管理工具自动生成。
项目名称
每个要测试软件项目均有唯一名称。
问题类型（严重限度）
BUG所属类型（即严重限度），涉及致命问题、严重问题、普通问题、优化建议等。
缺陷标题
简要对BUG进行概要描述。
优先级
BUG解决优先级。
所属模块
项目各个构成模块。
测试版本
提交BUG时，一定要对的填写产生BUG软件版本号。
分派人
BUG需要指派解决人员，如果不清晰统一给项目负责人。
报告人
报告BUG人员。
测试环境
可依照实际描述当前测试软硬件环境，以作为参照。
详细描述
在详细描述中，可对BUG产生前提条件、操作环节、实际成果、预期成果等进行描述。
文字注释与附图
在提交BUG时，可上传必要附图，便于确认错误体现形式和错误位置等。
4.2.2 问题类型选取
咱们在提交一种BUG时候，一方面会让咱们选取“项目”和“问题类型”，项目选取即是选取当前问题所出项目名称；“问题类型”这边定义了致命错误、错误、缺陷、优化四个类型，因此在选取类型时候一定要可以判断出你所选问题属于那种类型，并且进行选取。如下为几种类型定义：
（1）致命错误
致命错误普通有如下状况：
1、需求书中重要功能未实现；
2、导致系统崩溃、死机，并且不能通过其他办法实现功能；
3、常规操作导致程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其他办法实现功能。
（2）严重错误
严重错误普通使系统不稳定、不安全、或破坏数据、或产生错误成果，并且是常规操作中经常发生或非常规操作中不可避免重要问题，普通有如下状况：
1、重要功能基本能实现，但系统不稳定、某些边界条件下操作会导致run-time error、文献操作异常、通讯异常、数据丢失或破坏等错误；
2、重要功能不能按正常操作实现，但可通过其他办法可实现；
3、错误波及面广，影响到其他重要功能正常实现；
4、密码明文显示；
5、C/S、B/S模式下，运用客户端某些操作可导致服务端不能继续正常工作。
（3）普通错误
程序功能运营基本正常，但是存在某些需求、设计或实现上缺陷；次要功能运营不正常，普通有如下状况：
1、次要功能不能正常实现；
2、操作界面错误（涉及数据窗口内列名定义、含义不一致）；
3、打印内容、格式错误；
4、查询错误，数据错误显示；
5、简朴输入限制未放在前台进行控制；
6、删除操作未给出提示；
7、数据库表中有过多空字段；
8、因错误操作迫使程序中断；
9、找不到规律时好时坏；
10、数据库表、业务规则、缺省值未加完整性等约束条件；
11、通过一段时间运营后，系统性能或响应时间会变慢；
12、重要资料，如密码未加密存储（涉及配备文献中密码），或其他存在安全性隐患；
13、 硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多人工干预才行）；
14、系统兼容性差，与其他支持系统一起工作时容易出错，而没有充分理由阐明是由支持系统引起；或者由于使用了非常规技术或第三方组件导致不能使用自动化测试 工具进行测试。
（4）优化建议
可以提高产品质量建议，涉及新需求和对需求改进，以及程序在某些显示上不美观，不符合顾客习惯，或者是某些文字错误，普通有如下状况：
1、界面不规范；
2、辅助阐明描述不清晰；
3、输入输出不规范；
4、长操作未给顾客提示（或长操作结束后提示没有消失）；
5、提示窗口文字未采用行业术语；
6、可输入区域和只读区域没有明显区别标志；
7、界面存在文字错误；
8、在功能实现方式上如果需求中没有明拟定义，而没有按常规实现，并且不比常规方式实现优越；( 如顾客名第一位用数字或特殊字符)
4.2.3 BUG简要描述
在BUG简要描述中，规定描述内容清晰、简介、易懂，让用依照简要描述就可以大体理解问题所在。例如如下描述方式：
1、资料库-->我资料库中，删除一种上传文献失败，报白页
2、【IPad版】告知公示-->待发告知-->修改告知，信息没有带入到修改页面
4.2.4 优先级选取
在提交BUG时，提交人可依照提交BUG紧急限度，选取相应“优先级”，同步建议开发人员在解决BUG时候可以依照优先级进行解决，优先级别较高可以最先进行解决。详细优先级别有如下几种：
Ø 危机(Blocker) ：规定及时修改，作为修改最高级别；
Ø 紧急(Critical)：规定重点修改，产品发布前必要修复；
Ø 中档(Major)：需要尽快进行修改，产品发布前必要修复；
Ø 尽快(Minor)：需要修改，如果时间容许应当修改；
Ø 不急(Trivial)：也许要修复，时间空余状况下进行修改。
4.2.5 模块及版本选取
JIRA中，项目在创立时候已经配备了相应模块和版本，因此咱们在提交BUG时候，一定要依照BUG浮现地方将其归类到相应模块下，同步选取BUG浮现所属版本。如果在不拟定BUG所属模块时，可将其归类到“其她”模块中，最后由测试负责人或项目经理对其进行归类。
模块选取及版本规范选取，有运用后期做记录及项目缺陷评估，咱们可依照记录查看出某个模块或者某个版本所浮现缺陷较多，最后都可以成为衡量开发人员能力及产品质量一种重要根据。
4.2.6 BUG详细描述
在BUG详细描述中，可在从BUG产生前提条件、操作环节、实际成果、预期成果等方面进行描述。
1、 前提条件：有些BUG产生是需要在一定条件下才会浮现，例如浏览器、辨别率、Office版本等，因此就规定在描述时描述清晰前提条件；
2、 BUG操作环节：详细、有顺序、每一步操作环节，涉及输入数据，尽量重新操作环节；
3、 实际成果：指我按照以上操作环节，最后得出成果是什么，例如我点击“增长”按钮后浮现白页，这就是实际成果；
4、 预期成果：指我按照以上操作环节，我想要得到成果是什么，例如我点击“增长”按钮想要得到预期成果是提示我“增长成功”提示；
5、 图文描述：在必要状况下可上传截图并注释文字，这样更便于确认错误体现形式和错误位置等。

BUG描述基本规定是：需要让开发人员能依照描述理解这个BUG，最佳能让开发人员能明确这个BUG在哪可以找到（定位）、需要如何修复，BUG描述要简朴明了，条件清晰，环节分明，重点明确。
4.2.7 其她规范
1、 所有BUG统一记录在JIRA中，测试人员在测试过程中发现BUG，不建议用其她文本记录，同步不容许以口头方式直接告知开发人员，统一记录在JIRA中以以便管理，同步避免导致记录丢失或遗忘。
2、 避免提交重复BUG， BUG重复提交容易增长测试人员工作量，同步也容易增长开发人员工作和心里压力，因此在提交BUG时浮现重复问题，可在相应已提交BUG批注中填写。
3、 BUG描述清晰、简介、易懂，在描述BUG时候，标题尽量简介、易懂让，在详细描述中尽量描述完整或上传截图描述。
4.3 BUG分派及解决
4.3.1 BUG分派
普通状况下，开发人员在提交BUG时，“分派人”可指定相应解决人员，如果无法拟定“分派人”，可分派给项目负责人，然后由项目负责人进行二次分派给相应开发人员进行解决。在分派时可以添加某些相应批注信息。

项目负责人可对正常流程应当是测试人员提交BUG后，直接分派给项目负责人，然后由项目负责人进行二次分派给相应开发人员进行解决。在分派时可以添加某些相应批注信息。
4.3.2 BUG解决
开发人员应当及时对分派给自己BUG进行修改，在修改BUG时要注意如下几种方面：
1、 按“优先级”修改，在修改BUG时可依照BUG“优先级”去修改，级别越高规定优先修改。
2、 “同类问题一并解决”，在修改BUG时候开发人员应当有“同类问题一并解决”意识，由于有问题不止一种页面会浮现其她页面也会存在，测试人员也无法做到所有页面都一一记录下来，因此就规定开发人员有这方面意识。
3、 开发人员在解决BUG时候应当注意，有BUG中描述问题也许会是各种，应当所有解决了才干设为“已解决”。
BUG解决后要给出相应解决方式及批注信息，针对不同状况给出解决方式如下：
Ø 已修改Bug：解决方式选取“已修正”，并填写BUG产生因素、BUG解决方案等批注信息；
Ø 被回绝Bug：解决方式选取“被回绝”，并给出回绝因素；
Ø 重复Bug：解决方式选取“重复”，并给出与那条BUG重复了；
Ø 信息局限性Bug：解决方式选取“信息局限性”，并规定补齐信息；
Ø 无法重现Bug：解决方式选取“无法重现”，并给出无法重现因素 ；
Ø 延期修改Bug：解决方式选取“延期修改”，并给出延期修改因素；
4.4 BUG验证及关闭
当Bug由状态“未解决”变为“已解决”，且最新版本更新后，应及时对BUG进行验证测试，如果验证通过后，则关闭该BUG，并在注释中填写验证通过信息。如果BUG验证不通过，则重新启动该BUG，并在注释中填写重新启动因素。