Question

我刚刚开始使用SpecFlow。它是一种以BDD方式创建业务可理解的测试场景的工具。基本上它将用户故事转换为单元测试。

我是用户故事的初学者，我想知道它的长度。这是创建非常精确的用户故事的好习惯吗？这是一个例子：

In order to get help
As a StackOverflow user
I want to add post
   with name and content
   and add tags to it
   and format the content
   and the information about my post edits to be stored in the system
   and some more things like that

我应该保持我的故事紧凑吗？如果是这样 - 我如何管理详细要求？或者在用户故事的非常长且精确的I want部分中，它可能没有错？

Answer 1

我总是建议如下：

尝试在场景中剪切故事。情景越多，就越能确定何时出现问题。给出所有场景的主观名称。

现在举个例子，你的测试。如果第1步出错，那么所有其他步骤都不会得到测试。

还可以使用Given，When和Then标签轻松阅读您的场景。

相反，你可以说：

Feature: As a StackOverflow user I want to add a post

Scenario: I go to stackoverflow website
Given I open the browser
And I go to the stackoverflow website
When I click New Post
Then a new page appears to insert my data

Scenario: I fill in data for my post - Name and content
Given I do not modify this page
When I fill in name
And I fill in content
Then I add tags to it
And I format the content

Scenario: Check if information about post edits are stored in the system
Given...

猜猜你会得到这样的地方： - ）

Answer 2

如果你可以在几周内开发出一个完整的系统，并且可靠地做到这一点，那么没有人会担心用户故事＆＃34;。他们只是让你开发系统，和你坐在一起，并随着它调整它。

仅存在用户故事，以便从能够随时与您在一起的人那里获得反馈，并帮助您了解您的用户（和其他利益相关者）真正 >想要。

以下是我如何处理这样的列表：

In order to get help  
As a StackOverflow user  
I want to add post  
   with name and content  
   and add tags to it  
   and format the content  
   and the information about my post edits to be stored in the system

你想得到帮助。哪一项实际上增加了你获得帮助的能力？是您想要帮助，还是想向其他人提供帮助？您是否希望获得对其他人提供帮助的认可？这个问题的最重要部分似乎是错误的（这就是为什么用假要求进行这些对话真的很难）。

我认为这里有多个要求，远远超出了一个用户故事的范围。有了分析师的帽子，我就可以解决这个问题：

In order to award great content with appropriate recognition, 
as Stack Exchange,
we want people's usernames to appear with their content.

当然，用户也想要这个，但他们并没有为此付费（除了通过广告）。因此，找出谁为此付费，以及为什么。

In order to get more page impressions and keep people on the site for longer,
as Stack Exchange,
we want users to be able to find similar content really easily.

嗯。这个有点棘手。请注意，用户并非真正希望在StackOverflow上度过一生。只是如果我们给予他们适当的认可，并让其他人更容易找到他们的内容，他们可能会这样做。并非所有＆＃34;用户故事＆＃34;实际上有益于用户找出谁为他们付款，以及为什么;那么你找到了真正的利益相关者。一个故事让一个以上的利益相关者受益也是可以的，而且从用户的角度来看也很容易看到如何改写这个故事。

format the content

老实说，不确定这个。它可能是关于能够强调重点等等。有很多美学理想不适合BDD和自动化场景。有时，唯一的方法就是尝试并获得反馈。

In order to avoid retyping my request every time
As the user
I want the information about my post edits to be stored in the system

嗯，是的，那会很好。

事情是，每个都可以独立开发。如果你能想到任何一个功能，那么你可以摆脱并且仍然有发布的任何项目都是有价值的，请将它放在一个单独的故事中。

如果你能代替＆＃34;我想...＆＃34;用＆＃34;我希望能够...＆＃34;很可能你所拥有的不仅仅是一个故事，而是一个完整的能力。大多数人本能地这样做。很多人称之为＃34;史诗＆＃34;。

我刚刚告诉你我是如何分解他们的。这是一个非常简单的过程。

首先，看看你的要求。如果有任何你可以说的话，＆＃34;我希望能够......＆＃34;或者＆＃34;有人希望能够...＆＃34;然后你知道这是一个完全不同的能力，这意味着它将成为一个独立的故事。

然后，您可以将这些内容分为上下文。所以你可能会有这样的故事：

In order to free up our junior traders
We want them to be able to generate contracts automatically
So that they can help with the trade analysis instead of typing.

如果这对于反馈周期来说似乎太大（通常为两周的冲刺），你可以进一步划分它。

In order to free up our junior traders
We want them to be able to generate *orange juice* contracts automatically
So that they can help with the trade analysis instead of typing.

在这里，我们专注于能够交易橙汁，但我们可以将故事缩小到富时，美国或纽约证券交易所。这就是我们将工作重点放在能够实现的目标上：保护收入，降低成本或创造价值。

为了将这些变成情景，我问，＆＃34;你能举个例子说明纽约证券交易所的OJ交易吗？＆＃34;如果我看到任何我不理解的通用名称，我会问，＆＃34;你能给我一个例子吗？＆＃34;

这个例子成了我的第一个场景。上下文（给定）由故事的界限定义。事件（何时）是能力的表现。结果（然后）是结果值。

在回答您的问题时 - 是的，我认为创建精确的用户故事非常重要。这意味着要知道它为什么有价值，定义你将要涵盖的背景，并建议一个结果可能是什么的例子。

你给出的例子不仅仅是一个故事。它不够精确。希望这里的建议可以帮助您将故事缩小到有用的东西。对于一个故事来说，一两天是一个很好的长度，但如果你开始沿着这条路走下去并发现它们有点长，那就没问题了。

您的更改也是故事。

Answer 3

用户故事没有正确的详细级别，因为用户故事的大小（范围）会缩小，并且随着时间的推移会逐渐增加（规范）。这张幻灯片展示了Gojko Adzic对此的一个很好的可视化：http://www.slideshare.net/chassa/2015-0214agile-reqend2endcomplete/6

关于Gherkin场景应该如何精确和详细的问题：场景应该揭示要实现的用户故事的有趣方面。他们应该使用具体（关键）示例而不是抽象描述。这些例子应该集中在应该说明的方面。场景标题应该是使用场景中提供的示例说明的规则或方面的抽象描述。

您通常从主要方面（快乐路径）场景开始，然后通过提出探索故事其他方面的新示例（案例）来尝试“打破模型”。首先提出问题“如何实施故事时如何尝试？”（快乐路径）和“如果......会发生什么？”来收集潜在的情景（可能会定义一些问题）这个故事的范围）。

之后，您尝试回答这些问题（方案标题）并用具体示例（方案步骤）进行说明。这张幻灯片提供了“打破模型”的想法：http://www.slideshare.net/chassa/2015-0214agile-reqend2endcomplete/61

用户故事应该是多么精确？

3 个答案: