JIRAbug提交管理规范

1、Bug提交管理规范修订历史目录1. BUG管理工具介绍32. BUG定义31. BUG分类 32. Bug等级33. Bug状态44. Bug优先级43. BUG的生命周期44. BUG管理规范51) 项目的创建5项目名称及代号规范5项目的模块及版本划分规范5用户角色权限分配规范62) BUG提交规范6BUG的报告内容6主题，即BUG简要描述7严重程度选择7优先级选择8模块及版本选择8环境9BUG详细描述9其他规范93) BUG分配及处理10BUG的分配10BUG处理104) BUG验证及关闭101. BUG管理工具介绍常用的BUG管理工具有JIRA、BugFree、Bugzilla

2、、Mantis、XPWeb等。我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。2. BUG定义1. BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG进行分类。  1、从功能方面分，产生BUG的原因大体可以归结为以下四种：  A.重复的功能；             

3、;   B.多余的功能；  C.功能没有达到设计的要求；  D.功能实现与设计要求不相符。     2、从易用性方面分，可以归结为三点：  A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；  B.缺少帮助信息，或者帮助信息不完全；  C.功能操作复杂，提示信息不合理，易产生歧义。3、从 安全性方面分，BUG可以划分为以下几类：  A.数据有效性检测不合理； 

4、60;    B.重要数据在传输中没有加密；  C.缺少身份认证机制或认证不合理；D.数据产生缺乏随机性；  E网络安全性：开放端口、服务； F系统日志、审计。   4、从 可靠性方面分，BUG可划分为以下几类：  A.数据存贮的可靠性；     B.业务处理的可靠性；  C硬件可靠性：如打印机；D.应急处理措施；  E数据备份、恢复。 5、从性能

5、方面考虑，BUG可划分为三种：  A并发量； B吞吐量； C响应时间。   6、从兼容性方面考虑，BUG有两种：  A硬件兼容性；  B软件兼容性。    7、从可维护性方面考虑，可划分为两种原因：  A可扩展性；   B方便升级。  2. Bug等级BUG等级是根据BUG出现在系统中的严重程度来分的，主要定义如下5级：  1级 致命：系统重要功能无法正常使

6、用，系统崩溃；系统设计存在重大隐患；导致用户利益受到重大损失。该级别需要程序员修改。 2级 严重：系统主要功能无法正常实现，系统业务受到严重影响；导致用户利益受到损失。该级别需要程序员修改。3级 一般：系统次要功能无法实现；主要功能部分失效；系统业务受到影响；导致用户利益受到一定损失。该级别需求程序员修改。  4级  微小：系统能够正常使用，但有潜在风险；系统业务受到轻微影响。如提示信息不完整。该级别需要程序员修改。  5级  改进：不影响正常使用，对功能几乎没有影响，产品及属性仍可使用，如有个错别字。修

7、改优先级为低，该级别建议程序员修改。 3. Bug状态BUG状态标记BUG当前所处的状态，是用来处理BUG流程的主要参数，JIRA缺陷管理平台有以下一些状态：  开始：测试人员新发现的系统Bug；  进行中：开发人员正在修改的BUG；  已解决：开发人员通知测试人员已修复的BUG；关闭：测试人员经回归测试后确定已修复的BUG；  重新打开：Bug未被修复，重新出现在新的测试版本中；   4. Bug优先级Ø 危险 ：要求立即修改，作为修改最高等级；Ø 严重

8、：要求重点修改，产品发布前必须修复；Ø 重要：需要尽快进行修改，产品发布前必须修复；Ø 轻微：如果时间允许应该修改；Ø 微小：可能要修复，时间空余情况下进行修改。 3. BUG的生命周期1、测试人员在测试中发现BUG需要将其添加记录到JIRA中，然后由相关人员对BUG进行分配（一般由项目经理分配）给对应的开发人员进行处理。2、开发人员修改好BUG后需要在注释框中填写说明信息，并将BUG的状态设为“已解决”状态，同时开发人员如果认为有的缺陷没有必要修改、无法重现、延期修改等，可将其设置为对应的“不解决”、“重复提交”、“Not a bug”、“无法再次重现”、“未完

