敏捷测试 - 快速指南

敏捷测试 - 概述

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

敏捷宣言

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

敏捷宣言是 -

我们通过实践并帮助他人开发软件，从而发现更好的软件开发方法。通过这项工作，我们认识到了价值 -

  • 个人以及流程和工具上的交互。
  • 工作软件胜过全面的文档。
  • 客户协作胜过合同谈判。
  • 响应变化而不是遵循计划。

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

什么是敏捷测试？

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

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

此外，随着测试人员与跨职能团队成员一起参与整个开发生命周期，测试人员将有可能根据客户要求构建软件，并提供更好的设计和代码。

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

敏捷测试与敏捷测试 瀑布测试

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

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

敏捷测试 瀑布测试
测试不是一个单独的阶段，而是与开发同时进行。 测试是一个单独的阶段。所有级别和类型的测试只有在开发完成后才能开始。
测试人员和开发人员一起工作。 测试人员与开发人员分开工作。
测试人员参与提出需求。这有助于将需求映射到现实世界场景中的Behave，并制定验收标准。此外，逻辑验收测试用例将与需求一起准备好。 测试人员可能不参与需求阶段。
每次迭代后都会进行验收测试并寻求客户反馈。 验收测试仅在项目结束时进行。
每次迭代都会完成自己的测试，从而允许每次发布新功能或逻辑时实施回归测试。 回归测试只有在开发完成后才能实施。
编码和测试之间没有时间延迟。 编码和测试之间通常存在时间延迟。
具有重叠测试级别的连续测试。 测试是一项定时活动，测试级别不能重叠。
测试是最佳实践。 测试常常被忽视。

敏捷测试原则

敏捷测试的原则是 -

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

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

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

  • 缩短反馈循环- 在敏捷测试中，业务团队了解每次迭代的产品开发。他们参与每一次迭代。持续的反馈缩短了反馈响应时间，因此修复它所涉及的成本更少。

  • 保持代码整洁- 缺陷在同一迭代中出现时得到修复。这可以确保在任何开发里程碑时都保持干净的代码。

  • 轻量级文档- 敏捷测试人员不是全面的测试文档 -

    • 使用可重复使用的清单来建议测试。

    • 关注测试的本质而不是附带的细节。

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

    • 在探索性测试的章程中捕获测试想法。

    • 利用文档实现多种目的。

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

  • “完成”，不仅仅是完成- 在敏捷中，据说某个功能不是在开发之后完成的，而是在开发和测试之后完成的。

  • 最后测试与测试驱动- 测试用例与需求一起编写。因此，开发可以通过测试来驱动。这种方法称为测试驱动开发（TDD）和验收测试驱动开发（ATDD）。这与瀑布测试的最后阶段的测试形成对比。

敏捷测试活动

项目级别的敏捷测试活动是 -

  • 发布计划（测试计划）

    • 对于每一次迭代，

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

  • 回归测试

  • 发布活动（测试相关）

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

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

敏捷测试 - 方法论

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

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

项目团队

持续集成、持续质量

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

在敏捷中，沟通是最重要的，并且在必要时接收客户的请求。这让客户感到满意，因为所有的输入都得到考虑，并且在整个开发过程中都可以获得工作质量的产品。

敏捷方法论

有多种支持敏捷开发的敏捷方法。敏捷方法论包括 -

Scrum

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

XP

极限编程以客户为中心，关注不断变化的需求。通过频繁的发布和客户反馈，最终产品的质量将满足客户在此过程中更加明确的要求。

水晶

Crystal以租船、循环交付和打包为基础。

  • 特许包括组建开发团队、进行初步可行性分析、达成初步计划和开发方法。

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

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

频分双工

功能驱动开发（FDD）涉及设计和构建功能。FDD与其他敏捷开发方法的区别在于，功能是在特定的、短的阶段中分别开发的。

DSDM

动态软件开发方法 (DSDM) 基于快速应用程序开发 (RAD) 并与敏捷框架保持一致。DSDM 专注于产品的频繁交付，让用户积极参与并授权团队快速做出决策。

精益软件开发

在精益软件开发中，重点是消除浪费并为客户提供价值。这会带来快速的发展和有价值的产品。

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

精益原则是 -

  • 消除浪费
  • 强化学习
  • 延迟承诺
  • 赋予团队权力
  • 快速交付
  • 建立诚信
  • 查看整体

看板

看板专注于管理工作，强调准时 (JIT) 交付，同时不会让团队成员超负荷。显示任务以供所有参与者查看，并供团队成员从队列中提取工作。

