jira用户指南

JIRA用户指南

2014-07-08

1、总体概述

本文档简要介绍了JIRA在项目、缺陷管理等方面能实现的功能，能够达成的管控效果。针对部分JIRA应用中涉及的概念做了简单描述，让用户更好的理解掌握JIRA这一新的工具。文档的重点部分是列出了各个角色人员在JIRA中的实际工作内容，以及目前计费项目所要涉及到的工作流程。需要用户另外了解并注意的内容请查看注意事项。

2、JIRA产品介绍

简介

=============

JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。JIRA也是一个问题跟踪和项目管理应用系统，融合了项目管理、任务管理和缺陷管理。

基本概况

=============

JIRA 是目前比较流行的基于Java架构的管理系统，由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务，因此在开源领域，其认知度比其他的产品要高得多，而且易用性也好一些。同时，开源则是其另一特色，在用户购买其软件的同时，也就将源代码也购置进来，方便做二次开发。

JIRA功能全面，界面友好，安装简单，配置灵活，权限管理以及可扩展性方面都十分出色。

功能列表

=============

● 问题追踪和管理：用它管理项目，跟踪任务、bug、需求，通过jira的邮件通知功能进行协作通知，工作效率提高很多；

● 问题跟进情况的分析报告：可随时了解问题和项目的进展情况； ● 项目类别管理功能：可将相关的项目分组管理；

● 组件/模块负责人功能：可将项目的不同组件/模块指派相应的负责人，来处理所负责的组件的Issues；

● 项目email地址功能：每个项目可以有不同的email（该项目的通知邮件从该地址发出）；

● 无限制的工作流：可以创建多个工作流为不同的项目使用。

JIRA的优点 =============

使用JIRA管理项目，跟踪任务、bug，通过JIRA的邮件通知功能进行协作通知，使工作效率显著提高，安全性及可扩展性也有所体现；

JIRA不仅仅是一个缺陷跟踪系统，通过JIRA，可以整合客户、开发人员、测试人员，通过各自和共同的模块，信息能够及时得到交流和反馈；

Eclipse和IDEA下的JIRA插件，主要为开发人员服务，实时将信息反馈给开发人员，

开发人员同时迅速地将修复的结果信息反馈到跟踪系统中，最后通过持续集成，软件可以迅速完成了更新；

JIRA还拥有众多插件的支持，包括生成报表，XP编程，与SVN集成等，能够极大地丰富其功能；

同类软件产品TestTracker、ClearQuest、TestDirector相比，JIRA性价比最好。

主要功能

=============

1. 项目类别管理功能：可以将相关的项目分组管理；

2. 组件/模块负责人功能：可以将项目的不同组件/模块指派相应的负责人，来处理所负责的组件的Issues；

3. 项目email地址功能：每个项目可以有不同的email（该项目的通知邮件从该地址发出）；

4. LDAP配置器：用于将JIRA连接到公司的LDAP目录上；

5. Issue安全级别：在一个项目里可以精确地控制对Issue的访问； 6. 可订制的工作流：可以创建多个工作流为不同的项目使用； 7. 快速搜索和JQL高级查询功能；

9. 子任务功能：可以在某个Issue下创建子任务；

10. 共享过滤器功能：一个团队成员可以访问共享的过滤器； 11. 多个dashborads功能：可以定制自己的JIRA显示面板； 12. 与CVS、SVN，ClearCase, Mercurial集成；通过FishEye还可以连接Git代码库； 13. 与GreenHopper集成后支持敏捷开发； 14. 通过IDE连接器，可以将JIRA集成到Eclipse、IntelliJ IDEA、MS Visual Studio。

3、JIRA基本概念

3.1 问题

JIRA跟踪问题（Issue），这些问题可以是软件的缺陷bug，一个项目的具体任务，功能请求或者任何其他您想要跟踪的的任务。（图1为查询所有问题页面，图2、3为问题浏览界面）

项目 — 问题所属于的项目，详见3.3项目 类型 — 查看3.2问题类型

状态 — 当前问题在生命周期('工作流')中所处的处理状态 影响版本 — 表明问题发生在哪个版本中，详见3.4版本

修复版本 — 表明这个问题已经在哪个版本中被修复，详见3.4版本 经办人 — 问题当前由谁来负责 报告人 — 谁创建提交的这个问题

