什么是bdd行为驱动开发_BDD（行为驱动的开发）：持续集成难题中的缺失部分-优快云博客

本文探讨了行为驱动开发（BDD）如何成为持续集成（CI）流程中缺失的一环，通过将客户需求转化为可执行规范，确保软件开发始终满足用户期望。BDD不仅是一种开发过程，也是一种工具，它与CI结合，实现了软件的快速、低成本高质量交付。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

什么是bdd行为驱动开发

行为驱动开发（BDD）是一个过程，也可以是一个工具。在许多情况下，BDD都是两者。但是，它本身不应该是目标。软件开发的目标是尽可能快且便宜地交付质量。质量的唯一真实衡量标准是它是否以可靠的方式满足用户需求。我们可以实现这一目标的最佳方法是持续集成，部署和交付。为了本文的目的，我将忽略这三者之间的区别，并将它们全部称为持续集成或CI。

CI常常被误解，而BDD可以解决这一难题。通常将其实现为一系列步骤，这些步骤首先提交到存储库，然后进行构建，静态检查，单元测试，集成测试以及最终交付的软件。通过这些步骤，我们可以确定该软件始终能够满足团队的期望。

实现此目标的唯一方法是让团队作为一个统一的机构工作。即使总是存在某种类型的专业化，并且不同的配置文件可能具有一定程度的自治权（前端和后端开发人员，测试人员……），他们必须从头到尾一起工作。此图中经常被忽略的元素是客户端和用户。只有在整个过程中都涉及那些设定了期望值的软件，才能使软件始终按预期运行。谁设定期望？用户呢。他们是唯一可以说我们正在构建的应用程序是否成功的人。他们定义了应该构建的内容，因为我们正在努力满足他们的需求。这就是BDD进入的地方，并围绕我们的CI流程创建了一个包装。

使用CI和BDD，我们可以始终以满足用户期望的方式集成软件，而不必执行我们认为应该做的事情。这句话目前很小但很重要。软件是否如我们预期的那样工作并不是我们应该追求的目标。它应该执行用户期望的操作 。我们没有设定期望。用户呢。

BDD用由客户和用户编写或与客户和用户合作编写的可执行规范代替了传统要求，并在作为CI流程的一部分执行时提供了持续的反馈。尽管叙事和场景可以替代传统需求或用户故事，但要使BDD完全集成到CI流程中，就需要对这些场景进行自动化。叙事和场景是一个过程，可以通过不同的工具来提供我们所需的自动化。它既是过程又是工具。

Sprint 0应该用于设置我们的工具和高级设计（IDE，服务器，体系结构设计...），CI服务器和BDD框架。从那里开始，我们可以开始编写BDD故事。它们中的每一个一旦编写，都应由开发人员采用并实施。如果将故事与实现代码放在一起，从CI那里获得的反馈几乎是立即的。为了成功实施CI流程，经常缺少该反馈。仅仅拥有Jenkins（或任何其他类似框架）是不够的。如果我们寻求持续构建可靠的软件，则过程中的最终验证必须基于某种形式的集成和功能测试，以确认满足用户期望。否则，我们将永远不会拥有实施连续部署或交付决策的信心。

可能会产生一个问题，为什么单元测试的反馈不足以向我们提供有关我们的软件是否按预期运行的信息。单元测试是必须的，因为它们可以快速编写和执行。但是，他们告诉我们我们所有的代码单元是否正常工作。他们不能保证我们将所有这些单元都集成到了它们所组成的功能中。

其他类型的集成测试怎么样？如果它们基于纯代码，则客户或用户将无法编写或理解它们。没有它们，集成测试就是我们对他们想要的东西的假设，也许不正确。而且，由于它们必须与需求一起工作，因此它们通过提供两种形式的相同概念来表示重复的工作。需求是通常以不同格式编写的测试。如果需求变为可执行的，则无需单独的工件。

如果BDD代替了需求和集成测试，我们可以摆脱单元测试吗？是的，我们可以，但我们不应该。即使可以在所有级别上编写BDD，使用BDD代替单元测试也将大大增加工作量。而且，这将使与客户和用户的通信复杂化。保持单元测试作为验证所有组合软件可以在单元级别上完成的一种方式，使我们能够以紧凑的方式编写BDD方案，从而确认那些单元测试的集成，同时提供良好的沟通工具，作为我们对功能的最终验证发展。

需求本身应该是可执行的，这就是BDD试图实现的目标。如果将其集成到CI流程中，它将通过将不断提供有关我们认为应开发的内容的反馈转换为客户和用户应开发的内容的流程来提供缺少的部分。它贯穿于整个过程，从一开始就可以捕获需求，指导开发过程并充当CI的最终验证。它是连续可靠地交付生产所需的缺失部件。