我们最近开始使用BDD来编写我们的要求。它确实非常有用，它使分析师和开发人员之间的沟通变得更加容易。 （结合用户界面和旧学校要求）
现在我们正考虑用BDD编写测试用例。当我在网上搜索最佳实践时，我发现有很多不同的编写方式。
有一些例子：
问题几乎所有的例子都是针对非常简单的情况，另一方面我们想编写包含多个动作，多个系统输出（警告，错误等）和多个输出的场景。
我们正试图找出为以下场景编写BDD的最佳方法：
我们希望用户执行以下操作：
我们有这么长的故事的原因是，这是一种常见的情况，我们希望确保用户能够回到幸福的道路。
您认为使用BDD处理此类情景的最佳方式是什么？
答案 0 :(得分：11)
我会试着改写你在这里要求的东西，希望它能清除一些东西。
我们最近开始使用BDD编写我们的要求......现在我们正考虑用BDD编写测试用例。
我们最近开始使用示例来阐明我们的要求......现在我们正在考虑自动化这些示例。
当我在网上搜索最佳实践时，我会看到很多不同的编写方式。
当我在线搜索时，我会看到很多不同的背景，事件和结果。
（它不仅仅是在写作中;它在谈话中导致了写作。这就是你变异的原因;因为谈话真的很模糊。）
问题几乎所有的例子都是针对非常简单的案例
问题是，在过去，像我这样的早期采用者使用像登录这样的东西作为例子。
我们做错了。简单的例子实际上并不能帮助您理解BDD。整个美丽的是，当我们与了解问题的利益相关者（例如可能是安全或基础设施专家，他们并不仅仅适用于业务专家）交谈时，我们学会了一些东西。这是a talk关于我们在BDD早期做错的事情;你遇到了其中一些的成本。遗憾。
我在BDD的3个方面写了a whole blog post：探索，规范和测试。大多数人关注的是第二和第三，但第一是隐含的。探索很重要，围绕场景的对话是一种非常便宜的方式！
我们想编写包含多个操作，多个系统输出（警告，错误等）和多个输出的场景......我们之所以有这么长的故事是因为这是一个常见的场景，可以发生了，我们希望确保用户能够回到幸福的道路。
我们想检查完整的客户旅程，以确保我们的系统至少可用，无论发生什么。
因此，如果您想要使用像Cucumber这样的BDD工具来编写整个，全栈，自动化的客户旅程，而不是行为的一个方面（我们称之为场景）的单一示例，那么......它不是BDD。
然而， 仍然是个好主意。它不是BDD，但它并不意味着它是一件坏事。我和一些已经完成了这项工作的组织合作并从中受益。 （也许它应该有一个名字。）
以下是我根据以下经验给出的提示和提示：
不使用这些作为回归测试！尝试经历每一次旅程都是指数2 ^ n的努力;算了吧。选择几个旅程（每个理想会议3个似乎很典型）并尝试选择不同但典型的客户选择。不要用这些来测试边缘情况。您只是检查您的主要客户旅程仍然在一起缝合。
声明对命令仍然规则。避免谈论用户界面;根据每个阶段取得的成就来说明旅程。
如果您可以执行此操作，则可以重复使用较小方案中的步骤。将您的客户旅程（有时称为＆＃34;冒烟测试＆＃34;）放在一个单独的地方，即使它们在构建的同一部分中运行。首先运行它们，直到你不再需要它们为止（一个月左右的时间会让团队解决根本原因，环境问题等等。）
具体。它不只是＆＃34;用户＆＃34 ;;苏，这位路过的女孩在她的地图上使用你的多边形来试图发现她还没有抓到的小宠物。具体的故事真正吸引了人们的想象力，让旅程难忘。如果可以的话，让不同的旅程符合不同的角色。
通常＆＃34;然后＆＃34;一个场景构成了＃34;给定的＃34;另一个具有不同行为方面的人。如果您将它们串在一起，请不要担心＆＃34;然后＆＃34;。如果您要在下一步中使用它，则无需检查结果。例如，如果菜单需要显示特定的选择，请不要检查选择;只是使用它并假设它在那里。 UI检查可能是昂贵的，并且通过这些较长的旅程，我们应该在这些通常通过的地方。如果他们不是，那么在我们解决他们为什么会被打破的时期添加缺失的步骤是非常微不足道的。通常这些都是集成测试而不是任何东西;在运行较长的方案套件之前检查特定服务是否已连接等。
如果您的常见客户旅程包括用户感到困惑，做错事或浪费时间，请更改您的用户界面。用户体验专业知识仍然非常，非常重要，并且不是BDD的真正组成部分，因为很难为＃34; easy＆＃34;提供具体的例子。或者＆＃34;原谅＆＃34;与UI的比较和建议相比较。 BDD不是一颗银弹。
将整个客户旅程周围的对话中的文物记录下来，甚至遍布办公室的整个墙壁，这是很常见的。但是，自动版本通常在完成较小的方案并且功能正常工作后创建。
完整的端到端客户旅程与涵盖边缘情况等行为方面的较小方案之间通常存在重复。端到端的旅程提供快速反馈，确保没有人浪费时间;较小的方案提供了有关系统应如何运行的文档。在这种情况下复制是可以的。
如果您认为自己希望这是一次完整的旅程，那么我希望看到这种事情（我在这里做的就是＆＃34;陈述性与势在必行的事情：
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（我还没玩过）的理解，当它实际上有真实的想法时。这些旅程和较小的场景之间存在共同点。
你也会看到有很多很多人，他们都互相喂食。如果我们讨论行为的单个方面，那么每个方面都将以“给定的”为前提。概述了之前的内容，以及允许下一个＆＃34;何时＆＃34;将是＆＃34;然后＆＃34;。在这种情况下，虽然我们将它们链接在一起。不间断的序列＆＃34; whens＆＃34;在这些旅程中非常普遍且完全正常，只要你尊重这不是不看行为的一个方面，也不提供它的例子（所以它不是真的BDD）。 ＆＃34; Thens＆＃34;当结果是旅程的重要部分时，会出现中途旅行，特别是提供用户必须具体回应的非特定指导。
不要在误解的情况下自动化这些！自动化的客户旅程代表了一项重大投资（尽管一旦您拥有覆盖相同功能的较小方案，它们就很容易组合在一起）。首先获取功能，并将其显示给相关的利益相关者。你不想在可能随着学习和反馈而改变的事情上投入大量资金。
希望这有用，感谢让我想到这一点！
答案 1 :(得分：1)
处理长篇故事的最佳方式，就像在漫长的场景中一样，使用BDD并不是这样做的。
您想要做的是专注于应该实施的商业价值。其余的，授权，警告和类似的，应该在步骤的实现中处理，而不是在特征文件中明确。用户被授权可能不是业务代表真正关心的事情。他们只是假设执行特定任务时会出现这种情况。
您正在描述使用BDD作为测试工具。 BDD从来就不是一种测试工具，因此如果它是您真正需要的自动化测试，那么它是不合适的。
有一些博客文章，你可能有兴趣阅读，更多地谈论这个：