BDD 101: BDD 简介
系列概览
BDD 101 是一个博客系列，教授行为驱动开发的基础知识。它既是 BDD 初学者的“入门”指南，也是专业人士的最佳实践参考。我为参与软件开发日常职责的任何人编写了这个系列：开发人员、测试人员、Scrum 管理员、产品所有者和经理。本系列中的内容来自我在许多项目中使用 BDD 的经验。它侧重于基于 Gherkin 的规范，测试自动化将是一个主要主题。如果这个系列适合你，那就让我们潜入吧！
BDD 101 目录在 Automation Panda BDD 页面上给出。请注意，该系列中的一些文章相隔几个月发布，并且不会使用“上一篇”和“下一篇”文章箭头一起出现。
BDD 大图：BDD 的主要目标是协作和自动化。
什么是行为？
行为是产品或功能的运作方式。它被定义为输入、行动和结果的场景。一个产品或功能表现出无数的行为。单独识别行为会带来清晰和简单。它还有助于解释行为之间的关系。以下是行为示例：
-
登录网页
-
单击导航栏上的链接
-
提交表格
-
成功拨打服务电话
-
接收预期错误
分离个体行为可以很容易地定义一个系统，而无需不必要的重复。例如，可能有多种方式导航到同一页面。
什么是行为
行为驱动开发 (BDD) 是一种以测试为中心的软件开发过程，它源于测试驱动开发 (TDD)。它大约从 2000 年代中期开始出现。 BDD 专注于从一开始就清楚地确定功能的所需行为。行为是使用实例规范来识别的：行为规范是为了用现实的例子来说明所需的行为，而不是用抽象的、通用的行话编写的。它们既作为产品的需求/验收标准（开发前）又作为测试用例（开发后）。 Gherkin 是编写正式行为规范最流行的语言之一——它将行为捕获为“Given-When-Then”场景。借助自动化工具，可以轻松地将场景转换为自动化测试用例。从工程师到产品负责人，任何人都可以编写 BDD 场景，因为它们只是英文短语。 BDD 让开发人员专注于准确交付产品所有者想要的东西。它还加快了测试速度。因此，BDD 与敏捷软件开发完美结合。
知识速记
- BDD 是示例规范。
- 当有人说“BDD”时，立即想到“Given-When-Then”。
- BDD 首先关注行为。
- 行为场景是 BDD 的基石。
- BDD 是敏捷过程的改进，而不是大修。
- 它正式确定了验收标准和测试覆盖率。
- BDD 是一种范式转变。
- 行为成为团队的主要关注点。
BDD 的起源
以下引用来自 Dan North（“BDD 之父”）于 2006 年 3 月撰写的题为 Introducing BDD 的文章：
我有问题。在不同环境中的项目中使用和教授测试驱动开发 (TDD) 等敏捷实践时，我不断遇到同样的困惑和误解。程序员想知道从哪里开始，测试什么，不测试什么，一次测试多少，如何调用他们的测试，以及如何理解测试失败的原因。
我对 TDD 越深入，我就越觉得我自己的旅程与其说是一连串的死胡同，不如说是一个逐渐掌握的渐进式、渐进式的过程。我记得当时在想“要是有人告诉我就好了！哇，一扇门打开了。”我决定必须有可能以一种直接获得好东西并避免所有陷阱的方式来呈现 TDD。
我的回答是行为驱动开发（BDD）。它是从既定的敏捷实践发展而来的，旨在使敏捷软件交付的新手团队更容易获得和有效地使用它们。随着时间的推移，BDD 已经发展为涵盖更广泛的敏捷分析和自动化验收测试。
12大好处
BDD 以十几种方式改进了开发过程：
包容性 任何人都可以编写 BDD 场景，因为它们是用简单的英语编写的。想想三个朋友。
清晰性 场景特别关注正在开发的产品的预期行为，从而减少开发内容的歧义。
精简 需求 = 验收标准 = 测试用例。模块化语法也加快了自动化。
左移 测试用例定义本质上成为修饰的一部分。
工件 场景形成了测试用例的集合。任何未自动化的测试都可以添加到已知的自动化积压工作中。
自动化 BDD 框架可以轻松地将场景转换为自动化测试。
测试驱动 大多数 BDD 框架可以运行场景失败，直到实现该功能。
代码重用 “Given-When-Then”步骤可以在场景之间重用。
参数化 步骤可以参数化。例如，单击按钮的步骤可以接收其 ID。
变化 使用参数，示例表可以轻松运行具有不同输入组合的相同场景。
水到渠成 随着更多步骤定义的添加，场景的编写和自动化变得更容易、更快。
适应性 随着产品和功能的变化，场景很容易重写。
测试建议
由于 BDD 专注于实际的功能行为，行为规范最适合更高级别的、功能性的、黑盒测试。例如，BDD 非常适合测试 API 和 Web UI。 Gherkin 擅长验收测试。然而，行为规范对于单元测试来说是多余的，对于关注指标而不是通过/失败结果的性能测试来说，它也不是一个好的选择。在 BDD 101：单元、集成和端到端测试一文中了解更多相关信息。