本博文将介绍在软件开发中的常用的软件管理工具。Jira是Atlassian公司出品的一款事务管理软件（缺陷管理类的软件）。无论是“需求”，还是“BUG”，或是“任务”，都是“事务”的一种，所以Jira可以胜任非常多的角色：需求管理、缺陷跟踪、任务管理等等……因为Jira提供了专门的Scrum视图和Kanban视图，所以特别适合敏捷开发团队使用。大型互联网公司如LinkedIn、Facebook、eBay等内部都在使用Jira。

一、JIRA的基本概念

1.1 Project（项目）

项目的业务概念比较清晰，也容易理解。在JIRA系统中的项目概念是一组问题单（Issue）的集合，项目可以根据组织需求来定义，例如：软件研发项目，市场营销活动，服务台（helpdesk）系统，一个请假管理系统等等。每一个问题单属于一个项目。每个项目需要有一个名称（例如：Website Issues）和关键字（Key，例如WEB）。项目的关键字会成为项目问题单前缀，例如WEB-101, WEB-102等等。

1.2 Component（组件）

组件是项目中对问题单的一种逻辑分组，例如上图中的UI，DB，Server和Bug，组件一个项目根据组织的需要可能会包括多种组件。举例而言，一个软件开发项目可以包括如下组件：文档，后端，邮件子系统，界面。一个网站系统可能包括产品，联系方式等组件。在一个项目中，一个问题单可以归属于0到多个组件。

1.3 Version（版本）

对于一些类型的项目，尤其是软件研发项目，把一个问题单关联到一个特定的项目版本（例如：1.0 beta, 1.0, 1.2, 2.0）会非常有用。问题单（Issues）有两个跟版本有关的字段：

