行为驱动开发（BDD）方案与用户方案或用例差异？

Question

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

Answer 1

既然您刚刚提到了“常规用户方案”，这有点含糊，所以我假设您的意思是用户案例描述：

作为[角色]，
我想要[目标]
，以便[结果/优点]

那就是用户故事的描述，这需要描述用户应该如何在系统中表现的方案。这可以通过多种方式来完成。其中之一可能是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离开，那么无论在房间中正在进行什么过程，输入和输出或行为都是相同的。系统不应仅仅因为有人将房间从正方形更改为圆形而中断。那是过程的改变，而不是行为的改变。

另外，在此处查看此帖子。