关注人 — 有多少人关注这个问题（用户可选择关注想要关注的问题） 到期日 — 希望这个问题在何时之前解决 创建日期 — 问题提交的日期

更新日期 — 问题被最后一次编辑的日期 解决日期 — 问题被 解决的日期

预估时间 — 是估算解决这个问题需要耗费的时间

剩余时间 — 根据预估时间与实际工作时间计算出来的解决这个问题还需要的大概时间 实际工作时间 — 为解决这个问题，登记的实际的工作时间的总和

3.2 问题类型

JIRA可以为不同类型的问题单独设置相应的类型，可以用于跟踪多种不同类型的问题，可以根据需要添加。

JIRA系统缺省提供的问题类型如下：

Bug 测试过程、维护过程发现影响系统运行的缺陷 New Feature 对系统提出的新功能 Task 需要完成的任务

Improvement 对现有系统功能的改进

当前已自定义设定的问题类型如下： 父任务：需求、故障、测试用例、缺陷

子任务：需求类开发子任务、故障类开发子任务、测试子任务、支撑子任务、用例执行子任务

3.3 项目

JIRA的项目是根据你的企业组织需要定制的，一个JIRA系统通常包含许多项目，是问题的集合。每一个问题属于一个项目。每一个项目都有项目名称和一个项目关键字（如：GDCBS），项目关键字是项目中所有 问题编号 的前缀（如：GDCBS-100）。

3.4 版本

在一个项目上，会有多个版本。JIRA系统中的问题涉及到两个版本字段： 版本可以有3个状态: 已发布, 未发布 或 已归档。 版本可以设置 发布日期, 而JIRA会自动将到期而还没有发布的版本高亮显示出来，并标注上'超期'标志。

--影响版本，可以清晰地反映出这个问题在哪个版本中出现错误，如一个bug可能影响版本1.1和1.2。

--解决版本，可以反映出报告的问题将在哪个版本，或已经在哪个版本中修复了，如bug影响版本1.1和1.2，可能在2.0版本上被解决。

版本通常有三种状态：发布/released、未发布/unreleased和归档/archived。版本可以设置 发布日期，在特定的报告中会显示，而JIRA会自动将到期而还没有发布的版本高亮显示出来，并标注上'超期'标志。

3.5 工作流

工作流 是按照一定的规则和过程执行一个任务，在JIRA中体现在问题在生命周期内不同状态之间的变化。 下面的图像是JIAR中的一个工作流程: 每个 状态 以矩形框表示 每个工作流跳转由箭头指引方向，每个问题的工作流查看请点击浏览界面的状态右边的“查看工作流”，JIRA的工作流可以由系统管理员定制。

3.6 状态

每个问题有一个状态，用来表明问题所处的阶段，问题通过开始于open状态，然后开始处理/Progress，再到解决/Resolved，然后被关闭/Closed。目前jira可根据项目定制问题状态以及工作流。

JIRA系统提供的缺省状态如下：

Open 表示问题被提交等待有人处理。 In Progress 问题在处理当中，尚未完成。

Resolved 问题曾解决，但解决结论未获认可，需要重新分派解决。

Reopened 问题解决，等待结果确认，确认的结果是“Reopened”或者“Closed”。 Closed 问题处理结果确认后，置于关闭状态。

根据实际项目工作情况，设定的状态有：

开始，处理中，审核确认中，设计中，开发中，已退回，重新打开等···

4、JIRA中涉及角色

CBS项目涉及角色有12个

? 需求接口人：

1. 收到需求后，初步进行分析，将需求任务分配给对应的需求处理人；

2. 需求分析完成，进行审核，在需求单所关联的所有开发、测试、支撑子任务完成以后，

审核确认通过，关闭需求流程。

? 需求处理人：

1. 需求处理人对需求进行详细分析，并按照版本计划与对应的开发接口人，测试接口人，

支撑接口人等进行沟通，确认需求细节，并完成相关的文档； 2. 需求单下的开发、测试、支撑等子任务都可以由需求处理人直接建单提交给各接口人进

行处理；

3. 需求分析完成后提交需求接口人审核。

? 开发接口人：

1. 开发接口人在需求工单分析完成之后，在该需求单下手工新建开发子任务； 2. 分析开发任务，填写设计思路，分配对应的开发处理人进行开发处理； 3. 开发任务处理完成后，提交到开发接口人审核，关闭完成任务。

? 开发处理人：

1. 处理开发任务，开发完成后提交开发接口人审核。

? 支撑接口人：

1. 根据需求工单新建支撑子任务；

2. 支撑接口人根据工单内容支撑接口人，选择支撑处理人分配支撑任务； 3. 处理完成后，支撑接口人审核确认，确认通过则完成关闭。

? 支撑处理人：

1. 处理支撑子任务，完成后提交支撑接口人审核。

? 测试接口人：

1. 测试接口人在需求或故障工单分析完成之后，在该需求或故障单下手工新建测试子任

务，建单分配给测试接口人；

2. 分析测试任务，填写设计思路，分配给对应的测试设计人员； 3. 测试用例设计完成后提交测试接口人审核确认，不通过则会退回设计中的状态，通过则

分配对应的测试执行人进行测试执行；

4. 测试执行完成后，若没有缺陷，则提交到测试接口人审核，若审核通过则完成关闭。

? 测试设计人：

1. 测试设计人员处理测试设计任务，同时需要创建测试用例问题，设计用例完成后提交测

试接口人审核确认；

? 测试执行人：

1. 执行人由测试子任务分配执行测试任务，同时需要在对应的测试用例问题下新建测试执

行子任务，记录此次测试用例的执行过程和结果，测试执行完成后，若没有缺陷，则提交到测试接口人审核，审核不通过则重新执行；

2. 测试执行子任务审核通过关闭后，测试执行人则可以将测试子任务关闭。

? 运维接口人：

1. 在故障单所关联的所有子任务完成后，由运维处理人提交到运维接口人进行审核确认关

闭。

? 运维处理人：

1. 被分配故障任务后，对故障进行详细分析，与对应的开发、测试、支撑的接口人进行沟

通，确定解决方案；

2. 若需支撑，运维处理人可在故障下新建支撑类子任务，选择支撑接口人处理；

3. 对于需开发处理解决的，线下沟通确认以后，运维处理人修改故障单的版本计划字段，

同时由开发或测试接口人在故障单下建单，也可直接由运维处理人自己创建子任务给开发或测试接口人，进行开发和测试任务的流转； 4. 在故障单所关联的所有子任务完成后，运维处理人处理完成，提交运维接口人审核确认

关闭。

? 缺陷提交人：

1. 新建 缺陷 类型的问题，分配给开发接口人进行处理；

2. 开发修复完成后，根据开发修复情况，进行回归测试，并根据测试结果选择相应的处理

过程，审核确认，若回归测试通过则完成关闭。

5、JIRA中工作流程

目前按照计费的基本业务流程

运用到计费项目中的工作流程有8种： 需求工单处理流程 故障工单处理流程 测试用例工单处理流程 需求类开发工单处理流程 故障类开发工单处理流程 测试工单处理流程 支撑工单处理流程

测试执行子任务工单处理流程 缺陷管理流程

4.1 需求工单处理流程

1．需求由需求录入人员在JIRA中新建问题，问题类型选择需求，参考ITSM对应信息

进行录入，并选择对应的需求接口人，完成创建需求的过程；

2．需求接口人收到需求后，初步进行分析，点击提交需求分析，并选择对应的需求处理人，进行需求任务的分配；

3．需求处理人对需求进行详细分析，并按照版本计划与对应的开发接口人，测试接口人，支撑接口人等进行沟通，确认需求细节，并完成相关的文档，点击需求分析完成，提交需求接口人进行审核，若有额外的支撑任务，请需求人员线下通知对应的支撑接口人新建支撑子任务；

4．在需求单所关联的所有开发、测试、支撑子任务完成以后，需求接口人选择审核确认通过，关闭需求流程；

5．在需求接口人和需求处理人操作时都设置了需求退回环节，同时需求在关闭完成后可以重新打开，目前限定管理员以及需求接口人才能执行重新打开的动作。

4.2 故障工单处理流程

1．故障由录入人员在JIRA中创建问题，问题类型选择故障，并选择对应的运维处理人，进行故障任务的分配，完成创建故障的过程。（待系统稳定运行后将通过二次开发以实现故障的自动导入）

2．运维处理人对故障进行详细分析，与对应的开发接口人，测试接口人，支撑接口人等进行沟通，确定解决方案。

3．运维处理人可以在故障下新建支撑类子任务，选择对应的支撑接口人进行处理。 4．对于需要开发处理解决的，线下沟通确认以后，运维处理人修改故障单的版本计划字段，同时由对应的开发接口人和测试接口人在故障单下新建测试和故障类开发子任务，或直接由运维处理人在故障单下建单，进行开发和测试任务的流转。

