【发布时间】：2016-02-16 19:04:26
【问题描述】：
我是 BDD 的新人。所以我对场景有一些疑问？ BDD场景和用户场景有什么区别？与所谓的传统“用户场景”或“用例”有明显区别吗？你能解释一下吗？
【问题讨论】：
-
请举例说明您对“BDD 场景”和“用户场景”的看法。我不确定你对“传统用户场景”的定义，所以我无法帮助你。我需要更多的例子或上下文。可能两者兼而有之。
【发布时间】：2016-02-16 19:04:26
【问题描述】：
由于您刚刚提到的“常规用户场景”有点含糊，我假设您的意思是用户故事描述：
作为[角色]
我要[目标]
这样[结果/收益]
那是用户故事描述，它需要描述用户应该如何使用系统的场景。这可以通过多种方式完成。其中之一可能是 BDD。现在，BDD 并没有特别定义必须如何编写他们的场景。它所定义的只是
- 开发人员、测试人员和业务人员之间应该有清晰的沟通
- 此通信应采用所有人都能理解的简单格式
- 应在沟通中使用示例来指定和明确要求
第一点确保要求没有歧义，并且三个团队之间可以快速共享反馈。 第二点确保每个人都使用一种所有人都可以理解的语言，并且不会给每个人留下歧义。例如，测试人员可能会将场景编写为
When I drop a file to FTP location, then it's FTP information should be validated and file should be sent
但企业可能不熟悉 FTP/FTP 位置/信息验证是什么。更好的方法是使用领域特定语言 (DSL) 制作您的场景，例如
When a file is dropped in send location, then validate it's credentials and send the file
实现上述两点的一种方法是使用 Gherkin 语言。 Gherkin 是一种 DSL 语言，其语法如下：
Given [Precondition]
When [Action]
Then [Result]
扩展我们之前的例子：
Given user drops file "sample.txt"in "Send File" location
When the credentials for file "sample.txt" are validated
Then the "sample.txt" should be sent to "Receive File" location
如您所见，它与我们之前的示例几乎相同，只是我们使用了一个用户删除文件的示例，从而大大减少了歧义；也使用的语言本质上不是技术性的，但所有人都可以理解。
同样可以写成Verify that file FTP credentials are valid and fie is sent through FTP 但是在这里我们可能会错过前提条件，或者可能需要的最终结果可能是模棱两可的。而且语言更具技术性，因此企业无法理解。并且业务没有提供任何示例来解释他们真正想要什么，所以我们的场景可能与业务真正想要什么无关。
为避免所有这些混淆，BDD 建议业务部门、测试人员和开发人员坐在一起，一起写下特性和场景。这允许交叉问题、示例和快速反馈。这样做的另一个优点是，随着业务参与这些场景的制作，场景的重点将更多地集中在系统的行为上，而不是系统的技术方面。如果一个系统是 A 进入一个房间 B 离开，那么无论房间里做什么过程，输入和输出，或者行为都是一样的。系统不应该仅仅因为有人将房间从方形变为圆形而中断。那是过程的改变，而不是行为的改变。
另外，请查看此帖子 here。
【讨论】：