我是 BDD 的新人。所以我对场景有一些疑问？ BDD 场景和用户场景之间有什么区别？与传统所谓的“用户场景”或“用例”有明显区别吗？你能解释一下吗？
最佳答案
由于您刚才提到的“传统用户场景”有点含糊，我假设您指的是用户故事描述:
As a [Role]
I want [Goal]
So that [Result/Benefit]
那是用户故事描述，它需要描述用户应该如何与系统一起行动的场景。这可以通过多种方式完成。其中之一可能是 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 .
关于bdd - 行为驱动开发 (BDD) 场景与用户场景或用例差异？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35440948/