敏捷测试 - 快速指南

---

---

敏捷测试 - 概述

敏捷是一种迭代式开发方法，开发和测试活动同时进行。测试不是一个单独的阶段；编码和测试交互式地、增量式地进行，从而产生满足客户需求的优质最终产品。此外，持续集成可以尽早发现缺陷，从而节省时间、精力和成本。

敏捷宣言

敏捷宣言由一个软件开发团队于 2001 年发布，强调了开发团队的重要性、适应变化的需求以及客户参与。

敏捷宣言是：

我们正在通过实践和帮助他人实践来发现更好的软件开发方法。通过这项工作，我们已经了解到：

• 个体和互动高于流程和工具。
• 工作的软件高于详尽的文档。
• 客户合作高于合同谈判。
• 响应变化高于遵循计划。

也就是说，虽然右边的项目也有价值，我们更重视左边的项目。

什么是敏捷测试？

敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。

敏捷测试涉及项目团队的所有成员，测试人员贡献了特殊的专业知识。测试不是一个单独的阶段，而是与所有开发阶段（如需求、设计和编码以及测试用例生成）交织在一起。测试贯穿整个软件开发生命周期。

此外，测试人员与跨职能团队成员一起参与整个软件开发生命周期，这使得测试人员能够根据客户需求构建软件，并改进设计和代码。

敏捷测试涵盖所有测试级别和所有类型的测试。

敏捷测试与瀑布测试

在瀑布式开发方法中，软件开发生命周期活动按顺序分阶段进行。因此，测试是一个单独的阶段，只有在开发阶段完成后才能启动。

以下是敏捷测试和瀑布测试之间差异的要点：

敏捷测试原则

敏捷测试的原则包括：

• 测试推动项目前进 - 持续测试是确保持续进展的唯一途径。敏捷测试提供持续反馈，最终产品满足业务需求。

• 测试不是一个阶段 - 敏捷团队与开发团队一起测试，以确保在给定迭代期间实现的功能实际上已完成。测试不会留到以后的阶段。

• 每个人都测试 - 在敏捷测试中，整个团队，包括分析师、开发人员和测试人员，都会测试应用程序。每次迭代后，甚至客户也会执行用户验收测试。

• 缩短反馈循环 - 在敏捷测试中，业务团队可以了解每个迭代的产品开发情况。他们参与每个迭代。持续反馈缩短了反馈响应时间，从而降低了修复成本。

• 保持代码整洁 - 缺陷在同一迭代中提出时就被修复。这确保了在任何开发里程碑上代码的整洁。

• 轻量级文档 - 敏捷测试人员使用轻量级文档，而不是详尽的测试文档：

  • 使用可重复使用的检查表来建议测试。

  • 关注测试的本质，而不是偶然的细节。

  • 使用轻量级文档样式/工具。

  • 在探索性测试的章程中捕捉测试思路。

  • 利用文档实现多种用途。

• 利用一个测试工件进行手动和自动化测试 - 相同的测试脚本工件可用于手动测试和作为自动化测试的输入。这消除了手动测试文档以及等效的自动化测试脚本的要求。

• “真正完成”，而不仅仅是“完成” - 在敏捷中，一个功能在开发和测试后才算完成，而不仅仅是开发完成。

• 测试最后 vs. 测试驱动 - 测试用例与需求一起编写。因此，开发可以由测试驱动。这种方法称为测试驱动开发 (TDD) 和验收测试驱动开发 (ATDD)。这与瀑布测试中测试作为最后一个阶段形成对比。

敏捷测试活动

项目级别的敏捷测试活动包括：

• 发布计划（测试计划）

  • 对于每个迭代：

  • 迭代期间的敏捷测试活动

• 回归测试

• 发布活动（与测试相关）

迭代期间的敏捷测试活动包括：

• 参与迭代计划
• 从测试的角度估计任务
• 使用功能描述编写测试用例
• 单元测试
• 集成测试
• 功能测试
• 缺陷修复
• 集成测试
• 验收测试
• 测试进度状态报告
• 缺陷跟踪

敏捷测试 - 方法论

敏捷是一种迭代式开发方法，整个项目团队参与所有活动。通过客户和自组织团队之间的协作，需求随着迭代的进展而发展。由于编码和测试在开发过程中交互式地和增量式地进行，因此最终产品将具有高质量并确保满足客户需求。

每次迭代都会产生一个集成的可工作产品增量，并交付进行用户验收测试。由此获得的客户反馈将作为下一次/后续迭代的输入。

持续集成，持续质量

持续集成是敏捷开发成功的关键。频繁集成，至少每天集成一次，以便在需要时随时准备发布。敏捷中的测试成为所有开发阶段的重要组成部分，确保产品的持续质量。来自参与项目的所有人的持续反馈增加了产品的质量。

在敏捷中，沟通至关重要，客户请求随时接收。这使客户满意，因为所有输入都被考虑在内，并且在整个开发过程中都有高质量的产品。

敏捷方法论

有几种敏捷方法论支持敏捷开发。敏捷方法论包括：

Scrum

Scrum 是一种敏捷开发方法，强调以团队为中心的方法。它提倡整个团队参与所有项目开发活动。

XP

极限编程 (XP) 以客户为中心，专注于不断变化的需求。通过频繁发布和客户反馈，最终产品将具有高质量，满足在过程中变得更清晰的客户需求。

Crystal

Crystal 基于制定章程、循环交付和收尾。

• 制定章程包括组建开发团队、进行初步可行性分析、制定初步计划和开发方法。

• 具有两个或多个交付周期的循环交付侧重于开发阶段和最终集成产品的交付。

• 在收尾期间，将执行部署到用户环境、部署后审查和反思。

FDD

功能驱动开发 (FDD) 涉及设计和构建功能。FDD 与其他敏捷开发方法论的区别在于，功能是分别在特定且短暂的阶段开发的。

DSDM

动态软件开发方法 (DSDM) 基于快速应用程序开发 (RAD)，并与敏捷框架对齐。DSDM 侧重于频繁交付产品，积极参与用户，并授权团队快速做出决策。

精益软件开发