看板基于 -

  • 看板（整个开发过程中的视觉和持久性）
  • 在制品 (WIP) 限制
  • 交货时间

敏捷测试方法

每个项目（无论是否敏捷）都明确定义了测试实践，以交付高质量的产品。传统的测试原则在敏捷测试中经常使用。其中之一是早期测试，重点是 -

  • 编写测试用例来表达系统的Behave。

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

  • 确保正确的测试类型在正确的时间运行并作为正确测试级别的一部分。

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

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

其他常用的敏捷测试方法是 -

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

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

  • Behave驱动开发（BDD） - 在Behave驱动开发（BDD）中，测试基于正在开发的软件的预期Behave。

敏捷测试生命周期

在 Scrum 中，测试活动包括 -

  • 根据描述为测试用例的系统的预期Behave贡献用户故事

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

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

  • 持续测试的冲刺执行

  • Sprint 完成后的回归测试

  • 报告测试结果

  • 自动化测试

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

生命周期

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

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

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

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

  • 好的社交技能。

  • 能够与团队成员和利益相关者积极行动并以解决方案为导向。

  • 能够对产品表现出批判性的、以质量为导向的、怀疑性的思维。

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

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

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

  • 测试技能的可用性，以便在正确的时间和正确的级别获得正确的测试用例，并在冲刺期间很好地执行它们。

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

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

  • 自组织工作的潜力。

  • 对持续技能增长的热情。

  • 测试自动化、测试驱动开发 (TDD)、验收测试驱动开发 (ATDD)、Behave驱动开发 (BDD) 和基于经验的测试的能力。

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

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

敏捷测试人员活动包括 -

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

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

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

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

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

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

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

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

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

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

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

  • 团队合作
  • 测试计划
  • 冲刺零
  • 一体化
  • 敏捷测试实践

团队合作

在敏捷开发中，团队合作是基础，因此需要以下内容 -

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

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

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

  • 承诺- 致力于根据客户和利益相关者的要求理解和评估产品的Behave和特征。

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

  • 可信度- 确保测试策略、其实施和执行的可信度。让客户和利益相关者了解测试策略。

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

  • 弹性- 响应变化。

测试计划

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

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

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

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

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

  • 识别测试方法、技术、工具和测试数据。

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

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

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

  • 达到测试所需的时间和精力。

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

冲刺零

零冲刺涉及第一次冲刺之前的准备活动。测试人员需要与团队合作进行以下活动 -

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

一体化

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

为了实现这一点，测试人员需要 -

  • 了解整合策略。
  • 确定功能和特性之间的所有依赖关系。

敏捷测试实践

敏捷测试人员需要适应敏捷实践以在敏捷项目中进行测试。

  • 配对- 两个团队成员在同一个键盘上一起工作。当其中之一进行测试时，其他人审查/分析测试。两个团队成员可以是

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

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

    • 测试人员两名

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

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

敏捷测试 - 跟踪活动

可以传达测试状态 -

  • 在每日站立会议期间
  • 使用标准测试管理工具
  • 通过信使

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

测试进度

可以使用跟踪测试进度 -

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

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

如果测试进度出现任何延迟或阻塞，整个团队将进行讨论并协作解决问题。

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

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

产品质量

产品质量指标包括 -

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

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

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

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

关键成功因素

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

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

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

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

  • 敏捷测试人员需要保持节奏以适应开发发布时间表。因此，需要以产品质量为目标，动态地对测试活动进行适当的规划、跟踪和重新规划。

  • 手工测试占项目测试的80%。因此，具有专业知识的测试人员需要成为敏捷团队的一部分。

  • 这些具有专业知识的测试人员参与整个开发生命周期，使整个团队专注于满足客户期望的优质产品。

    • 定义强调最终用户期望的产品Behave的用户故事。

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

    • 测试活动的工作量和持续时间估计。

    • 规划测试活动。

    • 与开发团队合作，确保生成的代码符合预先测试设计的要求。

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

    • 确保冲刺中各个级别的测试。

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

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

    • 分析缺陷以确定哪些需要在当前 Sprint 中修复，哪些可以延迟到后续 Sprint。

    • 从客户的角度关注重要的事情。

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

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

  • 敏捷测试心态- 测试人员积极主动地不断提高质量并与团队其他成员不断合作。

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

  • 提供并获取反馈- 由于这是敏捷的核心价值，整个团队应该开放地接受反馈。由于测试人员是专家反馈提供者，需要关注相关和必要的信息。作为回报，在获得反馈时应适应测试用例的更改和测试。

  • 构建核心敏捷实践的基础- 专注于编码、持续集成、协作测试环境、增量工作、接受变更、保持协同作用的测试。

  • 与客户合作- 引出示例，理解并检查映射到产品Behave的需求，设置验收标准，获取反馈。

  • 查看大局- 使用真实世界的测试数据并考虑对其他领域的影响，通过面向业务的测试和示例来推动开发。

