Testing 为长篇故事编写BDD的最佳方法

Testing 为长篇故事编写BDD的最佳方法,testing,bdd,analysis,Testing,Bdd,Analysis,我们最近开始使用BDD来编写需求。这真的很有帮助,它使分析师和开发人员之间的沟通变得容易多了。(结合用户界面和旧式学校要求) 现在我们正在考虑用BDD编写测试用例。当我在网上搜索最佳实践时,我看到了很多不同的写作方法 例如: 给定>和(s)>当>和(s)>然后>和(s) 给定>和(s)>当>然后>和(s) 问题是,几乎所有的示例都是针对非常简单的情况,另一方面,我们希望编写包含多个操作、多个系统输出(警告、错误等)和多个输出的场景 我们正试图找出为以下场景编写BDD的最佳方法: 我们需要检

我们最近开始使用BDD来编写需求。这真的很有帮助,它使分析师和开发人员之间的沟通变得容易多了。(结合用户界面和旧式学校要求)

现在我们正在考虑用BDD编写测试用例。当我在网上搜索最佳实践时,我看到了很多不同的写作方法

例如:

  • 给定>和(s)>当>和(s)>然后>和(s)
  • 给定>和(s)>当>然后>和(s)
问题是,几乎所有的示例都是针对非常简单的情况,另一方面,我们希望编写包含多个操作、多个系统输出(警告、错误等)和多个输出的场景

我们正试图找出为以下场景编写BDD的最佳方法:

  • 我们需要检查用户是否被授权
  • 他/她在正确的模块中
我们希望用户执行以下操作:

  • 用户设置开始日期
  • 用户设置结束日期
  • 用户选择一个类别
  • 用户选择子类别(基于所选类别)
  • 用户点击运行
  • 系统抛出警告,因为地图上没有多边形
  • 用户关闭警告
  • 用户在地图上绘制多边形(绘制多边形的每个步骤都在后端进行验证,并在地图上进行可视化渲染)
  • 用户停止绘图
  • 用户点击运行
  • 系统生成一个图表
我们有这么长的故事的原因是,这是一个常见的场景,可能会发生,我们希望确保用户能够回到快乐的道路


您认为使用BDD处理此类场景的最佳方式是什么?

处理长篇故事的最佳方式,如在长篇场景中,不使用BDD

您想做的是关注应该实现的业务价值。其余的,授权,警告和类似的,应该在步骤的实现中处理,而不是在功能文件中明确。用户被授权可能不是业务代表真正关心的事情。他们只是假设在执行特定任务时会出现这种情况

您正在描述如何使用BDD作为测试工具。BDD从来就不是一种测试工具,因此,如果您真正想要的是自主测试,那么BDD就不适合

您可能有兴趣阅读以下几篇博文,其中详细介绍了这一点:


    • 我将尝试重新表述您在这里提出的要求,希望它能澄清一些问题

      我们最近开始使用BDD来编写我们的需求。。。现在我们正在考虑用BDD编写测试用例

      我们最近开始使用示例来阐明我们的需求。。。现在我们正在考虑将这些示例自动化

      当我在网上搜索最佳实践时,我看到了很多不同的写作方法

      当我在网上搜索时,我看到了很多不同的背景、事件和结果

      (不仅仅是在写作中,而是在对话中导致写作。这就是为什么你会有变化,因为对话真的很模糊。)

      问题是,几乎所有的例子都是针对非常简单的情况

      问题是,在过去,像我这样的早期采用者以登录为例

      我们这样做是错误的。简单的例子实际上不能帮助您理解BDD。整个好处在于,当我们与了解问题的利益相关者(例如,他们可能是安全或基础设施专家;这不仅仅适用于业务专家)交谈时,我们学到了一些东西。以下是我们在BDD早期犯下的错误;你正面临着一些这样的代价。对不起

      我写了BDD的3个方面:探索、规范和示例测试。大多数人关注第二和第三个,但第一个是隐含的。探索很重要,围绕场景进行对话是一种非常便宜的方式

      我们希望编写包含多个操作、多个系统输出(警告、错误等)和多个输出的场景。。。我们有这么长的故事的原因是,这是一个常见的场景,可能会发生,我们希望确保用户能够回到快乐的道路

      我们希望检查整个客户旅程,以确保我们的系统至少可用,无论发生什么情况

      因此,如果您想使用Cucumber之类的BDD工具来编写一个完整、完整、自动化的客户旅程,而不是一个单一的行为示例(我们称之为场景),那么。。。这不是BDD

      然而,这仍然是一个非常好的主意。这不是BDD,但并不意味着这是件坏事。我曾与许多这样做并从中受益的组织合作。(也许它应该有个名字。)

      以下是我根据这段经历给你的提示和提示:

      • 不要将这些用作回归测试!试图完成每一个旅程是一个指数2^n的努力;算了吧。选择几次旅程(每个理想的会话3次似乎很典型),并尝试选择不同但典型的客户选择。不要使用这些测试边缘情况。您只是在检查您的主要客户旅程是否仍然缝合在一起

      • 声明式规则优于命令式规则。避免谈论用户界面;根据每个阶段所取得的成就来描述旅程

      • 如果您能够做到这一点,您就可以重用较小场景中的步骤。将您的客户旅程(有时称为“冒烟测试”)放在单独的位置,即使它们在构建的同一部分中运行。首先运行它们,直到你不再需要运行它们(一个月左右的时间,这些坏掉的东西会让你变得更糟)
        Given Sue's registered to catch Pokemons  
        And Bulbasaurs, Koffings and Pikachus were caught in Trafalgar square this year
        When she filters for Pokemons caught between January and July
        And adds a filter for "Poison" traits
        And filters for "Bulbasaur"
        When she searches for Pokemons
        Then she should be asked to select an area of the map
        When she selects an area around Trafalgar Square
        Then she should be shown the Bulbasaur density
        But not the Pikachu or Koffing density.