Process BDD功能的功能，我应该做一个新的故事还是它属于一个场景？

好的，我刚刚开始尝试将BDD用于我们正在进行的一些新开发，我为日志查看器功能编写了一个类似这样的故事：

故事：用户查看工作流执行日志

As a user
I want to review the log of rules execution
So that I can examine the results and make adjustments/fixes to the rules definitions

在某些情况下，如果用户在单击“查看日志”时对日志查看器具有适当的安全权限，则授予他访问日志查看器的权限

现在我知道我们需要一种对日志进行排序和过滤的方法。这是一个完全不同的故事吗

Story: User filters the execution logs

As a user
I want to filter the log entries by selecting categories
so that I can view only log entries matching the category I selected

或者，在第一个故事的场景中是否有更“简单”的功能？像这样

情景2：

Given the user is looking at the log entries
When a category is selected
Then only the log entries matching the categories are displayed

我理解这可能很难回答，因为可能没有一种正确的方法来解决这个问题，但我仍然有点困惑，这类事情应该如何分割。

我们通常称之为故事的叙述。请看一下FeatureInjection的模板：“为了……作为……我想要”——将目标放在首位有一些有趣的效果

这个故事通常有不止一个场景。场景是系统用户可能希望如何使用它的示例。这些场景使我们能够与利益相关者进行对话：

“那么，考虑到我的账户里只有20美元，当我要50美元时，它应该会告诉我我没有足够的钱？”

“是的，除非你透支。”

当我们使用BDD工具或测试框架编写它们时，验收测试是这些对话的一个极好的副产品

您可以在此处找到有关BDD的更多信息：

在这里：

---

透明度：第一篇文章大部分是我写的，第二篇也是我写的，所以任何不清楚的地方都是我的错。

我还没有读完整的《牵引力》这篇文章，因为它很长，但看起来很不错。然而，我还是有点困惑，但我觉得场景实际上更像是QA的东西，而故事实际上是一个功能的东西，所以事实上，如果场景更倾向于验证实际功能，那么故事和我在问题中提到的场景可以共存。场景相当于验收测试，这样QA、BAs和开发人员都能很好地理解这个故事。是的，在我的项目中，两者通常共存。故事由视觉墙上的一张卡片表示，并有几个场景与之相关。在我的工作场所，BDD代表BossDrivenDevelopment：(