我对 BDD 以及它应该如何改进 TDD 的了解越多，在我看来这一切就越令人困惑。我从专家那里找到了关于设计的引述，也从其他专家那里找到了关于分析的引述。
我目前看到的方式是这样的：
1）分析：BDD
来自维基百科
面向对象分析的结果是以概念模型的形式描述系统在功能上需要做什么。
所以在 BDD 之后，我们有了需求（故事和场景）。但我不确定概念模型部分。
2) 设计：例如使用 CRC 卡的可靠性驱动设计等工具
3) 代码：对设计进行编码，可选择使用测试（就像他们所说的 TDD 做错了，我也觉得这很有用）
我怎么看错了？我现在很难从树林中看到森林。
简而言之，它与Analysis有关。
BDD 用于“验收测试驱动开发”——即了解被测系统是否按照特定用户故事场景的预期行为。
当我使用 Jbehave 时，我们在用户故事级别使用它，并且仍然使用“常规”TDD 来处理单个对象之间和子系统之间的协作。
通常，业务系统使用 BDD 场景来描述业务领域行为，而不是测试系统内部的微小实现细节。您希望将 BDD 场景定位在领域专家的抽象级别。这些场景对领域专家来说没有多大意义，如果他们描述了实现的每一个微小细节，它们就会非常脆弱。
BDD 场景说明了系统应该为用户故事做什么，但没有说明它是如何做的。
BDD 是关于编写“可执行规范”或验收测试，即黑盒测试，根据定义，它采用测试对象的外部视角来派生测试用例。
所以BDD不能是关于设计的，BDD是关于测试特性/故事/场景的，BDD更接近于分析。
BDD - 行为驱动开发
行为=..在..发展的背景下-...在...的建设中
在这种情况下，开发向我表明分析已经完成，并且正在实施特定行为背景下的某些东西。
所以要回答这个问题，我相信它在设计中。
我认为从架构 POV BDD 将是关于设计的。我需要设计一个可以做某事的应用程序，稍后将用于验收测试。因此，从高级设计中，我想确定我是针对各种行为要求进行设计的，这样我就不会过度设计，并限制重复。
它有助于确保我们可能不需要重新设计，因为用户有更多时间思考他们真正想要看到的内容，应用程序将如何执行。
BDD（或就此而言的TDD）与任何事情无关。它是一种支持分析和设计（以及讨厌的小实现步骤）的技术（在 BDD 的情况下，更多的是一种方法）。您经常听到与 TDD 相关的短语“红、绿、重构”，因此它适用于 BDD：创建测试并查看它是否失败，通过更新代码库使测试通过，然后将系统重新设计为改进的形式，同时您保留通过的测试。
因此，当您创建测试时，BDD 支持分析：您应该以测试或示例的形式描述所需的行为。它在您运行测试时支持设计：防止您的设计决策无意中破坏所需的行为，并且可以由分析指导。但它不会为您做任何分析或设计；你还是得想想。这是一种确保在分析和设计步骤期间不会自相矛盾的方法。
BDD 和 TDD 甚至有一个非常不吉利的名字，因为它实际上并没有涵盖它们的用途。
如果您在有一些代码描述您将要编写的代码位之前不编写一行代码，那么 BDD/TDD 中的任何一个都可以。这样做你会进入一个区域。
虽然没有证据表明 BDD/TDD 会提高您的开发速度（很可能不会），但它会大大减少您在发布已被证明的软件后返回的问题数量。
BDD 是 TDD 的演变，其中 TDD 施加压力以测试所有内容 BDD 放松了这一点，并表示您应该只测试类的公共行为，因为内部可能会发生变化。
BDD 既关乎设计，也关乎分析，但我认为这不是你的问题，是吗？您想知道如何将故事转化为流程图和架构图吗？
因为我从你的问题中得到的是，你预先做了一个大的设计，然后试着把它编码出来。这不适用于 BDD，因为在满足您应该以零碎的方式编写的故事的同时，您会自动获得您的代码和架构。它被称为紧急设计，因此没有庞大的规划阶段。
在 SCRUM 或类似的系统中，这非常有效，因为业务优先考虑您的故事。您从顶部开始并为其编写规范/示例，然后尝试满足示例重复此操作，直到您完成此积压项目，然后拿起下一个并重新开始。
我希望这能回答你的问题。如果不是，你需要澄清一点，因为这是一个粗略的话题。简而言之，BDD 纯粹是一种开发工具，不适用于架构师、BA ...... 测试人员可能会使用 BDD 工具，但我希望这不是他们用来测试应用程序的唯一工具。