敏捷测试 – 快速指南

敏捷测试 – 快速指南

敏捷测试 – 概述

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

敏捷宣言

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

敏捷宣言是 –

我们正在通过做和帮助他人来发现更好的软件开发方法。通过这项工作，我们开始重视 –

  • 个人和交互胜过流程和工具。
  • 工作软件优于综合文档。
  • 客户合作胜过合同谈判。
  • 响应变化而不是遵循计划。

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

什么是敏捷测试？

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

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

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

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

敏捷测试对比 瀑布测试

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

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

Agile Testing 瀑布测试
Testing is not a separate phase and occurs concurrently with development. 测试是一个单独的阶段。所有级别和类型的测试只有在开发完成后才能开始。
Testers and developers work together. 测试人员与开发人员分开工作。
Testers are involved in coming up with requirements. This helps in requirements mapping to the behaviors in the real world scenario and also framing the acceptance criteria. Also, logical Acceptance Test Cases would be ready along with the requirements. 测试人员可能不参与需求阶段。
Acceptance Testing is done after every iteration and customer feedback is sought. 验收测试仅在项目结束时进行。
Every iteration completes its own testing thus allowing regression testing to be implemented every time new functions or logic are released. 回归测试只有在开发完成后才能实施。
No time delays between coding and testing. 编码和测试之间通常存在时间延迟。
Continuous testing with overlapping test levels. 测试是一项定时活动，测试级别不能重叠。
Testing is a best practice. 测试经常被忽视。

敏捷测试原则

敏捷测试的原则是 –

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

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

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

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

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

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

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

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

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

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

    • 将文档用于多种用途。

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

  • “Done Done”，不仅仅是完成– 在敏捷中，一个功能被认为不是在开发之后完成，而是在开发和测试之后完成。

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

敏捷测试活动

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

  • 发布计划（测试计划）

    • 对于每一次迭代，

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

  • 回归测试

  • 发布活动（测试相关）

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

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

敏捷测试 – 方法论

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

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

项目团队

持续集成，持续质量

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

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

敏捷方法论

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

Scrum

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

经验值

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

水晶

Crystal 是基于租船、循环交付和收尾。

  • 章程包括组建一个开发团队，进行初步可行性分析，得出初步计划和开发方法。

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

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

软驱

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

DSDM

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

精益软件开发

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

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

在精益原则是-

  • 消除浪费
  • 扩大学习
  • 延迟承诺
  • 赋能团队
  • 快速交付
  • 建立诚信
  • 看到整体

看板

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

看板基于 –

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

敏捷测试方法

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

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

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

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

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

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

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

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

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

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

敏捷测试生命周期

在 Scrum 中，测试活动包括 –

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

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

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

  • 持续测试的 Sprint 执行

  • Sprint完成后的回归测试

  • 报告测试结果

  • 自动化测试

测试是基于迭代和冲刺的，如下图所示 –

生命周期

敏捷测试 – 团队中的测试员

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

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

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

  • 好的社交技能。

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

  • 能够对产品表现出批判性的、以质量为导向的、持怀疑态度的想法。

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

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

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

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

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

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

  • 自组织工作的潜力。

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

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

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

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

敏捷测试员活动包括 –

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

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

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

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

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

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

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

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

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

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

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

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

团队合作

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

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

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

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

  • 承诺– 承诺按照客户和利益相关者的要求理解和评估产品的行为和特征。

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

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

  • Open to Feedback – 参加冲刺回顾以从成功和失败中学习。寻求客户反馈并迅速而适当地采取行动以确保交付的质量。

  • 弹性– 响应变化。

测试计划

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

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

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

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

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

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

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

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

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

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

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

冲刺零

Sprint Zero 涉及第一个 sprint 之前的准备活动。测试人员需要在以下活动中与团队合作 –

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

一体化

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

为此，测试人员需要 –

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

敏捷测试实践

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

  • 配对– 两个团队成员在同一个键盘上一起工作。作为其中一个测试，另一个审查/分析测试。两个团队成员可以是

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

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

    • 两名测试员

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

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

敏捷测试 – 跟踪活动

可以传达测试状态 –

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

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

测试进度

可以使用以下方法跟踪测试进度 –

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

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

如果测试进度有任何延迟或阻塞，整个团队会讨论并协同解决相同的问题。

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

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

产品质量

产品质量指标包括 –

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

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

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

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

