BDD 如何让产品负责人、设计师、开发人员和测试人员的生活更轻松
从本质上讲，行为驱动开发 (BDD) 改善了项目利益相关者之间的沟通，以避免遗漏需求、出现更多错误、延迟时间表和产品失败。关于 BDD 方法论已经写了很多，但在这个博客中，我将分享它如何让每个利益相关者的生活更轻松。
BDD 如何让产品负责人的工作更轻松：
作为产品负责人，您将对产品的整体成功负责，并且您希望以用户认为的各种可能方式进行思考，以确保涵盖所有边缘情况。BDD 将帮助您仅以纯英文文本的场景形式写出那些边缘案例或任何潜在案例。BDD 的这一特性将有助于团队对产品进行更高程度的协作，因为团队中的每个成员都会对产品有更好的了解。此外，产品负责人是对确切需求有适当清晰度的人。他们可以列出多个场景，以确保团队中的每个人都不会偏离原始需求路径。
此外，BDD 功能文件将作为产品的可执行文档，在功能文件和测试场景之间设置自动化。因此，功能中的任何次要或重要更改请求都必须经过测试场景，除非更改代码，否则这些测试场景将失败。这种自动化将有助于保持需求和开发之间的同步。
BDD 如何提高设计人员的效率：
“通常，软件的设计和构建没有过多考虑其使用和支持生态系统。”
作为一名设计师，您希望为您工作的任何组织构建最好的模型。 BDD 将通过提供以用户为中心的设计方法来提供帮助，其中每一点可交付功能都专注于用户的意图和模式。与团队合作并了解每个可能的变化将帮助您准备好 UX 设计，同时考虑到用户旅程的各个方面。此外，在项目开始时保持这种清晰度可以帮助您将设计思维提升到新的水平。设计者和开发者必须考虑用户的需求；它是 BDD 中最关键的概念之一，也是以用户为中心的设计的关键。通过分析将使用该系统的用户的行为，我们不断探索各种选项，以选择最能满足需求的替代方案。在这样做，
BDD 如何改变开发人员的游戏规则：
作为开发人员，您希望拥有一组明确的要求，以便您可以自信地构建业务所要求的内容。当您已经在功能文件下的多个场景中以及纯英语中已经涵盖了需求时，您不想时不时地去找业务专业人士了解需求。没有比这更好的了！有一些可用于测试的工具，它们只是现有测试库（即 JavaScript 的 jest-cucumber）的包装器。因此，采用 BDD 方法不会让您仅限于功能文件，而且还可以利用测试，确保需求的每个部分都有相应的测试用例。以通俗语言编写的功能可以轻松实现自动化。
首先，将示例提供给自动化工具（例如 Cucumber 或 Spec Flow），这将生成自动化规范。开发人员可以使用该结果进行应用程序开发。此外，BDD 涉及与利益相关者和团队其他成员的协作，这将帮助您对将要构建的产品充满信心。
BDD 如何缩小测试人员和其他利益相关者之间的差距：
作为测试人员，您希望成功运行验收测试并确保软件按业务预期运行。BDD 的另一个优点是它有利于系统的可测试性。BDD 背后的原始概念是基于行为来驱动产品，这使得检查事情不会向南变得至关重要。与 TDD 不同，BDD 更侧重于测试整个产品，而不是测试代码的一小部分。确保一个人从 A 点到达 B 点是 BDD 所关心的，对所采取的路径很少或根本不重要。像 Gherkin 这样的工具提供了在测试规范和系统之间实现连接层的灵活性，这是自动化测试步骤的一部分。此外，在协作阶段，测试人员可以与开发人员和设计人员结对，以更好地了解要测试的功能。
一个实际的 BDD 用例：
产品所有者到开发人员。“这是我们刚刚想到的一个新功能。我已经在 Jira 上用这个场景更新了专题报道。您能否处理此请求并推送所需的代码更改？
BDD 方法。
开发人员进行所需的代码更改并将 Jira 中的功能文件粘贴到代码库中。BDD 将迫使开发人员为新添加的场景编写测试用例，即必须进行行为测试。一切都很好，结局很好。
传统方法。
开发人员通过进行所需的更改完成了出色的工作，并将更新的代码和新的更新测试推送到环境中。哦哦！我们忘记了行为测试！新添加的场景有相应的单元测试，确保代码运行良好，但没有进行行为测试。让我们下次采用 BDD。
上图展示了 BDD 在可扩展性和可维护性方面与传统软件开发方法相比可以提供的好处。确保新添加的场景不会破坏行为实施是使发布变更请求的过程变得顺畅的原因，并且采用 BDD 很好地涵盖了这一点。通过使产品易于管理和扩展，使用 BDD 编写多个脚本和任何可能的案例的额外步骤将很快得到回报。此外，BDD 的正确实施将确保产品的行为测试，这很可能导致其他方法变得可用。
