我们不打算严格遵循BDD的某个定义，而是来理解其背后的流程。正如其名字所示，BDD是一种软件开发技术。行为驱动开发并不是关于测试，尽管BDD的一些输出可能对测试自动化有用。它从团队所有成员的合作开始，包括技术和非技术人员。这意味着开发人员、软件架构师、QA工程师会与业务分析师、产品负责人和主题专家坐在一起，就未来的软件展开建设性的对话。这在开发开始之前进行，并且是开发过程中持续进行的活动。这一过程可能有一个像“三人小组”（BA、QA工程师和开发人员）这样的名字，但不一定必须叫这个名字。
目标和好处
BDD的主要目的是让各方在未来开发相关的事情上达成一致。业务分析师在不了解软件技术能力或使用的技术情况下编写他们的需求。这些会议是他们意识到需要根据技术限制进行更改的好机会。此外，这也是他们直接讨论需求替代方案的好时机。在这些会议中，通常还会进行验收标准的细化。
对于开发人员和质量工程师来说，这是一个询问边缘案例的机会。我们总是需要在软件行为中涵盖一些边缘情况。通常，这些情况、用户流程和场景并不在最初的需求文档中。这些会议的另一部分可能是用Gherkin格式生成用例，这些用例可以用于测试自动化。但这并不是必须的，成功实施BDD并不需要使用Gherkin。这是一个常见的误解，认为Gherkin是BDD的必要条件。它当然可以用于测试自动化，但这并不是成功实施BDD的要求。这并不意味着你不应该进行自动化测试。你应该做，只是不需要使用Gherkin。
BDD不是什么？
BDD不是测试自动化工程师无论如何都必须实现的东西。一个常见的错误是，即使你没有与开发人员和产品团队的成员合作，仍然在测试自动化中实施Cucumber和Gherkin。仅仅使用Cucumber和Gherkin并不会使你的流程成为BDD。要在项目中成功实施BDD，需要远不止这些。我曾听说在UI测试自动化中使用Gherkin和Cucumber可以帮助非技术人员阅读你的测试。这对我来说毫无意义。我不认识任何非技术人员会靠近测试。简单来说，如果你不使用完整的BDD，使用Cucumber就是在浪费时间。
回到开头提到的一些组织的主要利益相关者不积极参与开发。如果组织中有产品负责人、业务分析师、主题专家或产品经理这一角色，那么他们有责任为客户提供价值。如前所述，开发过程中总会有新问题出现。我们从已知事实开始开发，随后随着我们对问题的了解加深，做出调整。为了理解我们试图解决的问题，我们向业务方面的人询问问题。如果他们不愿意分享他们的专业知识，整个项目注定会失败。如果他们没有时间与我们合作，那么项目计划就是错误的。在这些情况下，无论你使用BDD还是其他任何东西，项目都会走向失败。
Gherkin的使用
Gherkin是一种为开发团队中所有成员（技术人员和业务人员）设计的领域语言。其目的是为团队中的技术和非技术人员提供一个共同的语言，使他们能够使用相同的术语讨论相同的事情。在BDD中，Gherkin是一种常见的记录用例和解释规范或需求的方式。正如前面提到的，它并不是BDD的必要组成部分，意味着即使没有它也可以成功实施BDD。一些公司有他们自己的术语/领域语言，并倾向于在BDD会议中使用它们，这完全可以，只要结果是相同的。目标是解释系统的行为，而不是描述它如何实现。解决方案的实现部分不应在这些会议中写入。
示例：
功能：猜单词
场景：破坏者加入游戏
给定：游戏创建者已经开始了一个单词为“silky”的游戏
当：破坏者加入游戏创建者的游戏
那么：破坏者必须猜测一个5个字符的单词
结语
作为结论，需要强调一点，行为驱动开发并不仅仅关乎测试。它确实对测试有极大的帮助。它帮助你更好地理解软件需要解决的问题。通过更好地理解问题，你可以更好地设计测试。它帮助团队确定验收标准，从而有助于创建测试。本文的另一个要点是，如果整个团队没有参与编写Gherkin功能文件，不要使用Cucumber和Gherkin。这样只会给测试自动化工程师带来压力，并且不会带来任何显著的价值。
