BDD - 基于示例的规范

---

---

根据《基于示例的规范》作者 Gojko Adzic 的说法，“基于示例的规范是一套流程模式，它促进软件产品中的变更，以确保高效交付正确的产品。”

基于示例的规范是一种协作方法，用于定义软件产品的需求和面向业务的功能测试，该方法基于使用现实示例而不是抽象语句来捕获和说明需求。

基于示例的规范 – 概述

基于示例的规范的目标是专注于优先级排序、可验证的业务需求的开发和交付。虽然基于示例的规范本身的概念相对较新，但这只是对现有实践的一种重新表述。

它支持一种非常具体、简洁的词汇，称为普遍语言，它：

• 支持可执行的需求。

• 被团队中的每个人使用。

• 由跨职能团队创建。

• 捕捉每个人的理解。

基于示例的规范可以直接用作构建反映业务领域的自动化测试的输入。因此，基于示例的规范的重点是构建正确的产品并正确构建产品。

基于示例的规范的目的

基于示例的规范的主要目标是构建正确的产品。它侧重于共享理解，从而建立单一事实来源。它支持验收标准的自动化，因此重点是缺陷预防而不是缺陷检测。它还提倡尽早测试以尽早发现缺陷。

SbE 的使用

基于示例的规范用于说明描述业务价值的预期系统行为。图示是通过具体和现实生活中的例子来实现的。这些例子用于创建可执行的需求，这些需求：

• 无需翻译即可测试。

• 捕获在实时文档中。

以下是我们使用示例来描述特定规范的原因：

• 它们更容易理解。

• 它们更不容易被误解。

SbE 的优势

使用基于示例的规范的优势在于：

• 提高质量

• 减少浪费

• 降低生产缺陷的风险

• 重点工作

• 可以更安全地进行更改

• 改进业务参与

SbE 的应用

基于示例的规范应用于：

• 复杂的业务或复杂的组织。

• 不适用于纯粹的技术问题。

• 不适用于以 UI 为中心的软件产品。

• 也可以应用于遗留系统。

SbE 和验收测试

基于示例的规范在验收测试方面的优势在于：

• 一个插图同时用于详细的需求和测试

• 项目的进度以验收测试为准：

  • 每个测试都是为了测试一种行为。

  • 一个测试要么通过某种行为，要么不通过。

  • 通过的测试表示特定行为已完成。

  • 如果一个需要完成 100 种行为的项目完成了 60 种行为，则表示已完成 60%。

• 测试人员从缺陷修复转向缺陷预防，并为解决方案的设计做出贡献。

• 自动化允许即时了解需求更改对解决方案的影响。

基于示例的规范 – 对不同角色的意义

基于示例的规范的目标是促进团队中每个人的协作，包括整个项目中的客户，以交付业务价值。为了更好地理解，每个人都使用相同的词汇。

SbE – 一套流程模式

正如我们在本章开头看到的那样，基于示例的规范被定义为一套流程模式，它促进软件产品中的变更，以确保高效交付正确的产品。

流程模式包括：

• 协作规范

• 使用示例说明规范

• 细化规范

• 自动化示例

• 频繁验证

• 活文档

协作规范

协作规范的目标是：

• 让团队中的各种角色拥有共同的理解和共享的词汇。

• 让每个人都参与到项目中，以便他们可以贡献对某个功能的不同视角。

• 确保功能的共享沟通和所有权。

这些目标在规范研讨会（也称为“三位一体会议”）中得到实现。“三位一体”是指 BA、QA 和开发人员。尽管项目中还有其他角色，但这三位将负责并对从定义到交付功能负责。

在会议期间：

• 业务分析师 (BA) 提出新功能的需求和测试。

• 三位一体 (BA、开发人员和 QA) 讨论新功能并审查规范。

• QA 和开发人员还会识别缺失的需求。

• 三位一体

  • 使用普遍语言使用共享模型。

  • 使用领域词汇（如果需要，则维护词汇表）。

  • 寻找差异和冲突。

• 此时不要跳到实现细节。

• 就功能是否已充分指定达成共识。

• 对需求和测试所有权的共享意识促进了高质量的规范

• 需求以场景的形式呈现，这些场景提供了明确无歧义的需求。场景是从用户的角度来看系统的行为的示例。

