JIRA-测试管理实用手册-全-

JIRA 测试管理实用手册（全）

原文：zh.annas-archive.org/md5/2A3F0396A60107802344B2CD4B1CF532

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

本书将帮助读者实际理解使用 Jira 进行测试管理的过程。本书假设读者在试图简化其测试管理流程时没有任何资格要求，并将指导您逐步实施有效的测试管理方法。它侧重于基本概念，涵盖软件测试过程的细节，然后探讨并对比了三种最流行的 Jira 插件——Zephyr、Test Management 和 synapseRT，这些插件被广泛用于测试管理。

涵盖的主题包括在 Jira 中创建和管理项目，创建 Jira 票以管理客户需求，跟踪 Jira 票，创建测试计划、测试用例、测试套件、缺陷、需求追踪矩阵，并在 Jira 中生成报告。它还涵盖了在 Jira 中建立可扩展和有效的测试管理套件的最佳实践。本书主要关注以下内容：

使用户熟悉概念：读者首先学习软件质量保证思维过程，以及行业中使用的质量管理标准，从而使自己熟悉软件开发过程和各阶段的交付管理，以及在软件开发生命周期的每个阶段生成的交付物管理。
使用户熟悉工具：读者将进一步学习如何使用 Jira 来组织和管理他们的 Scrum 和 Kanban 敏捷项目。他们还将了解来自 Atlassian Marketplace 的 Jira 插件，这些插件将有助于测试管理。
理解测试管理方法：读者将学习如何根据项目需求规划和管理工作流程。
学习实施：读者将详细了解根据项目需求选择各种项目执行工作流程的最佳方法，以及学习测试规划、测试策略和测试执行的不同方面。
监控和控制项目活动：读者将学习 Jira 如何帮助定义策略，并使用不同类型的报告监控和控制项目活动。
与 Jira 和 Jenkins 的持续集成：读者将学习如何配置 Jira 插件，使用 Jenkins 在 Jira 中创建、管理和执行自动化测试脚本。

这本书是为谁准备的

本书适用于任何对学习在其团队或组织中实施测试管理最佳实践感兴趣的质量保证专业人员、软件项目经理或测试经理。

从本书中获益最大

我们期望读者了解软件开发过程的基础知识，并对 Jira 有一定的了解。读者不需要具备任何测试管理工具的先前知识，因为本书将从基础知识到高级水平覆盖这些概念。

要成功完成本书，读者需要具有至少 Intel Core i3 处理器或同等配置、8 GB RAM 和 4 GB 可用存储空间的计算机系统。此外，您还需要以下软件：

Windows 或 iOS 操作系统。
Google Chrome / Firefox Mozilla / Internet Explorer（最新版本）浏览器
Jira（7 版及以上）与 synaseRT、Zephyr 和 Test Management 插件。本书使用的版本是 7。
Jenkins（2.150 版及以上）。
Eclipse IDE。
Jenkins 的 Java 8。

下载彩色图片

我们还提供了一个 PDF 文件，其中包含本书中使用的屏幕截图/图表的彩色图片。您可以在这里下载：www.packtpub.com/sites/default/files/downloads/9781789954524_ColorImages.pdf

使用的约定

本书中使用了许多文本约定。

CodeInText：表示文本中的代码词，数据库表名，文件夹名，文件名，文件扩展名，路径名，虚拟 URL，用户输入和 Twitter 用户名。这是一个例子：“测试人员可能还需要使用不同类型的文件，如.doc、.docx、.txt、.pdf、.xls、.xlsx、.csv、.png或.jpeg来导入数据，以确保它按照测试用例中定义的方式工作或不工作。”

代码块设置如下：

package JenkinsDemoPkg;
import org.testng.annotations.Test;
public class demoJenkins {
        @Test
        public void testJenkins(){
               System.out.println("Hello World");
        }
}

粗体：表示一个新术语，一个重要的词，或者屏幕上看到的词。例如，菜单或对话框中的单词会以这种方式出现在文本中。这是一个例子：“让我们点击“创建新项目”按钮。”

警告或重要提示会以这种方式出现。提示和技巧会以这种方式出现。

第一部分：软件质量保证简介

我们将学习软件质量保证背后的思维过程以及行业中使用的质量管理标准。然后，我们将熟悉软件开发过程及其阶段。我们还将学习如何管理在软件开发生命周期的每个阶段生成的可交付成果。

本节将包括以下章节：

第一章，软件质量保证概述

第一章：软件质量保证概述

作为人类，我们会犯错吗？答案是压倒性的“是”。有一些质量控制和决策失误的例子震惊了世界，并给涉及的公司带来了巨大的损失。例如，我们都记得挑战者号航天飞机在发射时爆炸的悲剧事故。这是一个简单的疏忽还是可能充分测试系统以控制故障威胁并避免爆炸的情况？

要弄清楚此类事件的底细，我们需要向参与设计和生产这些系统的人学习。错误通常是不可避免的，可以发生在生产的任何阶段，原因可能是需求不清晰、赶工满足截止日期或对系统的了解不足。然而，我们可以遵循一个过程，可以帮助减少制造或引入任何新错误，同时防止重复已知错误。这需要改变思维过程，并依赖制定标准实践，以生产更成功的产品。让我们首先了解质量意味着什么，然后再开始我们的旅程，重塑自己，创造可持续和可重复的最佳实践，交付无缺陷的软件。

在本章中，我们将涵盖以下主题：

什么是质量？
我们如何确保质量？
软件测试思维过程
质量管理体系
软件开发生命周期与软件测试生命周期
测试类型
准备测试数据和管理测试工件

什么是质量？

质量，就像任何其他度量标准一样，需要一个参照框架或标准，以便我们与客户需求进行比较。这些标准可以帮助我们维护和促进产品的一致性，最小化所需的重新工作量，并生产面向客户的产品。

质量可以用不同的方式定义。根据国际标准化组织（ISO）13628-2:2006，质量可以定义为符合指定要求。

ISO 9000 提出了七个主要的 ISO 原则，围绕着制造优质产品：

客户关注
领导力
人员的参与
过程方法
改进
基于证据的决策
关系管理

质量...

为什么要关心质量？

建立品牌需要大量工作，继续建立并保持对品牌的信任需要更多的工作。为了在当今竞争激烈的市场中生存并保持良好的声誉，组织在软件开发生命周期中加入测试阶段，并投入时间测试和调试软件产品。构建质量产品可以降低风险并提高性能。设计良好的产品可以减少用户的不满和挫折感。它还提高了产品的可靠性，改善了最终用户的体验，从而使客户满意。

谁对质量负责？

产品和服务对其客户群有直接影响，因为它们发布到市场上解决客户面临的问题。因此，提供此类服务或产品的组织在它们上市前后都有责任质量。组织需要考虑可能影响产品的内部和外部环境因素。这需要适当的规划和委派，以便为产品的每个方面分配团队和资源。通常，团队包括以下角色：

产品经理
项目经理
质量保证（QA）经理
业务分析师
软件开发人员
QA 工程师/测试人员

这个团队致力于...

我们如何确保质量？

质量保证是任何业务成功的关键。软件开发过程经历了各种阶段，确保每一步的质量是必不可少的。在前一节中，我们看到了为什么交付质量产品很重要。在本节中，我们将学习如何交付质量产品。

在规定的时间内交付一个明确定义的项目范围，以一定的预算，并且符合客户期望的一定质量标准是使项目成功的关键因素。然而，在这些因素之间达到合理的权衡是必要的，以便快速上市并保持竞争力。

例如，如果项目范围增加，而资源和时间保持不变，这将直接影响质量，因为团队需要在规定的时间内交付更多。由于他们的工作时间不变，团队可能不得不削减测试时间或减少测试覆盖范围以按时交付。以下图表描述了铁三角：

铁三角

三角形的目标——也称为铁三角——帮助我们成功交付项目。为了确保质量，我们需要满足铁三角的目标。传统的项目管理三角形包括以下内容：

范围

确保我们已经与客户验证和确认了项目范围，并排除了项目范围之外的内容
确保我们已经设计了需求规格说明文档和完成项目所需的所有支持文档
确保我们已经确定了所有测试用例和场景，以验证需求文档和测试计划中规定的范围

时间

确保所有活动及其依赖活动都得到适当规划
确保活动也包括会议时间、批准的假期、资源可用性和缓冲时间作为应急计划的一部分
确保每个项目启动都按时进行

成本

确保已经确定了基于技能和预算的所有资源
确保已经获取或更新了所有必需的工具、供应商产品和购买许可证，以适应指定的预算

质量

确保测试经理和测试领导已经进行了需求差距分析，并准备好了测试计划
确保测试计划列出了可能影响软件产品质量的所有因素，如资源、他们的技能水平、所需工具、范围内的事项、范围外的事项、测试策略、测试方法、兼容性和支持的浏览器版本

铁三角帮助项目经理分析和理解在满足这些因素时的权衡。必须达到适当的平衡，以确保所需的质量水平，从而生产成功的产品。

软件测试思维过程

软件产品是一个多学科团队共同努力制作的具体产品，以满足客户需求。尽管团队由多个角色组成，如经理、分析师、开发人员和测试人员，但每个角色对于交付合适和稳健的产品都是必不可少的。这要求每个贡献者都参与到质量过程中。

如果每个角色都在确保质量方面发挥作用，为什么我们还需要测试人员的独立角色呢？一个简单的原因是引入一双新的眼睛。虽然开发人员可能测试他们自己的代码或软件，但确保质量需要不同的思维方式。开发人员的思维方式是证明他们的软件能够工作，但测试人员的...

质量管理系统

到目前为止，我们已经看到了确保项目质量的各种方法，但是我们如何评估我们选择的质量体系是否有效呢？如果一个组织需要将其工作外包给另一个组织，并且需要知道承包商是否能够提供质量服务和产品，这就更成为一个关注点。对质量体系的需求进行审计需要使用质量管理体系（QMS）。

QMS 是一套标准，定义了组织如何满足客户和其他利益相关者的要求。质量标准是一套指南，而不是实际标准，在软件行业被广泛接受，具有明确定义的流程和评估指标，以帮助改进软件的质量。选择标准的动机留给企业和管理层决定。一旦获得认证，根据选择的认证，有必要制定质量计划。

所有质量标准都有相同的基本原则：

明确定义的软件开发流程
将人与流程相结合，以协同作用和促进对质量改进计划的承诺
强制执行为每个流程生成文档的要求

因此，流程应该被用作质量改进的促进者，而不是阻碍。管理层有责任在组织内营造一个在开发的明确定义框架内工作的文化，同时促进激励措施，以在开发过程的每一步推动质量。

有几个软件工程标准是由主要的标准化和认证机构制定的。ISO 9000 和能力成熟度模型集成（CMMI）是软件工程和产品开发组织中最广泛使用的国际标准。让我们详细了解它们，以了解如何实施标准可以帮助组织确保质量。

ISO 9000 系列

ISO 9000 是由 ISO 定义的一套标准。如果一个组织需要获得认证，它将认证最新的标准 ISO 9001:2015，这取代了之前的版本 ISO 9001:2008。ISO 9001:2015 提供了推动组织持续改进的指南。

这个最新的更新是基于高级结构（HLS）—附录 SL，它帮助组织将多个管理系统纳入核心业务流程并提高效率。

ISO 9001:2015 标准规定了 10 个条款，总结如下：

条款 1（范围）：解释标准的用途和涵盖的内容。范围条款涵盖以下方面：
标准的目标和目的...

CMMI

CMMI 是一套指南，使组织能够生产高质量的软件并提高其性能。CMMI 主要是为了评估组织承担美国国防部的大型开发项目的能力而开发的。

CMMI 于 2018 年 3 月发布了模型的第 2 版。这是从第 1.3 版的更新。CMMI v2.0 分为 4 个类别和 10 个能力，25 个实践领域。

现在让我们了解这些类别和实践领域：

执行：这个类别涉及设计和开发符合客户需求的高质量产品，同时减少供应链风险。执行阶段包括四个能力和 10 个实践领域，如下：
确保质量（ENQ）：
开发和管理需求：获取需求，确保利益相关者的相互理解，并调整需求、计划和工作产品。
流程质量保证：验证和促进执行的流程和产生的产品的质量改进。
验证和验证：这个实践领域的流程应该做到以下几点：
验证所选的解决方案和组件是否满足其要求
验证所选的解决方案和组件在其目标环境中是否实现其预期用途
同行评审：利用专业人员和同行审查产品，以识别和解决问题。
工程和产品开发（EDP）：
产品整合：整合和交付符合所需功能的高质量解决方案
技术解决方案：设计和构建满足客户要求的解决方案
交付和管理服务（DMS）：
服务交付管理：在符合服务级别协议（SLA）的情况下交付产品和服务
战略服务管理：建立和维护有关组织能力和战略需求的数据，这些数据作为标准服务
选择和管理供应商（SMS）：
供应商来源选择：通过评估供应商交付的解决方案是否满足预期要求来选择供应商
供应商协议管理：与选定的供应商建立协议，并确保供应商和收购方都遵守条款
管理：这个类别涉及提高员工生产力，同时管理来自波特五力模型的干扰，以实现市场速度。这个类别包括三个能力和七个实践领域，如下所示：
计划和管理工作（PMW）：
估算：预测生产高质量产品或解决方案所需的铁三角因素。
规划：制定描述基于组织标准和约束条件的交付流程的计划。这包括预算、时间表和资源，以及利益相关者和开发团队。
监控和控制：跟踪项目的进展，以确保如果项目偏离计划，则采取适当的控制措施。
业务韧性管理（MBR）：
风险管理和机会管理：识别、记录和管理潜在风险和机会
事件解决和预防：分析不符合要求，找出根本原因，并制定计划防止事件再次发生
连续性：制定应急计划，以在紧急情况下维持运营
管理劳动力（MWF）：
组织培训：开发人员的技能和知识，使他们有效高效地履行自己的角色
启用：这个类别涉及确保利益相关者的认同并确保产品的完整性。它包括一个能力和三个实践领域，如下所示：
支持实施（SI）：
因果分析和解决方案：了解所有结果的根本原因，并采取措施防止不符合要求的再次发生和/或确保符合要求
决策分析和解决方案：使用记录的过程做出和记录决策，分析替代方案
配置管理：使用版本控制、变更控制和适当的审计机制管理交付的完整性
改进：这个类别涉及确保绩效目标支持业务需求，同时建立可持续的效率。它包括两个能力和五个实践领域，如下所示：
提高绩效（IMP）：
过程管理：管理和实施持续改进流程和基础设施，以确定支持以可持续方式实现业务目标的最有利的流程改进
过程资产开发：记录和维护用于执行工作的流程列表
管理绩效和测量：使用测量和分析来管理绩效，以实现业务目标
维持习惯和坚持（SHP）：
治理：在过程活动的赞助和治理方面，向高层管理人员提供建议
实施基础设施：确保组织中重要的流程得到持续使用和改进

要了解更多关于新的 CMMI v2.0 的信息，请访问www.cmmiinstitute.com/cmmi/model-viewer。

成熟度水平

前面提到的类别和过程领域基本上是改善组织业务绩效的因素。根据组织如何实施这些过程领域，它们所处的等级被称为成熟度水平。

以下图表显示了软件过程成熟度的水平。根据软件过程成熟度，组织可以处于这六个成熟度水平中的一个。

https://commons.wikimedia.org/wiki/File:Characteristics_of_Capability_Maturity_Model.svg

让我们详细看看这些成熟度水平：

成熟度水平 0（不完整）：在这个水平上的组织...

软件开发生命周期与软件测试生命周期

软件开发生命周期（SDLC）是开发和交付软件产品或服务的过程，详细说明了从设计、编码和测试到发布后维护的端到端阶段。软件测试生命周期（STLC）是 SDLC 的一个子集。让我们详细探讨 SDLC 和 STLC。

SDLC

SDLC 是一个计划和组织良好的过程，将软件开发任务分成各个阶段。这些阶段帮助团队构建符合范围、时间、成本和质量因素的产品。它还帮助项目经理在每个阶段监控和控制项目活动，并有效地进行风险分析。

任何传统的 SDLC 都包括以下基本但关键的阶段：

需求分析：软件产品存在是为了解决客户的问题。因此，了解客户需求对于构建产品至关重要。需求分析是实现这一目标的阶段。这是我们试图回答问题的阶段，我们想要构建什么，为什么？
我们创建正式文件...

STLC

STLC 是 SDLC 的一部分。这是一种系统化的方法，可以确保软件产品或服务的质量。与 SDLC 一样，STLC 也包括不同的阶段，列举如下：