影响版本（Affects Version(s)） — 这个是要说明受问题单影响的版本.举例而言，一个软件Bug可能影响1.1和1.2版本。
修复版本（Fix Version(s)） — 这个是为了标明这个问题单在哪一个版本中被修复。继续上例，Bug的影响版本号是1.1和1.2，但是可能会在版本2.0中才被修复。没有修复版本号的问题单会被归类为未规划（Unscheduled）。
版本可以是下面三种状态之一：发布（Released），未发布（Unreleased）和归档(Archived）。版本会有一个发布日期，并且如果在发布日期之后还没有按时发布，这个状态会自动变为过期状态（overdue）。

1.4 Workflow（工作流）

JIRA中的工作流由一系列的状态（statuses）和变迁（transitions）构成，一个问题单在其生命周期中会经过这些状态和变迁。下图为例：

1.5 Issue（问题单）

JIRA的问题单非常灵活，页面可以定制，字段也可以定义。这里介绍一些内置的基本概念。

1.6 Issue Type（问题单类型）

JIRA可以用来跟踪不同类型的问题单。默认类型如下，JIRA的系统管理员也可能会定制这些类型。

Bug — 故障，功能失效
Improvement — 提升，既有功能增强
New Feature — 新功能
Task — 任务
Custom Issue — 根据需要客户化定制

1.7 Priority（优先级）

优先级也可以自定义，系统默认优先级如下：

Highest — 最高级别，表明问题阻塞了业务流程正常进行
High — 高级，表明问题引发明显故障，需要紧急关注
Medium — 中级，表明问题有一个明显的影响
Low — 低级，表明问题有一个轻微的影响
Lowest — 最低级

1.8 Status（状态）

每一个问题单都会有一个当前的状态。一个问题单开始阶段可能是Open状态，然后可以转移到Resolved或者Closed，依赖于系统流程配置的方式。内置的常见状态如下：

Open — 打开状态，表明问题单已经被创建，等待被分配到开始处理状态。
In Progress — 处理中状态，表明问题单已经被分配人激活，并处于被处理状态中.
Resolved — 已解决状态，表明问题已经被处理完成，等待问题报告人的验证。从这个状态，问题单一般可以进一步变更为重新打开状态（Reopened）或关闭状态（Closed）。
Reopened — 重新打开状态，问题经过验证发现没有被解决，就可以变更到这个状态。
Closed — 关闭状态，问题被彻底解决就可以转为这个状态。

1.9 Resolution（决议）

一个问题可以有多种解决结果，其中只有一种方法是修复。一个解决结果通常会在状态变更时候被设置起来。系统默认的问题解决结果会有以下几种：

Fixed — 修复。
Won’t Fix — 不用修复。例如这个问题所描述的现象已不再有影响了。
Duplicate — 重复。同其它已经存在的问题重复了，推荐把相关的单子链接起来.
Incomplete — 未完成。没有足够的信息继续完成这个问题。
Cannot Reproduce — 不能重现。如果以后有更多信息可以继续可以重新打开这张单子.
Won’t Do — 不做。类似于不用修复的方案，试用于软件项目的默认状态。

二、JIRA的基本配置与实战

JIRA的应用配置(V7.8版本)很简单和直观，使用管理员账号登陆以后，打开相应的配置页面很快就能搞清楚。配置主要是三块内容：项目（Projects），问题（Issues）和用户管理（User Management）。面举例说明一个配置过程。配置场景是创建一种新的问题类型“自产提升需求”，为这种类型设置一个流程，并且为这种问题类型定制一个UI页面，增加一个客户化的字段。

2.1 创建项目

从菜单选择创建项目，选择一种项目模板，点击下一步：

这个创建好的新项目会有一套默认的流程和问题类型，创建完成后实际已经就可以使用了。实际场景中，每个不同公司，不同部门都可能会有自己特有的工作类型和流程，下面会按场景的描述一步步进行配置。配置好流程后，下一步就是配置问题单类型了。

2.2 创建问题单类型

创建一个自产提升需求单类型。在管理员（Administration）菜单下，打开Issues菜单，选择增加问题类型。

在Issues Type的菜单里面就可以看到刚刚新增的Issue Type了。

2.3 定制流程

下面就可以为这个新的问题类型创建一个流程了，在管理员的菜单内找到Workflow的菜单项，选择新增一个流程，或者也可以从现有流程中拷贝一个出来：

填写好流程名称和备注，点击确认就可以创建这个流程了。下一步选择编辑流程，可以用图形界面编辑界面或者文字编辑方式来编辑流程，流程有两个重要概念状态（Status）和变迁（Transition）。参考正确的业务流程配置即可：

把问题单和流程加入项目生效：完成新问题单创建和流程创建后，下一步就把他们挂入项目生效。进入项目设置页面，选择编辑问题类型，把新的问题类型加入。

可以在问题类型的子页面中看到新增的自产提升单类型，把它拖到生效栏位，点击保存。在项目设置中就可以发现新的类型已经被加入了。

同样的方式，在项目配置的页面中选择Add Workflow，找到之前配置的新流程，选择下一步

在下一页中，选择流程适用的任务类型，勾选后点击完成

最后别忘了发布（！重要提示—一定要点发布流程才能正式生效，这个问题曾让我花了很长时间才找到流程不能生效的原因）

到这里其实一个配置就已经完成了，你可以点击创建（Create）来试用一下新流程和问题单了。

2.4 增加客制字段

JIRA提供的默认表单可能不够用怎么办，这时候就可以新增一个字段了，通过管理员的权限进入系统，就可以通过字段菜单来新增字段了。字段类型可以根据需要选择。

创建一个URL类型的字段为例：

下一步就是要把这个字段挂入页面中去。在项目设定中的Issue Type中选择增加一个字段，把之前新增的字段加入，还可以拖动调整显示顺序。

最后在页面的表单中选择显示这个字段即可。

2.5 定制受理页面

JIRA还可以完全定制一个新的表单，这个功能很强大，但是比较耗时，感兴趣的同学可以自己试试。

三、基于JIRA的测试管理插件

Xray就是众多这些插件应用中的一个，Xray在测试管理这个领域比较知名，下面就用这个插件为例介绍下使用JIRA+Xray如何进行测试管理。

3.1 核心概念和模型

项目可以包括多个版本，每一个版本可以包括一个或多个需求，一个需求可能包括一或多个测试用例。实际上，一个需求甚至可以包括测试集合。测试计划包括那些需要被跟踪的测试用例。测试执行包括那些希望被执行的测试用例。一个测试用例可以被包括在多个测试集合中，可以被多个测试计划所使用，也可以被多个测试执行所执行。一个测试用例可以包括一或多个前置条件，一个前置条件也可以被多个测试用例所引用。每次一个测试用例在测试执行中被执行后，一个测试运行（Test Run）就会被创建。

3.2 测试流程

通常一个典型的测试生命周期如下，在Xray基本都可以找到对应的映射实体：

每一个阶段的测试一般都包括计划，设计，执行和报告四个主要过程，Xray中可以通过创建特定的问题单来对应以上步骤。

计划阶段: “Test Plan”问题单
设计阶段: 通过创建“Pre-Condition”问题单和“Test”问题单（测试用例）解决. 另外还可以通过测试集合来组织这些测试用例。
执行阶段: Test Execution问题单
报告阶段: 通过使用JIRA内置工具，通过测试执行问题单可以产生需求覆盖率及一些其它测试报告数据。

3.3 需求和测试用例关系

通常在使用一个Xray的测试项目之前，最好先创建一个需求相关的项目，这样通过和需求项目的关联，我们可以很容易知道测试的覆盖率。

在系统中，测试用例会关联到需求（Requirement）或者缺陷（Defect）中，典型的需求问题会包括：Epic，Story，Requirement，Sub Requirement，Feature和Improvement这些，典型的缺陷问题会包括：Bug和Defect。需求和缺陷同测试用例的关系可以表示如下。

使用JIRA内置的Link类型，可以把需求和测试用例链接起来，以上图为例：

需求R “is tested by” 测试用例T (或者测试集合TS)
测试用例T (或者测试集合TS) “tests”需求R
缺陷D “is created by” 测试用例T
缺陷D “is tested by” 测试用例T (或者测试集合TS)
测试用例T “created” 缺陷D
测试用例T (或者测试集合TS) “tests” 缺陷D

3.4 如何使用Xray（操作介绍）

使用Xray的Template创建一个测试项目，创建完成后，会自动用于Xray自带的问题单类型，流程，表单和字段设置

完成测试项目创建后，就可以直接开始使用系统了，可以创建一个测试用例试试看。

为需求单关联一个测试用例，打开需求单，点击More，选择Link，选择测试用例即可。

为缺陷单关联一个测试用例，同样的方法，如果需要为一个缺陷单关联一个测试用例，选择link，选择created by或者tested by选项，既可把缺陷单和测试用例关联起来。

执行一个测试阶段，首先去创建一个测试计划，然后把需要测试的测试用例挂入测试计划中去，接下来可以创建一到多个测试执行，测试过程如果发现问题可以直接创建故障单。一个测试用例测试失败后，可以直接在当前测试执行中标识为Fail，等相关故障单修复完毕后，可以再次创建一个新的测试执行，后一次的测试结果如果是Pass，整个测试用例的状态也会被标明为Pass。在下面这个例子中，一个测试计划包括一个测试用例，这个测试用例产生了两个测试执行，第一次执行失败后创建了一种故障单，第二次执行成功。

最后就是测试报告。这个通过JIRA内置工具可以很方便的统计测试覆盖率，如下：