使用示例说明规范

使用 Given-When-Then 结构指定场景以创建可测试的规范：

Given <某些前提条件>

And <附加前提条件> 可选

When <某个动作/触发器发生>

Then <某些后置条件>

And <附加后置条件> 可选

此规范是系统行为的一个示例。它也代表系统的验收标准。

团队讨论示例，并合并反馈，直到达成一致意见，认为这些示例涵盖了该功能的预期行为。这确保了良好的测试覆盖率。

细化规范

要细化规范，

• 编写示例时要精确。如果示例变得复杂，请将其拆分为更简单的示例。

• 关注业务视角，避免技术细节。

• 考虑正面和负面条件。

• 遵守特定领域的词汇。

• 与客户讨论示例。

  • 选择对话来完成此任务。

  • 仅考虑客户感兴趣的示例。这仅支持生成所需代码，并避免涵盖可能不需要的每种可能的组合

• 为了确保场景通过，该场景的所有测试用例都必须通过。因此，增强规范以使其可测试。测试用例可以包括各种范围和数据值（边界和角点情况）以及导致数据变化的不同业务规则。

• 指定其他业务规则，例如复杂的计算、数据处理/转换等。

• 将非功能场景（例如性能、负载、可用性等）包括为基于示例的规范

自动化示例

自动化层需要保持非常简单 – 只需将规范连接到被测系统即可。您可以为此使用工具。

使用领域特定语言 (DSL) 执行测试自动化，并显示输入和输出之间的清晰连接。关注规范，而不是脚本。确保测试精确、易于理解且可测试。

频繁验证

在每次更改（添加/修改）时，将示例验证包含在您的开发管道中。有许多技术和工具可以（也应该）被采用以帮助确保产品的质量。它们围绕三个关键原则展开：**尽早测试、测试良好**和**经常测试**。

频繁执行测试，以便您可以识别薄弱环节。表示行为的示例有助于跟踪进度，并且只有在相应的测试通过后，才认为行为已完成。

活文档

使规范尽可能简单和简短。组织规范并在工作进展时对其进行改进。使团队中的所有人都可以访问文档。

基于示例的规范流程步骤

图示显示了基于示例的规范中的流程步骤。

反模式

反模式 (Anti-patterns) 是软件开发中某些被认为是不良编程实践的模式。与设计模式（design patterns）相反，设计模式是对常见问题的常用方法的总结，已被正式化，并普遍认为是一种良好的开发实践，而反模式则恰恰相反，是不可取的。

反模式会导致各种问题。

问题的解决方案 - 质量

可以通过关注反模式来确保质量。为了最大限度地减少反模式造成的问题，您应该：

• 一起使用示例进行规范。

• 清理和改进示例。

• 编写满足示例的代码。

• 自动化示例并部署。

• 对每个用户故事重复此方法。

为了解决因反模式造成的问题，意味着要遵守：

• 协作。

• 关注“是什么”。

• 关注业务。

• 做好准备。

让我们了解上述每一点的含义。

协作

在协作中：

• 业务人员、开发人员和测试人员从各自的角度提供输入。

• 自动化的示例证明团队构建了正确的东西。

• 过程比测试本身更有价值。

关注“是什么”

您必须关注“是什么”这个问题。在关注“是什么”时：

• 不要试图涵盖所有可能的案例。

• 不要忘记使用不同类型的测试。

• 保持示例尽可能简单。

• 示例应该易于系统用户理解。

• 工具不应在研讨会中扮演重要角色。

关注业务

为了关注业务：

• 将规范保持在业务意图层面。

• 让业务参与创建和审查规范。

• 将所有细节隐藏在自动化层中。

做好准备

为以下情况做好准备：

• 即使改变了团队实践，好处也不立即显现。

• 引入基于示例的规范 (SbE) 具有挑战性。

• 需要时间和投资。

• 自动化测试并非免费。

工具

基于示例的规范 (Specification by Example) 不强制要求使用工具，尽管实际上有许多工具可用。即使不使用工具，也有一些案例成功遵循了基于示例的规范。

以下工具支持基于示例的规范：

• Cucumber

• SpecFlow

• Fitnesse

• Jbehave

• Concordion

• Behat

• Jasmine

• Relish

• Speclog