在精益软件开发中，重点是消除浪费并为客户创造价值。这导致了快速开发和有价值的产品。

浪费包括部分完成的工作、不相关的工作、客户不使用的功能、缺陷等，这些都会导致交付延迟。

精益原则是：

• 消除浪费
• 敏捷学习
• 延后承诺
• 赋能团队
• 快速交付
• 内建完整性
• 全局视角

看板

看板关注于工作管理，强调准时制 (JIT) 交付，同时避免团队成员超负荷工作。任务对所有参与者可见，团队成员可以从队列中提取工作。

看板基于：

• 看板（在整个开发过程中都可见且持久）
• 在制品 (WIP) 限制
• 交付周期

敏捷测试方法

无论项目是否采用敏捷方法，测试实践都经过明确定义，以交付高质量产品。传统的测试原则经常用于敏捷测试中。其中之一是尽早测试，它关注于：

• 编写测试用例以表达系统的行为。

• 尽早预防、检测和消除缺陷。

• 确保在正确的时间、正确的测试级别运行正确的测试类型。

在我们讨论的所有敏捷方法中，敏捷测试本身就是一种方法。在所有方法中，测试用例都在编码之前编写。

在本教程中，我们将重点关注Scrum作为敏捷测试方法。

其他常用的敏捷测试方法包括：

• 测试驱动开发 (TDD) - 测试驱动开发 (TDD) 基于由测试引导的编码。

• 验收测试驱动开发 (ATDD) - 验收测试驱动开发 (ATDD) 基于客户、开发人员和测试人员之间的沟通，并由预定义的验收标准和验收测试用例驱动。

• 行为驱动开发 (BDD) - 在行为驱动开发 (BDD) 中，测试基于被开发软件的预期行为。

敏捷测试生命周期

在 Scrum 中，测试活动包括：

• 根据系统预期行为（以测试用例的形式描述）贡献用户故事

• 基于测试工作量和缺陷的发布计划

• 基于用户故事和缺陷的冲刺计划

• 持续测试的冲刺执行

• 冲刺完成后进行回归测试

• 报告测试结果

• 自动化测试

测试是迭代的，并且基于冲刺，如下图所示：

敏捷测试 - 团队中的测试人员

敏捷开发以团队为中心，开发人员和测试人员参与所有项目和开发活动。团队合作最大限度地提高了敏捷项目测试的成功率。

敏捷团队中的测试人员必须参与并贡献所有项目活动，同时必须充分利用其测试专业知识。

敏捷测试人员应该具备传统的测试技能。此外，敏捷测试人员还需要：

• 良好的沟通技巧。

• 能够积极主动地与团队成员和利益相关者一起解决问题。

• 能够对产品进行批判性、面向质量、怀疑性的思考。

• 积极主动地从利益相关者那里获取信息的能力。

• 与客户和利益相关者有效合作，定义可测试的用户故事和验收标准的技能。

• 与开发人员一起编写高质量代码，成为优秀团队成员的能力。

• 能够在冲刺时间内使用测试技能，在正确的时间和级别拥有正确的测试用例并有效地执行它们。

• 评估和报告测试结果、测试进度和产品质量的能力。

• 能够快速响应变化，包括更改、添加或改进测试用例。

• 能够进行自我组织工作。

• 对持续技能提升的热情。

• 胜任自动化测试、测试驱动开发 (TDD)、验收测试驱动开发 (ATDD)、行为驱动开发 (BDD) 和基于经验的测试。

敏捷团队中测试人员的角色

敏捷团队中的测试人员参与所有项目和开发活动，以贡献最佳的测试专业知识。

敏捷测试人员的活动包括：

• 确保正确使用测试工具。

• 配置、使用和管理测试环境和测试数据。

• 指导团队成员在测试相关方面的技能。

• 确保在发布和冲刺计划期间安排适当的测试任务。

• 理解、实施和更新测试策略。

• 与开发人员、客户和利益相关者合作，从可测试性、一致性和完整性方面阐明需求。

• 在正确的时间和正确的测试级别执行正确的测试。

• 报告缺陷并与团队合作解决缺陷。

• 衡量和报告所有适用覆盖率维度的测试覆盖率。

• 参与冲刺回顾，主动提出和实施改进。

在敏捷生命周期中，测试人员在以下方面发挥着重要作用：

• 团队合作
• 测试计划
• 零冲刺
• 集成
• 敏捷测试实践

团队合作

在敏捷开发中，团队合作是基础，因此需要以下几点：

• 协作方法 - 与跨职能团队成员一起进行测试策略、测试计划、测试规范、测试执行、测试评估和测试结果报告。结合其他团队活动贡献测试专业知识。

• 自我组织 - 在冲刺中进行良好的计划和组织，通过整合其他团队成员的专业知识来实现测试目标。

• 授权 - 在实现团队目标方面做出适当的技术决策。

• 承诺 - 承诺理解和评估客户和利益相关者所需的产品行为和特性。

• 透明 - 开放、沟通和负责。

• 信誉 - 确保测试策略及其实施和执行的信誉。使客户和利益相关者了解测试策略。

• 乐于接受反馈 - 参与冲刺回顾，从成功和失败中学习。寻求客户反馈，并迅速采取适当行动以确保高质量的交付成果。

• 有韧性 - 对变化做出响应。

测试计划

测试计划应在发布计划期间开始，并在每个冲刺期间更新。测试计划应涵盖以下任务：

• 定义测试范围、测试程度、测试和冲刺目标。

• 确定测试环境、测试工具、测试数据和配置。

• 分配功能和特性的测试。

• 安排测试任务并定义测试频率。

• 确定测试方法、技术、工具和测试数据。

• 确定先决条件，例如前置任务、专业知识和培训。

• 确定依赖关系，例如功能、代码、系统组件、供应商、技术、工具、活动、任务、团队、测试类型、测试级别和约束。

• 考虑客户/用户重要性和依赖关系来设置优先级。

• 确定测试所需的时间和工作量。

• 确定每个冲刺计划中的任务。

零冲刺

零冲刺涉及第一个冲刺之前的准备活动。测试人员需要与团队合作完成以下活动：