敏捷测试 - 重要属性

在本章中，我们将看到敏捷测试的一些重要属性。

敏捷测试的好处

敏捷测试的好处是 -

  • 通过快速、持续、全面测试产品并寻求客户反馈来满足客户需求。

  • 客户、开发人员和测试人员不断地相互交互，从而缩短周期时间。

  • 敏捷测试人员参与定义需求，贡献他们的测试专业知识，专注于可行的事情。

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

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

  • 整个团队统一测试要求，避免出现缺陷。

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

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

  • 对延迟或阻塞的持续反馈，以便在整个团队的努力下立即做出解决方案。

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

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

  • 开发和测试之间没有时间延迟。首先进行测试，然后采用持续测试方法。

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

敏捷测试的最佳实践

遵循下面给出的最佳实践 -

  • 包含具有各级各类测试专业知识的测试人员。

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

  • 测试人员不断与开发人员和客户分享反馈。

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

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

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

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

敏捷测试的挑战

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

  • 业务和管理层不了解敏捷方法及其局限性可能会导致无法实现的期望。

  • 敏捷遵循整个团队的方法，但并不是每个人都知道测试实践的要点。建议测试人员指导其他人，但在实际场景中，限时冲刺（迭代）可能是不切实际的。

  • 测试优先方法要求开发人员根据测试人员的反馈进行编码，但在实际场景中，开发人员更习惯根据来自客户或业务的需求进行编码。

  • 整个敏捷团队对质量产品负责，但在初始阶段，开发人员可能不会关注质量，因为他们更多地关注实施模式。

  • 持续集成需要回归测试，这需要相当大的努力，即使它必须自动化。

  • 测试人员可以通过敏捷思维来适应变化，但是适应由此产生的测试变更和测试在 Sprint 期间完成目标可能是不切实际的。

  • 建议尽早实现自动化，以便减少手动测试工作量和时间。但是，在实际场景中，实现可以自动化的测试并使其自动化需要时间和精力。

敏捷测试指南

执行敏捷测试时请遵循以下准则。

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

  • 参与评估会议以得出测试工作量和持续时间，以便测试活动适应迭代。

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

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

  • 在冲刺期间不断与开发团队合作，使测试和编码在冲刺期间取得成功。

  • 参加每日站立会议并传达测试延迟或阻塞（如果有），以便立即得到解决。

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

  • 准备好适应变化，通过对测试用例、测试数据的修改来做出响应。

  • 参加 Sprint 回顾以了解并贡献最佳实践和经验教训。

  • 在每个 Sprint 中协作获取客户反馈。

敏捷测试 - 象限

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

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

单元测试

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

集成测试

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

系统测试

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

用户验收测试

  • 在每个 Sprint 结束时和项目结束时完成

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

  • 反馈将作为后续 Sprint 的输入

  • Sprint 中的用户故事经过预先验证，可测试，并且具有定义的验收标准

测试类型

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

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

支持编程和批评产品测试

测试可以用于 -

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

    • 决定他们需要编写哪些代码来完成系统的特定Behave

    • 编码后需要运行哪些测试以确保新代码不会妨碍系统的其余Behave

  • 仅验证（批判产品） - 批判产品测试用于发现成品中的不足之处

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

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

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

面向业务的测试

如果测试回答了用业务领域的单词提出的问题，那么它就是面向业务的测试。这些是业务专家所理解的并且他们会感兴趣，以便可以在实时场景中解释系统的Behave。

技术面临考验

如果测试回答了用技术领域的词语提出的问题，那么它就是面向技术的测试。程序员根据技术的说明了解需要实现什么。

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

敏捷测试象限

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

象限

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

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

  • Q2 象限- 系统级、面向业务并符合产品Behave。功能测试属于这个象限。这些测试可以是手动的，也可以是自动的。

  • Q3 象限- 系统或用户接受程度、面向业务并关注实时场景。用户验收测试属于这个象限。这些测试是手动的。

  • 象限 Q4 - 系统或操作验收水平、技术面向并关注性能、负载、压力、可维护性、可扩展性测试。可以使用特殊工具以及自动化测试来进行这些测试。

结合这些，反映测试内容、测试时间的敏捷测试象限可以可视化如下：

测试象限