需求分析：一旦项目启动，团队就开始积极地收集客户需求。在这个阶段，测试人员、业务分析师和开发人员仔细研究用户提出的每个规格。在 STLC 的需求分析阶段，测试人员可以做以下事情：
测试人员需要将更广泛和更复杂的需求分解为更小的部分，以了解可测试的需求、测试范围和验证关键点，并确定需求中的差距
他们可以与开发人员和业务分析师就技术或软件需求、限制和依赖关系等问题澄清疑虑，并改进建议或强调需要添加到需求中的缺失信息
测试人员还可以在进入测试计划阶段之前，突出风险并制定风险缓解策略
测试计划：这是测试人员（通常是主管测试人员或经理）根据时间、范围和资源等各种因素计划测试活动和里程碑，以帮助他们跟踪项目的进展。让我们看看测试人员在测试计划期间执行的一些活动：
在这个阶段，测试人员计划测试活动和策略，这些活动和策略可以在随后的测试阶段有效地使用
此外，需要确定测试范围，并标记超出范围的部分
他们还需要根据当前产品需求决定在测试执行阶段实施的测试技术和类型。
此外，了解工具的要求以及所需资源的数量和其技能水平可以帮助他们更好地规划任务。

考虑这些因素和所选项目的时间表，测试人员可以准备一个有效的测试计划，以适应项目预算，并帮助团队创建一个高质量的产品。

测试设计：这是测试团队开始分解每个需求并将其转换为测试场景的地方。这些测试场景涵盖了正常路径、正向测试、需要验证的关键路径以及需要使用不同参数进行验证的功能。它还包括负面场景、验收测试以及基于用户交互工作流和数据流的场景。
根据应用程序的类型和需求分析中列出的测试类型，测试人员可以开始创建自动化测试脚本，添加压力和负载测试的场景，并进行性能测试，以帮助测试人员更好地测试应用程序并发现更多缺陷。
一旦场景准备好并经过审查，测试人员就会开始准备测试用例或测试脚本（在自动化测试的情况下），以列出详细的步骤。
一个场景可以有一个或多个测试用例，而一个需求可以与一个或多个场景相关联。在创建需求跟踪矩阵（RTM）时，这种映射是有帮助的。
环境设置：建立一个独立的测试环境总是一个良好的做法。保持测试代码与开发代码分开可以帮助测试人员和开发人员在特定版本中调试代码并更快地找到根本原因。此外，这使开发人员有机会在代码和其副本中进行错误修复，并在其环境中验证修复是否有效，然后再将其发送给测试人员。这样可以节省记录缺陷和收集工件所需的时间和精力。
在设置环境时，测试人员需要确保已配置所需版本的工具、软件、硬件和测试数据。
他们还需要确保他们有权限访问具有所需角色的环境，以测试应用程序、数据库和其他所需工具。测试环境应模拟最终用户的环境。这有助于记录产品的已知行为，并有助于在交付后管理期望。
测试执行：一旦代码由开发人员准备并经过单元测试，它就会部署到测试环境中，以便测试人员可以启动测试执行阶段。
测试人员执行的第一个测试是冒烟测试，以验证软件产品或服务是否满足基本要求。
软件通过冒烟测试后，测试人员可以继续验证过程，按照测试计划阶段计划的测试类型进行。
在执行阶段，测试人员将不良结果记录为缺陷。一旦缺陷被修复，测试人员需要重新测试已更改的部分以及未更改的应用程序部分，作为回归测试的一部分。
测试报告：对于测试人员、领导和经理来说，跟踪和监控项目的进展非常重要，这样可以更容易地及早识别障碍或风险。这也有助于灵活地提供解决方案并解决问题。
报告测试有助于利益相关者了解每次迭代或测试周期后测试执行的状态。
这也有助于缺陷管理人员识别依赖于缺陷的受阻测试用例。
相应地，其优先级或严重性可以更改，以帮助推进测试执行。
在所有迭代结束时，将准备一份最终报告，其中包括测试执行阶段发现的缺陷数量、关闭或标记为推迟的缺陷数量，以及通过或标记为 N/A 的测试用例数量。除此报告外，还要验证所有工件，并确保在需要时已添加。
闭环：在闭环阶段，测试经理或测试负责人确保所有测试按计划成功完成。
团队领导或经理确保所有必需的可交付成果和闭环文件按照评估标准获得批准和接受，并作为闭环阶段的一部分签署批准。

在接下来的章节中，我们将更多地了解 STLC 中的每个阶段，以及在 Jira 中的实际实施和使用其插件。

测试类型

为了确保产品的质量，我们需要了解我们的应用程序及其测试需求，使其更加健壮和无错误。根据客户需求和我们正在开发的产品类型，我们可以在 STLC 的测试计划阶段提出所需的测试类型列表。

在本节中，我们将学习在测试执行阶段可以使用的不同测试类型。

黑盒测试：关注应用程序通过一组已知的输入参数产生的外部行为、规范和期望的最终结果，而不是代码的内部结构。这里的主要目标是验证软件是否符合最终用户的预期...

准备测试数据和管理测试工件

在软件测试中，使用有效或无效参数以及不同的输入值集来验证测试场景是否至关重要，以确保其行为符合设计的测试。为了验证端到端的场景和顺利的路径工作流程，我们需要创建测试数据。然而，有时，测试的要求是将系统带到可以开始测试的初始级别。所有这些都可以作为测试数据准备阶段的一部分完成。

根据系统要求，测试人员可以创建不同的授权和未授权用户集，具有不同的角色，例如管理员或客户支持执行人员，他们都具有不同的权限集来访问应用程序。创建一组并发用户以访问应用程序也是测试数据准备的一部分。

测试人员可能还需要使用不同类型的文件，例如.doc、.docx、.txt、.pdf、.xls、.xlsx、.csv、.png或.jpeg来导入数据，以确保它按照测试用例中定义的方式工作或不工作。在这些文件中，他们可以添加有效或无效的用户，留下一些字段为空，或添加不可接受的值，这将破坏应用程序或引发错误。

测试人员还使用这些文件作为其自动化测试脚本的输入，这些脚本通过插入从这些输入文件中读取的测试数据来进行测试验证。

管理测试工件

管理测试工件涉及存储和管理作为测试执行阶段的一部分生成的证据，或者也可以是在 SDLC 的任何阶段之后生成的一组可交付成果。

正确管理这些工件非常有用：

在缺陷记录和重新测试期间生成的工件可以节省开发人员和测试人员的时间，避免他们不得不调试代码的每个部分，使用指定的测试数据、构建版本和环境重现测试。日志错误文件、截屏、带有结果集的数据库查询、输入参数、测试期间使用的应用程序的 URL、环境、测试日期、构建编号等。
生成的可交付成果...

总结

在本章中，我们详细讨论了软件质量保证。让我们总结一下重要的观点——优质产品指的是符合客户要求的产品。ISO/IEC 25010:2011 质量模型列举了 13 个特征，帮助我们评估产品的质量。生产优质产品需要产品开发团队中互补的技能和角色的结合。范围、时间、成本和质量是相互交织的，因此在开发满足组织能力和客户满意度的产品时，平衡它们是必不可少的。测试破坏的态度对于测试人员在其职业生涯中取得成功是必要的。我们看了一下测试人员需要带到工作中的思维过程，以精通这项工作。质量管理体系解决了开发优质产品所需遵循的流程。我们详细讨论了 ISO 9001:2015 和 CMMI v2.0。我们看了一下 SDLC 的五个阶段，并了解了 STLC 如何融入其中。我们讨论了测试人员在根据客户和产品需求规划测试时可以利用的七种测试类型。在最后一节中，我们了解了测试数据和工件是如何准备、管理、保留和共享的，以实现有效的测试管理。

在下一章中，我们将研究 Jira 中的项目组织，并探讨 Zephyr、Test Management 和 synapseRT 插件，这些插件将用于在 Jira 中实现测试管理。

第二部分：Jira 环境-概述

我们将学习如何使用 Jira 来组织和管理敏捷 Scrum 和看板项目。我们还将了解来自 Atlassian Marketplace 的 Jira 插件，这些插件将有助于测试管理。

本节将包括以下章节：

第二章，开始使用 Jira
第三章，了解 Jira 测试的组成部分

第二章：开始使用 Jira

项目的成功是开发团队在开发过程的每个阶段所采用的方法的结果。为了取得成功，开发团队需要一个优秀的项目经理，他具备良好的项目管理技能和经验，能够交付满足最终用户需求的产品。项目管理流程分为以下阶段：

启动
规划
执行
监控和控制
结束

在本章中，我们将涵盖以下主题：

Jira 是什么，以及如何用于项目管理
如何设置 Jira 进行项目的启动和规划
三个插件——synapseRT、Zephyr 和测试管理的功能和特性概述

什么是 Jira？

Jira 是由澳大利亚的 Atlassian 公司开发的软件工具，提供了一种有效的组织和管理项目的方式。它还提供了满足敏捷项目管理需求的能力。

Jira 就像一个容器，包含在 Jira 项目下分类的不同类型的 Jira 问题。使用 Jira，您可以设计、管理和定制各种类型的任务、工作流程和报告，并简化项目管理流程。它有助于简化创建和管理项目工件的过程，并为项目利益相关者提供了一个共享平台来监控项目进展。

Jira 通过以下方式提高协作和生产力：

减少跟踪客户所花费的工作...

使用 Jira 组织项目

现在我们已经了解了 Jira 是什么，我们可以学习如何使用它来组织项目。

Jira 可以在企业级别上用于为各个部门创建不同的项目。虽然没有固定的创建项目的规则，但决定某些参数可以通过将项目分隔，有助于有效地制定工作策略。

使用 Jira 进行敏捷项目管理

组织正在从传统的瀑布项目管理流程转向迭代、快速、顺畅和系统化的敏捷项目管理流程。产品开发的敏捷方法在每个迭代或周期中选择最相关的需求，并在每个周期中生成最终产品的部分。

迭代通常较短，因此计划为有限期。它提供了在不影响正在开发的更大产品的情况下撤销任何新变更的灵活性。因此，它有助于减少失败的风险并控制其影响。与传统的瀑布流程相比，每个开发阶段都是完整的，但又相互依赖于前一个阶段。...

什么是 Scrum？

Scrum 是一个框架，通过其自适应、迭代和系统化的方法，帮助解决客户需求和复杂产品需求。它帮助团队以不同的迭代方式交付产品，以实现目标。作为产品开发的一部分，它提供了定义利益相关者角色和组织任务的机会，将复杂的项目范围分解为更小、更易理解的需求，并提供了更好的集成范围变更的方式。下图显示了敏捷 Scrum 方法论中的阶段和参与者，我们将在接下来详细讨论：

https://commons.wikimedia.org/wiki/File:Scrum_process.svg

详细了解 Scrum

在 Scrum 中，项目需求可以使用产品待办事项和冲刺待办事项进行组织：

产品待办事项：这是一个包含复杂用户需求、愿望清单、需求和想法的列表。产品负责人负责根据客户需求组织和优先考虑这个列表。利益相关者可以随时向列表中添加需求，但只有产品负责人负责优先考虑和删除需求。因此，产品待办事项总是处于增长阶段。
冲刺待办事项：一旦需求被拆分成一个较小的项目列表，团队就会准备和计划需要在即将到来的冲刺中交付的任务列表。这些项目是...

Scrum 会议

Scrum 相信协作，并要求利益相关者参加会议，以使每个人都了解和知晓范围内的事项、障碍、依赖关系、风险、资源可用性等，以便能够有效地进行规划和解决。

Scrum 中有五种关键会议类型：

待办事项细化会议：也称为产品待办事项整理，旨在为产品负责人和团队提供一些时间来准备、重新排序和组织下一个冲刺的待办事项之前。通常，Scrum 主管、产品负责人和开发团队参加待办事项整理会议。
冲刺规划：这是所有利益相关者承诺产品待办事项（PBI）和相关任务的机会，他们将作为即将到来的冲刺的一部分完成。这些会议帮助团队确定用户故事，分配故事点等。
冲刺回顾：验证用户故事是否符合团队指定和同意的范围和验收标准，以及它们是否满足客户的需求是很重要的。冲刺回顾会议旨在向产品负责人展示开发和测试的产品。
冲刺回顾：由于 Scrum 是一个持续的自适应框架，了解做对了什么和做错了什么是必要的。冲刺回顾会议为所有利益相关者提供了一个机会，以确定改进的范围，并保留在当前冲刺期间运作良好的做法。这个会议通常在冲刺结束时进行。
每日 Scrum：为了及时应对障碍并跟踪项目的进展，所有利益相关者分享他们正在处理的任何工作项的当前状态是很重要的。每日 Scrum 会议旨在解决这些问题，并且顾名思义，它们每天都会发生（平均持续 15 分钟）。

读者可以在此链接找到有关 Scrum 的更多信息：www.scrumalliance.org/。

什么是 Kanban？

Kanban 是一个持续交付、精益调度的流程，旨在帮助人们更有效地作为团队合作。Kanban 和 Scrum 的目标都是及时交付产品。然而，Kanban 使用 SDLC 的阶段来跟踪工作项的进展，从需求收集到产品或软件的交付。这些不同的泳道是待办事项、选择开发、进行中和完成。

与 Scrum 不同，Kanban 不遵循迭代方法，而是具有增量性质的长期开发周期。由于没有迭代，工作项不需要在特定时间开始或结束，而是取决于其他因素，例如工作项的优先级等。

项目启动和管理

现在我们已经了解了 Scrum 和 Kanban 的基础知识，让我们发现 Jira 如何帮助我们使用预定义的项目模板创建和管理我们的敏捷项目。我们将利用 Scrum 和 Kanban 的软件开发模板来规划我们的项目。

在 Jira 中如何启动项目

Jira 为团队提供了灵活性，可以根据他们的角色组织项目条目。我们将在下一节讨论这些用户角色和权限。然而，管理员角色是我们可以根据需要创建和设置项目的角色。

设置 Jira 项目是一个非常简单的过程。注册后，您将看到欢迎页面，在那里您可以从提供的模板中创建项目，例如 Scrum、看板等。

让我们点击“创建新项目”按钮。它为我们提供了在软件或业务中创建项目的模板。在软件中，我们可以看到基本软件开发、Scrum 软件开发和看板软件开发项目的模板。这...

Jira 中的基于角色的权限

Jira 可以针对不同的用户角色进行设置和配置，以满足团队的需求。敏捷项目有各种角色，如 Scrum 主管、开发经理、产品经理、项目所有者、团队负责人、开发人员、QA 工程师、设计师、技术作家等。借助管理员用户角色，我们可以满足每个用户组的需求，并相应地自定义 Jira 权限。

Jira 中有三种主要类型的权限：

全局权限：基本上是具有管理员权限的用户。这是一个可以访问 Jira 中所有项目的用户。
项目权限：这是一种受限权限，仅限于所选项目。这样的用户无法访问他们没有访问权限的项目。但是，对于任何给定的项目，他们可以创建、编辑和管理项目问题，并将其来回分配给其他团队成员。
问题安全权限：这是在问题类型级别上的受限访问，只提供给有限的受众。Jira 是一个基于票据的系统，您可以创建不同类型的票据或问题，并使用问题安全权限限制其访问。例如，如果问题类型是史诗，那么您只能将经理添加到列表中，以便能够查看史诗问题类型的票据。

然而，这些权限的每个级别都有管理员，如下所示：

Jira 管理员：这是一个用户可以自定义、管理和配置 Jira 的角色
项目管理员：项目管理员可以控制与冲刺相关的任务，如创建、开始、移动、编辑、结束、删除、完成和重命名冲刺
看板管理员：看板管理员可以通过创建看板、修改工作流程、添加/移除状态等来控制仪表板

确保您了解您的项目需求。确保您提前了解您的团队可能需要的问题类型，以及团队想要使用的默认或自定义工作流程、字段或组件的类型。

在下一节中，我们将使用 Jira 管理员用户角色创建和管理项目。

使用 Jira 进行 Scrum

让我们从在 Jira 中创建一个 Scrum 项目开始：

选择 Scrum 软件开发选项后，它会带您到以下页面。列出的问题类型将作为您的项目的默认问题类型，并具有指定的默认工作流程。记住，您始终可以添加新的或修改现有的问题类型和工作流程。这在下面的截图中显示：

为您的项目提供一个名称和一个关键字，并指定项目负责人，如下面的截图所示：

点击提交后，项目将...

使用 Jira 进行看板

现在让我们在 Jira 中创建一个看板项目：

选择看板软件开发选项后，它会带您到以下页面：

列出的问题类型将作为您的看板项目的默认问题类型，并具有指定的默认工作流程。如前所述，您始终可以添加新的或修改现有的问题类型和工作流程。

通过指定名称和关键字并分配项目负责人来创建看板项目。
点击提交后，看板项目将被创建，您将看到看板。
现在，您可以通过创建问题、计划并将其组织到泳道中来添加项目项。以下截图显示了一个看板，其中的需求通过不同的泳道，如“待办事项”、“选择进行开发”、“进行中”和“完成”：

现在我们已经准备好了我们的项目，让我们探索 Jira 支持的插件，以了解其测试管理方面。

探索 Jira 的测试管理插件

测试管理流程有助于组织、跟踪和管理与测试相关的项目需求。软件开发经历了各种阶段，测试也有其自己的一系列阶段。每个阶段都有一系列活动，通过这些活动我们可以跟踪项目的进展，例如创建测试计划和测试用例，将它们组织到测试套件中，创建测试周期，管理执行，创建和重新测试缺陷等。STLC 及其与 SDLC 的集成在第一章中已经介绍过，即软件质量保证概述。

