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

Question

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

Answer 1

由于您刚刚提到过＆＃34;传统的用户场景＆＃34;这有点模糊，我假设你的意思是用户故事描述：

  

作为[角色]
  我想要[目标]
  所以[结果/效益]

这是用户故事描述，需要描述用户应该如何使用系统行为的方案。这可以通过多种方式完成。其中一个可能是BDD。现在，BDD并没有特别定义如何编写场景。所有它定义的是

• 开发人员，测试人员和业务部门之间应该有明确的沟通
• 此通讯应采用易于理解的格式，所有
均可理解
• 应在通信中使用示例来指定＆amp;明确的要求

第一点确保要求中没有歧义，并且三个团队之间很快就会分享反馈。 第二点确保每个人都使用一种所有人都能理解的语言，并且不会给每个人带来歧义。例如，测试人员可能将场景编写为

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建议业务，测试人员和开发人员齐心协力，一起记下功能和方案。这允许交叉问题，示例和快速反馈。这样做的另一个好处是，与商业＆＃39;参与制作这些场景时，场景的重点将更多地放在系统的行为而不是技术方面。如果系统是A进入房间而B离开，那么无论在房间内进行什么过程，输入和输出，或行为都是相同的。系统不应该因为有人将房间从正方形改为圆形而破坏。这是流程的变化，而不是行为的变化。

另外，请查看此帖子here。