• 确定范围
• 将用户故事细分为冲刺
• 创建系统架构
• 计划、获取和安装工具（包括测试工具）
• 为所有测试级别创建初始测试策略
• 定义测试指标
• 指定验收标准，也称为“完成”的定义
• 定义退出标准
• 创建Scrum看板
• 设定整个冲刺中测试的方向

集成

在敏捷方法中，高质量的工作产品应该在开发生命周期的任何时间点准备好发布。这意味着持续集成是开发的一部分。敏捷测试人员需要通过持续测试来支持持续集成。

为此，测试人员需要：

• 了解集成策略。
• 识别功能和特性之间的所有依赖关系。

敏捷测试实践

敏捷测试人员需要为敏捷项目中的测试采用敏捷实践。

• 结对编程 - 两名团队成员在同一键盘上一起工作。当其中一人进行测试时，另一人进行审查/分析测试。这两名团队成员可以是：

  • 一名测试人员和一名开发人员

  • 一名测试人员和一名业务分析师

  • 两名测试人员

• 增量测试设计 - 测试用例是从用户故事构建的，从简单的测试开始，然后转向更复杂的测试。

• 思维导图 - 思维导图是一种以图形方式组织信息的图表。思维导图可以用作敏捷测试中的有效工具，可以使用它来组织有关必要测试会话、测试策略和测试数据的相关信息。

敏捷测试 - 活动跟踪

测试状态可以通过以下方式进行沟通：

• 在每日站会期间
• 使用标准的测试管理工具
• 通过即时通讯工具

由测试通过状态确定的测试状态对于决定任务是否“完成”至关重要。“完成”意味着任务的所有测试都通过了。

测试进度

测试进度可以使用以下方式跟踪：

• Scrum看板（敏捷任务看板）
• 燃尽图
• 自动化测试结果

测试进度也直接影响开发进度。这是因为只有在达到验收标准后，用户故事才能被移至完成状态。反过来，这由测试状态决定，因为验收标准是由测试状态来判断的。

如果测试进度有任何延误或阻塞，整个团队将一起讨论并协作解决。

在敏捷项目中，变化经常发生。当发生许多变化时，我们可以预期测试状态、测试进度和产品质量会不断发展。敏捷测试人员需要将这些信息提供给团队，以便能够在正确的时间做出适当的决策，以保持每个迭代的成功完成。

当发生变化时，它们可能会影响先前迭代中的现有功能。在这种情况下，必须更新手动和自动化测试，以有效地应对回归风险。还需要进行回归测试。

产品质量

产品质量指标包括：

• 测试通过/失败
• 发现/修复的缺陷
• 测试覆盖率
• 测试通过/失败率
• 缺陷发现率
• 缺陷密度

自动化收集和报告产品质量指标有助于：

• 保持透明度。
• 在正确的时间收集所有相关和必需的指标。
• 无需沟通延迟即可立即报告。
• 允许测试人员专注于测试。
• 过滤指标的滥用。

为了确保整体产品质量，敏捷团队需要获得客户反馈，以了解产品是否满足客户期望。这需要在每个迭代结束时进行，反馈将作为后续迭代的输入。

关键成功因素

在敏捷项目中，如果敏捷测试成功，就可以交付高质量的产品。

敏捷测试的成功需要考虑以下几点：

• 敏捷测试基于测试优先和持续测试方法。因此，基于测试后方法构建的传统测试工具可能不适用。因此，在敏捷项目中选择测试工具时，需要验证其与敏捷测试的一致性。

• 通过在开发生命周期的早期自动化测试来减少总测试时间。

• 敏捷测试人员需要保持其速度以适应开发发布计划。因此，需要根据产品质量目标，动态地进行测试活动的适当计划、跟踪和重新计划。

• 在项目中，手动测试占测试的 80%。因此，需要经验丰富的测试人员加入敏捷团队。

• 这些经验丰富的测试人员在整个开发生命周期中的参与使整个团队专注于满足客户期望的优质产品。

  • 定义强调最终用户预期产品行为的用户故事。

  • 根据客户期望，在用户故事级别/任务级别确定验收标准。

  • 测试活动的工时和时间估算。

  • 计划测试活动。

  • 与开发团队协同工作，确保在前期测试设计的基础上产出符合需求的代码。

  • 测试先行并持续测试，确保在预期时间内达到完成状态并满足验收标准。

  • 确保在冲刺（Sprint）中的所有级别进行测试。

  • 每个冲刺结束时进行回归测试。

  • 收集和分析对项目成功有用的产品指标。

  • 分析缺陷，确定哪些需要在本冲刺修复，哪些可以推迟到后续冲刺。

  • 关注从客户角度来看什么才是重要的。

Lisa Crispin 已经定义了敏捷测试成功的七个关键因素：

• **全团队参与**——在这种方法中，开发人员培训测试人员，测试人员培训其他团队成员。这有助于每个人理解项目中的每个任务，从而使协作和贡献获得最大收益。测试人员与客户的协作也是一个重要因素，以便在开始时就正确设定他们的期望，并将验收标准转化为测试通过所需的标准。

• **敏捷测试思维**——测试人员积极主动地持续改进质量，并与团队其他成员持续协作。

• **自动化回归测试**——设计可测试性，并通过测试驱动开发。从简单开始，允许团队选择工具。准备好提供建议。

• **提供和获取反馈**——由于这是敏捷的核心价值观，整个团队都应该开放反馈。由于测试人员是专业的反馈提供者，因此需要关注相关和必要的信息。反过来，在获得反馈后，应适应测试用例的更改和测试。

• **建立核心敏捷实践的基础**——关注与编码并行的测试、持续集成、协作测试环境、增量工作、接受更改、保持协同。

• **与客户协作**——引出示例、理解和检查需求映射到产品行为，设置验收标准，获取反馈。

• **着眼大局**——使用真实世界的测试数据，通过面向业务的测试和示例驱动开发，并考虑对其他领域的影响。

敏捷测试 - 重要属性

本章，我们将了解敏捷测试的一些重要属性。

敏捷测试的益处