敏捷测试-Scrum

Scrum 提倡整体团队方法，即每个团队成员都必须参与每个项目活动。Scrum 团队是自组织的，对项目可交付成果负责。决策权留给团队，以便在正确的时间采取适当的行动，而不会造成任何时间延误。这种方法还鼓励正确利用团队才能，而不是仅限于一项活动。测试人员还参与所有项目和开发活动，贡献他们的测试专业知识。

整个团队在测试策略、测试计划、测试规范、测试执行、测试评估和测试结果报告方面共同努力。

协作用户故事创建

测试人员参与用户故事创建。测试人员就系统可能的Behave提出他们的想法。这有助于客户和/或最终用户了解真实环境中的系统，从而清楚地了解他们真正想要的结果。这会导致需求更快地冻结，并减少以后需求发生变化的可能性。

测试人员还为客户同意的每个场景制定验收标准。

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

发布计划

发布计划是针对整个项目完成的。然而，Scrum 框架涉及迭代决策，因为在执行冲刺的适当过程中会获得更多信息。因此，项目开始时的发布计划会议不需要为整个项目制定详细的发布计划。当相关信息可用时，它可以不断更新。

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

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

冲刺计划

冲刺计划是在每个冲刺开始时完成的。冲刺待办事项是使用从产品待办事项中选取的用户故事创建的，以便在特定冲刺中实施。

测试人员应该 -

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

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

测试分析

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

测试

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

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

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

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

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

  • 收集并维护测试结果。

自动化测试

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

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

测试活动自动化

测试活动的自动化减少了重复工作的负担，从而节省了成本。自动化

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

回归测试

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

配置管理

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

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

敏捷测试实践

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

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

  • 增量测试设计- 随着冲刺的逐步进展和用户故事的增加，测试用例被开发。

敏捷指标

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

针对 Scrum 开发提出了几个指标。重要的指标是 -

  • 成功 Sprint 的比率- (成功 Sprint 的数量 / Sprint 的总数) * 100。成功的冲刺是团队能够履行其承诺的冲刺。

  • 速度- 团队的速度基于团队在冲刺期间获得的故事点数量。故事点是评估过程中计算的用户故事的衡量标准。

  • 焦点因素- （速度/团队的工作能力）/100。焦点因素是团队努力完成故事的百分比。

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

  • Sprint Burndown - 剩余工作与剩余工作（以故事点或小时为单位）需要保持理想状态的工作（根据估计）。

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

    • 如果较少，则意味着团队没有准确估计。

  • 缺陷计数- Sprint 中的缺陷数量。缺陷计数是软件中相对于积压的缺陷数量。

  • 缺陷的严重性- 缺陷可以根据其严重程度分为轻微、主要和严重。测试人员可以定义分类。

冲刺回顾

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

  • 那些进展顺利的事情
  • 指标
  • 改进范围
  • 要应用的行动项目

敏捷测试 - 方法

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

在本章中，您将了解这些方法 -

  • 测试驱动开发 (TDD)
  • 验收测试驱动开发 (ATDD)
  • Behave驱动开发（BDD）

测试驱动开发

在测试驱动开发（TDD）方法中，代码是基于自动化测试用例指导的测试优先方法开发的。首先编写测试用例以失败，然后基于该用例开发代码以确保测试通过。方法是重复的，重构是通过代码的开发来完成的。

可以通过以下步骤来理解 TDD -

  • 步骤 1 - 编写测试用例以反映需要编写的代码功能的预期Behave。

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

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

  • 步骤 4 - 再次运行测试。这一次，随着功能的编码，测试必须通过。重复步骤（3）和步骤（4），直到测试通过。

  • 步骤 5 - 重构代码。

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

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

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

验收测试驱动开发

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

  • 步骤 1 - 与客户和用户合作编写验收测试用例以及用户故事。

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

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

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

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

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

  • 步骤 7 - 运行自动回归测试以确保连续回归。

Behave驱动开发（BDD）

Behave驱动开发（BDD）与测试驱动开发（TDD）类似，重点是测试代码以确保系统的预期Behave。

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

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

敏捷测试 - 技术

传统测试的测试技术也可以用于敏捷测试。除此之外，敏捷项目中还使用了敏捷特定的测试技术和术语。

测试依据

在敏捷项目中，产品待办事项列表取代了需求规范文档。产品待办事项列表的内容通常是用户故事。用户故事中也考虑了非功能性需求。因此，敏捷项目的测试基础是用户故事。

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

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

完成的定义

