bdd - 行为驱动开发 (BDD) 场景与用户场景或用例差异？

Question

我是 BDD 的新人。所以我对场景有一些疑问？ BDD 场景和用户场景之间有什么区别？与传统所谓的“用户场景”或“用例”有明显区别吗？你能解释一下吗？

Answer 1

由于您刚才提到的“传统用户场景”有点含糊，我假设您指的是用户故事描述:

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 .