敏捷测试的益处包括：

• 通过快速、持续、完全测试的产品以及寻求客户反馈来提高客户满意度。

• 客户、开发人员和测试人员持续互动，从而缩短周期时间。

• 敏捷测试人员参与定义需求，贡献他们的测试专业知识，重点关注可行性。

• 敏捷测试人员参与评估测试工作量和时间的估算。

• 反映验收标准的早期测试设计。

• 整个团队整合测试需求，避免缺点。

• 整个团队持续关注产品质量。

• “完成”状态的定义反映了测试通过，确保满足需求。

• 持续反馈延迟或阻塞，以便能够立即解决，并付出整个团队的努力。

• 快速响应不断变化的需求并尽快适应它们。

• 持续集成驱动的回归测试。

• 开发和测试之间没有时间延迟。遵循测试先行、持续测试的方法。

• 在开发生命周期的早期实施自动化测试，从而减少总测试时间和工作量。

敏捷测试最佳实践

遵循以下最佳实践：

• 包含在所有级别具有各种测试类型专业知识的测试人员。

• 测试人员参与需求定义，与客户协作确定产品的预期行为。

• 测试人员持续与开发人员和客户共享反馈。

• 测试先行和持续测试方法与开发工作保持一致。

• 及时且持续地跟踪测试状态和测试进度，重点关注交付高质量产品。

• 在开发生命周期的早期进行自动化测试以缩短周期时间。

• 利用自动化测试作为一种有效的方法来执行回归测试。

敏捷测试中的挑战

敏捷测试中存在以下挑战：

• 业务和管理人员未能理解敏捷方法及其局限性，可能导致期望无法实现。

• 敏捷遵循全团队参与的方法，但并非每个人都了解测试实践的基本知识。建议测试人员指导其他人，但在实际情况下，由于冲刺（迭代）的时间限制，这可能难以实现。

• 测试先行方法要求开发人员基于测试人员的反馈进行编码，但在实际情况下，开发人员更习惯于基于来自客户或业务的需求进行编码。

• 高质量产品的责任在于整个敏捷团队，但在初始阶段，开发人员可能不会关注质量，因为他们更专注于实施。

• 持续集成需要回归测试，即使需要自动化，这也需要相当大的工作量。

• 测试人员可以适应敏捷思维模式下的变化，但适应由此产生的测试更改和测试，在冲刺期间难以实现目标。

• 建议尽早进行自动化，以便减少手动测试的工作量和时间。但是，在实际情况下，确定可以自动化的测试并对其进行自动化需要时间和精力。

敏捷测试指南

执行敏捷测试时，请使用以下指南：

• 参与发布计划，以确定所需的测试活动并制定测试计划的初始版本。

• 参与估算会议，以确定测试工作量和持续时间，以便在迭代中容纳测试活动。

• 参与用户故事定义，以确定验收测试用例。

• 参与每次冲刺计划会议，以了解范围并更新测试计划。

• 在冲刺期间持续与开发团队协作，使测试和编码能够在冲刺内顺利完成。

• 参与每日站会，并传达任何测试延迟或阻塞，以便立即得到解决。

• 定期跟踪和报告测试状态、测试进度和产品质量。

• 准备好适应变化，并相应地修改测试用例和测试数据。

• 参与冲刺回顾，以了解和贡献最佳实践和经验教训。

• 协作获取每个冲刺的客户反馈。

敏捷测试 - 四象限

与传统测试一样，敏捷测试也需要涵盖所有测试级别。

• 单元测试
• 集成测试
• 系统测试
• 用户验收测试

单元测试

• 与编码同时进行，由开发人员完成
• 由编写测试用例并确保 100% 设计覆盖率的测试人员支持
• 需要审查单元测试用例和单元测试结果
• 未解决的主要缺陷（根据优先级和严重性）不会遗留
• 所有单元测试都已自动化

集成测试

• 随着冲刺的进展，与持续集成同时进行
• 在所有冲刺完成后进行
• 所有功能需求都经过测试
• 所有单元之间的接口都经过测试
• 所有缺陷都已报告
• 尽可能自动化测试

系统测试

• 随着开发的进展而进行
• 测试用户故事、功能和特性
• 在生产环境中进行测试
• 执行质量测试（性能、可靠性等）
• 报告缺陷
• 尽可能自动化测试

用户验收测试

• 在每个冲刺结束时和项目结束时进行

• 由客户完成。团队会收集反馈

• 反馈将作为后续冲刺的输入

• 冲刺中的用户故事已预先验证为可测试的，并具有已定义的验收标准

测试类型

• 组件测试（单元测试）
• 功能测试（用户故事测试）
• 非功能测试（性能、负载、压力等）
• 验收测试

测试可以是完全手动的、完全自动化的、手动和自动化的组合或由工具支持的手动测试。

支持编程和评论产品测试

测试可以用于：

• **支持开发（支持编程）**——支持编程测试由程序员使用。

  • 决定他们需要编写哪些代码来实现系统的特定行为

  • 编码后需要运行哪些测试才能确保新代码不会影响系统的其余行为

• **仅验证（评论产品）**——评论产品测试用于发现成品中的不足之处

面向业务和面向技术的测试

要决定何时执行哪些测试，您需要确定测试是：

• 面向业务的，或者
• 面向技术的

面向业务的测试

如果测试能够回答用业务领域词汇构成的疑问，则该测试是面向业务的测试。业务专家能够理解这些测试，并且这些测试会引起他们的兴趣，以便能够在实时场景中解释系统的行为。

面向技术的测试

如果测试能够回答用技术领域词汇构成的疑问，则该测试是面向技术的测试。程序员根据技术方面的说明来了解需要实现的内容。

可以使用 Brian Marick 定义的敏捷测试象限来查看测试类型的这两个方面。

敏捷测试象限

结合测试类型的两个方面，Brian Marick 得出了以下敏捷测试象限：

敏捷测试象限提供了一个有用的分类法，可以帮助团队识别、计划和执行所需的测试。

• **象限 Q1**——单元级别、面向技术，并支持开发人员。单元测试属于此象限。这些测试可以是自动化测试。

• **象限 Q2**——系统级别、面向业务，并符合产品行为。功能测试属于此象限。这些测试是手动或自动的。

• **象限 Q3**——系统或用户验收级别、面向业务，并关注实时场景。用户验收测试属于此象限。这些测试是手动的。

• **象限 Q4**——系统或运营验收级别、面向技术，并关注性能、负载、压力、可维护性、可扩展性测试。可以使用一些专用工具以及自动化测试来进行这些测试。

结合这些，可以将反映**什么测试——何时测试**的敏捷测试象限可视化如下：

敏捷测试 - Scrum

Scrum 提倡**全员参与的团队方法**，即每个团队成员都必须参与每个项目的活动。Scrum 团队是自组织的，对项目交付成果负责。决策权交给团队，从而能够在适当的时间采取适当的行动，避免任何时间延误。这种方法还鼓励充分利用团队人才，而不是将其限制在单一活动中。测试人员也参与所有项目和开发活动，贡献他们在测试方面的专业知识。

整个团队共同参与测试策略、测试计划、测试规范、测试执行、测试评估和测试结果报告。

协作的用户故事创建

测试人员参与用户故事创建。测试人员贡献他们对系统可能行为的想法。这有助于客户和/或最终用户了解真实环境中的系统，从而明确他们实际想要的结果。这导致更快地确定需求，并降低后期需求变更的可能性。

测试人员还会提出每个场景的验收标准，并与客户达成一致。

测试人员有助于创建可测试的用户故事。

发布计划

整个项目都会进行发布计划。但是，Scrum 框架涉及在执行冲刺的过程中获得更多信息时的迭代决策。因此，项目开始时的发布计划会议不必生成整个项目的详细发布计划。它可以随着相关信息的可用性而不断更新。

并非每个冲刺结束都需要发布。发布可以在一组冲刺之后进行。发布的主要标准是为客户提供业务价值。团队根据发布计划作为输入来决定冲刺长度。

发布计划是发布测试方法和测试计划的基础。测试人员评估测试工作量并计划发布测试。当发布计划发生变化时，测试人员必须处理这些变化，并考虑到发布的更大范围，获得充分的测试基础。测试人员还提供所有冲刺结束后所需的测试工作量。

冲刺计划

冲刺计划在每个冲刺开始时进行。冲刺待办事项列表是从产品待办事项列表中挑选出来，用于在特定冲刺中实施的用户故事。

测试人员应该：

• 确定为冲刺选择的用户的可测试性
• 创建验收测试
• 定义测试级别
• 确定测试自动化

测试人员使用冲刺中测试工作量和持续时间的估算值更新测试计划。这确保了在限时冲刺期间为所需的测试提供时间，并保证了测试工作的责任性。

测试分析

冲刺开始时，当开发人员进行设计和实现的故事分析时，测试人员会对冲刺待办事项列表中的故事进行测试分析。测试人员创建所需的测试用例——手动测试和自动化测试。

测试

Scrum 团队的所有成员都应参与测试。

• 开发人员在为用户故事开发代码时执行单元测试。单元测试在编写代码之前，在每个冲刺中创建。单元测试用例源自低级别设计规范。

• 测试人员执行用户故事的功能和非功能特性。

• 测试人员指导 Scrum 团队中的其他成员，发挥他们在测试方面的专业知识，以便整个团队对产品的质量承担集体责任。

• 冲刺结束时，客户和/或最终用户进行用户验收测试并向 Scrum 团队提供反馈。这将作为下一个冲刺的输入。

• 收集和维护测试结果。

自动化测试

在 Scrum 团队中，自动化测试非常重要。测试人员投入时间创建、执行、监控和维护自动化测试和结果。由于 Scrum 项目中随时可能发生变化，测试人员需要适应对已更改功能的测试以及相关的回归测试。自动化测试有助于管理与更改相关的测试工作量。所有级别的自动化测试有助于实现持续集成。自动化测试比手动测试快得多，而且无需额外的工作量。

手动测试更侧重于探索性测试、产品漏洞和缺陷预测。

测试活动的自动化

测试活动的自动化减少了重复工作的负担，并降低了成本。自动化

• 测试数据生成
• 测试数据加载
• 将构建部署到测试环境
• 测试环境管理
• 数据输出比较

回归测试

在一个冲刺中，测试人员测试该冲刺中新增/修改的代码。但是，测试人员还需要确保在早期冲刺中开发和测试的代码也能与新代码一起工作。因此，回归测试在 Scrum 中非常重要。自动化回归测试在持续集成中运行。

配置管理

Scrum 项目中使用使用自动化构建和测试框架的配置管理系统。这允许在将新代码检入配置管理系统时重复运行静态分析和单元测试。它还管理新代码与系统的持续集成。自动化回归测试在持续集成期间运行。

需要对手动测试用例、自动化测试、测试数据、测试计划、测试策略和其他测试工件进行版本控制，并确保相关的访问权限。这可以通过在配置管理系统中维护测试工件来实现。

敏捷测试实践

Scrum 团队中的测试人员可以遵循以下敏捷实践：

• **结对编程**——两名团队成员坐在一起协作工作。这两个人可以是两名测试人员，也可以是一名测试人员和一名开发人员。

• **增量测试设计**——随着冲刺的进行和用户故事的增加，测试用例也逐步开发。

敏捷指标

在软件开发过程中，指标的收集和分析有助于改进流程，从而实现更高的生产力、高质量的交付成果和客户满意度。在基于 Scrum 的开发中，这是可能的，测试人员必须关注他们需要的指标。

建议了几种 Scrum 开发指标。重要的指标包括：

• **成功冲刺比率**——**（成功冲刺次数 / 总冲刺次数）* 100**。成功冲刺是指团队能够完成其承诺的冲刺。

• **速度**——团队的速度基于团队在一个冲刺中获得的故事点数。故事点是在估计期间计算的用户故事的度量。

• **专注系数**——**（速度 / 团队工作能力）/ 100**。专注系数是团队工作量中导致完成故事的百分比。

• **估计准确性**——**（估计工作量 / 实际工作量）/ 100**。估计准确性是团队准确估计工作量的能力。

