根据“示例规范”的作者Gojko Adzic的说法，“示例规范”是一套过程模式，可促进软件产品的更改，以确保正确地交付正确的产品。”

“按实例指定”是一种协作方法，它基于捕获和说明需求(使用实际示例而不是抽象语句)来定义软件产品的需求和面向业务的功能测试。

示例说明–概述

通过示例进行规范的目的是集中于开发和交付优先的，可验证的业务需求。尽管“实例化规范”的概念本身是相对较新的概念，但它仅是对现有实践的重新表述。

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

• 启用可执行要求。

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

• 由跨职能团队创建。

• 抓住每个人的理解。

实例说明可以用作构建反映业务领域的自动化测试的直接输入。因此，“示例说明”的重点在于构建正确的产品和构建产品权利。

举例说明的目的

通过示例进行规范的主要目的是构建合适的产品。它着重于共同的理解，从而建立了单一的真理来源。它可以实现验收标准的自动化，从而使重点集中在缺陷预防而不是缺陷检测上。它还可以提早进行测试以及早发现缺陷。

SbE的使用

示例说明用于说明描述业务价值的预期系统行为。该插图是通过具体和现实生活中的示例进行的。这些示例用于创建可执行要求是-

• 可测试，无需翻译。

• 在实时文档中捕获。

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

• 它们更容易理解。

• 他们很难被误解。

SbE的优势

使用示例规范的优点是-

• 提高质量

• 减少浪费

• 降低生产缺陷的风险

• 集中精力

• 可以更安全地进行更改

• 改善业务参与

SbE的应用

通过示例规范找到应用程序-

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

• 对于纯粹的技术问题，效果不佳。

• 对于以UI为重点的软件产品，效果不佳。

• 也可以应用于旧系统。

SbE和验收测试

在验收测试方面，通过示例规范的优势是-

• 一个单独的图示用于详细的需求和测试

• 该项目的进展取决于验收测试-

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

  • 测试是否通过某种行为，或者没有通过。

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

  • 如果需要完成100个行为的项目已完成60个行为，则说明已完成60％。

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

• 自动化使您可以立即了解需求变更对解决方案的影响。

通过示例进行说明–不同角色的含义

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

SbE –一组过程模式

正如我们在本章开始所看到的那样，“示例规范”定义为一组过程模式，这些过程模式有助于软件产品的更改，以确保正确交付正确的产品。

流程模式是-

• 协作规范

• 使用示例说明规格

• 完善规格

• 自动化示例

• 经常验证

• 生活文件

协作规范

协作规范的目标是-

• 获得团队中的各种角色，以具有共同的理解和共同的词汇。

• 让每个人都参与该项目，以便他们可以对功能发表不同的看法。

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

这些目标是在规范研讨会上实现的，该研讨会也称为“三好友”会议。三个朋友是BA，QA和开发商。尽管项目中还有其他角色，但从定义到功能交付，这三个角色将是负责任的。

在会议期间-

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

• 三个Amigos(BA，Developer和QA)讨论了新功能并查看了规格。

• 质量检查人员和开发人员还可以确定缺少的要求。

• 三个朋友

  • 使用通用语言使用共享模型。

  • 使用域词汇表(如果需要，维护词汇表)。

  • 寻找差异和冲突。

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

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

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

• 需求以方案的形式提出，提供了明确，明确的要求。从用户的角度来看，场景是系统行为的一个示例。

使用示例说明规范

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

给定<某些先决条件>

和<其他前提条件>可选

当<动作/触发发生>

然后<某些后期条件>

和<其他职位条件>可选

该规范是系统行为的示例。它还代表系统的接受标准。

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

完善规格

为了完善规范，

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

• 着眼于业务角度，避免使用技术细节。

• 同时考虑正面和负面条件。

• 遵守特定领域的词汇。

• 与客户讨论示例。

  • 选择对话即可完成此任务。

  • 仅考虑客户感兴趣的那些示例。这仅能生成所需的代码，并且避免覆盖可能不需要的所有可能组合。

• 为了确保该方案通过，该方案的所有测试用例都必须通过。因此，请增强规格以使其可测试。测试用例可以包括各种范围和数据值(边界和极端情况)以及导致数据更改的不同业务规则。

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

• 包括非功能性场景(例如性能，负载，可用性等)，作为示例规范

自动化示例

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

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

经常验证

每次更改(添加/修改)时，请在开发管道中包括示例验证。有很多技术和工具可以(并且应该)用来帮助确保产品质量。他们围绕三个关键原则进行围绕：早期测试，正常测试和经常测试。

经常执行测试，以便您可以识别薄弱环节。表示行为的示例有助于跟踪进度，并且仅在相应的测试通过之后，行为才被称为是完整的。

生活文件

保持规格尽可能简短。组织规范并随着工作的进行而发展。使文档可供团队中的所有人访问。

通过示例过程步骤进行规范

该图显示了“示例说明”中的处理步骤。

反模式

反模式是软件开发中的某些模式，被认为是不良的编程习惯。设计模式是解决常见问题的常用方法，已经被形式化并且通常被认为是良好的开发实践，而反模式则相反，这是不希望的

反模式引起各种问题。

解决问题的方法-质量

可以通过观看反模式来确保质量。为了最小化反模式所产生的问题，您应该-

• 聚在一起使用示例进行说明。

• 清理并改进示例。

• 编写一个满足示例的代码

• 使示例自动化并进行部署。

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

解决由于反模式导致的问题意味着遵守-

• 合作。

• 专注于什么。

• 专注于业务。

• 做好准备

让我们了解上述每个含义。

合作

在合作中-

• 商界人士，开发人员和测试人员从各自的角度提出意见。

• 自动化的例子证明了团队已经建立了正确的东西。

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

专注于什么

您必须关注“什么”问题。在专注于“什么”时-

• 不要试图涵盖所有可能的情况。

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

• 保持示例尽可能简单。

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

• 工具在研讨会上不应起重要作用。

专注于业务

专注于业务-

• 保持规范符合业务意图。

• 将业务包括在创建和审查规范中。

• 隐藏自动化层中的所有详细信息。

做好准备

为以下做好准备-

• 即使团队实践发生了变化，收益也不会立即显现。

• 引入SbE具有挑战性。

• 需要时间和投资。

• 自动化测试不是免费的。

工具类

尽管在实践中有几种工具可用，但对于示例性规范并非强制使用工具。在某些情况下，即使不使用工具，也可以成功地遵循“按示例规范”。

以下工具支持示例规范-

• 黄瓜

• 规格流程

• Fitnesse

• 行为

• 协和

• 贝哈特

• 茉莉花

• 津津有味

• 规格日志