我们最近开始使用BDD来编写我们的需求。这真的很有帮助，它让分析师和开发人员之间的沟通变得容易多了。(结合用户界面和老派要求)
现在我们正在考虑用BDD编写测试用例。当我在网上搜索最佳实践时，我看到了很多关于如何编写的不同变体
例如：
- 给定>和
- Given>And(s)>When>Then>And
问题是几乎所有的例子都是针对非常简单的情况，另一方面，我们希望编写包括多个操作、多个系统输出(警告、错误等)和多个输出的场景。
我们正试图找出为以下场景编写BDD的最佳方法：
- 我们需要检查用户是否获得授权
- 并且他/她在正确的模块中
我们希望用户执行以下操作：
- 用户设置开始日期
- 用户设置结束日期
- 用户选择类别
- 用户选择子类别(基于所选类别)
- 用户单击"运行">
- 系统发出警告，因为地图上没有多边形
- 用户关闭警告
- 用户在地图上绘制多边形(绘制多边形的每个步骤都在后台进行验证，并在地图上进行可视化渲染)
- 用户停止绘图
- 用户单击"运行">
- 系统生成图表
我们之所以有这么长的故事，是因为这是一种可能发生的常见情况，我们希望确保用户能够回到快乐的道路上。
您认为使用BDD处理这种情况的最佳方式是什么？
我将尝试重新表述您在这里的要求，希望它能澄清一些问题。
我们最近开始使用BDD来编写我们的需求。。。现在我们正在考虑用BDD编写测试用例。
我们最近开始使用示例来澄清我们的需求。。。现在我们正在考虑将这些示例自动化。
当我在网上搜索最佳实践时，我看到了很多关于如何编写的不同变体。
当我在网上搜索时，我看到了很多不同的上下文、事件和结果。
(这不仅仅是在写作中，而是在对话中导致写作。这就是为什么你会有变化；因为对话真的很模糊。)
问题是几乎所有的例子都是针对非常简单的情况
问题是，在过去，像我这样的早期采用者使用登录之类的东西作为例子。
我们这样做是错误的。简单的例子实际上并不能帮助你理解BDD。整个美妙之处在于，当我们与了解问题的利益相关者(例如，他们可能是安全或基础设施专家；这不仅仅适用于业务专家)交谈时，我们学到了一些东西。以下是关于BDD早期我们做错的事情的演讲；你会遇到其中一些的成本。很抱歉
我写了一整篇关于BDD的三个方面的博客文章：探索、规范和示例测试。大多数人关注的是其中的第二个和第三个，但第一个是隐含的。探索很重要，围绕场景进行对话是一种非常便宜的方式！
我们想编写包括多个操作、多个系统输出(警告、错误等)和多个输出的场景。。。我们之所以有这么长的故事，是因为这是一种可能发生的常见情况，我们希望确保用户能够回到快乐的道路上。
我们希望检查客户的完整旅程，以确保我们的系统至少可用，无论发生什么情况。
因此，如果你想使用Cucumber等BDD工具来编写一个完整的、全栈的、自动化的客户旅程，而不是行为的一个方面的一个例子(我们称之为场景)，那么。。。它不是BDD。
然而，仍然是一个非常好的主意。这不是BDD，但并不意味着这是一件坏事。我曾与许多组织合作过，他们做过这件事并从中受益。(也许它应该有一个名字。)
以下是我可以根据经验给你的提示和提示：
-
Donot使用这些作为回归测试！尝试走过每一段旅程都是一种指数级的努力；忘了它。选择几次旅程(每个理想的会话3次似乎很典型)，并尝试选择不同但典型的客户选择。不要用这些来测试边缘案例。你只是在检查你的主要客户旅程是否仍然缝合在一起。
-
声明而非命令的静止规则。避免谈论UI；用每个阶段所取得的成就来描述这段旅程。
-
如果你能做到这一点，你就可以重用你的小场景中的步骤。将您的客户旅程(有时称为"烟雾测试")放在一个单独的地方，即使它们在构建的同一部分运行。首先运行它们，直到您不再需要(一个月左右的这些中断将使团队解决根本原因、环境问题等！)。
-
具体一点。它不仅仅是"一个用户"；是苏，一个在路上的女孩，她正在用你在地图上的多边形来寻找她还没有抓到的口袋妖怪。具体的故事确实吸引了人们的想象力，使旅程令人难忘。如果可以的话，让不同的旅程与不同的人物角色相匹配。
-
通常，一个场景的"当时"形成了另一个具有不同行为方面的场景的"给定"。如果你把它们串在一起，不要担心"然后"。如果你打算在下一步中使用它，你不需要检查结果。例如，如果菜单需要显示特定的选项，不要检查该选项；只要使用它并假设它就在那里。UI检查可能很昂贵，而且由于行程较长，我们应该在一个通常可以通过的地方。如果它们不是，那么在我们找出它们为什么坏掉的这段时间里，添加缺失的步骤是非常琐碎的。通常，这些都是集成测试；在运行较长的场景套件之前，检查特定服务是否已连接等。
-
如果你的常见客户旅程包括用户感到困惑、做错事或浪费时间，请更改你的用户界面。用户体验专业知识仍然非常非常重要，并不是BDD的一部分，因为与UI的比较和建议相比，很难想出"简单"或"宽容"的具体例子。BDD不是银弹。
-
将客户全程对话中的工件写下来，甚至散布在办公室的整面墙上，这是非常常见的。然而，自动化版本通常是在之后创建的，较小的场景已经完成，功能正在运行。
-
完整的端到端客户旅程和涵盖边缘案例等行为方面的较小场景之间通常存在重复。端到端的旅程提供快速反馈，确保没有人浪费时间；较小的场景提供了有关系统应该如何运行的文档。在这种情况下复制是可以的。
如果你决定要这是一次完整的旅程，下面是我希望看到的事情(我在这里所做的只是"声明性与命令性"的事情)：
Given Sue's registered to catch Pokemons
And Bulbasaurs, Koffings and Pikachus were caught in Trafalgar square this year
When she filters for Pokemons caught between January and July
And adds a filter for "Poison" traits
And filters for "Bulbasaur"
When she searches for Pokemons
Then she should be asked to select an area of the map
When she selects an area around Trafalgar Square
Then she should be shown the Bulbasaur density
But not the Pikachu or Koffing density.
使用具体示例。当《精灵宝可梦Go》(我还没有玩过)中有现实的想法时，我更容易理解和看到上面的缺陷，或者我对它的理解。这是这些旅程和较小场景的共同点。
你还会看到有很多很多"何时"，它们都相互影响。如果我们讨论的是行为的单一方面，每一个方面都会以一个"给定"作为开头，概述之前发生的事情的背景，以及允许下一个"何时"成为"当时"的结果。在这种情况下，尽管我们将它们链接在一起。不间断的"何时"序列在这类旅程中非常常见，而且完全可以，只要你尊重这不是观察行为的单一方面，也不是提供行为的例子(所以这不是真正的BDD)。当结果是旅程的重要组成部分时，就会出现"Thens"中途，特别是提供用户必须具体回应的非特定指导。
不要因为误解而自动执行这些！自动化的客户旅程是一项重大投资(尽管一旦您有涵盖相同功能的较小场景，就很容易将其组合在一起)。首先让功能发挥作用，并将其展示给相关的利益相关者。你不想在那些可能随着学习和反馈而改变的事情上投入巨资。
希望这对我有帮助，谢谢你让我仔细思考！
处理长故事的最佳方法，就像在长场景中一样，使用BDD不是这样做。
您想做的是关注应该实现的busniess值。其余部分、授权、警告和类似内容应在步骤的实现中处理，而不是在功能文件中显式处理。用户获得授权可能不是业务代表真正关心的问题。他们只是假设在执行特定任务时会出现这种情况。
您正在描述使用BDD作为测试工具。BDD从来就不是一个测试工具，因此，如果它是你真正想要的独立测试，它就不适合。
你可能有兴趣阅读一些关于的博客文章
- https://cucumber.io/blog/2016/07/20/where_should_you_use_bdd
- http://www.thinkcode.se/blog/2016/07/25/the-right-tool-for-the-job
- http://www.thinkcode.se/blog/2016/06/22/cucumber-antipatterns