JBehave 基于 Java，适用于 Java 应用程序。 JBehave 还支持良好的 HTML 报告。但是，JBehave 的问题在于它只支持 Story 级别而不支持 Feature 级别。
这里的任何人都可以帮助我提供一个小的解释或文档，以便我了解 Cucumber 如何支持功能级别吗？
【问题讨论】：
标签： cucumber bdd agile acceptance-testing jbehave
一个特性是一种能力的实现（一个能力可能需要多个特性）。
我们来看看Mike Cohn's description的一个“故事”，因为它很不错：
用户故事是对从 渴望获得新能力的人的观点，通常是 系统的用户或客户。他们通常遵循一个简单的 模板：
As a <type of user>, I want <some goal> so that <some reason>.
一个好的用户故事遵循INVEST principles，这就是我们开始进入场景的地方：
一个故事可能有一个或多个上下文，该功能将在其中发挥作用。上下文本质上独立于其他上下文。
在处理故事时，您可能会发现需要考虑的其他背景或结果。作为功能核心的能力通常与“何时”相关联。例如，如果我希望能够生成报告，“何时”将是“当我生成报告时......”
可能有多个利益相关者会产生不同的结果。例如，发送一封电子邮件说出租车已被预订很重要，但将预订确认发送给司机也很重要！通过考虑不同的利益相关者，我们得出了需要考虑的场景的结果。
如果您无法估计大小，请尝试让一种方案正常工作。这是 Kent Beck 的“尖峰”的功能等价物。顺便说一句，您需要估算的唯一原因通常是确定它是否值得做，考虑到其他可以完成的工作，因此请相应地对待它。
我实际上更喜欢人们知道他们对此有一定程度的不确定性，并希望尽快获得反馈。如果你真的确定它（例如：登录），那么它可以更大，因为你需要更少的反馈；你知道“工作”是什么样子的。
示例成为该分析的一个很好的副产品。
但是，为什么我们首先要做故事？为什么不只提供全部功能？
事实证明，交付某些功能所需的工作量非常大，特别是如果您有很多利益相关者参与其中，并且我们希望将它们分割开来，以便更早地从它们那里获得价值，或者我们想对它们进行切片以便获得反馈。
所以一个故事可能是一个可以实际发布的功能的片段，或者它可能是为了获得反馈而设计的。
场景是执行此操作的绝佳方式！该功能可以缩小到最有价值的上下文或需要考虑其结果的不同利益相关者。请注意不要排除具有交易需求（ATM 用户取款；银行借记账户）或监管需求（银行进行重大投资；监管机构看到资本储备的变化）的利益相关者。
场景并不是获得功能反馈的唯一方式。新用户界面？在没有任何行为的情况下对其进行硬编码并将其展示给人们。新报告？制作一个模拟副本。从未有人处理过的新提要？做一个尖峰，看看你是否能从中得到你认为可以的信息。
否则，请考虑需要考虑其结果的不同背景和利益相关者，并考虑不同的能力及其背景和结果。功能实现了不同的需求，其行为由您派生的场景说明。
由于一个故事是一个功能的切片，而一个功能实现了一种能力，这是一个典型的层次结构：
如果您想弄清楚如何将场景与故事和功能联系起来，这不是一个坏方法。如果你看一下Gojko Adzic's "Impact Mapping" 或Matt Wynne's "Example Mapping"，你会发现它很熟悉（我想我们都听过 Chris Matts）。
要小心，因为实际上这有点模糊；你会在开始交付时发现，所以不要提前分解所有内容。我发现功能是很好的计划级别的工件，并且通常很容易与“史诗”相关联。他们还附带了自己的高级测试：“我们的用户能否针对我们需要考虑的上下文以及也需要其结果的利益相关者做他们需要做的事情？”
故事的诀窍是只考虑需要来传递价值，直到它真正被传递......然后剩下的一些将是下一个的事情这是需要的，等等。
如需更多想法，请查看我在 capability-based planning and lightweight analysis 上的博客，以及在 splitting up stories 上的另一个博客。
对于 Cucumber，按功能组织，然后（如果需要）按上下文组织，并用故事编号标记您的签到（大多数 CI 工具、电子板和版本控制系统都支持这一点）。一个功能或故事可以创建更多场景。
【讨论】：