验收测试驱动开发 (ATDD)

引言

测试驱动开发 (TDD) 和验收测试驱动开发 (ATDD) 具有共同点：开发、测试和客户方的团队成员共同协作，在部署相应功能之前创建验收测试。客户（我们试图解决什么问题？）、开发（我们如何解决这个问题？）和测试（什么关于...？）这三个视角体现在构建验收测试过程中进行的协作讨论中，通常被称为“三方对话”。

除了展示用户的视角外，这些验收测试还充当一种规范，用于指定系统的运行方式，并作为确认系统按计划运行的手段。在某些情况下，团队可能会自动化验收测试。

顾名思义，ATDD 与 TDD，即测试驱动开发相关。它也与行为驱动开发 (BDD) 和示例驱动规范 (SBE) 等方法相关。

什么是验收测试驱动开发？

首先，让我们谈谈 ATDD 是什么。尽管其名称如此，但这并不是一种测试方法。另一方面，验收测试驱动开发是一种编程方法论。与它的“表亲”TDD 一样，ATDD 高度重视测试自动化。在实施时，团队将使用自动化测试用例来指导生产代码的开发。

与通常被认为是工程技术的 TDD 不同，ATDD 是一项协作工作，它将测试人员、工程师和业务利益相关者团结起来，在整个软件开发过程中进行协作。这种协作的结果是应用程序的需求，以每个人都能理解的格式表达，然后转化为自动化的验收测试。

验收测试驱动开发的主要目标是什么？

ATDD 的目标是培养一种协作环境，从而形成对系统需求的共同理解，这些需求以简单的英文规范表达。然后，这些规范被转换为自动化的验收测试用例。这样做有什么好处？

首先，考虑单元测试，看看为什么它有用。这种类型的测试在设计上是高度以开发人员为中心的。它使开发人员能够以可执行格式记录其代码假设。单元测试回答了“我们是否正确地构建了事物？”这个问题。

另一方面，单元测试并未回答“我们是否构建了正确的事物？”这个问题。需要通过与领域专家的对话确定的验收标准来评估应用程序的运行情况的验收测试。

需要通过与领域专家的互动来评估应用程序的运行情况的验收测试。

验收测试驱动开发基本上解决了开发团队部署不符合客户需求的功能的问题。

自动化是 ATDD 的关键组成部分：在讨论期间开发的规范被转换为可执行测试，这些测试保证软件工程师按照要求实现功能。

简史

Kent Beck 在他著名的著作《Test-driven Development: By Example》（首次出版于 2000 年）中简要提到了 ATDD（他称之为 Application Test-Driven Development），但否决了这个想法。

尽管如此，该方法凭借 Fit 和 Fitnesse 等应用程序的成功而获得了广泛关注。

Dan North 于 2006 年创建了行为驱动开发的概念，最初是为了替换 TDD 词汇表中的部分内容，但后来演变为需求分析。BDD 和 ATDD 有许多相似之处，并且随着时间的推移，前者的大部分词汇、工具和技术都被后者所采纳。

它是如何工作的/原则和实践？

ATDD 概览

验收测试驱动开发遵循与 TDD 类似的流程，即在编写生产代码之前先编写测试。ATDD 测试是验收测试，而 TDD 测试是单元测试。测试人员、开发人员和客户或业务利益相关者进行讨论，形成需求，这些需求随后成为测试的基础。

在创建测试之后，开发人员编写代码以确保测试通过，从而实现指定的功能。

通过这种方式，您不仅拥有了每个人（无论编码技能如何）都能理解并做出贡献的全面规范，而且还确保了开发人员构建的是客户所需的内容。

验收测试驱动开发周期

尽管对于验收测试驱动开发周期的阶段没有普遍共识，但这四个过程经常被看到：讨论、提炼、开发和演示。

1. 讨论

与几乎所有敏捷方法或框架一样，在规划会议期间，测试人员和开发人员将与利益相关者、产品负责人和客户gather，通过讨论将在下一个迭代或冲刺中实现的任务和用户故事来获取尽可能多的信息。

在讨论过程中，团队可以澄清关于需求的任何困惑。这有助于团队避免在程序后期进行调试、诊断和解决错误，从而节省大量成本。

此外，团队可能会在“讨论”阶段发现，一个看似简单的用户故事实际上要复杂得多。在这种情况下，团队和业务利益相关者可能会决定将该故事分为两个或多个故事。

此阶段的结果是易于理解的表格或纯英文短语形式的验收测试，可供组织中的所有成员使用。

2. 提炼

在前一阶段创建的测试必须转换为与您当前使用的验收测试工具兼容的格式。这些格式因工具而异，包括

表格

维基页面

甚至 DSL（领域特定语言）中的代码。

因此，验收测试是此阶段的输出。但是，您会发现，它们尚未准备好投入使用。

3. 开发

在上一个阶段生成的测试现在无法有效测试正在测试的系统。此时，它们只是骨架；您必须将它们与将运行应用程序代码的实际测试代码连接起来。

所使用的特定工具决定了如何配置这种连接。简而言之，在完成连接后，由于它们正在测试的功能尚不可用，测试将不会通过。

然后，开发人员根据在“讨论”阶段获取并在“提炼”阶段转化为测试的需求来使用该功能。

4. 演示

开发人员在实现功能后将其演示给利益相关者。许多敏捷方法都包含一个非常受欢迎的实践，即在每个周期结束时举行一次会议，团队在此期间审查产品和/或如何改进流程本身。因此，这与 ATDD 演示阶段非常契合。

一旦完成实现，测试人员还可以进行手动探索性测试。这些测试可以发现缺陷以及改进的机会，从而可能导致创建更多故事。

验收测试驱动开发与测试驱动开发

人们通常会将测试驱动开发与验收测试驱动开发进行比较。它们显然是相关的，但两者之间存在哪些相似之处？

在测试驱动开发 (TDD) 方法论下，开发人员在继续创建通过测试所需的生产代码之前，会编写一个会失败的单元测试。

TDD 的目标是生成简单、干净的代码，这些代码由松散耦合的模块组成，以提高可维护性。尽管如此，TDD 是一种以开发人员为中心的方法论，它依赖于单元测试。如前所述，单元测试可能会导致错误地实现不正确功能的问题。

ATDD 促进开发人员与其他团队成员（甚至非程序员）之间的协作，而不是仅仅关注开发人员。

TDD 和 ATDD 可以也应该一起使用。在每个迭代开始时，根据领域专家的建议创建自动化的验收测试。

使用测试驱动开发 (TDD)，在实际实现之前，对生产代码的开发进行测试驱动。换句话说，TDD 可以在整个 ATDD 阶段内用作“内部”循环。

对验收测试驱动开发的需求

1. 确保需求清晰明了。
2. 确保产品顺利开发。
3. 避免最后时刻的更改。
4. 交付高质量的产品。

ATDD 的关键实践

1. 分析和讨论真实场景。
2. 为不同情况建立验收标准。
3. 自动化验收测试用例。
4. 专注于基于需求的开发。

ATDD 的好处

1. 更清晰地阐明需求。
2. 更快地解决问题或疑虑。
3. 加强团队成员之间的协作。
4. 更加关注客户需求。
5. 它为开发过程的所有阶段提供了一个路线图。
6. 易于管理。