在接下来的章节中，我们将详细了解不同的测试管理阶段，如管理、计划、设计...

synapseRT

synapseRT 是一个支持 Jira 端到端测试和需求管理的应用程序。它是一个插件，可以与 Jira 环境无缝集成，通过使测试人员、测试经理和项目经理能够计划、执行和跟踪项目在 SDLC 期间的进展来扩展其功能。它将整个测试过程组织成四个部分：

测试用例：这个部分是测试人员可以设计和维护测试用例的地方。它还提供了在需要时重复使用它们的灵活性。
测试执行：这是测试人员可以设计和计划当前发布所需的测试策略的阶段。
测试自动化：synapseRT 可以与其他第三方自动化或持续集成工具无缝集成，借助这些工具，测试专业人员可以执行自动化脚本并获取执行状态。
需求：在需求管理方面，团队跟踪项目进展是至关重要的，这样资源的分配和分配就变得容易。此外，这有助于在测试的早期阶段识别和减轻风险。synapseRT 生成的可追溯性报告对此非常有用。

在接下来的章节中，我们将详细介绍 synapseRT 的每个部分，并探索其用途和最佳实践。在这一部分，让我们在 Jira 中安装 synapseRT，并了解启动所需的基本配置设置。

Jira 可以根据用户的需求进行定制，synapseRT 也可以。它提供了设计自定义工作流程和添加问题类型或字段的灵活性。您可以从 Atlassian Marketplace 安装 synapseRT。

只需登录 Jira 并在“添加-ons”部分搜索synapseRT。在购买之前，可以使用其免费试用版本进行探索。本书使用的是 synapseRT 的当前版本（v9.3.1）。启用插件后，Jira 项目资源管理器将添加“需求”、“测试套件”和“测试计划”选项。在接下来的截图中，您将看到安装前后的屏幕：

为了查看问题类型（在您的情况下是需求）的 synapseRT 字段，例如史诗、故事、任务等，您需要进行以下配置：

缺陷问题类型是一个新的问题类型，我们将在接下来的章节中学习如何添加。

以下是一个链接，可以了解与 Jira 一起使用的支持版本 synapseRT：doc.go2group.com/synapsert/latest/en/synapsert-ver-9-x/supported-jira-versions。

Zephyr

Zephyr for Jira 是 Jira 支持的另一个测试管理工具。就像 synapseRT 一样，它可以用于设计和组织测试用例。它帮助测试人员计划测试执行并在全局或项目级别管理自定义字段。借助敏捷测试面板，团队可以管理和报告工作进展。它还支持使用Zephyr 查询语言（ZQL）进行高级搜索选项。它可以轻松集成其他自动化工具，以及使用 ZAPI 的持续集成工具。

Zephyr 可以从 Atlassian Marketplace 下载。本书使用的是当前版本的 Zephyr（v4.0.2）。

在以下屏幕截图中，您将看到安装前后的情况...

测试管理

测试管理插件是 Jira 支持的另一个工具。它具有与 synapseRT 和 Zephyr 类似的组件，并通过不同的测试套件创建和管理测试用例。测试人员可以根据所选需求的测试类型创建测试周期，例如不同浏览器的测试等。

可以使用追溯矩阵跟踪缺陷的需求。它通过 REST API 扩展了对自动化工具和 DevOps 工具的支持。测试管理工具可用于使用英语、德语、西班牙语、葡萄牙语和意大利语等本地化语言。

测试管理工具可以从 Atlassian Marketplace（marketplace.atlassian.com/）下载。本书使用的是当前版本的测试管理工具（v5.1.1）。

在以下屏幕截图中，您将看到安装前后的情况。

在安装和启用测试管理插件之前，Jira 项目在菜单栏中没有 Tests 选项卡：

如您所见，它在管理下拉菜单中添加了一个名为“Tests and Test Management for Jira”的选项卡：

为了查看问题类型（在您的情况下是需求）的测试管理工具，例如 Epic、Story、Task 等，您需要启用它。启用项目的插件后，您将能够从以下位置的 Tests 选项卡为项目创建测试：

摘要

在本章中，我们了解了 Jira 和 Jira 支持的插件，以满足您的敏捷项目需求。Jira 是一个项目管理工具，提供各种模板来创建和管理项目工件。Scrum 和 Kanban 是两种最常用的敏捷项目管理方法。Jira 支持这两种方法，并提供工具来满足您的测试管理需求。使用简单的步骤，您可以在 Jira 中创建和管理项目，并使用不同的权限和角色限制信息访问。我们探讨了在 Scrum 和 Kanban 中创建项目的工作流程。在最后一节中，我们探讨了三个测试管理插件 synapseRT、Zephyr 和 Test Management 的安装和配置...

第三章：了解 Jira 中的测试组件

需求、测试套件、测试计划、可追溯性和报告是 Jira 测试管理解决方案的主要组成部分。测试套件，也称为测试存储库，用于组织测试用例。在进行测试执行阶段之前，测试计划是一个重要因素。可追溯性和报告帮助我们跟踪项目发布周期中测试工作的覆盖范围和进展情况。

在本章中，我们将介绍使用 Jira 中的插件进行测试管理的方法。首先，我们将了解需求和测试计划的一些基础知识，包括问题类型，以及 Jira 中每种问题类型经历的默认工作流程。我们将学习创建自定义工作流程，并将其添加到项目中使用工作流方案。然后，我们将创建自己的问题类型，并将这个新创建的工作流应用到该问题类型。我们还将详细了解问题类型，并比较三个插件提供的测试套件功能。我们将从了解测试计划的一些基础知识开始，以及它在 Jira 插件中的位置。

本章中，我们将详细讨论以下主题：

什么是需求？
问题类型
什么是测试套件及其优势？
什么是测试计划？
什么是可追溯性矩阵及其好处？
报告及其类型

需求

需求基本上是解决最终用户问题的解决方案的一部分。它们也可以是吸引最终用户使用产品或服务的可取之处。此外，需求还可能包含在市场上现有产品中广泛使用的功能，这使得它对于新产品进入市场至关重要。

什么是需求？

需求可以是功能性/非功能性和隐式/显式的功能列表。无论哪种方式，它们基本上被分类为产品或服务的核心需求或好要求。规范因目标受众和组织开发的产品类型而异。

在软件行业中，一旦项目正式启动并分配给软件开发团队，项目利益相关者的第一个任务是收集需求。收集需求有助于团队了解项目范围、时间表、预算、支持的技术、其限制、所需资源数量、所请求的功能、客户的愿望清单等。

在收集和记录需求之后，项目协调员（充当最终用户和软件开发团队之间的联络人）会从最终用户那里获得批准。在获得开发阶段的批准后，需求被分析并分解为更小的工作包，成为团队的任务。Jira 提供了一种有效的方式来帮助团队组织和管理这些任务。

Jira 是一个基于工单的系统，其中每个任务都表示为一个工单。因此，团队的需求在 Jira 中变成了一个工单。Jira 还允许利用问题类型对任务进行分类（基本上有助于对需求进行分类以分隔工作）。每个 Jira 项目默认支持问题类型。现在，如果你想知道你的项目是否支持某个问题类型，可以在创建新项目时在第一个屏幕上确认：

在前面的截图中看到的默认问题类型是 Bug、Task、Sub-task、Story 和 Epic。Jira 还提供了灵活性，可以通过添加、编辑和/或删除问题类型以及工作流程来自定义项目支持的问题类型。如果项目或组织需要对项目中的项目进行进一步的分离和分类，超出了默认提供的内容，那么团队成员也可以创建自己的问题类型，我们将在下一节中看到。

在第九章中，需求管理，我们将学习如何将 Jira 问题类型配置为测试需求。我们还将使用这些问题类型使用 Jira 插件与相关测试用例进行链接。

问题类型

创建和使用新的问题类型涉及以下六个步骤：

以Admin身份登录，导航到 Administration | Issues | Add issue type，并按照官方文档中的步骤进行操作（定义问题类型字段值：confluence.atlassian.com/adminjiraserver/defining-issue-type-field-values-938847087.html）添加一个新的问题类型。我们已经创建了一个名为ProdIssue的新问题类型：

让我们为ProdIssue创建一个新的工作流。要创建一个新的工作流，以Admin身份登录，导航到 Administration | Workflows | Add Workflow，并按照官方文档中的步骤进行操作（使用工作流：confluence.atlassian.com/adminjiraserver072/working-with-workflows-828787890.html ...

测试套件

当软件开发公司获得一个大项目时，必须将项目分成较小的组件，以便可以应用分而治之的策略。然后通过集成这些较小的组件来创建最终产品。划分更大项目的一般程序是将共同特征的需求分组，形成较小的项目。然后将这些较小的项目分配给开发团队。因此，每个团队都致力于交付较大最终产品的一部分：

这些项目的测试工作始于测试人员创建测试场景和测试用例。测试用例的数量和复杂性因项目的大小、持续时间、复杂性、使用的测试工具和测试策略而异。然而，最大的挑战是将这些测试用例分开，以便它们易于访问，并且可以跨项目或整个组织进行引用或重复使用。这就是测试套件的概念派上用场的地方。

什么是测试套件？

测试套件只是一个容纳具有相似行为或目标的测试用例集合的容器。每个测试套件都有由基础测试用例定义的共同特征，并且数量不同。

各种特征有助于识别和区分测试套件的模式，即以下内容：

需求。
优先级：
高
低
关键
组件。
测试环境：
开发
测试
生产
测试输入参数或类型。这些包括不同的值集或类型，例如.csv文件、图像、变量、对象，甚至是从函数返回的值。
预期行为。
测试类型：
回归
冒烟
特定于浏览器
团队用于测试的特定工具，例如...

synapseRT 中的测试套件

在 synapseRT 中，测试套件选项卡显示在项目页面的左侧面板上。从这个部分，我们可以创建和管理主要和子测试套件的测试用例。以下截图显示了主测试套件“移动银行应用测试”，其中包含四个测试用例，这些测试用例已经组织成两个子测试套件“IOS 设备测试”和“Android 设备测试”。我们还可以选择将测试用例从一个测试套件克隆到另一个测试套件，删除，甚至导出测试用例：

Zephyr 中的测试套件

Zephyr 提供了一种通过测试周期管理测试执行的方式。但是，它并没有提供按测试套件组织测试用例的功能。测试摘要屏幕提供了按版本、组件或标签组织的测试用例数量的详细视图，以及它们的执行状态：

测试管理中的测试套件

单击“测试”选项卡，并在“文件夹”部分创建一个新文件夹。这些文件夹将成为您的测试套件。您可以通过单击屏幕上的“+新建”按钮来添加新的测试用例。我们已经为我们的银行示例创建了一些测试套件和测试用例，如下所示：

对于前面的银行示例，测试人员还可以基于移动测试、Web 应用程序测试、信用卡测试、个人银行测试、账户类型测试、负载类型测试等高层次创建测试套件。

测试套件的优势

对于测试专业人员来说，拥有组织良好的测试套件是有益的，原因如下：

它有助于区分需要执行的任务类型，以验证需求
以时间和资源需求为单位进行的工作估计变得容易
它充当了知识库存储库
它可以帮助轻松识别测试用例以减轻风险
先前发布的组件的识别和重新测试变得容易。

测试套件通常会随着项目的进展而增长。良好组织的测试套件对于有效的测试管理至关重要。

测试计划

如果您想成功交付项目，规划是很重要的。我们在开发过程的每个阶段都会为每个活动进行规划。测试也不例外。为了确保产品的质量并进行验证，测试计划至关重要。

什么是测试计划？

测试计划是一份详细的文档，概述了您验证和测试软件产品的方法。这是由测试经理或测试负责人准备的详细文档，突出显示需要验证的功能、测试策略、资源的可用性及其角色。它还包含有关测试范围、不属于测试阶段的组件、支持的浏览器类型和版本、用于测试的工具的限制等详细信息。

SDLC 中的每个阶段都会生成一系列可交付成果。例如，需求收集阶段会生成 BRD，设计阶段会生成高级和低级系统和组件设计计划，测试规划阶段会生成...

synapseRT 中的测试计划

测试计划是 synapseRT 中的另一种问题类型。单击“创建”按钮后，我们可以选择将问题类型设置为测试计划。一旦输入所有细节并创建我们的测试计划，我们可以添加测试用例和测试周期，如下截图所示。synapseRT 提供了一种有效的管理测试周期的方式。在开始执行之前，您可以随时向所选周期添加或删除测试用例。

但是，一旦周期开始，用户只能向测试周期添加新的测试用例：

Zephyr 中的测试计划

Zephyr 使用 Cycle Summary 来规划测试周期。一旦计划好周期，测试团队可以根据需要添加和删除测试用例。测试用例经过内容和细节的验证，并分配给团队进行同行评审。同行评审后，可以标记为“准备测试”，并分配给负责执行测试用例的团队成员。一旦更新了测试用例的周期准备就绪，就可以将其移动到目标发布测试周期下，并且团队可以开始执行阶段。以下截图显示了如何规划测试周期：

测试管理中的测试计划

测试管理提供了一个名为“计划”的选项卡来创建和管理测试计划：

创建测试计划后，可以添加包含测试用例的测试周期，如下截图所示。然后可以从测试计划的追溯部分查看：

追溯

需求通常记录在 BRD、软件需求和规格（SRS）文档中，或者记录在项目管理工具（如团队使用的 Jira）的需求部分。测试场景和测试用例是为了验证所述需求而创建的。重要的是要确保并跟踪所有需求都有相应的测试用例，并在测试和验证阶段中得到覆盖。这就是追溯矩阵帮助我们管理的内容。

什么是追溯矩阵？

追溯矩阵，也称为需求追溯矩阵（RTM），是一份文件，帮助测试专业人员建立被要求测试的内容与测试阶段覆盖的内容之间的关联。它在需求和确定的测试场景或测试用例之间建立了多对多的关系，这些将用于验证相关需求。追溯矩阵帮助我们识别质量泄漏，并确保完整的测试覆盖，以便不会漏掉任何需求的部分。

一旦执行阶段开始，测试专业人员将按照测试用例中提到的详细步骤开始应用验证过程。主要目标是确定模块是否满足条件并符合预期结果。如果是，测试通过，如果不是，我们称之为缺陷。缺陷的数量可能会因执行周期而异。

项目利益相关者了解测试执行状态的重要性，这样他们就能了解尚未验证的需求，并及时解决障碍。在系统中提出缺陷时，如果与相关测试用例相关联，就很容易追溯缺陷到测试用例，然后追溯到给定的需求。通常，在追溯矩阵的情况下，添加测试执行状态以及相关缺陷的细节非常重要。有各种格式的 RTM 可用于建立被测试需求与测试用例和相关缺陷之间的关系。

追溯矩阵的类型

最受欢迎的 RTM 类型如下示例所示：

正向追溯矩阵： 这是将需求与测试用例相关联的地方：

业务需求 ID#	用例 ID#	优先级	测试用例 ID#
BR_1	UC_1	High	TC#001
	UC_2	High	TC#002TC#005
BR_2	UC_3	Medium	TC#003TC#004

反向追溯矩阵： 这是将测试用例映射到需求的地方：

测试用例 ID#	用例 ID#	优先级	业务需求 ID#
TC#001	UC_1	High	BR_1
TC#002	UC_2	High	BR_1
TC#003	UC_3	Medium	BR_2
TC#004	UC_3	Medium	BR_2
TC#005	UC_1	High	BR_1

双向可追溯矩阵： 这是...

可追溯矩阵的好处

以下是可追溯矩阵的好处：

它使跟踪测试执行状态变得容易
它有助于确保测试场景在测试执行开始之前提供完整的测试覆盖
它确定了哪些需求在资源分配、时间、调试或缺陷解决时间方面需要更多的测试工作。
它提前解决问题，以减少对项目的影响
它通过减少失败的风险，监控项目的进展并提前估计完成时间

在第八章中，缺陷管理阶段，我们将看到如何将缺陷与测试用例关联，在第九章中，需求管理，我们将学习如何将需求与测试用例关联。现在，让我们看看每个 Jira 插件如何生成可追溯报告。

synapseRT 中的可追溯性

synapseRT 中的可追溯矩阵可以从页面左侧的可追溯性选项卡生成。我们必须输入详细信息，例如需求（Epic、Task、Story 或 Requirement）或项目，以及我们要生成可追溯矩阵的相关测试计划（如果存在）。以下截图显示了在 synapseRT 中生成的前向可追溯矩阵。它显示了需求的详细信息，其相关的测试用例，它们当前的执行状态以及任何关联的缺陷。我们还可以选择将可追溯性视为矩阵或树：

Zephyr 中的可追溯性

Zephyr 提供前向和后向的可追溯报告。让我们详细了解如何创建它们：

要创建前向可追溯矩阵，指定当前版本并从列表中选择需求问题类型，例如 Epic、Story 或 Tasks，并单击搜索图标。根据输入参数，Zephyr 在页面上列出了相关的问题类型。选择问题的复选框和要生成可追溯矩阵的需求到缺陷：