关键成功因素

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

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

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

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

  • 敏捷测试人员需要保持他们的步伐以与开发发布计划保持一致。因此，需要以产品质量为目标，对测试活动进行适当的计划、跟踪和重新计划。

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

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

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

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

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

    • 规划测试活动。

    • 与开发团队保持一致，以确保通过前期测试设计生产满足要求的代码。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

敏捷测试 – 重要属性

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

敏捷测试的好处

敏捷测试的好处是 –

  • 通过快速、持续、全面测试的产品和寻求客户反馈来让客户满意。

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

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

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

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

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

  • 整个团队始终关注产品质量。

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

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

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

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

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

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

敏捷测试的最佳实践

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

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

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

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

  • 测试优先和持续测试方法以适应开发工作。

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

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

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

敏捷测试的挑战

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

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

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

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

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

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

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

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

敏捷测试指南

在执行敏捷测试时使用以下指南。

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

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

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

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

  • 在 Sprint 期间与开发团队持续合作，使测试和编码在 Sprint 中取得成功。

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

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

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

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

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

敏捷测试 – 象限

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

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

单元测试

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

集成测试

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

系统测试

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

用户验收测试

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

  • 由客户完成。反馈由团队接受

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

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

测试类型

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

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

支持编程和评论产品测试

测试可以用于 –

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

    • 决定他们需要编写什么代码来完成系统的特定行为

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

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

业务面和技术面测试

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

  • 业务面，或
  • 技术面

业务面测试

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

技术面临测试

测试是面向技术的测试，如果它回答用技术领域的词语构成的问题。程序员根据对技术的澄清了解需要实现什么。

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

敏捷测试象限

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

象限

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

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

  • 象限 Q2 – 系统级、面向业务和符合产品行为。功能测试属于这个象限。这些测试要么是手动的，要么是自动的。

  • 象限 Q3 – 系统或用户接受水平，面向业务并专注于实时场景。用户验收测试属于这个象限。这些测试是手动的。

  • 象限 Q4 – 系统或运营接受水平、技术面临和关注性能、负载、压力、可维护性、可扩展性测试。特殊工具可用于这些测试以及自动化测试。

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

测试象限

敏捷测试 – Scrum

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

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

协作用户故事创建

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

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

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

发布计划

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

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

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

冲刺计划

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

测试人员应该 –

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

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

测试分析

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

测试

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

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

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

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

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

  • 收集和维护测试结果。

自动化测试

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

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

测试活动自动化

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

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

回归测试

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

配置管理

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

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

敏捷测试实践

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

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

  • 增量测试设计– 随着 Sprint 的进展和用户故事的增加，开发测试用例。

敏捷指标

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

为 Scrum 开发建议了几个指标。重要的指标是 –

  • 成功 Sprint 的比率– （成功 Sprint 的数量 / Sprint 的总数）* 100。一个成功的 Sprint 是一个团队能够兑现其承诺的 Sprint。

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

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

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

  • Sprint Burndown – 剩余 Vs 的工作（以故事点数或以小时为单位）。理想情况下需要保留的工作（根据估计）。

    • 如果它更多，那么这意味着团队承担了比他们能做的更多的工作。

    • 如果小于，则表示团队没有准确估算。

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

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

冲刺回顾

在 Sprint Retrospectives 中，所有团队成员都将参加。他们分享 –

  • 顺利的事情
  • 指标
  • 改进的余地
  • 申请的行动项目

敏捷测试 – 方法

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

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

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

测试驱动开发

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

在以下步骤的帮助下可以理解 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) 是敏捷项目中使用的标准，用于确保完成 Sprint 待办事项中的活动。DoD 可以因 Scrum 团队而异，但在一个团队内应该是一致的。

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

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

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

除了用户故事的 DoD，还需要 DoD –

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

测试信息

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

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

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

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

功能和非功能测试设计

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

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

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

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

探索性测试

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

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

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

基于风险的测试

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

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

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

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

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

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

拟合测试

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

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

敏捷测试 – 工作产品

测试计划在发布计划时准备，并在每个 Sprint 计划时修订。测试计划作为测试过程的指南，以获得完整的测试覆盖率。

测试计划的典型内容是 –

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

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

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

用户故事

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

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

手动和自动测试

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

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

然后，测试会自动进行，以进行后续运行。

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

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

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

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

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

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

测试结果

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

还可以准备包含以下内容的测试摘要 –

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