（注意此处与以前流程有区别，开发和测试子任务只能建在故障父任务下，而且是由对应的开发接口人和测试接口人负责组织新建，原维护建的支撑子任务单作为同级别的任务保留）

5．在故障单所关联的所有开发、测试、支撑子任务完成以后，运维处理人点击处理完成，提交运维接口人进行审核确认，完成关闭。

6．故障在关闭完成后可以重新打开，当前限定运维接口人才能执行重新打开的动作。

4.3 开发工单处理流程

注意：开发子任务有区分

由于需求类开发子任务与故障类的开发子任务在部分字段有不一样的继承要求，继承的配置涉及工作流中状态的处理结果脚本设置，还有界面显示等问题，因此区分了故障类开发子任务与需求类开发子任务两个不同的问题类型，不同的创建界面，不同的工作流，对用户来说没有使用上的另外说明，只要求在创建子任务时注意选择好对应的子任务即可。 ? 需求类开发子任务

1．在需求工单分析完成之后，由开发接口人或需求处理人直接在需求单下建开发子任务，根据需要可新建多个，选择开发接口人，开发接口人根据项目可设置多个。

2．开发接口人分析开发任务，填写设计思路，点击提交开发处理，选择对应的开发处理人进行分配。

3．开发处理人处理开发任务，开发完成后提交开发接口人审核，也可以直接完成关闭

任务。

4．开发接口人审核开发任务，进行开发任务完成关闭。

5．以备需要，在开始和需求处理中两个状态时均设置了需求退回环节，同时需求在关闭完成后可以重新打开，目前限定管理员以及开发接口人才能执行重新打开的动作。 ? 故障类的开发子任务

该子任务就只能在故障工单分析完成后，由开发接口人或运维处理人在故障单下建故障类开发子任务。

与需求类开发子任务创建操作及处理流程基本一致，用户进行创建操作时只有创建界面须填写的字段与需求类开发子任务有区别，但这些字段会改变工单内容的描述，请用户按父任务的不同选择创建对应的开发子任务。

*目前融合采预项目的开发子任务的工作流有特别区分，取消了测试子任务，测试用例，用例执行等子任务，将测试流程全部放入开发流程中。

融合采预项目中开发的问题类型名还是：需求类开发子任务，暂时未设定故障类开发子任务，工作流明细如下：

1、前两步与其他项目的开发子任务一致，

4.4 测试工单和测试用例工单处理流程

1．测试接口人在需求或故障工单分析完成之后，在该需求或故障单下手工新建测试子任务，根据需要可以新建多个，工作流目前设置是建单分配给测试接口人，主要是考虑建单人和分配任务人可能并非一个。

2．测试接口人分析测试任务，填写设计思路，点击测试设计，选择对应的测试设计人员进行分配。

3．测试设计人员处理测试设计任务，同时需要创建 测试用例 问题，测试用例可以在创建时与需求或故障或其他任务建立关联，需要手工选择，设计用例完成后点击设计完成，提交测试接口人审核确认，审核不通过则会退到设计中的状态，通过则测试执行，选择对应的测试执行人进行任务分配。

4．测试执行人员处理测试执行任务，同时需要在对应的 测试用例 问题下新建 测试执行子任务，记录此次测试用例的执行过程和结果，如果有缺陷，进入缺陷流程，测试执行完成后走完测试流程，若没有缺陷，则提交审核到测试接口人，审核通过则完成关闭，审核不通过则重新执行。

5．测试执行子任务审核通过关闭后，测试执行人则可以将测试子任务完成关闭，点击测试完成。

6．在测试接口人，测试设计人和测试执行人阶段均设置了测试退回的环节，目前测试子任务工单限定只有测试接口人，测试用例工单限定只有创建此工单的报告人和测试接口人才能执行重新打开的动作。

4.5 缺陷管理流程

1．内部测试或第三方测试过程中发生的缺陷，要进行缺陷流程管理，以用于版本质量和产品质量的评估，缺陷提交人新建 缺陷 类型的问题，并选择对应的开发接口人进行分配。

2．开发接口人收到缺陷以后，进行初步分析，点击提交缺陷处理，选择相应的开发处理人进行处理。

本文来源：https://www.bwwdw.com/article/tntf.html