Zephyr 生成的前向可追溯矩阵显示了需求、其关联的测试用例、其执行状态和关联的缺陷之间的关系。我们有一个需求ZP-1，并且有三个测试用例添加到此需求。Executions列显示了每个测试用例的执行状态的进一步详细信息，例如，作为一个测试用例，ZP-9有两次执行，两次都失败。它还有一个链接的缺陷ZP-11，添加在Defects列中：

使用上述步骤生成后向可追溯矩阵。在这种情况下，我们将选择 Bug 作为问题类型，我们希望为其生成 Zephyr 的可追溯矩阵，屏幕上显示了所有相关的 bug 问题-选择要生成可追溯性的问题，选择类型为缺陷到需求，并单击生成按钮：

如下截图所示，我们有一个后向可追溯矩阵，它建立了测试用例的缺陷与相关需求之间的关系。该矩阵具有带有链接的 Jira 问题的缺陷、执行、测试和需求列。在这两种情况下，我们可以选择以 HTML 或 Excel 格式导出可追溯性：

测试管理中的可追溯性

在测试管理插件中，可追溯报告详细说明了覆盖范围，显示了需求；测试用例和测试执行结果，显示了测试用例的详细信息；以及问题，详细说明了测试执行期间发现的缺陷：

报告

报告是有效和定期传达项目进展状态的正式方式。它们在项目管理过程中发挥着关键作用。报告中提供的细节有助于识别和减轻可能导致项目失败的风险。

报告充当项目健康检查员，并帮助管理者跟踪任何偏离约定范围、时间、成本、预算和所需资源的情况，以满足质量要求。这些报告也作为知识库的一部分，可以在组织内进行维护和共享。

报告类型

报告的需求根据目标受众而有所不同。Jira 报告有助于确定项目的统计数据，并可以根据我们将在这里探讨的人员、项目、版本或问题类型进行定制。在第十章中，《测试执行状态报告》，我们将探讨 Jira 插件支持的不同类型的报告。现在，让我们看看 Jira 支持的报告类型：

敏捷：敏捷报告有助于通过生成各种类型的报告来跟踪项目的进展。它可以更深入地了解项目，并帮助项目团队及时解决问题。它有助于比较和对比项目的预期时间表。
燃尽图：这张图有助于...

摘要

在本章中，我们介绍了如何使用 Jira 中的测试管理插件执行测试管理的每个阶段。我们还比较了每个插件提供的功能。需求是最终用户的文档化需求，可以使用问题类型在 Jira 中捕获。我们学会了如何在 Jira 中为我们的项目添加和修改问题类型和工作流程。测试用例可以根据组件或需求进行组织，使用测试套件。我们看到了如何使用插件在 Jira 中创建测试套件。规划对于管理测试阶段至关重要。测试计划使我们能够制定测试的执行策略。我们比较了每个插件如何提供测试计划功能。可追溯性报告帮助我们将缺陷追溯到测试用例和需求。我们探讨了每个插件如何提供其版本的可追溯性报告。最后，我们熟悉了 Jira 中的报告部分，这将在第十章中《测试执行状态报告》中进行详细介绍。

在下一章中，我们将根据项目的需求，探讨选择各种项目执行工作流的最佳方法。

第三部分：测试管理-管理和计划

读者将学习如何规划和管理适合其项目需求的工作流程。

本节将包括以下章节：

第四章，测试管理方法
第五章，测试计划

第四章：测试管理方法

测试管理方法中的执行策略在确定测试周期的成功或失败方面起着至关重要的作用。该策略有助于识别优化的路径以尽早减轻风险。在本章中，我们将详细介绍根据项目需求选择各种项目执行工作流程的最佳方法。我们将学习如何创建临时测试运行并将测试用例作为测试计划的一部分在测试周期中执行。然后，我们将了解每种执行类型的重要性、其优势和目标目的。让我们开始 TMap 的结构化测试执行策略。

在本章中，我们将涵盖以下主题：

TMap 结构化测试的执行策略
在选定的发布中进行测试周期内的执行
测试管理的最佳实践

TMap 结构化测试的执行策略

随着软件行业及其标准的发展，强调的重点是流程应该由业务目标驱动，而不是流程成为业务目标的驱动因素。这导致了以下两种评估测试流程的方式的创建：

规定性：在这种方法中，模型提供了一个框架，以及每个测试单元的关键绩效指标（KPI）和需要询问的问题。这有助于您识别低效的根本原因。它还提供了应该解决每个这些低效的顺序以改进流程。
非规定性：在这种方法中，模型提供了一个框架，以及 KPI 和问题...

临时测试运行

测试团队在测试过程中面临各种情况，这取决于组织中遵循的流程成熟度以按计划交付产品。以下是这些情况的一些示例：

周转时间窗口很短，例如以下示例：
产品上线后进行错误修复的测试
在维护阶段需要快速处理的小更改请求
需要验证的工作流程不太复杂，例如以下示例：
针对范围较小且需要较少测试的需求进行测试，例如向表单添加验证弹出窗口以提示最终用户填写所有字段
诸如在 UI 中将按钮上的文本从“确定”更改为“接受”等外观变化

在这些情况下，潜在因素是变化不是激烈的，测试范围非常有限。因此，在这种情况下，我们可以采用临时测试方法。

临时测试程序是一个理解需求、为测试需求构建测试用例并根据需要执行它们的三个步骤。在这种方法中，测试专业人员只需创建最少量的测试用例，将它们链接到相关需求，然后在测试用例级别执行测试。在测试执行过程中，测试人员可以更新执行状态，并提供所需的工件支持。这节省了大量的开销和时间，无需安排会议、准备测试计划、测试周期，等待获得测试计划的签字等。

让我们看看如何在 synapseRT、Zephyr 和测试管理工具中将测试用例作为临时测试运行的一部分执行。

synapseRT

测试用例可以作为临时执行的一部分在需要时执行。在 synapseRT 中，您可以将测试用例创建为 Jira 工单。由于测试用例只是另一种类型的 Jira 工单，它在“详细信息”部分具有默认字段，就像其他问题类型一样。但是，它包含测试步骤、自动化和临时测试运行部分，如下面的屏幕截图所示：

现在，点击创建按钮，为所选的测试用例创建了一个临时测试运行。测试人员可以执行每个步骤并更新执行状态，添加新缺陷或链接现有缺陷，附加工件等，如下所示...

Zephyr

Zephyr 将测试用例作为临时运行或作为临时测试周期的一部分执行。为了这样做，用户只需创建一个测试用例问题类型并输入所有必需的详细信息。创建后，您可以在测试用例摘要字段下看到“执行”按钮，如下截图所示：

或者，我们也可以通过导航到 Tests | Cycle Summary 选项卡来创建一个临时测试周期。它给了我们一个选项，可以添加或删除多个测试用例作为临时测试周期的一部分：

在将测试用例添加到临时周期后，它看起来像以下的截图。正如您所看到的，它给了我们一个选项，可以根据您的发布来组织临时测试周期。它还显示了添加的测试用例的详细摘要，包括它们的票号、摘要、当前执行状态和链接的缺陷：

测试管理

临时测试执行选项不受测试管理工具支持。然而，它支持在测试周期中执行，我们将在下一节中详细介绍。

为选定的发布执行测试周期

临时测试是测试较短工作流程的一种灵活和更快的方式。然而，当您想要为整个发布计划或想要覆盖多种测试类型/特性（如性能、安全性、验收和集成）时，这种方法并不有效。在这种情况下，我们可以考虑准备测试周期，然后根据测试计划中定义的测试策略执行测试用例。让我们考虑一些在使用临时方法时测试团队面临的情况：

周转时间更长，例如以下示例：
团队正在建立一个新项目，并计划在年底发布产品。
计划在本季度发布产品的升级。
验证工作流程具有更多步骤和/或更复杂，例如以下示例：
客户要求进行更彻底的测试，因为变更具有大型、复杂的要求。
当测试一个报告的错误影响应用程序的多个组件时，需要进行严格的测试。

在这些情况下，我们需要分析问题并计划我们的测试策略。在周期内规划和执行测试用例可能是确保我们已经覆盖了所需产品或应用程序的所有类型的测试的最有效方式。因此，我们采用“测试周期中的执行”方法，这使我们有机会准备一个详细的测试计划，做以下事情：

调用所有依赖项
列出执行测试用例所需的输入和输出参数
定义通过测试的成功标准
定义缺陷跟踪和测试策略
根据用例设计和执行端到端工作流程
计划不同类型的测试并将它们集成到测试周期中
为冒烟测试、理智测试、集成测试、跨浏览器测试或环境测试等设计测试用例

由于变化很大，因为它的影响，我们最好准备好前面的方法。让我们详细看看 Jira 插件如何用于计划我们在不同类型的周期中的执行。

synapseRT

测试周期是 synapseRT 中测试计划票的一部分。因此，为了创建测试周期，我们需要首先创建一个测试计划。一旦测试计划准备好，您可以添加测试用例或测试套件，然后根据它们的类型、优先级或其他执行标准将其分类到测试周期下。

以下截图显示了一个包含三个测试周期的测试计划——信用卡类型 A，信用卡类型 B和回归测试：

我们将在第七章中详细介绍如何跟踪和执行这些测试周期，测试执行阶段。

Zephyr

另一方面，如果您想根据测试需求创建不同类型的测试周期，Zephyr 将它们归类到测试部分的周期摘要选项卡下。以下图片显示了两个主要的测试周期——贷款测试和临时测试。贷款测试包括教育贷款，个人贷款，汽车贷款和房屋贷款子测试周期：

测试用例票据还有一个测试执行部分，显示了这个测试已经被执行了多少次，是临时执行还是作为其他测试周期的一部分。如下截图所示，如果我们展开测试执行部分，它会显示所有测试运行和它所执行的测试周期。它还显示了关联的缺陷和执行日期：

测试管理

在测试管理工具中，可以从周期选项卡创建测试周期。如下截图所示，对于银行应用程序，我们有信用评分发布作为主要测试周期。在此之下，我们有三个子测试周期——验收测试，功能测试和回归测试。每个周期包含所需的测试用例，其执行状态可以从进度列中查看：

测试管理的最佳实践

TMap 提供了在组织中实施结构化测试方法的指导。以下是一些重要因素，将帮助您建立一个坚实的基础，以建立测试管理实践：

利用基于开发流程的测试活动模型。在我们的情况下，我们使用 STLC 模型，这是测试活动的 SDLC 模型的子集。TMap 生命周期模型可用于测试管理活动。
确保采用适当的测试工具和技术，如检查表，来识别、执行、跟踪和沟通进展和结果。沟通是必不可少的，以便及时识别和解决障碍。
建立所需的测试环境，满足测试产品的软件和硬件要求。这还包括设置测试数据库和测试数据。这将使执行阶段更加顺利。
为了有效的测试管理，测试团队应该是一个具有正确测试技能和产品知识的团队。这也意味着组织应确保员工接受培训，并改进流程，以实现建立可扩展和可重复的成功故事所需的成熟水平。建立一个成熟的组织和流程确保团队遵循共同的术语、方法、工具、技术、进入和退出标准、每周或每日电话会议和报告格式。这有助于高层管理生成标准的报告文档。
自动化是关键，因此组织必须尝试整合开源或付费测试工具，这将帮助测试人员更有效地执行工作。自动化重复活动可以帮助测试人员专注于探索性测试，而测试工具执行回归测试。在采用这些工具之前，应进行成本效益分析，因为这些工具需要相当长的培训和技能获取时间，员工才能有效地使用它们。
利用 BDTM 过程的每个步骤的成果，确保测试目标明确并与测试需求具体相关。这有助于彻底分析测试基础，及时实施策略，并实现良好的测试覆盖。
测试的目的是对产品的功能和需求进行可行的测试覆盖。项目越大，测试级别和测试单元就越多。因此，使用测试套件对它们进行组织是至关重要的。此外，避免将大型复杂需求合并到一个测试用例中，通过添加大量的测试步骤来覆盖它们，而是将它们添加到单独的测试用例中，以更准确地验证功能。

摘要

在本章中，我们涵盖了选择各种项目执行策略的最佳方法，以及在测试执行阶段执行测试用例的不同方法。TMap 提供了一种结构化的测试方法。我们了解了 BDTM 方法。对于较短和不太复杂的需求，可以使用临时测试策略来有效和高效地测试和验证需求。我们了解了如何使用 Jira 插件来实施临时测试。对于更大更复杂的项目，需要在测试周期内执行以组织和管理测试用例。我们了解了如何使用 Jira 插件创建和组织测试周期。最后，我们讨论了建立最佳实践的方法来...

第五章：测试规划

测试规划是 STLC 中最重要的阶段。规划为测试专业人员提供了建立对问题的理解的机会，以了解需求的复杂性。这是通过分析基于用例的工作流程，然后从中推导测试用例来实现的。需求文档是指定应用功能的测试基础。然后，测试计划通过使用多种工件，包括测试分配、方法和测试策略，指定了如何在测试中覆盖这些项目。测试策略是测试过程中特别重要的工件。

在理解需求和测试计划之间的关系的同时，我们将涵盖测试规划和测试策略的不同方面。我们还将看看 Jira 如何帮助我们使用 synapseRT、Zephyr 和 Jira 测试管理工具来定义和比较我们的测试需求的策略。

在本章中，我们将学习以下主题：

使用 Jira 插件创建和组织测试计划
定义和实施测试策略
建立需求和测试计划之间的关系

使用 Jira 插件创建和组织测试计划

测试规划阶段涉及各种工作流程。如果使用 TMap 方法，测试规划阶段对应于 TMap 生命周期中的规划和控制阶段。规划阶段包括使用产品风险分析、估算和规划创建测试策略，而控制阶段旨在通过监控、报告和调整实现持续的质量改进以达到测试目标。让我们深入了解测试规划阶段的活动。

一旦测试分配确认，团队开始讨论规划会议期间所述规格，团队试图解决模糊和复杂的问题...

synapseRT

在 synapseRT 中，测试计划只是另一种问题类型。一旦我们创建了一个测试计划票，就该是添加优先级、描述和当前状态的时间了。之后，我们可以创建一个新的测试用例或者添加所需的测试用例的测试套件。此外，我们还可以创建测试周期来分隔这些测试用例，并使它们成为所选周期的一部分：

使用 synapseRT 创建测试计划

Zephyr

测试计划选项仅适用于 Zephyr 企业版，用户可以使用测试周期创建和管理测试计划。

请随意从此链接探索 Zephyr 企业版：zephyrdocs.atlassian.net/wiki/spaces/ZE6/pages/149455000/Test+Planning。

测试管理工具

为了在测试管理工具中创建测试计划，我们需要按照以下步骤进行：

导航到 Tests | Plans 部分。单击+New 按钮创建一个新计划。在左侧面板上有一个选项，可以创建多个文件夹，并将测试计划组织在主文件夹或子文件夹下：

一旦我们添加了一些基本细节，比如名称、目标、状态或所有者，我们就可以转到 Traceability 选项卡：

在 Traceability 选项下，我们可以搜索现有的测试周期，并选择一个或多个测试周期将其添加到测试计划中。在搜索现有的测试周期时，它还显示了每个测试周期的执行状态，包括所有者的详细信息、日期和已识别的缺陷：

定义和实施测试策略

您的测试策略完全取决于应用程序的测试需求；主要是每个需求的风险等级。例如，如果需求是验证应用程序是否能够处理同时访问应用程序的 1,000 个用户的请求，那么我们需要将性能测试添加到我们的测试策略中。作为测试策略的一部分，我们可以通过发现超过允许阈值的断点来执行压力测试。我们还可以通过分析基于允许用户限制同时访问应用程序的性能来执行负载测试。我们还可以测量应用程序的响应时间，以呈现所有页面组件/对象...

建立需求和测试计划之间的关系

正如我们在第三章中所看到的，“在 Jira 中理解测试组件”，可追溯矩阵对于清晰了解项目进展并确定需要更多测试工作或存在更多缺陷的需求非常有用。可追溯矩阵还指示了测试策略、测试活动的类型以及测试专业人员定义和计划的任务，以验证所述需求。这在阶段初期创建，以便项目利益相关者审查，从而有足够的时间监控它，提供反馈，并根据团队的要求调整测试流程以实现测试目标。

建立需求和测试计划之间的关系是创建可追溯矩阵的第一步。每当在 Jira 中创建需求票证时，测试专业人员可以准备一个测试计划票证并将其链接到需求。一个需求可能有一个主测试计划和/或多个子测试计划，具体取决于测试需求。这为项目经理提供了跟踪所选需求的测试计划细节的机会。这些需求可以是具有目标发布截止日期的史诗或故事，也可以是客户报告的需要大量测试的任何错误。

让我们了解如何使用 Jira 插件建立需求和测试计划之间的关系。

synapseRT

使用测试用例很容易建立需求和测试计划之间的关系。在前面的部分创建测试计划时，我们看到了如何将测试用例添加到测试计划中。同样，您也可以将相同的测试用例添加到需求票证中。下面的屏幕截图显示了一个故事问题类型，其中包含了四个测试用例：

一旦我们将相同的测试用例添加到测试计划中，我们可以在需求部分下看到需求覆盖率，如下面的屏幕截图所示。这表明，为了验证需求，测试人员已经添加了四个...

Zephyr