完成定义 (DoD) 是敏捷项目中使用的标准，用于确保 Sprint 待办事项中的活动完成。DoD 因 Scrum 团队而异，但在一个团队内应该保持一致。

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

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

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

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

  • 在每个测试级别
  • 对于每个功能
  • 对于每个迭代
  • 待发布

测试信息

测试人员需要具有以下测试信息 -

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

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

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

功能和非功能测试设计

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

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

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

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

探索性测试

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

探索性测试（ET）被定义为同时学习、测试设计和测试执行。在探索性测试中，测试人员在执行测试时主动控制测试的设计，并使用测试时获得的信息来设计新的更好的测试。

探索性测试可以方便地适应敏捷项目中的变化。

基于风险的测试

基于风险的测试是基于失败风险的测试，并使用测试设计技术减轻风险。

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

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

进行风险分析以评估每种风险的概率（可能性）和影响。然后，风险被优先考虑 -

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

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

适合度测试

适合性测试是自动化的验收测试。Fit 和 FitNesse 工具可用于自动化验收测试。

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

敏捷测试 - 工作产品

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

测试计划的典型内容是 -

  • 测试策略
  • 测试环境
  • 测试覆盖率
  • 测试范围
  • 测试工作和时间表
  • 测试工具

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

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

用户故事

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

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

手动和自动测试

在第一次运行测试期间，使用手动测试。它们包括 -

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

然后测试将自动进行后续运行。

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

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

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

在所有类型的方法中，都会发生持续集成，其中包括持续集成测试。

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

在Scrum中，迭代是有时间限制的。因此，如果用户故事测试无法在特定的 Sprint 中完成，测试人员可以在每日站立会议中报告用户故事无法在该 Sprint 中达到完成状态，因此需要保留到下一个 Sprint。

检测结果

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

还可以准备一份测试摘要，其中包含 -

  • 测试范围（测试了什么，未测试什么）
  • 缺陷分析以及根本原因分析（如果可能）
  • 缺陷修复后的回归测试状态
  • 问题及相应的解决方案
  • 未决问题（如果有）
  • 测试策略中所需的任何修改
  • 测试指标

测试指标报告

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

  • 测试努力
  • 测试估计准确性
  • 测试覆盖率
  • 自动化测试覆盖率
  • 缺陷数
  • 缺陷率（每个用户故事点的缺陷数量）
  • 缺陷严重程度
  • 在同一个 Sprint 中修复缺陷的时间（修复逃脱当前 sprint 的 bug 的成本是修复缺陷的 24 倍）
  • 同一 Sprint 中修复的缺陷数量
  • 客户在 Sprint 内完成验收测试

Sprint 审查和回顾报告

测试人员还为 Sprint 评审和回顾报告做出贡献。典型的内容是 -

  • 测试指标
  • 测试结果记录审核结果
  • 从测试的角度来看，哪些是正确的，哪些可以改进
  • 最佳实践
  • 得到教训
  • 问题
  • 客户的反馈意见

敏捷测试 - 看板

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

  • 可测试且大小有效的用户故事可以在指定的时间限制内进行开发和测试。

  • WIP（工作中）限制允许一次专注于有限数量的用户故事。

  • 看板以直观方式表示工作流程，有助于跟踪测试活动和瓶颈（如果有）。

  • 看板团队协作概念可以在识别瓶颈时解决它们，而无需等待时间。

  • 预先准备测试用例，随着开发的进展维护测试套件并获取客户反馈有助于消除迭代/冲刺中的缺陷。

  • 完成的定义 (DoD) 被称为“完成-完成”，因为故事只有在测试也完成后才达到完成状态。

产品开发中的测试活动

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

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

以下敏捷测试活动确保每个版本以及所有版本结束时的质量交付 -

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

    • 系统所有可能的Behave都通过用户故事和属于用户故事一部分的非功能性需求来捕获。

    • 用户故事是可测试的。

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

  • 视觉任务看板 -

    • 描述任务的状态和进度

    • 瓶颈出现时立即被识别

    • 有助于测量循环时间，然后进行优化

  • 团队协作有助于 -

    • 整个团队对产品质量负责

    • 当瓶颈发生时予以解决，节省等待时间

    • 所有活动中每项专业知识的贡献

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

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

  • 通过之前编写的测试用例来预防缺陷，并指导开发人员了解系统不同Behave的预期 -

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

  • 随着开发的进展进行持续测试，以确保迭代中的缺陷修复 -

    • 确保测试覆盖率

    • 保持较低的开放缺陷数量

故事探索

故事探索是敏捷团队内部的沟通，当产品负责人传递故事以供开发接受时，探索故事理解。