gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-02 00:55:37 29 4
gpt4 key购买 nike

我是 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/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com