由于测试计划功能仅在 Zephyr Enterprise 中可用，我们可以将测试用例与需求关联起来，以建立它们之间的关系。如下面的屏幕截图所示，打开现有的测试用例，转到“更多操作”|链接选项。然后，搜索相关的需求问题票证并进行链接，如下所示：

测试管理工具

在测试管理工具中，转到“测试”|计划，并选择要添加需求的测试计划。然后，转到可追溯性部分，在那里您可以搜索现有的用户故事或需求，并将它们链接到测试计划，如下所示：

如下面的屏幕截图所示，“问题”部分显示了为其创建了该测试计划的相关需求，以及需要执行的测试周期，以完成验证过程：

摘要

在本章中，我们涵盖了测试规划和测试策略的不同方面，同时了解了需求和测试计划之间的关系。我们了解了通用测试计划的组成部分，可以在测试规划过程中使用。我们还学会了如何使用 Jira 插件编写测试计划。

有各种各样的方法来定义测试策略。我们看了一个使用 TMap 方法为银行应用创建测试策略的例子。为了创建一个可追溯的矩阵，我们需要建立测试用例和测试计划以及测试需求之间的关系。在本章中，我们清楚地看到了如何将测试计划与其相关的需求联系起来。

在下一章中，我们将学习测试用例设计和创建的过程。我们还将学习如何组织测试用例，并磨练重复使用测试用例和测试数据的技能。

第四部分：测试管理 - 设计和执行

我们将详细了解根据项目需求从各种项目执行工作流中选择最佳方法，学习测试设计、测试策略和测试执行的不同方面。

本节将包括以下章节：

第六章，测试设计阶段
第七章，测试执行阶段
第八章，缺陷管理阶段

第六章：测试设计阶段

测试用例可以定义为一组用户（测试人员）的指令，以便他们可以在预定义状态下对应用程序进行测试。他们还需要预定义的测试数据来获得需求中提到的预期结果。没有测试用例，就无法进行测试，因为产品验证过程是从这些测试用例开始的。它们可以是自动化的或手动的，但目标是相同的。

在本章中，我们将涵盖以下主题，并详细了解测试设计阶段：

创建和维护测试用例
重用测试用例和测试数据
组织测试用例

创建测试用例

在测试团队了解项目需求之后，测试计划得到准备和批准。现在，测试团队可以开始测试设计阶段——这个阶段需要测试团队创建测试场景和测试用例。在涉及自动化测试的情况下，产品的可测试版本变得可用，这导致了测试脚本的创建。

测试用例应简要描述测试的目的、用户操作以及这些操作的预期结果。在创建测试用例时添加的详细信息如下：

测试用例字段	描述
TC-ID	测试用例 ID 帮助您唯一标识测试用例。通常，由测试...添加

对测试用例进行优先排序

有各种方法可以组织测试用例。您可以添加标签、项目名称、需求的详细信息，甚至测试套件的详细信息，以将它们分组到单个分支下。其中一个例子是测试优先级。测试优先级是组织测试用例的有效方式。测试优先级设置了验证所述功能的选定测试用例的重要性，通过定义决定执行顺序的紧急程度级别。优先级状态通常是以下之一：

关键：这些需要添加到项目验证迭代中，并且需要在迭代开始时执行。设计和执行关键测试用例有助于降低产品风险。
高：这些对于需求验证过程很重要。在验证了关键优先级测试用例之后，测试团队将转向高优先级测试用例。
中：这些包括值得验证的功能；但是它们的影响是中等的。因此，在紧张的执行计划中，团队会从列表中挑选出最相关的一些测试用例进行执行。
低：这对应用程序的功能影响很小，主要用于验证应用程序中的化妆变化。

测试用例状态

测试设计阶段的测试用例状态表示测试用例的当前状态。因此，对团队来说，根据测试用例状态采取行动是有帮助的。测试设计阶段的测试状态可以有所不同，可以是以下任何一种：

草稿/进行中：顾名思义，当测试用例仍处于设计阶段且不完整时，其状态标记为草稿。
准备好审核：一旦测试人员完成了测试用例中的详细信息，并且可以进行审核，状态可以设置为准备好审核。
审核完成：一旦测试用例经过同行审核，其状态可以更新为审核完成。
准备/未执行/未运行：测试用例可以标记为准备...

管理测试工件及其格式

测试用例可以以各种格式编写和捕获，例如存储在文本文件、Word 文档、Excel 工作簿中，或者利用专门的测试捕获工具。然而，最普遍的方式是在 Excel 表中创建测试用例，并将其加载到 HP ALM、Jira 等测试管理工具中。

除了详细的测试执行步骤之外，测试用例还可以附有各种支持文档或工件，例如以下内容：

测试人员想要在执行阶段参考的原型文档
用户凭据
测试执行所需的一组 SQL 查询和/或过程
关于预定作业的详细信息
可以在执行过程中参考的文档链接

此外，如果同一个测试用例已用于一个或多个发布版本，则它可能包含执行工件，例如在上一个发布版本测试期间生成的日志文件或截图。参考先前附加的工件并比较当前执行结果非常有帮助。

让我们看看如何使用 Jira 工具创建测试用例并添加相关细节。

synapseRT

要在 synapseRT 中创建测试用例，测试专业人员需要按照以下步骤进行：

从问题类型字段中选择测试用例选项。默认问题类型为故事；将其更改为测试用例并选择相关项目。
选择问题类型后，是时候输入所有其他必需的细节，如摘要，描述，优先级，标签，受让人和史诗链接。一旦准备好创建测试用例，点击“创建”按钮。我们始终可以使用 Jira 问题右上角的“配置字段”图标配置要在此页面显示的字段：

Jira 将成功创建...

Zephyr

Zephyr 还将测试用例识别为另一种问题类型。要在 Zephyr 中创建测试用例，我们需要按照以下步骤进行：

选择问题类型为测试。我们还需要输入其他必需的细节，如摘要，描述，优先级，关联问题，受让人，测试步骤与预期结果以及测试数据。单击“创建”按钮创建测试用例：

创建测试用例后，您会看到它包含了我们输入的所有细节。与任何 Jira 工单一样，我们始终可以修改这些细节。我们还可以选择克隆测试用例，添加更多相关问题或需求，甚至通过单击“执行”按钮开始执行：

测试管理

要在测试管理工具中创建测试用例，我们需要按照以下步骤进行：

首先，从主选项卡中导航到“测试”部分，然后单击“+新建”按钮添加新的测试用例。现在，我们需要在“银行网站测试管理项目”项目下添加一个新的测试用例：

单击“+新建”按钮后，在“详细信息”选项卡中输入必需的细节，如测试用例名称，目标，前提条件（如果有），以及其他相关细节，如标签，状态，优先级，所有者等。
现在，是时候添加测试步骤了。单击“测试脚本”选项卡以添加步骤，预期结果和相关...

在不同项目之间重用测试用例

现在我们已经学会了如何编写新的测试用例，让我们看看如何有效地重用现有的项目。

对于完全新的项目或发布，没有来自过去项目或发布的任何依赖或相关工件，测试团队必须为所有发布的功能请求设计所有测试用例。然而，随着产品的发展和多次发布，一些常见的未触及的功能保持稳定。这为将来的发布重用测试用例提供了机会。

有各种原因会让您想要重用现有的测试用例：

如果有新团队成员加入团队，现有的测试用例可以帮助他们通过查看现有的测试用例来熟悉产品。
它减少了为先前版本中未更改和已经验证的功能创建所有测试用例的工作量。测试人员可以简单地在当前迭代中提取现有的有效测试用例。
它为测试人员提供了一个基准，附带了附件，以便比较应用程序的功能。
通过比较先前版本的执行结果，可以帮助找到缺失的功能。
它有助于回归测试和验证在目标发布中未更改的应用程序部分。
它帮助团队了解可能与相关测试用例相关联的现有报告的缺陷。这为测试人员验证上次发布时出现故障的功能提供了方向。
对于已存在相关测试用例的相同功能，审查测试用例可以节省时间和精力。
当其他团队想要参考现有的测试用例了解先前发布的产品或服务时，它也可以帮助他们。
如果新项目作为先前产品的扩展引入，团队可以重用现有的测试用例进行集成或兼容性测试。

让我们看看如何通过使用 Jira 插件重用现有的测试用例并将它们链接到多个项目。

synapseRT

我们可以通过将现有测试用例添加到不同项目下的测试套件中来重用 synapseRT 中的现有测试用例。如下图所示，测试用例SYN-1、SYN-3和SYN-4属于SynapseTestProject，已添加到Reusing Existing Test Cases测试套件中，该测试套件是Banking payment using mobile devices project的一部分：

Zephyr

Zephyr 不支持从一个项目复制测试用例或测试周期的功能。但是，为了在另一个项目中重用现有的测试用例，可以复制测试用例的结构，这只会克隆问题结构。

如果您想探索这个选项，请随时参考以下页面：wiki.almworks.com/display/structure/Copying+a+Structure。

测试管理

测试用例可以在测试管理工具中复制到另一个项目，以便重用。要将它们添加到新项目中，我们需要按照以下步骤进行：

转到测试选项卡，单击省略号。选择从其他项目导入...的选项。如下图所示，我们正在将测试用例添加到一个新项目，即TM Mobile payment project：

现在，从项目下拉菜单中，选择要复制测试用例的项目名称。一旦选择了项目名称，它就会显示该项目下存在的测试用例。选择所有测试用例的复选框...

组织主测试套件和子测试套件

在创建主测试套件和子测试套件以组织测试用例时，有各种因素需要考虑。主测试套件可以基于项目名称或模块创建，添加子测试套件有助于根据测试类型、环境、用户角色等进一步对其进行分类。如测试创建表中所述，我们可以使用一个或多个字段对其进行分类，例如项目名称、需求 ID、测试验证环境、构建编号或测试类型。

最好的做法是在创建测试用例时立即添加，而不是批量整理它们。

Jira 插件还为我们提供了根据我们的标准组织测试用例的灵活性。现在让我们详细看一下这一点。

synapseRT

关于项目的测试用例可以从“测试套件”选项卡中查看。如下截图所示，在“测试套件”选项卡的活动部分中，我们可以看到SynapseTestProject项目的所有活动测试套件。我们可以选择在同一项目中不同的测试套件之间克隆测试用例的选项：

要查看所有子测试套件和测试用例，请点击该测试套件的编辑图标。如下截图所示，我们在编辑模式下有一个测试套件视图。它有两个子测试套件，共有四个测试用例：

Zephyr

在 Zephyr 中，当前项目的所有测试用例都在“测试”选项卡下按照不同的周期和子周期进行组织。如下截图所示，我们可以通过选择测试周期来查看测试用例的数量和它们当前的执行状态：

测试管理

在测试管理工具中，所有的测试用例都可以在“测试”选项卡下进行组织。以下截图显示了所有测试用例都在“所有测试用例”文件夹下，然后可以进一步组织在主测试套件和子测试套件下：

总结

在本章中，我们学习了通过为当前项目创建和组织测试用例以及在不同项目下重用它们来进行测试设计阶段。测试用例描述了测试人员需要执行的逐步操作以获得他们期望的结果。设置当前数据或适当的环境对于获得准确的结果至关重要，因为环境和测试数据的任何更改都可能改变这些结果。根据需要在不同项目中重用这些测试用例可以最大程度地减少创建和审查测试用例所花费的时间和精力。

我们看到了如何使用 Jira 插件在项目中跨项目重用测试用例。在测试存储库中有各种组织测试用例的方法。我们可以根据测试套件、子测试套件、标签、需求 ID 等进行分类。我们看到了如何使用 Jira 插件为项目创建这些测试存储库。

在下一章中，我们将更详细地了解测试执行阶段以及如何使用 Jira 进行管理。

第七章：测试执行阶段

现在我们了解了测试设计阶段是什么，是时候进入下一个阶段了，即测试执行阶段。这是软件测试生命周期中的一个阶段，在这个阶段，构建代码使用在测试设计阶段设计和创建的测试用例进行验证。

在开发团队忙于构建应用程序代码的同时，测试团队开始准备测试设计和测试周期准备阶段。它还利用这段时间准备测试环境和测试数据。然后团队开始执行测试用例，但只有在最新的代码更改部署到测试环境后或者第一个可测试组件被部署进行测试后才开始。一旦测试...

定义测试周期

测试周期的设计基于测试团队正在处理的项目类型。在设计测试周期时，测试团队执行以下任务：

验证测试覆盖范围：这确保测试执行阶段包括验证所有需求所需的所有测试用例。
估计工作量：基于需求的复杂性、测试用例的优先级、分配资源的当前技能水平、测试工具的可用性以及范围和分配的时间，测试团队估计完成测试执行所需的时间。
定义迭代：如果在初始测试执行迭代期间发现了多个缺陷，这对应用程序的功能产生了巨大影响，测试团队可以随时添加另一个测试执行迭代。根据循环次数、缓冲时间、缺陷重新测试时间和预定会议，测试执行的估计可能会有所不同。

根据定义和隐含的客户需求，测试团队可以设计各种类型的测试周期/迭代。一些测试用例也应设计为冒烟测试和回归测试周期的一部分：

冒烟测试周期：此周期使测试人员能够在执行一小组测试用例后检查当前部署的版本是否可测试。例如，在银行网站的情况下，一些基本测试，如启动应用程序、浏览各种选项卡、单击可用链接以及登录和退出应用程序，可以帮助您了解应用程序是否正常工作。如果应用程序在启动后立即崩溃或在单击个人银行链接后崩溃，团队可以报告一个缺陷。然后，开发人员可以立即开始修复。冒烟测试有助于确保已在请求的测试环境中部署了正确版本的构建。有时，在部署阶段，构建可能会失败，开发人员可能需要回滚更改并重新部署新构建。在这种情况下，冒烟测试很有用，因为它可以确定当前部署的构建是否具有所有基本功能可供测试，并且当前部署的构建中没有文件或功能缺失。
回归测试周期：此周期用于识别新添加/实施的需求对产品或应用程序现有可行解决方案的任何不利影响。我们还可以使用自动化工具安排回归测试，并根据需要收集结果。

在第四章中，《测试管理方法》，我们看了如何将测试周期添加到测试计划中。在接下来的部分中，我们将更详细地了解如何向测试周期添加和移除测试用例，以及如何在测试执行阶段开始、完成和中止测试周期。

从同一项目添加测试用例到测试周期

由于我们已经完成了必要的测试用例，它们已经准备好使用，我们可以将它们添加到测试周期中。从当前项目添加测试用例是通过拖放或将测试用例链接到新创建的测试周期中完成的。让我们看看如何创建和初始化测试周期。一旦我们创建了测试周期，就可以向其中添加测试用例，更新测试周期，然后开始测试执行阶段。

初始化测试周期

测试用例被分组形成测试周期或测试迭代。在执行周期之前，重要的是要检查我们是否已经添加了完整的测试用例集，以验证功能请求。在初始化测试周期之前，您应该检查以下内容：

测试将要执行的当前构建版本
测试将要执行的测试环境
执行开始和结束日期
测试用例应该根据其优先级进行组织
测试用例应该分配给负责执行测试用例的测试人员

让我们看看如何使用 Jira 插件创建和执行测试周期。

synapseRT

在 synapseRT 中，一旦测试计划已经创建并准备就绪，因为已经添加了测试用例，我们可以创建测试周期：

单击“测试周期”部分的“添加”按钮，输入测试周期的详细信息，例如名称、环境、开始日期和结束日期，如下面的屏幕截图所示：

创建周期后，我们可以选择将其状态从草稿更改为开始、完成或中止。我们还可以查看和编辑其详细信息。要修改其详细信息，请单击新创建的测试周期旁边的“编辑”，如下面的屏幕截图所示：
添加测试周期后，我们可以看到所有的测试用例...

Zephyr

与 synapseRT 一样，Zephyr 不需要测试计划或测试用例来创建测试周期。按照以下步骤创建测试周期：

在 Zephyr 中创建测试周期时，我们可以更加具体地设置其详细信息，例如版本、描述、名称、开始和结束日期等。这些详细信息帮助我们区分不同的测试周期：

如下面的屏幕截图所示，一旦我们添加了一个测试周期，它将显示在“周期摘要”选项卡下。该选项卡显示了在该测试周期下添加的测试用例的总数，其创建者，总执行次数，开始和结束日期等信息：

通过单击“+添加测试”按钮从测试周期中添加和删除测试用例。我们还可以选择按其票号选择测试用例或从另一个测试周期中添加测试用例的选项。如下面的屏幕截图所示，我们已经使用它们的票号添加了三个测试用例：

在 Zephyr 的情况下，我们可以在测试用例级别更新测试状态，也可以在测试步骤级别更新测试状态。以下屏幕截图显示了在测试用例级别更新测试用例的执行状态。默认情况下，Zephyr 具有未执行、通过、失败、进行中和阻塞的测试执行状态：

测试管理

与 Zephyr 一样，测试管理工具不需要测试计划或测试用例来创建测试周期：

我们可以通过导航到“测试|周期”部分来添加测试周期。一旦我们单击“新建”按钮添加新周期，我们将看到以下详细信息屏幕，在这里我们可以输入有关此周期的详细信息，例如文件夹、状态、版本、迭代、所有者、计划开始日期和计划结束日期、描述等：

一旦我们添加了新的测试周期，我们将获得其唯一标识符，以便我们可以将其与其他周期区分开。所有周期都可以在“周期”选项卡下查看。在这一部分，我们...

测试执行状态

测试执行状态定义了其在执行阶段的当前状态。以下是最常用的测试执行状态：

未运行/未执行：当测试用例已添加到测试周期中时，将显示未运行或未执行的测试状态。然后根据执行结果更新其状态。
通过：如果测试中提到的所有测试步骤满足预期结果，其状态可以标记为通过。
失败：如果任何测试步骤未能满足预期结果，那么可以将其标记为失败。
不适用/不在范围内：有时，测试用例不需要作为当前测试周期的一部分执行。在这种情况下，测试执行状态可以更新为不适用。
阻塞：如果一个未解决的缺陷影响了一个或多个测试用例的测试，那么相关的测试用例可以被标记为阻塞，并与更新的缺陷号相关联。

如果在测试用例的执行过程中的任何时候测试步骤失败，那么整个测试用例的状态将被标记为失败。此时，测试人员可以选择在步骤级别或测试用例级别创建缺陷并将其链接到测试用例。

此外，在每次测试运行期间，测试工具会创建一个新的测试运行实例。因此，相对容易比较同一周期内测试的测试执行结果。

组织测试周期

就像我们可以对测试用例进行优先排序一样，测试周期也可以根据其优先级进行排序。顺序排列和重新排序测试周期通常可以节省重新测试一个或多个测试用例，甚至整个周期的时间和精力，并有助于在测试执行周期的初始阶段验证最完整或最紧急的需求。

这有助于早期发现缺陷，并为团队提供足够的时间来修复和重新测试任何更改。随着执行的进行，测试团队更新所有项目利益相关者有关当前执行状态的信息，其中包含有关此版本考虑的测试用例总数，标记为通过的测试用例数量，...

完成测试周期

在确认关闭测试周期之前，需要您查看以下检查表：

该周期中的所有测试用例都已标记为通过或不适用
与测试用例相关的所有缺陷都已修复并重新测试，并且相关的测试用例已通过
所有作为文本执行一部分的工件都已生成并附加到相关的测试用例
所有生成的工件，包括测试报告，都满足测试计划的退出或测试完成标准
测试执行报告已生成并与项目利益相关者共享，并已获得相关审批者的批准

一旦完成了这个检查表，测试团队可以正式宣布选择的测试周期/迭代或执行阶段的关闭。

从不同项目添加测试用例到测试周期

最好重用以前版本或不同项目中的测试用例。我们可以将它们添加到当前项目并将其用作当前周期的一部分。让我们看看如何将不同项目中的测试用例添加到测试周期中。

synapseRT

我们可以从另一个项目中添加测试用例到测试周期中。要做到这一点，点击测试用例中的“添加测试用例”按钮，并搜索所需的测试用例。正如您在以下截图中所看到的，我们通过搜索其 ID 简单地从另一个项目中添加测试用例：

风神

我们可以从另一个项目中向 Zephyr 中添加测试用例。导航到测试周期，然后点击“添加测试”按钮；您将看到以下屏幕。现在，通过它们的票号从另一个项目中搜索任何测试用例，并将它们添加到项目中：

测试管理

在将测试用例添加到当前测试周期时，测试管理为您提供了选择必要项目的选项。当前项目会被默认选择。我们可以从其他项目中选择要添加测试用例的项目。选择后，我们可以看到所有可供我们添加到当前测试周期的测试用例。选择所需的测试用例，然后点击“添加”按钮：

摘要

在本章中，我们学习了如何使用 Jira 插件创建和执行测试周期。测试执行阶段的测试周期可以包括开始和结束日期、指定的测试人员、构建编号等详细信息。在开始测试周期之前，可以修改测试周期以添加或移除当前项目中的测试用例。测试用例也可以从之前的版本中重复使用，作为当前版本的一部分。

在下一章中，我们将讨论缺陷管理的重要性，并看看 Jira 如何帮助我们有效地跟踪和管理缺陷。

第八章：缺陷管理阶段

只有生成令人满意的结果且没有任何故障的软件产品才能受到信任。无效的结果可能会对最终用户产生负面影响。有缺陷的产品会让消费者感到不满并引起沮丧。因此，及时发现故障或问题可以帮助开发人员交付高质量的产品。然而，我们需要了解如何对缺陷进行分类，以及有效报告缺陷的方法，以确认缺陷是否已解决。

在本章中，我们将涵盖以下主题：

理解记录缺陷的重要性
创建新缺陷
将现有缺陷链接到测试用例

我们还将看到 Jira 如何帮助我们有效地跟踪和管理缺陷。

理解记录缺陷的重要性

在理解缺陷的重要性之前，让我们先了解一下在软件行业中缺陷实际上意味着什么。当团队开始处理项目的某个部分或组件时，他们会根据预定义的一组要求或条件开始构建它。同样，当测试团队创建测试用例时，他们也是基于相同组件的相同要求。

现在，在测试执行阶段，测试团队开始逐步与测试环境中的实际产品进行交互验证，因为最终用户将执行相同的操作，并将其与预期结果进行比较。如果结果匹配，测试人员可以通过所选的步骤...

创建新缺陷

简而言之，与预期结果的偏差被视为缺陷。在行业中还有一些术语可以互换使用来定义问题，例如故障、错误或错误。然而，无论称呼如何，任何形式的问题在推出产品之前都必须得到解决。

软件缺陷可能是以下原因的结果：

基于无效或不完整的要求构建了一个功能
需求文件中规定了一个功能，但缺少了相应的软件
代码中使用的函数未返回预期结果，或者在无限循环中运行，或者接受无效的数字/输入参数类型
用户未受限制地执行无效/未经授权的操作
错误消息未按预期显示
未满足明示和隐含的要求
文本和图像无法阅读
无效的代码被合并到构建中，并部署到测试环境中

一旦确认应用程序展示的行为与规定的要求不符，并且开发团队也确认了这一点，测试团队就可以将其标记为缺陷，并在测试管理系统中记录。我们将在接下来的章节中看看如何使用 Jira 插件创建和记录缺陷。

现在我们知道了什么是缺陷，让我们开始缺陷创建过程。测试管理工具可用于报告新发现的缺陷。跟踪缺陷并帮助测试人员与团队顺利合作是有帮助的。在创建新缺陷之前，有必要检查系统中是否已存在类似的缺陷以及其当前状态。只有在可重现的情况下才能成功报告和修复缺陷；因此，在将其记录在系统中之前，有必要多次重现它。

建议在记录任何缺陷之前遵守以下检查表。虽然这是一个常见的检查表，但可以根据您的要求添加更多步骤：

需求文件中指定的应用程序行为与实际结果不同
验证测试是否在正确的环境中进行，并且具有预期的配置
检查应用程序的构建版本是否正确，并且已根据测试要求配置
检查应用程序的所有必需服务是否正常运行
检查应用程序是否与指定的操作系统、浏览器或第三方应用程序兼容
检查测试是否是从具有有效测试数据的应用程序的指定状态执行的
检查用户角色是否具有执行测试用例中提到的所有必要权限
检查应用程序、服务器和数据库之间是否存在连接

在缺陷中添加更多细节有助于开发人员在执行根本原因分析时，识别特定代码部分的初始位置以开始调试，而不是检查整个产品或模块。让我们看看在记录缺陷时应添加哪些细节。

有关缺陷管理的更多信息，请查看位于www.red-gate.com/simple-talk/dotnet/software-delivery/a-primer-on-defect-managment/的缺陷管理文章。

如何使用 Jira 插件创建缺陷

通常，测试管理工具提供一个模板，其中包含一些默认字段来记录缺陷。但是，我们总是可以更详细，例如通过指定以下内容：

用于识别缺陷的唯一标识符
缺陷的摘要
重现缺陷所需执行的操作
实际结果与预期结果之间的差异
用于执行测试的测试环境
预置条件，例如被测试应用程序的状态
被测试应用程序的版本及其配置详细信息
部署在测试环境中的代码构建版本
用于执行测试的测试数据
缺陷创建日期
缺陷的当前状态
名称...

在 Jira 中设计和管理缺陷工作流程

缺陷工作流程可以定制为具有其自己的一组缺陷问题类型可以经历的状态。组织可以拥有自己的工作流程。让我们看看缺陷应该经历的一些推荐状态。这也被称为缺陷生命周期：

草稿：当测试人员仍需要提供与之相关的更多细节时，可以将缺陷设置为草稿
新/打开：当所有细节都已添加并且准备分配给开发人员时，可以为缺陷设置此状态
已分配：一旦项目团队确定了将处理记录的缺陷的开发人员，缺陷的状态可以设置为已分配，并应分配给相关的开发人员
进行中：一旦缺陷被分配，开发人员可以将缺陷状态更改为进行中，以指示开发人员正在努力解决问题
已修复：一旦实施了所需的代码更改并且已供测试人员验证更改，开发人员可以将缺陷状态更改为已修复
未修复：如果缺陷仍然可以重现，并且修复不符合要求，则测试人员将缺陷状态设置为未修复
关闭：如果已修复的缺陷按预期工作并且符合规定的要求，则测试人员关闭缺陷并将其状态设置为关闭
重新打开：如果先前已解决的缺陷现在再次出现，则测试人员可以将缺陷状态更改为重新打开
不适用：如果新创建的缺陷与已验证的更改无关，则开发人员可以将缺陷状态更改为不适用
非缺陷：如果应用程序或功能的行为符合预期，则开发人员可以将缺陷状态更改为非缺陷
无法重现：如果开发人员无法在相同的环境和构建版本中重新创建缺陷，则其状态可以更新为无法重现
重复：如果系统中已经存在类似的缺陷，则开发团队可以将缺陷状态更新为重复
已验证：如果测试人员已验证了缺陷的代码更改，那么其状态可以标记为“已验证”。
待定：如果由于环境、测试数据或资源不可用而导致缺陷验证暂停，那么其状态可以更新为“待定”。
已延迟：如果团队决定在即将到来的迭代或发布中修复缺陷，则可以将缺陷状态标记为“已延迟”。

既然我们现在熟悉了缺陷工作流程，让我们使用 Jira 创建一个：

为了在 Jira 中创建自定义工作流，我们需要添加工作流方案并将自定义工作流添加到此方案中。添加工作流方案的选项可在“管理” | “问题” | “工作流” | “工作流方案”下找到。为此缺陷工作流方案指定一个名称，例如DefectWorkflowScheme-1，添加描述，然后点击“添加”按钮创建方案：

如下截图所示，定制的缺陷工作流具有与我们之前讨论过的类似的各种状态。此工作流已分类为缺陷工作流，将添加到工作流方案中：

选择现有工作流后，点击“下一步”按钮。下图显示了要应用于此工作流的问题类型。选择“缺陷”问题类型，然后点击“完成”按钮，如图所示：

添加缺陷工作流后，可以从项目设置 | 问题 | 工作流部分查看。如下截图所示，当前项目有两种工作流，即 Jira 工作流和缺陷工作流。缺陷工作流字段有一个关联的问题类型为缺陷。在这里，它会提示您发布更改，一旦发布，新添加的工作流将添加到缺陷问题类型中：

现在，转到项目 | 项目设置 | 问题部分。在这里，您需要自定义项目以具有缺陷问题类型。如下截图所示，我们已将缺陷问题类型添加到当前方案的问题类型部分，以便将其添加到当前项目方案中：

点击保存，我们的缺陷工作流已创建。

synapseRT

synapseRT 还有其他问题类型，包括需求、测试用例和测试计划，但缺少缺陷问题类型。从前面的部分，我们现在知道如何将带有自定义工作流的缺陷问题类型添加到我们的项目中。添加问题类型后，请按照以下步骤记录缺陷：

由于缺陷是另一种问题类型，点击“创建”按钮创建一个缺陷，选择相关项目，然后选择问题类型为缺陷，如下截图所示。然后，点击“下一步”按钮：

这将加载带有标题“创建问题”的问题描述页面，如下所示...

将现有缺陷链接到测试用例

建立缺陷与测试用例之间的关系有助于确定缺陷对当前测试用例执行的影响。如果单个缺陷影响多个测试用例，那么测试人员可以将相同的缺陷链接到所有受影响的测试用例，并将测试用例状态更新为“已阻塞”。

除了影响分析之外，它还有助于生成可追溯性矩阵，其中需求与测试用例相关联，测试用例与缺陷相关联。缺陷可以在测试用例级别或测试步骤级别与测试用例相关联。如果一个测试用例有更多的测试步骤，并且对同一个测试用例观察到多个缺陷，那么在这种情况下，将这些缺陷在测试步骤级别相关联更有意义，以确定错误具体发生在哪个步骤。

根据缺陷更改测试用例状态

每当测试团队记录一个缺陷并将其链接到相关的测试用例时，测试用例的状态将更新为失败。现在，测试用例状态将保持为失败，直到相关的缺陷被关闭或推迟。一旦缺陷关闭，相关的测试用例状态将更新为通过。

然而，如果在测试步骤级别链接了缺陷，那么正常工作的步骤将被更新为通过。观察到缺陷的步骤将被更新为失败，而测试人员无法执行的剩余步骤将保持默认的未执行或未运行状态。

让我们使用 Jira 插件将缺陷链接到测试用例。

synapseRT

synapseRT 提供了在测试用例级别或测试步骤级别链接缺陷的选项。在 synapseRT 中选择任何测试用例并创建一个临时运行。在执行过程中，它会创建一个新的测试运行，并显示在运行属性部分下链接现有缺陷或创建新缺陷的选项。我们还可以选择在测试步骤级别更新测试状态。

在下面的截图中，步骤一已标记为失败，并且在测试步骤级别有一个关联的 SCRUM-7 缺陷。然而，在测试用例级别有两个缺陷，SCRUM-7 和SCRUM-5。由于这里有一个测试步骤失败，整个测试用例的状态被更新为失败：

如果在测试周期中由于单个缺陷而阻塞了多个测试用例，那么可以将相同的缺陷链接到测试用例，并将它们的状态更新为阻塞。以下截图展示了这种行为：

总共有三个测试用例。其中一个由于缺陷而失败，而相同的缺陷正在阻止当前测试周期中剩余的两个测试用例。

Zephyr

在 Zephyr 的情况下，一旦我们开始执行所选测试周期中的测试用例，我们可以在测试用例级别或测试步骤级别更新测试状态。

在执行测试时，我们还可以选择在测试步骤级别或测试用例级别链接缺陷。如下截图所示，由于有一个步骤标记为失败，整个测试用例的状态已更改为失败。以下步骤标记为阻塞。在缺陷部分，它有一个与之链接的缺陷SCRUMZ-3：

完成此运行后，可以在测试周期级别查看测试执行的状态及其链接的缺陷。...

测试管理

测试管理工具还提供了在测试步骤和测试用例级别链接缺陷并更新测试步骤状态的选项。

如下截图所示，测试用例TESTP-T2在步骤 1 处标记为失败，并且其 ISSUES 部分指示了链接的缺陷。在我们的情况下，这是TESTP-1。剩下的步骤被标记为阻塞：

摘要

在本章中，我们学习了缺陷创建和管理过程。我们学会了识别缺陷并了解它们可能的根本原因。我们还看了在报告缺陷之前应执行的初步检查，以及在系统中记录缺陷时应提供的详细信息。

然后，我们学会了通过具有自定义问题类型（如缺陷）和自定义工作流的 Jira 来创建缺陷。为了创建可追溯性，我们学会了如何在测试执行阶段通过 Jira 插件将缺陷链接到相关的测试用例，无论是在测试步骤还是测试用例级别。

在下一章中，我们将讨论如何使用 Jira 问题来跟踪项目需求。...

第五部分：测试管理-监控和控制

我们将学习 Jira 如何帮助您定义监控和控制项目的策略，使用不同类型的报告。

本节将包括以下章节：

第九章，需求管理
第十章，测试执行状态报告

第九章：需求管理

需求是与项目相关定义的客户需求。它们使用 Jira 中的需求编号或工单编号进行跟踪，以监控和控制项目的进展。将需求与测试用例关联帮助项目团队估计不仅在资源方面所需的工作量和验证相关需求所需的时间，还有助于了解在执行阶段哪些需求存在更多缺陷。

在本章中，我们将涵盖以下主题：

将 Jira 问题类型创建为需求
建立需求和测试用例之间的关系

我们还将看看 Jira 如何帮助我们使用 Jira 问题定义项目需求...

将 Jira 问题类型创建为需求

在 Jira 中，我们有默认的问题类型，如史诗、故事、任务、子任务和错误。这些问题类型使我们能够根据项目的要求灵活定义自己的问题类型。但是，每种问题类型都可以被视为一个需求。一旦需求在系统中定义和记录，就变得容易跟踪和管理它们。我们在第三章中学习了如何在 Jira 中定义需求，了解使用 Jira 进行测试的组件。现在，让我们在 Jira 中创建它们。

创建需求