• **冲刺燃尽图**——剩余工作量（以故事点或小时为单位）与理想情况下应剩余的工作量（根据估计）。

  • 如果更多，则意味着团队承担的工作量超过了他们的能力。

  • 如果更少，则意味着团队没有准确地进行估计。

• **缺陷数量**——冲刺中的缺陷数量。缺陷数量是指软件中相对于待办事项的缺陷数量。

• **缺陷严重程度**——根据严重程度，缺陷可以分为轻微、主要和严重。测试人员可以定义分类。

冲刺回顾

在冲刺回顾中，所有团队成员都将参与。他们分享：

• 进展顺利的事情
• 指标
• 改进的空间
• 要应用的行动项

敏捷测试 - 方法

在敏捷测试中，常用的测试方法来自传统实践，并符合“尽早测试”的原则。测试用例是在编写代码之前编写的。重点是缺陷的预防、检测和消除，在正确的时间和正确级别运行正确的测试类型。

在本节中，您将了解以下方法：

• 测试驱动开发 (TDD)
• 验收测试驱动开发 (ATDD)
• 行为驱动开发 (BDD)

测试驱动开发

在测试驱动开发 (TDD) 方法中，代码的开发基于自动化测试用例引导的测试优先方法。首先编写一个测试用例使其失败，然后根据该测试用例开发代码以确保测试通过。重复该方法，通过代码开发进行重构。

可以通过以下步骤了解 TDD：

• **步骤 1**——编写一个测试用例来反映需要编写的代码的功能的预期行为。

• **步骤 2**——运行测试。由于代码尚未开发，测试将失败。

• **步骤 3**——根据测试用例开发代码。

• **步骤 4**——再次运行测试。这次，测试必须通过，因为功能已编码。重复步骤 (3) 和步骤 (4)，直到测试通过。

• **步骤 5**——重构代码。

• **步骤 6**——再次运行测试以确保其通过。

重复**步骤 1 - 步骤 6**，添加测试用例以添加功能。每次都会运行添加的测试和之前的测试，以确保代码按预期运行。为了使此过程加快，测试是自动化的。

测试可以在单元、集成或系统级别进行。需要确保测试人员和开发人员之间持续沟通。

验收测试驱动开发

在验收测试驱动开发 (ATDD) 方法中，代码的开发基于验收测试用例引导的测试优先方法。重点是验收标准以及测试人员在与客户、最终用户和相关利益相关者协作创建用户故事期间编写的验收测试用例。

• **步骤 1**——与客户和用户协作，编写用户故事的验收测试用例。

• **步骤 2**——定义相关的验收标准。

• **步骤 3**——根据验收测试和验收标准开发代码。

• **步骤 4**——运行验收测试以确保代码按预期运行。

• **步骤 5**——自动化验收测试。重复**步骤 3 - 步骤 5**，直到迭代中的所有用户故事都已实现。

• **步骤 6**——自动化回归测试。

• **步骤 7**——运行自动化回归测试以确保持续回归。

行为驱动开发 (BDD)

行为驱动开发 (BDD) 类似于测试驱动开发 (TDD)，重点是测试代码以确保系统的预期行为。

在 BDD 中，使用英语等语言，以便对用户、测试人员和开发人员有意义。它确保：

• 用户、测试人员和开发人员之间持续沟通。
• 开发和测试内容的透明度。

敏捷测试 - 技术

传统测试的技术也可以应用于敏捷测试。此外，敏捷项目中还会使用敏捷特有的测试技术和术语。

测试依据

在敏捷项目中，产品待办事项取代了需求规格说明文档。产品待办事项的内容通常是用户故事。非功能性需求也在用户故事中得到处理。因此，敏捷项目中的测试依据是用户故事。

为了确保高质量测试，还可以额外考虑以下内容作为测试依据：

• 相同项目或过去项目的先前迭代经验。
• 系统现有的功能、架构、设计、代码和质量特性。
• 当前和过去项目的缺陷数据。
• 客户反馈。
• 用户文档。

完成定义 (DoD)

完成定义 (DoD) 是敏捷项目中用于确保冲刺待办事项中活动完成的标准。DoD 在不同的 Scrum 团队之间可能有所不同，但在同一个团队内应保持一致。

DoD 是必要的活动清单，它确保了用户故事中功能和特性的实现，以及作为用户故事一部分的非功能性需求。在完成 DoD 清单中的所有项目后，用户故事达到“完成”阶段。DoD 在团队中共享。

用户故事的典型 DoD 可以包含：

• 详细的可测试验收标准
• 确保用户故事与迭代中其他用户故事一致的标准
• 与产品相关的特定标准
• 功能行为方面
• 非功能特性
• 接口
• 测试数据需求
• 测试覆盖率
• 重构
• 审查和批准要求

除了用户故事的 DoD 之外，DoD 还需要：

• 在每个测试级别
• 对于每个特性
• 对于每次迭代
• 对于发布

测试信息

测试人员需要具备以下测试信息：

• 需要测试的用户故事
• 相关的验收标准
• 系统接口
• 系统预期工作的环境
• 工具可用性
• 测试覆盖率
• DoD

在敏捷项目中，由于测试不是一个顺序活动，并且测试人员应该以协作模式工作，因此测试人员有责任：

• 持续获取必要的测试信息。
• 识别影响测试的信息差距。
• 与其他团队成员协作解决差距。
• 确定达到测试级别的时间。
• 确保在相关时间执行适当的测试。

功能和非功能测试设计

在敏捷项目中，可以使用传统的测试技术，但重点是尽早测试。测试用例需要在实现开始之前就到位。

对于功能测试设计，测试人员和开发人员可以使用传统的黑盒测试设计技术，例如：

• 等价划分
• 边界值分析
• 决策表
• 状态转换
• 类树

对于非功能测试设计，由于非功能性需求也是每个用户故事的一部分，因此只能使用黑盒测试设计技术来设计相关的测试用例。

探索式测试

在敏捷项目中，时间往往是测试分析和测试设计的限制因素。在这种情况下，可以将探索式测试技术与传统的测试技术结合起来。

探索式测试 (ET) 定义为同时进行学习、测试设计和测试执行。在探索式测试中，测试人员积极控制测试的设计，并在执行测试时使用获得的信息来设计新的和更好的测试。

探索式测试有助于适应敏捷项目中的变化。

基于风险的测试

基于风险的测试是基于失败风险的测试，并使用测试设计技术来降低风险。

产品质量风险可以定义为产品质量的潜在问题。产品质量风险包括：

• 功能风险
• 非功能性能风险
• 非功能可用性风险

需要进行风险分析以评估每个风险的概率（可能性）和影响。然后，对风险进行优先级排序：

• 高风险需要广泛的测试
• 低风险只需要粗略测试

根据每个风险的风险级别和风险特征，使用适当的测试技术设计测试。然后执行测试以降低风险。

Fit 测试

Fit 测试是自动化的验收测试。可以使用 Fit 和 FitNesse 工具来自动化验收测试。

FIT 使用 JUnit，但扩展了测试功能。HTML 表格用于显示测试用例。Fixture 是 HTML 表格背后的 Java 类。Fixture 获取 HTML 表格的内容并在被测项目上运行测试用例。

敏捷测试 - 工作产品

测试计划在发布计划时准备，并在每次冲刺计划时进行修订。测试计划作为测试过程的指南，以便获得完整的测试覆盖率。

测试计划的典型内容包括：

• 测试策略
• 测试环境
• 测试覆盖率
• 测试范围
• 测试工作量和进度安排
• 测试工具

在敏捷项目中，所有团队成员都对产品的质量负责。因此，每个人都参与测试计划。

测试人员的责任是提供必要的指导，并利用其测试专业知识指导团队其他成员。

用户故事

原则上，用户故事不是测试工作产品。但是，在敏捷项目中，测试人员参与用户故事的创建。测试人员编写为客户带来价值并涵盖系统不同可能行为的用户故事。

测试人员还确保所有用户故事都是可测试的，并确保验收标准。

手动和自动化测试

在第一次测试运行中，使用手动测试。它们包括：

• 单元测试
• 集成测试
• 功能测试
• 非功能测试
• 验收测试

然后自动执行后续运行的测试。

在**测试驱动开发 (TDD)** 中，首先编写单元测试使其失败，然后开发和测试代码以确保测试通过。

在**验收测试驱动开发 (ATDD)** 中，首先编写验收测试使其失败，然后开发和测试代码以确保测试通过。

在其他开发方法中，测试人员与团队其他成员协作以确保测试覆盖率。

在所有类型的过程中，都会进行持续集成，其中包括持续集成测试。

团队可以决定何时以及自动化哪些测试。即使自动化测试需要付出努力和时间，生成的自动化测试也会显著减少敏捷项目迭代期间重复的测试工作量和时间。这反过来又促使团队更多地关注其他所需活动，例如新的用户故事、更改等。

在**Scrum** 中，迭代的时间是固定的。因此，如果某个用户故事测试在特定冲刺中无法完成，测试人员可以在每日站会中报告该用户故事无法在该冲刺中达到“完成”状态，因此需要推迟到下一个冲刺。

测试结果

由于敏捷项目中的大部分测试都是自动化的，因此工具会生成必要的测试结果日志。测试人员会检查测试结果日志。需要为每个冲刺/发布维护测试结果。

还可以准备测试摘要，其中包含：

• 测试范围（测试的内容和未测试的内容）
• 缺陷分析，如果可能的话，还要进行根本原因分析
• 缺陷修复后的回归测试状态
• 问题及相应的解决方案
• 如有任何待处理问题
• 测试策略中需要进行的任何修改
• 测试指标

测试指标报告

在敏捷项目中，测试指标包括每个冲刺的以下内容：

• 测试工作量
• 测试估计准确性
• 测试覆盖率
• 自动化测试覆盖率
• 缺陷数量
• 缺陷率（每个用户故事点的缺陷数量）
• 缺陷严重性
• 在同一冲刺中修复缺陷所需的时间（在当前冲刺中逃脱的错误修复成本是其 24 倍）
• 在同一冲刺中修复的缺陷数量
• 客户在冲刺内完成验收测试

冲刺回顾和总结报告

测试人员还参与冲刺回顾和总结报告。典型内容包括：

• 测试指标
• 测试结果日志审查结果
• 从测试角度来看，哪些方面做得很好，哪些方面可以改进
• 最佳实践
• 经验教训
• 问题
• 客户反馈

敏捷测试 - Kanban

可以使用看板概念有效地管理敏捷测试活动。以下内容确保测试在迭代/冲刺内按时完成，从而专注于交付高质量的产品。

• 可测试且大小合适的用户故事能够在规定的时间限制内完成开发和测试。

• 在制品 (WIP) 限制允许一次专注于有限数量的用户故事。

• 直观显示工作流程的看板，有助于跟踪测试活动和瓶颈（如有）。

• 看板团队协作理念允许在发现瓶颈时立即解决，无需等待。

• 提前准备测试用例，在开发过程中维护测试套件并获取客户反馈有助于在迭代/冲刺内消除缺陷。

• 完成定义 (DoD) 被认为是“真正完成”，这意味着只有在测试完成之后，故事才达到完成状态。

产品开发中的测试活动

在产品开发中，可以使用功能看板来跟踪发布。特定发布的功能被分配到功能看板，该看板直观地跟踪功能开发状态。

发布中的功能被分解成故事，并使用敏捷方法在发布中进行开发。

以下敏捷测试活动确保每次发布以及所有发布结束时的质量交付：

• 测试人员参与用户故事创建，从而确保：

  • 通过用户故事和作为用户故事一部分的非功能性需求来捕获系统的所有可能行为。

  • 用户故事是可测试的。

  • 用户故事的大小允许在迭代内完成开发和测试（真正完成）。

• 可视化任务看板：

  • 描述任务的状态和进度

  • 在出现瓶颈时立即识别

  • 有助于衡量循环时间，然后可以对其进行优化

• 团队协作有助于：

  • 整个团队对高质量产品的责任

  • 在出现瓶颈时立即解决，节省等待时间

  • 所有活动中每项专业技能的贡献

• 专注于持续集成测试的持续集成

• 自动化测试以节省测试工作量和时间

• 缺陷预防，提前编写测试用例进行开发，并指导开发人员了解系统不同行为的预期：

  • WIP 限制，一次专注于有限数量的用户故事

• 在开发过程中进行持续测试，以确保在迭代中修复缺陷：

  • 确保测试覆盖率

  • 保持未解决缺陷数量较低

故事探索

故事探索是在敏捷团队内部进行的沟通，用于在产品负责人提交故事以供开发验收时探索对故事的理解。

产品负责人根据系统预期的功能提出故事。开发人员在标记故事为准备验收之前，会对每个故事进行更多探索。测试人员也会从测试的角度参与沟通，使其尽可能易于测试。

故事的最终确定是基于产品负责人、开发人员和测试人员之间持续不断的沟通。

估算

估算发生在发布计划和每次迭代计划中。

在发布计划中，测试人员提供：

• 所需测试活动的信息
• 相应的努力估算

在迭代计划中，测试人员有助于确定在一个迭代中可以包含哪些和多少个故事。该决定取决于测试工作量和测试进度估算。故事估算也反映了测试估算。

在看板中，只有当故事被开发和测试并标记为无缺陷完成时，才能完成“完成完成”状态。

因此，测试估算在故事估算中扮演着重要角色。

故事计划

故事计划在故事被估算并分配到当前迭代之后开始。

故事计划包括以下测试任务：

• 准备测试数据
• 扩展验收测试
• 执行手动测试
• 进行探索性测试
• 自动化持续集成测试

除了这些测试任务外，可能还需要其他任务，例如：

• 性能测试
• 回归测试
• 相关持续集成测试的更新

故事进展

故事进展揭示了开发人员和测试人员之间持续沟通所导致的额外测试需求。在开发人员需要更多实施说明的情况下，测试人员会进行探索性测试。

在故事进展期间进行持续测试，包括持续集成测试。整个团队都参与测试活动。

故事验收

当故事达到“完成完成”状态时，故事验收完成，即故事已开发和测试并标记为完成。

当与故事相关的所有测试通过或达到测试自动化水平时，则认为故事测试已完成。

敏捷测试 - 工具

在敏捷项目中，测试人员负责以下日常任务：

• 支持开发人员进行编码，并对系统的预期行为进行澄清。

• 帮助开发人员创建有效且高效的单元测试。

• 开发自动化脚本。

• 将自动化测试工具/脚本与持续集成集成，进行回归测试。

为了有效快速地执行这些任务，大多数敏捷项目都使用支持代码和测试组件持续集成的持续集成 (CI) 系统。

敏捷项目中的测试人员和开发人员可以受益于各种工具来管理测试会话以及创建和提交缺陷报告。除了专门用于敏捷测试的工具外，敏捷团队还可以受益于测试自动化和测试管理工具。

注意 - 记录和回放、测试最后、重量级和测试自动化解决方案并非敏捷的，因为：

• 此类工具鼓励的测试最后工作流程不适用于敏捷团队。

• 使用此类工具创建的难以维护的脚本会成为变更的障碍。

• 此类专用工具会产生对测试自动化专家的需求，从而形成信息孤岛。

广泛使用的工具包括：

敏捷测试自动化工具

有效的敏捷测试自动化工具支持：

• 使用测试优先方法进行早期测试自动化。

• 使用真实的语言和领域特定语言编写测试自动化代码。

• 关注系统的预期行为。

• 将测试的本质与实现细节分开，使其与技术无关。

• 促进协作。

自动化单元测试（使用Junit或NUnit）支持代码的测试优先方法。这些是白盒测试，确保设计合理且没有缺陷。此类测试由开发人员在测试人员的支持下构建，可以独立于所需的功能。这导致交付的产品可能无法满足客户需求，因此没有业务价值。

通过自动化验收测试来解决此问题，这些测试是在客户、其他利益相关者、测试人员和开发人员的协作下编写的。自动化验收测试由客户或产品负责人/业务分析师编写，反映产品的预期行为。开发人员的参与确保根据需求生成代码。但是，如果测试仅关注验收，则生成的代码可能仍然不可扩展。

因此，自动化单元测试和自动化验收测试是互补的，敏捷开发都需要两者。

支持自动化验收测试的敏捷工具和框架包括：

• Fit
• Fitnesse
• Concordion
• Ruby
• Cucumber

Fit

Ward Cunningham开发的Fit工具可用于验收测试自动化。Fit允许：

• 客户或产品负责人使用Microsoft Word和Microsoft Excel提供产品行为示例

• 程序员可以轻松地将这些示例转换为自动化测试。

Fit 1.1支持Java和.NET。

FitNesse

FitNesse是一个wiki，它是一种Web服务器样式，允许任何访问者进行任何编辑，包括更改现有页面和创建新页面。简单的标记语言使您可以轻松创建标题，使文本加粗、下划线和斜体，创建项目符号列表以及执行其他简单的格式设置。

在FitNesse中，验收测试自动化如下：

• 将测试表示为输入数据和预期输出数据的表格。

• 使用FitNesse将测试表放在您可以编辑的页面上。

  • 或者，将测试表放在Microsoft Excel中，复制到剪贴板，然后使用Spreadsheet to FitNesse命令让FitNesse正确格式化您的表格。

• 运行测试

• 您可以通过测试表中单元格的颜色编码来获得测试结果

  • 绿色单元格表示获得了预期值

  • 红色单元格表示获得的值与预期值不同

  • 黄色单元格表示抛出异常

Cucumber

Cucumber是一个基于行为驱动开发（BDD）框架的工具。主要功能包括：

• 用于编写Web应用程序的验收测试。

• 允许以易于阅读和理解的格式（如纯英语）自动化功能验证。

• 在Ruby中实现，然后扩展到Java框架。两者都支持Junit。

• 支持其他语言，如Perl、PHP、Python、.Net等。

• 可以与Selenium、Watir、Capybara等一起使用。