BDD - 规范示例

根据《实例化需求说明》一书的作者 Gojko Adzic 的说法，实例化需求说明是一组过程模式，可以促进软件产品的变更，以确保高效地交付正确的产品。

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

示例规范 – 概述

示例需求说明的目标是专注于开发和交付优先化的、可验证的业务需求。虽然示例需求说明的概念本身相对较新，但它只是对现有实践的重新表述。

它支持一种非常具体、简洁的词汇，称为无处不在的语言 -

  • 启用可执行的要求。

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

  • 由跨职能团队创建。

  • 得到了大家的理解。

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

举例说明的目的

实例化需求说明的主要目的是构建正确的产品。它注重共同理解，从而建立单一的事实来源。它可以实现验收标准的自动化，以便重点关注缺陷预防而不是缺陷检测。它还提倡尽早测试，尽早发现缺陷。

锑化硼的用途

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

  • 无需翻译即可测试。

  • 在实时文档中捕获。

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

  • 它们更容易理解。

  • 它们更难被误解。

SbE的优点

使用实例说明的优点是 -

  • 提高质量

  • 减少浪费

  • 降低生产缺陷的风险

  • 集中精力

  • 可以更安全地进行更改

  • 提高业务参与度

SbE的应用

示例规范在以下领域找到应用：

  • 要么是复杂的业务，要么是复杂的组织。

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

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

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

SbE 和验收测试

示例规范在验收测试方面的优点是 -

  • 一张插图用于详细需求和测试

  • 该项目的进展是在验收测试方面 -

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

    • 测试要么通过某种Behave，要么不通过。

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

    • 如果一个需要完成 100 个Behave的项目完成了 60 个Behave，那么它就完成了 60%。

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

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

示例规范 – 对于不同角色意味着什么

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

角色 锑化硼的用途
业务分析师

  • 要求明确且没有功能差距。

  • 开发人员，实际阅读规范。
开发商

  • 开发人员更好地了解正在开发的内容。

  • 通过计算已正确开发的规范，可以更好地跟踪开发进度。
测试员

  • 测试人员更好地了解正在测试的内容。

  • 测试人员从一开始就参与其中并在设计中发挥作用。

  • 测试人员致力于缺陷预防而不是缺陷检测。
每个人

  • 从一开始就识别错误可以节省时间。

  • 优质的产品是从一开始就生产出来的。

SbE – 一组过程模式

正如我们在本章开头所看到的，示例需求说明被定义为一组过程模式，这些模式促进软件产品的变更，以确保有效地交付正确的产品。

流程模式是 -

  • 协作规范

  • 使用示例说明规格

  • 细化规范

  • 自动化示例

  • 经常验证

  • 生活文档

协作规范

协作规范的目标是 -

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

  • 让每个人都参与到项目中，以便他们可以就某个功能贡献自己的不同观点。

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

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

会议期间 -

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

  • 三位好友（BA、开发人员和 QA）讨论新功能并审查规范。

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

  • 三个朋友

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

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

    • 寻找差异和冲突。

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

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

  • 共同的需求意识和测试所有权有利于质量规范

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

使用示例说明规范

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

给定<一些前提>

并且<附加前提条件>可选

当<动作/触发发生>时

然后<一些后置条件>

并且<附加后置条件>可选

该规范是系统Behave的示例。它还代表系统的验收标准。

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

细化规范

为了完善规范，

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

  • 专注于业务角度，避免技术细节。

  • 考虑积极和消极的条件。

  • 遵守特定领域的词汇。

  • 与客户讨论示例。

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

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

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

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

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

自动化示例

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

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

经常验证

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

经常执行测试，以便识别薄弱环节。代表Behave的示例有助于跟踪进度，只有在相应的测试通过后，Behave才被称为完成。

生活文档

使规格尽可能简单和简短。组织规范并随着工作的进展不断完善它们。使团队中的所有人都可以访问文档。

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

该图显示了示例需求说明中的流程步骤。

生活文档

反模式

反模式是软件开发中的某些模式，被认为是不好的编程实践。设计模式是解决常见问题的常用方法，已被形式化，通常被认为是一种良好的开发实践，而反模式则相反，是不可取的

反模式会引起各种问题。

反模式 问题
没有合作

  • 许多假设

  • 构建错误的东西

  • 测试错误的东西

  • 不知道代码何时完成
不知道代码何时完成

  • 难以维护测试

  • 很难理解规格

  • 业务代表失去兴趣
过于详细或过于以 UI 为中心的示例

  • 难以维护测试

  • 难以理解的规格

  • 业务代表失去兴趣
低估所需的努力

  • 团队认为他们失败了并且很早就感到失望

问题的解决方案——质量

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

  • 聚在一起使用示例来指定。

  • 清理并改进示例。

  • 编写一段代码，满足示例

  • 自动化示例并部署。

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

要解决因反模式引起的问题意味着坚持 -

  • 合作。

  • 专注于什么。

  • 专注于商业。

  • 做好准备。

让我们了解以上每一项的含义。

合作

合作中 -

  • 业务人员、开发人员和测试人员从自己的角度提供意见。

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

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

专注于什么

你必须关注这个问题——“什么”。专注于“什么” -

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

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

  • 使示例尽可能简单。

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

  • 工具不应在研讨会中发挥重要作用。

专注于商业

专注于业务 -

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

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

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

做好准备

做好以下准备 -

  • 即使团队做法发生了变化，好处也不会立即显现出来。

  • 引入 SbE 具有挑战性。

  • 需要时间和投资。

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

工具

尽管实际上有多种工具可用，但示例需求说明并不强制使用工具。有些案例即使不使用工具也能成功遵循示例需求说明。

以下工具支持示例说明 -

  • Cucumber

  • 规格流

  • 健身

  • Behave举止

  • Concordion

  • 贝哈特

  • 茉莉花

  • 津津有味

  • 光谱记录