Jira 有一组预定义的字段来创建 Jira 工单。此外，我们可以根据所选的问题类型添加自定义字段。任何需求问题类型通常应包含以下内容：

团队预期完成的需求或任务的目的
将复杂需求细分为更多细节和规格的详细描述
问题类型的优先级
问题类型的当前状态

在创建需求问题类型时添加了以下细节：

需求字段	描述
需求 ID	此字段有助于唯一标识需求。大多数情况下，业务需求由业务分析师准备...

对需求进行优先排序

需求优先级是基于向最终用户交付功能的需求和紧急性进行的。在对需求进行优先排序时，项目团队还考虑其复杂性和完成所请求任务所需的工作量。项目团队可以根据优先级采取行动。

例如，如果功能请求具有关键优先级，这意味着其重要性非常高，时间非常短。因此，为了在短时间内实现上述任务所需的所有事物，如数据、工具、权限、技能和资源，都在短时间内获得，并且项目团队努力按照设定的时间表实现其目标。

Jira 默认为任何问题类型分配了四种不同的优先级类型：

关键：这些是非常紧急的需求，对业务影响很大。这些方面需要在最短时间内解决并修复，以便紧急交付给最终用户。
高：这些是需要尽快解决和处理的需求。但是，时间通常由项目利益相关者指定。
中等：这些是中等优先级的需求，它们在交付所有关键或高优先级项目后进行处理，因为它们的紧急程度是中等的。
低：低优先级的需求紧急性较低。因此，它们是开发人员优先级列表中要处理的最后一项。有时，具有低优先级状态的任务/子任务也可以移至另一个发布或冲刺，如果项目团队需要更多时间专注于当前发布/冲刺中最关键/高优先级的项目。

需求状态

需求状态帮助项目团队了解其当前状态，并为下一步行动做好准备。设置状态是工作流程的一部分。因此，组织可能会有一个可以根据项目或问题类型而有所不同的定制状态。

一般来说，以下状态对需求问题类型是有用的：

草案：顾名思义，如果有进一步需要添加的细节，可以使用这个状态。一般来说，业务分析师负责创建业务需求。如果不是，那么项目负责人会在系统中创建它们。
草稿完成：一旦所有需求细节都被添加，它们的状态可以被更新...

管理需求工件

需求可以以各种格式创建，同时可能存在不同类型的工件，包括以下内容：

项目章程：这启动了项目。
项目批准的需求文件：包含高层次的批准需求。
项目的高层次和低层次设计文档：这些详细定义了项目架构。
项目计划：这包括有关范围、时间、成本、预算和其他相关计划的详细信息，包括变更管理策略计划和资源分配计划。它还定义了每个阶段结束时可接受的可交付成果清单及其格式。
项目相关的第三方工具文档：这些将与当前项目相关，例如产品信息、教程或需要访问工具的用户权限。
风险缓解策略和行动计划：用于了解项目风险以及减轻风险所需的步骤。
知识库存储库：其中包含与当前项目相关的所有文档，以及项目团队可以使用的任何其他相关项目。例如，以前发布的经验教训和回顾文件可以被项目团队参考。
培训文件：这些是与资源培训相关的文件和视频，如果有的话。
角色和责任：这些是与资源角色和责任相关的文件。
项目会议：这包括项目规划、每周和/或每日会议或电话会议、讨论报告，包括会议记录或用于确认项目特性的需求或条件的任何电子邮件。
项目进展报告：这份报告是在每个冲刺结束或产品开发的每个阶段生成的。例如冲刺报告、史诗报告、项目燃尽图、测试执行报告、测试周期报告和测试计划报告。

由于在项目之前、期间和结束时生成了各种类型的文档，根据冲刺或发布管理项目存储库是必要的。

建立需求和测试用例之间的关系

建立追溯矩阵的第一步是将基于需求设计的测试用例与系统中记录的相关需求进行关联。追溯矩阵帮助测试团队了解测试覆盖范围，并通过根据需要添加或删除测试用例来适当地管理测试用例。

在测试执行阶段，这个链接帮助测试团队了解哪些需求失败或需要更多时间来执行。测试经理可以决定采取策略来克服这些问题，并根据需要分配更多资源或时间。

让我们看看如何使用 Jira 插件将测试用例与需求关联起来。

synapseRT

要将测试用例链接到 Jira 中的不同问题类型，我们需要从配置部分将问题类型配置为需求。配置正确后，这些问题类型将具有一个测试用例部分，可用于将测试用例链接到工单。现在，让我们观察以下步骤来链接测试用例：

如下面的屏幕截图所示，故事问题类型已配置为需求。因此，它具有一个测试用例部分，使用户可以创建新的测试用例或将现有的测试用例链接到故事。下面的屏幕截图显示了一个测试用例SCRUM-11，它链接到了故事SCRUM-14：

创建测试用例选项将打开一个创建问题页面，您可以在其中创建一个新的测试用例，并且它将自动链接到故事。为了链接现有的测试用例，单击“链接测试用例”按钮，并且如下面的屏幕截图所示，它会给您选择测试用例并将其链接到工单的选项：

由于 synapseRT 中的测试用例是另一种问题类型，我们还可以从测试用例问题类型链接需求。为了这样做，打开测试用例问题，然后从“选择需求”部分单击“链接”按钮。如下面的屏幕截图所示，通过其 ID 选择需求，然后单击“链接”：

链接需求之后，如果您现在返回到测试用例的需求部分，您将看到 Jira 已经在测试用例和测试用例问题类型的故事之间创建了链接。如下面的屏幕截图所示，除了需求部分，我们还可以添加有关测试用例所属的测试套件以及测试计划的详细信息：

我们在 synapseRT 中还有一个选项，称为测试计划问题类型，用于查看所选需求的测试用例覆盖范围。为了首先查看覆盖范围，我们需要将相同的一组测试用例添加到需求问题类型中，以及在测试计划中添加。之后，如果您打开测试计划问题，您可以从需求部分查看测试用例覆盖范围，如下面的屏幕截图所示。在这种情况下，需求覆盖率为 100.0%，因为计划到需求的所有测试用例都与需求问题类型链接，并且已添加到测试计划中以验证功能：

Zephyr

在 Zephyr 中，我们可以通过链接问题来建立需求问题类型和测试用例之间的关系。

为此，首先在 Zephyr 中创建一个需求问题类型。在创建问题屏幕上，有一个名为“链接问题”的字段。单击它。这将显示以下屏幕截图，从中可以链接相关问题-在我们的情况下，是一个测试用例：

一旦我们完成将所有测试用例链接到需求问题类型，链接就可以从“问题链接”部分查看。现在，由于 Zephyr 中的测试用例也是一个问题类型，通过以下相同的步骤，我们可以将需求链接到测试用例问题。...

测试管理

在 Jira 插件的测试管理中，我们可以从“可追溯性”部分将测试用例添加到需求问题类型。该部分提供多个选项，可以创建或链接测试用例，甚至测试周期：

单击故事问题类型的“可追溯性”部分的+图标。
选择一个选项，添加现有的测试用例。这将显示以下屏幕，用于选择现有的测试用例。它在“添加现有测试用例”窗口中显示所有现有的测试用例。选择所需的测试用例的复选框，然后单击“添加”按钮将这些测试用例添加到需求问题类型中：

将现有的测试用例链接到故事类型后，所有链接的测试用例都可以从可追溯性部分查看。如下截图所示，在故事TESTP-2的情况下，我们已经链接了两个测试用例，TESTP-T2(1.0)和TESTP-T3(1.0)：

我们还可以从测试用例中链接需求。为了这样做，转到测试部分，打开任何现有的测试，并单击追溯性选项卡。在问题部分单击添加按钮，然后选择要链接到测试用例的所需问题。问题可以从当前项目或其他项目中搜索。选中要链接的所需问题的复选框，然后单击添加按钮。
添加需求后，应该在可追溯性 | 问题部分显示。如下截图所示，我们已经从测试用例追溯性部分将TESTP-T2测试用例与TESTP-2需求进行了关联：

总结

在本章中，我们学习了如何在 Jira 中有效地管理和记录需求。我们看到了 Jira 问题可以用于跟踪测试阶段的需求。然后我们了解了如何使用可追溯性矩阵来追踪测试覆盖率。此外，我们使用每个 Jira 插件创建了可追溯性矩阵，通过将需求与相关的测试用例进行关联。

在下一章中，我们将探讨 Jira 如何通过报告帮助监控和控制项目，并详细介绍 Jira 提供的各种报告。

第十章：测试执行状态报告

项目状态报告可以让我们了解项目在项目开发阶段的健康状况。这有助于监控和控制项目进展，以确保交付达到所需的质量标准和截止日期。Jira 提供了各种类型的报告。报告的主要目标是识别任何运行时问题和障碍，或需要实施的最后一分钟更改。报告帮助所有项目利益相关者了解项目的当前状态，并允许他们就包含计划中的任何偏差做出民主决策。

项目经理提前计划以识别风险并创建风险缓解策略。他们还处理变更管理和沟通管理中的活动。报告是沟通管理的一部分。

在本章中，我们将涵盖以下主题：

测试计划执行报告
临时测试运行报告
基于需求的报告
缺陷矩阵报告
测试套件报告
燃尽图

我们还将涵盖项目测试执行阶段创建的报告，因为 Jira 插件对生成这些报告很有用。

测试计划执行报告

在测试执行阶段，测试执行是按照测试周期或迭代进行的。每个迭代或测试周期都有一组计划的测试用例。根据周期或迭代跟踪测试执行的进度是有用的。如果迭代或测试周期是测试计划的一部分，那么生成测试计划执行报告可以让我们清楚地了解当前执行的测试用例及其状态。

让我们使用 Jira 插件生成一个测试计划执行报告。

synapseRT

synapseRT 有一个选项可以生成测试计划执行报告，借助这个选项，项目团队可以跟踪当前执行的进展：

synapseRT 有一个 SynapseRT 报告选项卡，我们可以从中选择测试计划执行报告选项来自定义和生成测试计划执行报告。
如下截图所示，我们可以选择测试计划和特定周期，或所有周期，以及测试用例执行状态。在选择所有适当的值后，点击“生成报告”按钮来创建报告：

这创建了下图所示的报告。报告列出了属于所选测试周期的所有测试用例，它们在“结果”列中的当前状态，分配给测试用例的测试人员，以及执行测试用例的人（在“测试者”列中）。还有一些更多的细节，比如“执行时间”（指执行的日期和时间），缺陷，估计和工作量。我们还有一个选项以 Excel 格式提取此报告：

通过测试计划部分，我们还可以查看测试计划当前执行的状态。转到测试计划选项卡，然后转到“未解决的计划”部分。它列出了所有没有关闭状态的测试计划。只需点击下拉图标，它会显示按测试周期分隔的执行进度。如下截图所示，我们有两个状态为“活动”的测试周期。它还显示了测试运行，缺陷及其当前状态等详细信息：

Zephyr

在 Zephyr 中，我们可以生成测试用例执行报告来查看每个周期的进展及其关联的测试用例：

为了生成报告，导航到 Jira 中的报告部分。有两个主要部分——所有报告和其他。测试用例执行报告列在其他部分下。点击它以创建一个。如下截图所示，这样做会显示用于根据项目、测试周期、版本等自定义报告的配置页面。提供适当的值，然后点击下一步。在下面的截图中，我们将测试周期的数量设置为3：

以下报告...

测试管理

测试管理有一个选项，可以创建由测试周期组成的测试计划：

为了通过测试计划生成测试报告，导航到测试选项卡并转到报告部分。这显示了生成报告的多个选项；选择按测试计划选项执行的测试执行结果。它允许您根据项目、开始和结束日期以及基于最近或全部的执行来自定义报告。在选择所有必需的选项后，点击生成按钮：

它生成了以下报告。y轴表示所选测试计划的数量，x轴显示了具有当前执行状态的测试用例的数量。下面的截图显示，我们总共计划了八个测试用例，其中一个被阻止，一个通过了，两个失败了，四个测试用例没有被执行。我们还有一个选项可以打印或以 Excel 格式导出报告：

自定义测试运行报告

自定义测试运行报告指示所选测试用例作为自定义测试运行的一部分已执行的次数。在这种情况下，测试用例不是任何测试计划的一部分，独立执行。跟踪其状态变化也很有用。如果在自定义测试运行期间附加了任何工件，例如测试数据、截图或日志，测试人员可以使用这些信息来比较其上次执行的结果。Jira 插件有生成此类报告的选项。让我们逐个创建它们。

synapseRT

synapseRT 有一个选项，可以从自定义测试运行部分查看单个测试用例级别的自定义测试运行详细信息。如下截图所示，所选测试用例已执行三次，其状态从 BLOCKED 变化到 FAILED 和 PASSED。它还显示了测试运行的 ID，执行者，执行日期和时间以及相关缺陷（如果有）等细节：

可以为所有测试用例生成自定义测试运行报告：

为了生成这样的报告，导航到SynapseRT 报告选项卡，并选择自定义测试运行报告选项。如下截图所示，输入所需的细节，如执行类型和开始日期和结束日期，并点击生成报告按钮：

如下截图所示，生成了自定义测试运行报告。它显示了测试用例的名称；它们在结果列中的当前状态；在测试人员列中测试了谁；在执行时间中的执行日期和时间；以及缺陷列中的关联缺陷（如果有）：

Zephyr

Zephyr 有一个自定义测试周期，可以向其中添加并执行测试用例。我们可以从周期摘要选项卡查看所选周期的状态：

导航到测试 | 测试摘要 | 周期摘要选项卡。它显示了所有发布的所有测试周期。
将鼠标悬停在临时周期上，并观察它列出了该周期中所有测试用例的当前状态。它还指示了一个颜色条，以显示绿色、红色和蓝色来表示通过、失败和阻塞的状态进度。如下截图所示，临时测试周期共有四个测试用例，其中两个，即总测试用例的 50%，处于通过状态，一个处于失败状态，一个处于阻塞状态...

测试管理

在测试管理工具中，我们可以通过导航到报告|测试执行|测试执行结果（列表）报告来查看所选测试用例已执行的次数：

要创建此报告，请转到测试|报告|测试执行选项卡并选择测试执行结果（列表）选项。输入所需的细节，例如您要测试的周期。如下截图所示，我们已选择了测试周期和项目。在输入所有必需的细节后，点击生成按钮：

这生成了以下截图中显示的报告。其中列出了在所选测试周期下添加的测试用例列表。在我们的案例中，我们有TESTP-T2测试用例，作为TESTP-C1测试周期的一部分共执行了四次。状态列显示了每次执行期间的状态，还有其他列提供其他细节：

基于需求的报告

基于需求的报告帮助我们了解所选需求的当前执行状态。在有多个需求的项目中，这些报告很有帮助，因为它们根据 Jira 中的需求工单对测试用例进行分组。让我们使用 Jira 插件创建一个报告。

synapseRT

synapseRT 有一个选项可以生成基于需求的报告，并根据需求跟踪当前执行的进度：

要在 synapseRT 中创建基于需求的报告，请转到 SynapseRT 报告选项卡并选择基于需求的报告选项。这让您可以根据需求自定义报告。如下截图所示，输入所有必需的细节以及测试计划，它将生成与所选需求工单关联的报告：

它生成了以下截图中显示的报告。图表显示了所选需求工单的执行状态。它还有摘要报告和详细报告部分。摘要报告部分显示了项目名称、其需求以及关联的测试用例及其当前执行状态等详细信息：

详细报告部分显示了所选需求及其关联的测试用例、测试周期和执行结果的详细信息。

Zephyr

Zephyr 没有生成基于需求的报告的功能。

测试管理

测试管理工具使用测试执行结果覆盖报告，该报告根据关联的需求显示了测试用例的当前状态：

要创建测试执行结果覆盖报告，请转到测试|报告|测试执行选项卡并选择测试执行结果覆盖选项。这将显示配置页面以自定义报告并根据需要生成。如下截图所示，在配置页面上，输入所需的细节，例如项目、文件夹、开始日期和结束日期，然后点击生成按钮：

这生成了下面截图中显示的报告。y轴显示了用户故事列表，x轴显示了按用户故事分组的测试用例数量。以下图表表明TESTP-6用户故事共有八个测试用例与之关联，其中两个被阻塞，两个失败，四个通过：

缺陷矩阵报告

正如名称所示，缺陷矩阵报告可用于了解与测试用例关联的缺陷的当前状态。因此，它有助于了解所选项目的当前测试周期和测试计划的进展情况。根据缺陷的当前状态、受托人、优先级、组件等，有各种选项可供定制和生成此类报告。让我们尝试使用 Jira 插件生成缺陷矩阵报告。

synapseRT

synapseRT 有一个选项来创建缺陷矩阵报告，并验证团队报告的当前周期或测试计划执行的缺陷状态：

为了在 synapseRT 中生成缺陷矩阵报告，请导航到 SynapseRT Reports 选项卡，并选择 Defect Matrix Report 选项。这显示了配置报告的选项。我们还可以通过选择x轴和y轴的值来选择报告的查看方式。在输入所有必需的细节后，点击生成报告按钮：

