我将尝试改写您在这里要求的内容，希望它能解决一些问题。
我们最近开始使用 BDD 来编写我们的需求...现在我们正在考虑使用 BDD 编写我们的测试用例。
我们最近开始使用示例来阐明我们的要求...现在我们正在考虑自动化这些示例。
当我在网上搜索最佳实践时，我看到了很多关于如何编写它的不同变化。
当我在线搜索时，我看到了很多不同的背景、事件和结果。
（不只是在写作中；在导致写作的对话中。这就是为什么你会得到变化；因为对话真的很模糊。）
问题是几乎所有的例子都是针对非常简单的案例
问题在于，在过去，像我这样的早期采用者使用诸如登录之类的东西作为示例。
我们这样做是错误的。简单的示例实际上并不能帮助您理解 BDD。整个美妙之处在于，当我们与了解问题的利益相关者（例如，他们可能是安全或基础架构专家；它不仅适用于业务专家）交谈时，我们学到了一些东西。下面是a talk，关于我们在 BDD 早期做错的事情；你遇到了其中一些的成本。对不起。
我写了a whole blog post 关于 BDD 的 3 个方面：探索、规范和示例测试。大多数人专注于其中的第二和第三，但第一是隐含的。探索很重要，围绕场景进行对话是一种非常便宜的方式！
我们想编写包含多个操作、多个系统输出（警告、错误等）和多个输出的场景......我们之所以有这么长的故事是因为这是一个可能发生的常见场景，并且我们希望确保用户能够回到快乐的道路上。
我们希望检查完整的客户旅程，以确保我们的系统至少可用，无论发生什么其他情况。
因此，如果您想使用 Cucumber 之类的 BDD 工具来编写一个完整的、全栈的、自动化的客户旅程，而不是单个行为方面的示例（我们称之为场景），那么...... . 这不是 BDD。
然而，它是仍然是一个非常好的主意。这不是 BDD，但这并不意味着它是一件坏事。我曾与许多这样做过并从中受益的组织合作过。 （也许它应该有一个名字。）
以下是我可以根据该经验为您提供的提示和技巧：
不要不要将这些用作回归测试！尝试完成每一次旅程是指数级的 2^n 努力；忘了它。选择一些旅程（每个理想会话 3 次似乎很典型）并尝试选择不同但典型的客户选择。不要使用这些来测试边缘情况。您只是在检查您的主要客户旅程是否仍然缝合在一起。
声明式优于命令式静止规则。避免谈论 UI；根据每个阶段所取得的成就来描述旅程。
如果您能做到这一点，您就可以在较小的场景中重复使用您的步骤。将您的客户旅程（有时称为“冒烟测试”）放在一个单独的位置，即使它们在构建的同一部分中运行。首先运行它们，直到您不再需要（这些中断中的一个月左右将使团队解决根本原因、环境问题等！）。
要具体。这不仅仅是“用户”；是苏，在路上的那个女孩，她在她的地图上使用你的多边形来试图发现她还没有抓到的口袋妖怪。具体的故事真的能抓住人们的想象力，让旅程令人难忘。如果可以的话，让不同的旅程匹配不同的角色。
通常情况下，一个场景的“那么”会形成具有不同行为方面的另一个场景的“给定”。如果您将它们串在一起，请不要担心“然后”。如果您要在下一步中使用它，则无需检查结果。例如，如果一个菜单需要显示一个特定的选项，不要检查选项；只需使用它并假设它就在那里。 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.
使用具体示例。当它实际上有真正的想法时，更容易理解和看到上面的缺陷，或者根据我对 Pokemon Go（我还没有玩过）的理解。这是这些旅程和较小场景之间的共同点。
您还会看到有很多很多“时间”，它们都相互影响。如果我们讨论行为的单个方面，每个方面都将以“给定”开头，概述之前发生的情况，而允许下一个“何时”的结果将是“当时”。在这种情况下，尽管我们将它们链接在一起。在此类旅程中，不间断的“何时”序列非常常见且完全可以，只要您尊重这不是在查看行为的单个方面，也不是提供它的示例（所以它是不是真正的 BDD）。当结果是旅程的重要组成部分时，会出现“然后”中间旅程，特别是提供用户必须具体响应的非特定指导。
如果存在误解，不要将这些自动化！自动化的客户旅程代表了一项重大投资（尽管一旦您拥有涵盖相同功能的较小场景，它们就很容易组合在一起）。首先让功能发挥作用，并将其展示给相关的利益相关者。您不想在可能会因学习和反馈而改变的事情上投入巨资。
希望这对您有所帮助，并感谢您让我思考这个问题！