BDD,什么特征?

它应该是一个特性,但是试着从用户的角度来描述它。这份产品清单给他提供了什么?

• 用户应该能够获得所提供产品的概述
• 用户应该能够订购和重新订购产品的名称,价格,可用性。

开始做BDD很难。唯一有助于对自己的能力和整个方法感到自信的是编写测试场景和执行它们的代码。我建议你不要把已经很复杂和混乱的情况弄得更糟。选择你需要执行的任务,打开一个空白文本文件,试着用简单的句子来解释这个行为。每个句子都应以以下三个关键词之一开头: 鉴于 , 然后 . 使用您最喜欢的BDD框架编写代码,解析这些语句并刺激应用程序进入开始状态(给定),执行一些命令(何时)并断言转换状态(然后)。应用程序代码可能仅仅从模拟开始。逐渐用逐步构建的代码替换这些模拟,并以更高的信心和质量级别来扩展应用程序。

用户故事是一个特性。可以用格式表示的东西:

• 角色
• 做点什么
• 以便 目标

例如。

• 我想能够比较产品

• 作为客人

• 这样我就可以完成购买了

当然,每个特征都必须由一系列给定的场景来确认。

你基本上是在问什么是功能。想想看,你有一个故事,一个故事描述了你(或其他相关人员)想要为你的应用程序提供的功能。通常它的形式是:作为一个用户,我想查看产品列表。你可以给这个故事加上注释,使它更清楚。但是接下来是具体的行为(最终你将测试它)-有无数的行为符合这个故事(想想产品的观点和展示它们的多种方式)。在BDD中,你的重点是找到适合你的应用程序需要的行为(我使用应用程序而不是用户,因为有时你应该为用户做决定)-通过与尽可能多的人交谈,尝试一些东西并反复迭代。

更重要的是找出用户想要对产品列表做什么? 该功能将为用户提供一些有价值的东西。

• 从产品列表中选择要查看的产品
• 从产品列表中选择要比较的x个产品
• 其他

有关BDD框架,请参见 http://kernowcode.wordpress.com

为了确定需求是否是一个明确的特性/用户故事,您可以使用基于任务的设计/文档指南(例如。 http://www.sprez.com/articles/task-documentation-design.html 在BDD中,一个好的起点是在用户手册中编写作为章节使用的主题。这些主题通常是您将在软件解决方案中提供的功能。 协和是一个很好的框架,它通过示例来支持这种规范化方法( http://concordion.org ). 请看一下用通俗易懂的英语描述的验收测试( http://gojko.net/2009/09/01/acceptance-testing-in-plain-english-with-concordion-net/