生成了以下报告，以图形格式显示了缺陷状态。如下截图所示，所选的测试周期共有三个缺陷，其中两个是中等优先级，一个是高优先级。它还提供了缺陷的详细信息，比如在缺陷列中的缺陷编号和解决方案：

Zephyr

Zephyr 没有生成缺陷矩阵报告的功能。然而，它帮助我们识别对测试执行阶段产生高影响的缺陷：

为了生成这个报告，请导航到报告选项卡，并从其他报告部分选择 Top Defects Impacting Testing 选项。
为了定制报告，输入必需的细节，输入要查看的缺陷数量和缺陷的状态。现在，如下截图所示，选择的缺陷数量为 10，状态为草稿。点击下一步生成报告：

生成了以下报告。它列出了缺陷...

测试管理

测试管理有一个测试执行（问题）报告，列出了在所选周期、测试计划、版本、迭代甚至文件夹中报告的所有问题。此报告可以从报告选项卡生成：

为了创建测试执行（问题）报告，请导航到 Tests | Reports | Test Execution 选项卡。测试管理已添加了额外的报告；然而，我们仍然可以使用传统的报告选项来生成报告。
选择切换到传统报告选项以使用传统的报告格式。
切换视图后，导航到测试执行选项卡并选择测试执行（问题）选项。如下截图所示，这样做会显示报告配置页面。输入必需的细节。选择测试周期，输入开始和结束日期，然后点击生成按钮：

生成了以下报告，显示了创建的总缺陷及其优先级、状态等：

在问题部分，您还可以看到缺陷的详细信息，比如在关键列中的问题 ID 和摘要：

测试套件报告

如果测试用例是基于测试套件添加和执行的，那么生成基于测试套件的测试执行报告是很好的选择。这提供了有关测试用例的当前执行状态、谁执行了它们以及负责测试的人的详细信息。让我们借助 Jira 插件生成这份报告。

synapseRT

synapseRT 有一个选项可以生成测试套件报告，借助它可以跟踪测试套件的进度：

要在 synapseRT 中生成测试套件报告，请导航到 SynapseRT 报告选项卡，并选择测试套件报告选项。这使您可以根据项目、测试套件、测试计划、测试周期等配置报告的选项。
在所有必填字段中输入数据，然后点击生成报告按钮。如下截图所示，我们提供了有关这些测试用例所添加的项目、测试套件和测试计划的详细信息：

这将生成以下截图中显示的报告。报告有诸如测试套件覆盖率和搜索细节之类的部分。测试套件覆盖率部分指示所选周期的测试用例总数及其当前状态。

周期和运行详细信息指示了这些测试用例所添加的测试周期及其当前执行状态和其他详细信息。此报告还列出了所有与这些测试用例相关联的缺陷：

Zephyr

Zephyr 没有生成测试套件报告的功能。但是，我们仍然可以查看所选测试周期的执行测试的状态，如前面的 Zephyr 特别测试运行报告所示。

测试管理

测试管理具有用于组织测试用例的文件夹结构，因此在基于测试套件生成报告时，我们将不得不根据文件夹选择选项：

要在测试管理中生成测试套件报告，请导航到 Tests | Reports | Test Execution 选项卡，并输入所需的详细信息。如下截图所示，输入项目名称，需要生成报告的文件夹（测试套件）等，然后点击生成按钮：

这将生成以下截图中显示的报告。报告列出了已创建此报告的文件夹名称、测试用例总数及其执行状态。它还指示了任何给定状态的测试用例的百分比。在这种情况下，我们有 33.33%的测试用例处于通过状态。它还显示了有关测试执行剩余量、已完成情况等的详细信息。问题部分列出了与测试用例相关联的缺陷（如果有）：

燃尽图

测试用例燃尽图帮助项目团队跟踪所选测试周期的测试用例执行速度。它还指示了已在所选日期、周或月执行的测试用例数量以及剩余测试用例。它帮助团队了解完成所选测试周期还需要多少努力。让我们借助 Jira 插件创建这份报告。

synapseRT

synapseRT 有一个选项可以生成测试用例燃尽报告，用于跟踪测试执行速度：

要在 synapseRT 工具中生成测试用例燃尽报告，请导航到 SynapseRT 报告部分，并选择测试用例燃尽报告选项。这让您可以选择必须生成报告的项目、测试计划和测试周期。
如下截图所示，输入所有必填详细信息，然后点击生成报告按钮：

这将生成测试用例燃尽报告，如下面的屏幕截图所示。 x轴表示测试用例的数量，y轴表示执行这些测试用例的日期。如下面的屏幕截图所示，执行开始日期是 1 月 7 日，执行的最后日期是 1 月 22 日，这是生成此报告的日期：

如果我们将鼠标悬停在节点上，它会提供更多详细信息，例如需要执行的测试用例的日期和剩余数量。如下面的屏幕截图所示，所选节点的日期是 2019 年 1 月 17 日，截至当天仍有两个测试用例需要执行：

风神

Zephyr 有一个选项可以生成测试执行燃尽图，这有助于团队了解当前测试执行阶段的状态：

要创建此报告，请导航到报告部分，并从报告的其他部分中选择 Test Execution Burndown Chart 选项。输入详细信息，如下面的屏幕截图所示，以生成所有周期的测试执行燃尽图：

这生成以下图表。图表显示了执行的平均速率，剩余的未执行测试总数和预期完成日期：

在这种情况下，这些值如下：

平均...

测试管理

测试管理有一个选项可以生成测试执行燃尽图，借助该选项可以跟踪测试执行的速率：

要在测试管理工具中生成测试执行燃尽图，请导航到 Tests | Reports | Test execution 选项卡，并选择 Test execution burn down 选项。这将显示配置页面。
输入详细信息，选择报告的持续时间，然后单击生成按钮：

这将生成以下报告，显示了所选的两个测试周期的测试用例的每日执行速率。 y轴表示测试用例的总数，x轴显示了执行这些测试用例的日期：

摘要

在本章中，我们学习了如何使用 Jira 插件创建各种报告，并了解了每种类型的目的。我们看到报告如何帮助监控和控制测试活动。

正如我们所知，报告作为一个重要的沟通工具，可以在项目开发生命周期中提供关于项目的见解。因此，项目团队和管理层理解其重要性，并找到适当利用其项目的重要报告的方法是至关重要的。

在下一章中，我们将探讨如何将第三方自动化测试工具集成到 Jira 中，以管理自动化测试用例。

第六部分：Jira 和 Jenkins 的持续集成

我们将学习 Jira 如何帮助 SQA 团队利用 DevOps 流水线来自动化执行和管理测试用例。我们将学习如何配置 Jira 与 Jenkins，以在 Selenium 中执行自动化测试用例。

本节将包括以下章节：

第十一章，Jira 与自动化测试工具的集成

第十一章：Jira 与自动化测试工具集成

在之前的章节中，我们已经了解了什么是测试管理，以及 Jira 如何帮助 SQA 团队有效地管理测试过程。现在，让我们看看如何利用 Jira 和 DevOps 管道来自动化和管理测试执行，以改善开发生命周期中的敏捷性。

在本章中，我们将涵盖以下主题：

理解 DevOps 管道
配置 Jira 插件以连接 Jenkins
理解集成和执行自动化脚本的示例工作流程

我们还将学习 Jira 如何在软件项目中帮助持续集成（CI）和持续交付（CD）。

理解 DevOps 管道

DevOps 是一个涉及持续开发、测试、集成、部署和监控循环的软件开发范式。这个模型是成熟的软件开发实践的结果，特别是随着敏捷方法学的出现，它要求更快的产品和服务发布，同时确保足够的质量措施。以下图表显示了 DevOps 周期中的各个阶段：

如前图所示，DevOps 需要开发、测试和运维功能协同工作。DevOps 阶段基本上是敏捷 SDLC 中开发阶段的自动化和流程化实现。

在开发阶段，开发人员根据产品需求开始编写代码。同时，测试人员开始编写自动化测试的测试用例或脚本。这要求开发人员和测试人员在实现最终可工作的构建之前，对其代码和脚本的多个版本进行多次提交。因此，源代码管理对于有效和高效的开发至关重要。在没有版本控制工具的团队环境中，这可能会成为一个问题。因此，DevOps 采用了几种版本控制工具，如 GitHub、Bitbucket 和 Team Foundation。

一旦开发人员提交了代码，DevOps 流程就会被触发，自动编译和构建代码以及团队其他成员的代码提交。如果编写了适当的单元测试，DevOps 流程会执行这些测试以断言结果是否符合预期。在这个阶段发现的任何缺陷或问题都会通过电子邮件和工单通知给开发团队。市场上有几种 CI 工具，如 Jenkins 和 Circle CI。在本章中，我们将学习如何利用 Jenkins 与 Jira 进行集成。Jenkins 是一个用于 CI 的开源工具。它可以与多种软件开发工具集成，以自动化 CI/CD 的过程。

一旦构建通过了开发级别的单元测试和集成测试，发布构建就会部署到适当的测试服务器上，供测试团队启动他们的测试。此时，如果有自动化测试脚本，将会触发自动化测试来测试构建。自动化确保了 DevOps 阶段的连续性；否则，会导致开发过程的敏捷性受阻。有几种测试自动化框架和工具可用，如 Selenium、TestComplete 和 Eggplant，可以帮助自动化测试过程。

构建一旦经过测试并修复了所有缺陷，就准备好部署了。经过产品团队和利益相关者的适当批准后，它将部署到生产服务器上。部署构建的容器化有助于促进弹性服务器，以及有效的负载平衡和配置管理。市场上有许多容器化工具，包括 Docker、Ansible 和 Kubernetes。

DevOps 流程的所有阶段都需要持续监控，使用 Prometheus、Splunk 和 Ganglia 等工具，以提醒开发团队需要高效解决的问题。持续监控对于解决瓶颈并改进更快交付机制的流程至关重要。持续反馈是另一种通过帮助团队规划下一次部署来改进产品的机制。

现在我们了解了 DevOps 流程的基础知识，让我们看看如何配置 Jenkins 与 Jira 和测试自动化工具集成。

配置 Jira 插件连接到 Jenkins

synapseRT、Zephyr 和 Jira 的测试管理工具插件都有各自连接 CI/CD 工具（如 Jenkins）的方式。我们将看看如何为 Jenkins 安装和配置这些 Jira 插件。

synapseRT

synapseRT 预先安装了与 CI/CD 工具的集成。让我们配置插件以连接到我们的 Jenkins 安装：

转到 Administration | Add-ons | synapseRT | Integration，然后点击“添加”按钮。
将 Jenkins 设置为应用程序类型，并提供 Jenkins URL。在我们的情况下，我们在 Docker 实例上托管了 Jira，而 Jenkins 托管在端口8081的本地主机上。因此，我们提供http://host.docker.internal:8081作为 URL，而不是http://localhost:8081，以及 Jenkins 实例的用户名和密码：

有关配置和设置 synapseRT 与 Jenkins 的问题的更多信息或澄清，请访问bit.ly/2RBEAfA。

Zephyr

Zephyr 提供了与 Jenkins 集成的插件。

要安装插件，请点击“管理 Jenkins”|“管理插件”：

点击“可用”选项卡，搜索Zephyr for Jira，然后点击“无需重启安装”或“立即下载并在重启后安装”按钮。安装成功后，插件将显示在“已安装”选项卡上：

安装后，我们可以配置插件以将其与我们 Jira 实例中的 Zephyr for Jira 连接。

现在，点击“管理 Jenkins”，然后点击“配置系统”。如果插件...

测试管理

Jira 的测试管理提供了与 Jenkins 集成的插件。

要安装插件，请点击“管理 Jenkins”|“管理插件”，就像你为 Zephyr 所做的那样。
然后，点击“可用”选项卡，搜索“Jira 的测试管理”，然后点击“无需重启安装”或“立即下载并在重启后安装”按钮。安装成功后，插件将显示在“已安装”选项卡上：

安装后，我们可以配置插件以将其与我们 Jira 实例中的测试管理连接。点击“管理 Jenkins”，然后点击“配置系统”。如果插件安装正确，配置系统将有一个名为“Jira 的测试管理”的部分。选择组织中 Jira 实例的类型。在我们的情况下，我们选择了 Jira 服务器。
提供 Jira URL 和与 Jira 项目连接的凭据。点击“测试配置”按钮验证设置。如果一切验证通过，它会看起来像这样：

有关配置和设置 Jira 的测试管理插件与 Jenkins 的问题的更多信息或澄清，请访问以下链接：www.adaptavist.com/doco/display/KT/Jenkins。

集成和执行自动化脚本的示例工作流程

现在我们已经配置了插件与 Jenkins 集成，我们现在看到了 DevOps 流水线如何使用每个插件的示例。对于这个工作流程，我们使用以下自动化测试脚本：

在 Eclipse 中使用 TestNG 构建脚本的测试自动化代码。为此，我们使用 Eclipse 在 Java 中创建了代码。我们在一个名为JenkinsDemoPkg的新包中创建了一个新的 Java 项目，其中包含一个名为demoJenkins的类。我们还使用JenkinsDemoPkg.demoJenkins: testJenkins来获取类和方法的完整名称，这将用于插件中的跟踪：

package JenkinsDemoPkg;import org.testng.annotations.Test;public class demoJenkins {

synapseRT

让我们看看将 Jenkins 与 synapseRT 集成的步骤。

捕获构建操作的结果作为后期构建活动。为了捕获 Jenkins 中的构建结果，以便 synapseRT 可以拉取它们，需要为 Jenkins 作业配置后期构建操作如下：

synapseRT 允许我们从测试周期内触发 Jenkins 作业。为了 synapseRT 能够跟踪执行结果，需要将测试参考添加到自动化部分的测试用例中：

自动化|测试参考是我们在第 1 步中捕获的模块的完整名称。然后，将测试用例添加到测试周期，并单击“运行”按钮以触发 Jenkins 作业：

当单击“运行”按钮时，Jenkins 作业开始运行：

在 Jira 插件中捕获构建结果。大约 60 秒后，作业的结果将在 Jira 中被捕获：

Zephyr

让我们看看将 Jenkins 与 Zephyr 集成的步骤。

将构建操作的结果作为后期构建活动捕获。为了捕获 Jenkins 中的构建结果，以便 Zephyr 可以拉取它，需要为 Jenkins 作业配置后期构建操作。为 Zephyr 项目提供项目名称，并选择适当的周期和版本：

要触发 Jenkins 作业，请在单击作业名称后单击“立即构建”按钮：

在 Jira 插件中捕获构建结果。Jenkins 作业完成后，...

测试管理

将 Jira 的测试管理与 Jenkins 和其他 CI/CD 工具集成，就像我们为 Zephyr 执行的设置一样。这在以下链接的帮助部分中有详细介绍：www.adaptavist.com/doco/display/KT/Integrations。

摘要

在本章中，我们学习了使用 Jira 插件的 DevOps 流水线和执行。我们了解了如何在软件开发项目中利用 DevOps 流水线，实现真正的敏捷交付，并不断改进交付过程。我们配置了我们的 Jira 测试管理插件，以与 Jenkins 集成为我们的 CI/CD 工具。我们看到了一个简单的实际示例，演示了在 DevOps 流水线中自动化测试用例管理。

我们漫长的旅程到此结束。希望您喜欢阅读本书！

posted @ 2024-05-20 11:58 绝不原创的飞龙阅读(139) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

JIRA-测试管理实用手册-全-

JIRA 测试管理实用手册（全）

前言

这本书是为谁准备的

从本书中获益最大

下载彩色图片

使用的约定

第一部分：软件质量保证简介

第一章：软件质量保证概述

什么是质量？

为什么要关心质量？

谁对质量负责？

我们如何确保质量？

软件测试思维过程

质量管理系统

ISO 9000 系列

CMMI

成熟度水平

软件开发生命周期与软件测试生命周期

SDLC

STLC

测试类型

准备测试数据和管理测试工件

管理测试工件

总结

第二部分：Jira 环境-概述

第二章：开始使用 Jira

什么是 Jira？

使用 Jira 组织项目

使用 Jira 进行敏捷项目管理

什么是 Scrum？

详细了解 Scrum

Scrum 会议

什么是 Kanban？

项目启动和管理

在 Jira 中如何启动项目

Jira 中的基于角色的权限

使用 Jira 进行 Scrum

使用 Jira 进行看板

探索 Jira 的测试管理插件

synapseRT

Zephyr

测试管理

摘要

第三章：了解 Jira 中的测试组件

需求

什么是需求？

问题类型

测试套件

什么是测试套件？

synapseRT 中的测试套件

Zephyr 中的测试套件

测试管理中的测试套件

测试套件的优势

测试计划

什么是测试计划？

synapseRT 中的测试计划

Zephyr 中的测试计划

测试管理中的测试计划

追溯

什么是追溯矩阵？

追溯矩阵的类型

可追溯矩阵的好处

synapseRT 中的可追溯性

Zephyr 中的可追溯性

测试管理中的可追溯性

报告

报告类型

摘要

第三部分：测试管理-管理和计划

第四章：测试管理方法

TMap 结构化测试的执行策略

临时测试运行

synapseRT

Zephyr

测试管理

为选定的发布执行测试周期

synapseRT