测试指标报告

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

  • 测试工作
  • 测试估计精度
  • 测试覆盖率
  • 自动化测试覆盖率
  • 缺陷数
  • 缺陷率（每个用户故事点的缺陷数）
  • 缺陷严重程度
  • 在同一个 Sprint 中修复缺陷的时间（修复逃避当前 sprint 的错误的成本是原来的 24 倍）
  • 在同一个 Sprint 中修复的缺陷数量
  • 客户在 Sprint 内完成验收测试

Sprint 回顾和回顾报告

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

  • 测试指标
  • 测试结果日志审查结果
  • 从测试的角度来看什么是正确的，什么可以改进
  • 最佳实践
  • 得到教训
  • 问题
  • 客户的反馈意见

敏捷测试 – 看板

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

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

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

  • 可视化表示工作流程的看板有助于跟踪测试活动和瓶颈（如果有）。

  • 看板团队协作概念允许在确定瓶颈时解决瓶颈，而无需等待时间。

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

  • 完成的定义 (DoD) 被称为 Done-Done，因为故事仅在测试完成后才达到完成状态。

产品开发中的测试活动

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

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

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

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

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

    • 用户故事是可测试的。

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

  • 视觉任务看板 –

    • 描述任务的状态和进度

    • 瓶颈在发生时立即被识别

    • 便于测量然后可以优化的循环时间

  • 团队协作有助于 –

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

    • 在瓶颈发生时解决瓶颈，节省等待时间

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

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

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

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

    • WIP 限制一次只关注有限数量的用户故事

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

    • 确保测试覆盖

    • 保持低开放缺陷数

故事探索

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

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

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

估计

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

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

  • 有关需要哪些测试活动的信息
  • 相同的工作量估计

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

在看板中，只有当一个故事被开发和测试并标记为完整且没有缺陷时，Done-Done 才会完成。

因此，测试估计在故事估计中起着重要作用。

故事策划

故事计划在估计故事并将其分配给当前迭代后开始。

故事规划包括以下测试任务 –

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

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

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

故事进展

Story Progression 揭示了开发人员和测试人员之间持续沟通所需的额外测试。在开发人员需要更清楚实现的情况下，测试人员执行探索性测试。

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

故事接受

当故事达到 Done-Done 状态时发生故事接受。即，故事被开发和测试并表示为完成。

当与故事相关的所有测试都通过或满足测试自动化水平时，故事测试就完成了。

敏捷测试 – 工具

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

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

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

  • 开发自动化脚本。

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

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

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

注意– 记录和回放、最后测试、重量级和测试自动化解决方案不是敏捷的 –

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

  • 使用此类工具创建的无法维护的脚本成为更改的障碍

  • 此类专业工具需要测试自动化专家，从而形成孤岛

广泛使用的工具是 –

S.No. 工具和目的
1

Hudson

持续集成框架
2

Selenium

功能测试 – 与 Hudson 集成
3

CruiseControl

持续集成框架
4

Junit

Java 单元测试
5

Nunit

.Net 单元测试
6

Cobertura / JavaCodeCoverage / JFeature / JCover /

Java 测试覆盖率
7

Jester

Java – 变异测试/自动错误播种
8

Gretel

Java 测试覆盖率监控工具
9

TestCocoon

C/C++ 或 C# – 通过查找冗余测试和查找死代码来减少测试数量
10

JAZZ

Java – Branch、Node 和 Defuse Coverage 并实现 GUI、测试计划器、动态检测和测试分析器
11

Ant

Java – 自动化构建
12

Nant

.Net – 自动化构建
13

Bonfire

JIRA 的敏捷测试插件

敏捷测试自动化工具

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

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

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

  • 关注系统的预期行为。

  • 将测试的本质与实现细节分离，从而使其技术独立。

  • 促进合作。

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

这个问题可以通过自动化验收测试来解决，这些测试是与客户、其他利益相关者、测试人员和开发人员合作编写的。自动验收测试由客户或产品所有者/业务分析师编写，反映产品的预期行为。开发人员的参与确保按照要求生成代码。但是，如果测试只关注验收，则生成的代码可能保持不可扩展。

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

支持自动化验收测试的敏捷工具和框架是 –

  • 合身
  • 健身
  • 协和
  • 红宝石
  • 黄瓜

合身

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

  • 客户或产品负责人使用 Microsoft Word 和 Microsoft Excel 举例说明产品行为

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

Fit 1.1 支持 Java 和 .NET。

健身

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

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

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

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

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

  • 运行测试

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

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

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

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

黄瓜

Cucumber 是一个基于行为驱动开发 (BDD) 框架的工具。主要特点是 –

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

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

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

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

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

觉得文章有用？

点个广告表达一下你的爱意吧 ！😁