BDD - 规范示例
根据《实例需求说明》一书的作者 Gojko Adzic 的说法，实例需求说明是一组过程模式，可以促进软件产品的变更，以确保高效地交付正确的产品。"
示例规范是一种协作方法，用于定义软件产品的需求和面向业务的功能测试，其基础是使用实际示例而不是抽象语句来捕获和说明需求。
示例规范 - 概述
实例化需求说明的目标是专注于开发和交付优先化的、可验证的业务需求。 虽然示例需求说明的概念本身相对较新，但它只是对现有实践的改写。
它支持一种非常具体、简洁的词汇，称为通用语言， −
启用可执行要求。
由团队中的每个人使用。
由跨职能团队创建。
获得每个人的理解。
示例规范可以用作构建反映业务领域的自动化测试的直接输入。 因此，实例化需求说明的重点是构建正确的产品并构建正确的产品。
示例规范的目的
实例化需求说明的主要目的是构建正确的产品。 它注重共同理解，从而建立单一的事实来源。 它可以实现验收标准的自动化，以便重点关注缺陷预防而不是缺陷检测。 它还提倡尽早测试，尽早发现缺陷。
SbE 的使用
示例规范用于说明描述业务价值的预期系统行为。 说明是通过具体和现实生活中的例子来进行的。 这些示例用于创建可执行需求 −
无需翻译即可测试。
在实时文档中捕获。
以下是我们使用示例来描述特定规格的原因 −
它们更容易理解。
它们更难被误解。
SbE 的优势
使用示例需求说明的优点是 −
提高质量
减少浪费
降低生产缺陷的风险
集中精力
可以更安全地进行更改
提高业务参与度
SbE 的应用
示例规范在以下领域中查找应用 −
复杂的业务或复杂的组织。
对于纯粹的技术问题效果不佳。
不适用于以 UI 为中心的软件产品。
也可以应用于旧系统。
SbE 和验收测试
实例化需求说明在验收测试方面的优点是 −
一张插图用于详细需求和测试
项目的进展取决于验收测试−
每个测试都是为了测试一种行为。
测试要么通过某种行为，要么不通过。
通过测试表示特定行为已完成。
如果一个需要完成 100 个行为的项目完成了 60 个行为，那么它就完成了 60%。
测试人员从缺陷修复转向缺陷预防，他们为解决方案的设计做出贡献。
自动化可以立即了解需求变更对解决方案的影响。
示例规范 - 对于不同角色意味着什么
示例需求说明的目标是促进团队中每个人(包括整个项目中的客户)的协作，以交付业务价值。 为了更好地理解，每个人都使用相同的词汇。
| 角色 | 使用 SbE |
|---|---|
| 业务分析师 |
|
| 开发者 |
|
| 测试人员 |
|
| 所有人 |
|
SbE – 一组流程模式
正如我们在本章开头所看到的，示例需求说明被定义为一组过程模式，可促进软件产品的变更，以确保有效地交付正确的产品。
流程模式是 −
协作规范
使用示例说明规格
完善规范
自动化示例
经常验证
实时文档
协作规范
协作规范的目标是 −
让团队中的不同角色达成共识并共享词汇。
让每个人都参与到项目中，以便他们能够就某个功能贡献自己的不同观点。
确保共享沟通和功能所有权。
这些目标是在规范研讨会(也称为"三个朋友会议")中实现的。 三个朋友是 BA、QA 和开发人员。 尽管项目中还有其他角色，但这三个角色将从定义到功能交付负责。
会议期间 −
业务分析师 (BA) 提出新功能的要求和测试。
三位好友(BA、开发人员和 QA)讨论新功能并审查规范。
QA 和开发人员还会识别缺失的需求。
三位好友
使用通用语言来利用共享模型。
使用领域词汇(如果需要，可维护词汇表)。
寻找差异和冲突。
此时不要跳转到实现细节。
就某个功能是否已充分指定达成共识。
对需求和测试所有权的共同认识有助于制定质量规范
需求以场景的形式呈现，提供了明确、明确的需求。 场景是从用户角度来看系统行为的示例。
使用示例说明规范
使用 Give-When-Then 结构指定场景以创建可测试的规范 −
Given <some precondition>
And <additional preconditions> Optional
When <an action/trigger occurs>
Then <some post condition>
And <additional post conditions> Optional
此规范是系统行为的示例。 它还代表了系统的验收标准。
团队讨论示例并合并反馈，直到就示例涵盖功能的预期行为达成一致。 这确保了良好的测试覆盖率。
完善规范
要完善规范，
准确地书写示例。 如果示例变得复杂，请将其拆分为更简单的示例。
关注业务角度并避免技术细节。
同时考虑积极和消极条件。
遵守领域特定词汇。
与客户讨论示例。
选择对话来完成此任务。
仅考虑客户感兴趣的示例。这样可以仅生成所需的代码，并避免覆盖可能不需要的所有可能组合
为了确保场景通过，该场景的所有测试用例都必须通过。 因此，增强规范以使其可测试。 测试用例可以包括各种范围和数据值(边界和极端情况)以及导致数据更改的不同业务规则。
指定其他业务规则，例如复杂计算、数据操作/转换等。
包含非功能性场景(例如性能、负载、可用性等)作为示例规范
自动化示例
自动化层需要保持非常简单——只需将规范连接到被测系统即可。 您可以使用工具来实现同样的目的。
使用领域特定语言 (DSL) 执行测试自动化，并显示输入和输出之间的清晰连接。 专注于规范，而不是脚本。 确保测试精确、易于理解和可测试。
经常验证
在每次更改(添加/修改)时，在开发管道中包含示例验证。 可以(并且应该)采用许多技术和工具来帮助确保产品的质量。 它们围绕三个关键原则 - 尽早测试、良好测试和经常测试。
经常执行测试，以便识别薄弱环节。 代表行为的示例有助于跟踪进度，只有在相应的测试通过后，行为才被称为完成。
实时文档
使规格尽可能简单和简短。 组织规范并随着工作的进展不断完善它们。 使团队中的所有人都可以访问文档。
示例流程步骤规范
插图显示了示例需求说明中的流程步骤。
反模式
反模式是软件开发中的某些模式，被认为是不好的编程实践。 设计模式是解决常见问题的常用方法，已经被形式化，通常被认为是一种良好的开发实践，而反模式则相反，是不可取的
反模式会引起各种问题。
| 反模式 | 问题 |
|---|---|
| 无协作 |
|
| 不知道代码何时完成 |
|
| 过于详细或过于以 UI 为中心的示例 |
|
| 低估了所需的努力 |
|
问题的解决方案 - 质量
通过密切关注反模式可以确保质量。 为了最大限度地减少反模式造成的问题，您应该 −
一起使用示例来指定。
清理并改进示例。
编写一段代码，满足示例
自动化示例并部署。
对每个用户故事重复该方法。
解决反模式带来的问题意味着坚持 −
协作。
专注于什么。
专注于业务。
做好准备。
让我们了解以上各项的含义。
协作
合作中 −
业务人员、开发人员和测试人员从自己的角度提供意见。
自动化示例证明团队构建了正确的东西。
这个过程比测试本身更有价值。
关注什么
您必须关注"什么"这个问题。同时关注"什么" −
不要试图涵盖所有可能的情况。
不要忘记使用不同类型的测试。
示例尽可能简单。
示例应该易于系统用户理解。
工具不应在研讨会中发挥重要作用。
专注于业务
专注于业务 −
保持规范符合业务意图。
让业务参与制定和审查规范。
隐藏自动化层中的所有详细信息。
做好准备
做好以下准备 −
即使团队做法发生改变，好处也不会立即显现出来。
引入 SbE 具有挑战性。
需要时间和投资。
自动化测试并不是免费的。
工具
尽管实际上有多种工具可用，但示例规范并不强制使用工具。 有些案例即使不使用工具也能成功遵循示例需求说明。
以下工具支持示例说明 −
Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog
