SBE(Specification By Example)实例化需求介绍

SBE 是什么？

SBE，Specification By Example（实例化需求），是一种以含义明确的例子来驱动软件开发的方式，它结合了多种概念、思想、实践和工具。我们可以说它是一种思想，来自于敏捷开发和行为驱动开发（BDD）等领域的心得和实践积累，特别是它对"example"（例子）作为沟通、设计、反馈和文档的工具，给了深刻的重视。

思想： Specification by Example 强调通过以用户的角度出发，用共同理解的例子来夯实需求的语义基础，以此去开展开发和测试------这是敏捷开发理念的体现。它以实例为中心，注重团队之间的协作和交流，尤其是细化需求时的协作------这是一种更高质量、更用户导向的思想。
规范： SBE 提出了一种详细程度、结构性和易验证性都较高的需求描述方法。同时，SBE 规定了一种遵循"Given-When-Then" 模式的例子描述和自动化测试用例编写的约定，也提出了例子应反映真实使用情景，满足所有关键路径，覆盖所有可能的输入组合等原则。
技术： SBE 实践了自动化测试，将例子转化为可以直接运行的测试代码，与此相关的如 Cucumber、FitNess、Jbehave 等工具提供了实现这一过程的技术支持。

综合起来， Specification by Example 是一种跨越需求沟通、开发设计、测试验证全阶段的开发理念与实践模式，提供了一整套的实践原则和工具手段，帮助我们以一种更加精确和有效的方式进行软件开发。

Specification by Example (SBE) 其实就是一种软件开发技术，一部分行为驱动开发 (BDD) 与测试驱动开发 (TDD) 理论的理想实践，通常用于开发者和业务团队合作开发软件产品的情况里。

在 SBE 中，团队从用户的角度考虑功能需求，然后创建多个真实集体的例子来规定预期的程序行为。这些例子衍生了具体的用户故事和验收准则，不仅作为产品规格说明书，也用作自动化测试的输入。这些例子的目的在于帮助业务团队清晰、明确地表达他们的需求，并成为一种和开发团队高效沟通的工具。

SBE 确保了所有团队成员在理解需求上达成一致，让开发和测试紧密结合，并能提供一份'活'规格文档，即介绍产品功能的同时，也是检验功能正确性的测试。这就使得规格文档产生了现实的价值，而不只是面向过程的输出。这是一个使产品管理与质量保证实现真正高效整合的方法。

SBE 的主要过程

说到SBE，就不得不说到一个人以及其的一本著作： Gojko Adzic，《Specification By Example》。

这本著作介绍了如何通过实例去分析和沟通需求。它是一组过程模式，可以协助软件产品的变更，确保有效地交付正确的产品。实例化需求的过程分为：

从目标中获取范围
用实例进行描述
精炼需求说明
自动化验证，无须改变需求说明
频繁验证
演进出一个文档系统

实施SBE的主要步骤

在 SBE 中，团队从用户的角度考虑功能需求，然后创建多个真实集体的例子来规定预期的程序行为。这些例子衍生了具体的用户故事和验收准则，不仅作为产品规格说明书，也用作自动化测试的输入。这些例子的目的在于帮助业务团队清晰、明确地表达他们的需求，并成为一种和开发团队高效沟通的工具，通常有以下几个主要步骤：

创建实例:通过对话和讨论，业务团队、开发团队和测试团队一起创建实例。
从实例中抽象出规格: 团队将具体的实例抽象为通用的规格。这些规格和关联的实例定义了预期的系统行为。
编写自动化测试: 团队在产品开发阶段就根据这些实例编写而自动化测试。
补全并优化代码: 开发者编写和优化代码，直到所有的自动化测试都通过。
使用实例的规格控制回归测试: 即使在产品发布后，也可以继续使用这些实例来进行回归测试和维护。

SBE 与BDD 的关系

Specification by Example (SBE) 和 Behavior-Driven Development (BDD) 是紧密相关并且有交叉的实践。基本来说，它们都是被设计用来帮助团队更好地理解、沟通需求并开发出符合预期的软件。

BDD最初是由 Dan North 在 2006 年提出来的，它是一种旨在解决测试驱动开发（TDD）中理解难题的新方法论。BDD 采用的是一种更自然语言的方式来描述软件的行为，其主要目的是为了促进开发人员、测试人员和非技术人员（如客户、利益相关者）之间的沟通和理解。其核心思想就是用通俗易懂的语言描述软件的行为，然后让这种描述转化为自动化的测试。

SBE由 Gojko Adzic 提出来，涵盖了 BDD 的一部分并在其基础上进行了扩展，着重于使用易于理解的例子来精确描述系统的行为。SBE 不仅关注于系统的行为，还强调通过提供例子来确保开发团队、测试团队和业务团队间达成一致的理解。这些例子既可以被用作需求文档，还可以被转换为自动化测试。

因此我们可以这样理解，BDD 为我们提供了一种理念和方法，去强调用户行为和期望的描述，而 SBE 则是这种理念在实际项目实践中的具体操作方式，通过明确的、具体的例子，来明确需求的语义，以此驱动需求设计、开发和测试等活动。

总的来说，BDD 和 SBE 都重视围绕实际业务需求进行协作和沟通，它们都认为，通过详细、准确且有代表性的例子，可以帮助团队更好地理解业务需求，实现贴近用户需要的软件产品。

