我刚刚开始使用 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 部分可能没有错？
【问题讨论】：
标签： bdd specflow user-stories
我总是建议以下几点：
尝试在场景中剪辑你的故事。场景越多，您就越能准确地确定何时出现问题。给所有场景主观命名。
现在以您的测试为例。如果第 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...
猜猜你会知道这是怎么回事:-)
【讨论】：
用户故事没有正确的详细程度，因为用户故事的大小（范围）会随着时间的推移而缩小（范围）并在细节（规格）上增加。这张幻灯片展示了 Gojko Adzic 的精彩可视化：http://www.slideshare.net/chassa/2015-0214agile-reqend2endcomplete/6
关于 Gherkin 场景应该有多精确和详细的问题：场景应该揭示要实现的用户故事的有趣方面。他们应该使用具体（关键）示例而不是抽象描述。示例应侧重于应说明的方面。场景标题应该是对规则或方面的抽象描述，并通过场景中提供的示例进行说明。
您通常从一个主要方面（快乐路径）场景开始，然后尝试通过提出探索故事其他方面的新示例（案例）来“打破模式”。您首先提出以下问题：“当故事实施时，您将如何尝试？” （幸福的道路）和“如果……会发生什么？”收集要考虑的潜在场景（可能定义一些超出本文范围的问题）。
之后，您将尝试回答这些问题（场景标题）并用具体示例（场景步骤）来说明它们。这张幻灯片给出了“打破模式”的想法：http://www.slideshare.net/chassa/2015-0214agile-reqend2endcomplete/61
【讨论】：
如果您可以在几周内开发出一个完整的系统并且可靠地完成，那么没有人会担心“用户故事”。他们只会让您开发系统，与您坐在一起，并随时对其进行调整。
用户故事的存在只是为了从无法一直与您在一起的人那里获得反馈，并帮助您了解您的用户（和其他利益相关者）真正想要什么.
我是这样处理列表的：
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 上度过他们的一生。只是如果我们给予他们适当的认可，让其他人更容易找到他们的内容，他们可能会这样做。并非所有的“用户故事”实际上都使用户受益。找出谁在为他们付费，以及为什么；然后你找到你真正的利益相关者。一个故事也可以使多个利益相关者受益，而且从用户的角度也很容易理解如何重新表述这一点。
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
嗯，是的，那太好了。
问题是这些中的每一个都可以独立开发。如果您能想到任何功能，任何您可以摆脱但仍然具有发布价值的项目，请将其放在单独的故事中。
如果您可以将“我想...”替换为“我希望能够...”，那么您所拥有的可能不是故事，而是完整的能力。大多数人本能地这样做。很多人称这些为“史诗”。
我刚刚向您展示了我是如何分解它们的。这是一个非常简单的过程。
首先，看看您的要求。如果有什么你可以说，“我希望能够......”或“有人希望能够......”那么你知道这是一种完全不同的能力，这意味着它将是一个单独的故事.
然后您可以将它们分成上下文。所以你可能会有这样的故事：
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.
在这里，我们的重点是能够交易橙汁，但我们同样可以将故事范围缩小到 FTSE、美国或纽约证券交易所。这就是我们如何将精力集中在能够实现的事情上：保护收入、降低成本或创造价值。
为了将这些转化为情景，我问：“您能给我举一个在纽约证券交易所进行 OJ 交易的例子吗？”如果我看到任何我不理解的通用内容，我会问：“你能给我举个例子吗？”
这个例子成为我的第一个场景。上下文（给定的）由故事的限制来定义。事件（何时）是能力的表现。结果（然后）是结果值。
回答您的问题 - 是的，我认为创建精确的用户故事很重要。这意味着知道它为什么有价值，定义你将要涵盖的背景，并提出一个结果可能是什么的例子。
不过，您提供的示例不仅仅是一个故事。它不够精确。希望这里的建议可以帮助您将故事范围缩小到有用的范围内。一两天对于一个故事来说是一个不错的长度，但如果你从这条路开始，发现它们有点长，那没关系。
您的更改也是故事。
【讨论】：