9、成”等状态。3、开发人员处理完毕BUG后需要测试人员对BUG进行验证，验证通过后就把其状态设置为“关闭”状态，若验证不通过则把状态设置为“重现开启”状态。4、对被置为不解决状态的BUG，测试人员与开发人员协商后同意关闭，则置为关闭；若测试人员不同意关闭则提交到产品负责人处，由他来决定是否要修改，若要修改，则把BUG状态置为“重新开启” ，然后开发人员继续修改；若不用再修改则置为关闭；若延期处理则置为未完成。   5、对被置为“无法再次重现”状态的BUG需要测试人员再次复现，然后补全信息；然后重新开启让开发人员继续修复。4. BUG管理规范合理的BUG流程

10、管理有助于提高整个项目的效率与质量。BUG管理规范要求在BUG提交、BUG分配、BUG处理、BUG验证等环节都要进行规范。以下为各个环节的具体规范要求。1) 项目的创建在使用JIRA进行BUG管理时，首先需要我们创建一个项目，并划分项目的相关模块、版本及配置不同角色用户的权限等。在创建项目的名称、代号及项目模块的划分、不同角色用户权限的都要求按照严格规范。项目名称及代号规范在创建项目时要求项目的名称要与实际项目名称保持一致，并且每个项目都会有自己的代号。代号可以项目最重要的部分为基础来进行标识，不建议随意的乱写。项目的模块及版本划分规范在项目创建后，我们要根据项目的实际情况对其进行模块拆分，这

11、样我们在提交BUG的时候，可将BUG划分到对应的模块下，以便后期做统计，以判断不同模块的BUG数等。在拆分模块时，要按照一定的依据不能随意的划分，可依据项目使用的不同角色、模块类型、前端后端、项目不同部分的负责人等。同时项目创建后要配置对应的版本，因为在测试时候会根据发布的不同版本进行测试的，配置好版本后，这样在提交BUG的时候可方便BUG的版本归类，以便统计管理。用户角色权限分配规范在项目创建后，我们要对不同角色用户进行权限分配，一般有测试人员、开发人员、项目经理、管理员等。所以在分配权限的时候，要根据每个角色的不同进行权限分配，例如开发人员不允许分配关闭、删除BUG的权限等，以确保BUG的

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

13、、 研制中产生的问题。 而标准清晰的BUG描述可方便快速的使其尽早、尽快的融入我测试部门。另外，对于BUG的追踪验证时， 由于是不同测试人员进行验证，所以规范的BUG描述，可以提高测试人员验证问题的效率。BUG的报告内容在JIRA中，BUG的内容主要包括以下要素，具体可参看表格：缺陷IDBUG的唯一标识，由BUG管理工具自动生成。项目每个要测试的软件项目都有唯一的名称。问题类型描述问题的类型：缺陷、新功能、任务还是改进主题简明的对BUG进行概要描述。严重程度严重程度，即BUG所属的类型，包括致命、严重、一般、微小、改进。优先级BUG解决的优先级。模块产品的各个组成模块。影响版本提交BUG时，正

14、确填写发现BUG的软件版本。经办人BUG需要指派处理的人员，如果不清楚统一给产品开发负责人。报告人报告BUG的人员。自动默认当前人员。环境可根据实际描述当前测试的软硬件环境，相应的服务器IP，客户端环境，以作为参考。描述在详细描述中，可对BUG产生的前提条件、操作的步骤、实际结果、预期结果等进行描述。附件在提交BUG时，可上传必要的附图，便于确认错误的表现形式和错误位置等。标签输入内容来查找或创建标签，或点击下拉列表中选择一个建议的标签。链接的问题键入需要链接的问题键值并搜索问题。 如果留空, 将不会链接任何问题。一般是关联该bug的需求。主题，即BUG简要描述在BUG的简要描述中，要求描述内

15、容清晰、简介、易懂，让用根据简要描述就可以大致了解问题所在。例如以下描述方式：1、 资料库->我的资料库中，删除一个上传的文件失败，报白页2、 【IPad版】通知公告->待发通知->修改通知，信息没有带入到修改页面严重程度选择我们在提交一个BUG的时候，首先会让我们选择“项目”和“问题类型”，项目选择即是选择当前问题所出的项目名称；“问题类型”这边定义了致命错误、错误、缺陷、优化四个类型，所以在选择类型的时候一定要能够判断出你所选的问题属于那种类型，并且进行选择。以下为几种类型的定义：（1）致命错误致命错误通常有如下情况：1、需求书中的重要功能未实现；2、造成系统崩溃、死机，

16、并且不能通过其它方法实现功能；3、常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。（2）严重错误严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，通常有如下情况：1、重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误；2、重要功能不能按正常操作实现，但可通过其它方法可实现；3、错误的波及面广，影响到其它重要功能正常实现；4、密码明文显示；5、C/S、B/S模式下，利用客户端某些操作可造成

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

18、隐患的；13、 硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多的人工干预才行）；14、系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；或者由于使用了非常规技术或第三方组件造成不能使用自动化测试 工具进行测试的。（4）微小及改进可以提高产品质量的建议，包括新需求和对需求的改进，以及程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误，通常有如下情况：1、界面不规范；2、辅助说明描述不清楚；3、输入输出不规范；4、长操作未给用户提示（或长操作结束后提示没有消失）；5、提示窗口文字未采用行业术语；6、可输入区域和只读区域没有明显的

19、区分标志；7、界面存在文字错误；8、在功能实现方式上如果需求中没有明确定义，而没有按常规实现，并且不比常规方式实现优越的；( 如用户名第一位用数字或特殊字符)优先级选择在提交BUG时，提交人可根据提交BUG的紧急程度，选择对应的“优先级”，同时建议开发人员在处理BUG的时候能够根据优先级进行处理，优先级别较高的可以最先进行处理。具体的优先级别有以下几种：Ø 危险 ：要求立即修改，作为修改最高等级；Ø 严重：要求重点修改，产品发布前必须修复；Ø 重要：需要尽快进行修改，产品发布前必须修复；Ø 轻微：如果时间允许应该修改；Ø 微小：可能要修复，时间

20、空余情况下进行修改。 模块及版本选择JIRA中，项目在创建的时候已经配置了对应的模块和版本，所以我们在提交BUG的时候，一定要根据BUG出现的地方将其归类到对应的模块下，同时选择BUG出现所属的版本。如果在不确定BUG所属的模块时，可将其归类到“其他”模块中，最后由测试负责人或项目经理对其进行归类。模块的选择及版本的规范选择，有利用后期做统计及项目缺陷评估，我们可根据统计查看出某个模块或者某个版本所出现的缺陷较多，最后都能够成为衡量开发人员的能力及产品质量的一个重要依据。环境根据实际描述当前测试的软硬件环境，包括相应的服务器IP，客户端环境，操作系统版本，IE浏览器版本，以作为参考。测试人员需

21、要提供尽可能详细的信息，并给出有效的环境条件，方便开发快速定位问题范围。BUG详细描述在BUG详细描述中，可在从BUG产生的前提条件、操作的步骤、实际结果、预期结果等方面进行描述。1、 前提条件：有些BUG的产生是需要在一定条件下才会出现，例如浏览器、分辨率、Office版本等，所以就要求在描述时描述清楚前提条件；2、 BUG的操作步骤：详细的、有次序的、每一步的操作步骤，包括输入的数据，尽可能的重新操作的步骤；3、 实际结果：指的我按照以上的操作步骤，最后得出的结果是什么，例如我点击“增加”按钮后出现白页，这就是实际结果；4、 预期结果：指的我按照以上的操作步骤，我想要得到的结果是什么，例如

22、我点击“增加”按钮想要得到的预期结果是提示我“增加成功”提示；5、 图文描述：在必要的情况下可上传截图并注释文字，这样更便于确认错误的表现形式和错误位置等。BUG的描述的基本要求是：需要让开发人员能根据描述理解这个BUG，最好能让开发人员能明确这个BUG在哪可以找到（定位）、需要怎样修复，BUG描述要简单明了，条件清晰，步骤分明，重点明确。其他规范1、 所有BUG统一记录在JIRA中，测试人员在测试过程中发现的BUG，不建议用其他文本记录，同时不允许以口头方式直接告知开发人员，统一记录在JIRA中以方便管理，同时避免造成记录丢失或遗忘。2、 避免提交重复BUG， BUG的重复提交容易增加测试人员的工作量，同时也容易增加开发人员的工作和心里压力，所以在提交BUG时出现重复问题，可在对应已提交BUG的批注中填写。3、 BUG描述清晰、简介、易懂，在描述BUG的时候，标题尽量简介、易懂让，在详细描述中尽可能的描述完整或上传截图描述。3) BUG分配及处理BUG的分配一般情况下，测试人员在提交BUG时，“经办人”可指定对应的处理人员，如果无法确定“