SBE 与 Cucumber 的关系

Specification by Example（SBE）和 Cucumber 两者之间的关系可以看作是两种不同维度的一种对应或映射。

**Specification by Example (SBE) 是一种方法论或者说工作方式：**它是一种以含义明确的例子来驱动软件开发的方式。通过明确的、具体的例子，团队成员（包括产品经理、开发者、测试者等）共同理解和达成对需求的约定。然后，这些例子被转化为自动化测试，去驱动软件的开发。同时这些例子也形成了"活文档"，实时反映软件的行为。
**Cucumber 是一种工具，来实现 SBE：**Cucumber 是一款开源的，支持行为驱动开发（BDD）的工具，它允许开发人员使用自然语言（通过 Gherkin 语法）编写功能测试用例。这些用例可以写得就像是例子，非常适合用来实现 SBE 方法。最后，Cucumber 会用实现的步骤定义来运行这些例子，形成自动化测试。

所以说， SBE 是一种理念或者方法，描述我们应该如何去工作。而 Cucumber 是一款工具，帮助我们实现 SBE 明确描述的工作方式。在许多实践 SBE 的团队和项目中，Cucumber 是非常重要的一款工具。

实现 SBE的工具

实现 Specification by Example (SBE) 方法论的工具有很多种，选择哪一种工具通常取决于团队的技术偏好和使用的编程语言。下面是一些常见的工具：

Cucumber：这是一款非常流行的支持 Behavior-Driven Development (BDD) 的开源工具，特别适合用于实现 SBE。Cucumber 使用 Gherkin 语言编写测试用例，这种语言的语法简洁明了，并且相当接近自然语言，使得非技术背景的团队成员也可以容易地阅读和编写测试。
JBehave：这是一个 Java 的 BDD 框架，和 Cucumber 类似，也可以用于实现 SBE。JBehave 允许用例以用户故事的形式编写，是 Java 项目实施 SBE 的好选择。
SpecFlow：这是一个 .NET 的 BDD 框架，类似于 Cucumber，允许开发者用近乎自然语言的形式来描述测试的行为。
FitNesse：这是一个开源的测试框架，允许用户创建和维护描述软件行为的 Wiki 页面。它适用于任何支持 Slim 或 Fit 测试系统的编程语言。
Concordion：这又是一款开源工具，可通过描述性的 Markdown 或 HTML 格式的规格文档来定义测试。
Robot Framework：这是一个用 Python 编写的，但可以用关键字驱动测试的测试自动化框架。它不仅适用于接口测试，还适用于 GUI 测试和系统测试。

这些工具都有其自身的优点和特性，选择哪种工具应当依据团队的实际需要和技术栈来决定。

Python中可以帮助实现SBE的工具

在 Python 语言中，有几个主要的工具可以帮助你实现 Specification by Example (SBE)：

**Behave：**这是一个 Python 的 BDD (行为驱动开发) 框架，可以用来实现 SBE。Behave 使用 Gherkin 语言来描述用户故事和行为，并将这些描述翻译成自动化测试。
**Lettuce：**这也是一个用于 Python 的 BDD 框架。它借鉴了 Ruby 的 Cucumber 项目，提供了一个使用 Gherkin 语言来定义特性和场景的方式。
**PyCukes：**PyCukes 是另一个用于 Python 的 BDD 工具。它是一个非常轻量级的库，提供了一种书写顶层的验收测试的方式。
**pytest-bdd：**这是 pytest 的一个插件，它提供了 BDD 风格的场景在 pytest 中的实现，非常适合已经在使用 pytest 的项目。

推荐使用 Behave 或 pytest-bdd。

Gherkin 介绍

Gherkin 是一种领域特定语言，在行为驱动开发（BDD）中被广泛用来编写测试案例。它使用了一种简洁，易读的格式，使得开发者和非技术背景的人员都可以理解软件的行为。

Gherkin 是给Cucumber 工具开发的一个语言，因其简单和通用性，逐渐成为通用的描述语言。

基本的 Gherkin 语句把需求描述为多个场景，每个场景都是给定一些条件（Given），当某件事发生（When），然后应该有一些结果（Then）。

下面是一个 Gherkin 语句的例子：

Feature: Search function on the website

  Scenario: Search a known keyword
    Given I am on the main page
    When I enter "laptop" into the search field
    And I click the Search button
    Then I should see a list of laptops

关于Gherkin的语法，主要包括以下几个关键词：

Feature: 描述软件需要具备的特性。特性描述了一种功能，或者描述了一些相关的场景的集合。
Scenario: 描述一个具体的示例或者情境，一个特性通常包含一个或者多个场景。场景描述了给定一些初始条件和事件的情况下，软件预期的行为。
Given, When, Then, And, But: 这些关键词被用于描述场景。每一个手风琴分别是起始条件、动作和预期结果。

Gherkin 的语法是对白话语言的一种结构化表达，使得转化为自动化测试变得更简单，并作为"一份活的文档"有效地传达了业务规则的细节。

参考

Specification by Example在线版: https://livebook.manning.com/book/specification-by-example/table-of-contents/
业务系统开发------读"specification by example"有感
Cucumber介绍： https://cucumber.io/tools/cucumber-open/