彩票走势图

行为驱动开发（BDD）通过利用业务领域和QA专业人员的领域专业知识来确保开发团队构建正确的软件，从而解决了定义不明确的需求的问题。请继续阅读以了解有关如何在企业中采用BDD的更多信息。

在过去的几年中，许多组织已经过渡到敏捷开发，以加快交付速度并从市场上获得更及时的反馈。在这些组织中，尽管开发开始快速发展，但是质量保证团队将难以跟上步伐，除非他们将自动化软件测试实践集成到开发管道中，所以这通常是要克服的第一个瓶颈。

但是，在成功采用测试自动化并且整个组织的发展速度更快之后，组织开始问自己是否正在构建正确的软件。通过自动连续测试来加速软件开发并确保软件质量是一项伟大的成就，但是如果软件不是客户想要或不需要的软件，那将是无济于事的。

在软件开发流程发展的现阶段，人们正在密切关注BDD，以确保他们的软件满足组织的业务需求。但是BDD到底是什么？它与测试有什么关系？

TDD与BDD

BDD是测试驱动开发（TDD）方法的演变，开发人员在其中开发测试，然后再编写代码。在设计出无法通过的测试以启动之后，练习TDD的开发人员只需编写足以确保测试通过的代码，然后编写另一个测试；冲洗并重复。结果是精简且具有较高测试覆盖率的代码。

TDD是一项旨在提高软件质量并确保代码覆盖率的活动。相比之下，BDD解决了正确实现需求的问题。BDD与其专注于验证您要实现的功能的测试，不如定义应用程序的行为以使其满足特定的业务需求。

TDD和BDD之间的相似之处在于，在完成任何工作之前要实施契约机制，以确保输出符合特定期望。但这就是相似性结束的地方。在TDD中，测试是一项旨在确保应用程序满足特定功能要求的合同。在BDD中，行为是旨在确保应用程序满足特定业务需求的合同。

什么是软件开发中的BDD？

我们一直在随意使用“行为”一词，但是它在BDD中确实具有技术意义。在BDD中，行为是遵循特定格式的精心设计的，人类可读的语句。它们收集在“功能文件”中，可以集成到开发过程中。

功能文件通常以Gherkin编写，Gherkin是BDD特定的语法，它使BDD工具（例如Cucumber和SpecFlow）能够自动执行验证行为的过程。这些BDD工具解析功能文件中的行为并执行适当的“胶水代码”。该粘合代码将“行为”映射到特定测试引擎中的执行步骤，通常是开发人员编写的Java或.NET测试代码。这些映射通常被称为“步骤定义”或“step-defs”。因此，测试人员可以将功能文件用作测试用例，以验证与需求相关的行为。

BDD的好处是什么？

业务驱动开发为软件开发带来了许多优势。使用BDD，您可以：

• 增加协作。BDD为组织中的不同角色提供了一种通用语言。这有助于技术和非技术团队成员了解项目的预期功能和业务需求。

• 利用更广泛的领域专业知识。由于行为是以人类可理解的格式定义的，因此组织可以利用具有不同观点和背景的测试人员，架构师和其他利益相关者的专业知识。

• 以测试为重点满足要求。BDD着眼于满足需求来推动测试覆盖范围，从而确保最终产品与组织的业务需求相关。

• 促进重用并降低自动化的复杂性。鼓励开发粘贴代码的开发人员编写可重用的测试步骤，以及更多可测试的代码。例如，应用程序可能具有一些重复的设置步骤，需要调用这些步骤才能实现某种状态。开发人员可以在粘合代码中定义这些步骤，这些步骤可以重用于处理设置和执行。

最后一点是BDD的主要功能之一。模块化，可重复使用的测试步骤使测试人员可以在验证和确认需求时依靠BDD工具进行繁重的工作。但是，问题的关键在于，仍然需要开发人员编写将行为绑定到需求的粘合代码。接下来，我们将详细讨论。

在企业中实施BDD的成本

与实现BDD相关的最大成本是编写粘合代码。在大多数情况下，此任务落在开发团队上，这将创建用于验证需求的测试工件的负担从测试人员转移到了开发人员。

在BDD之前的世界中，测试人员将使用工具和框架来创建测试，以验证功能（不一定是要求）。使用BDD，测试人员、业务分析师和其他涉众可以在功能文件中定义行为，但是仍然需要开发人员或具有代码编写技能的人员编写将行为映射到功能的粘合代码。

BDD增加了开发成本这一事实可能会损害开发资源有限的组织。尽管胶水代码旨在可重用并且更易于用于测试自动化，但是在整个企业中扩展和实施BDD所需的投资通常太高。

如何减轻BDD的技术负担

帮助减轻与BDD测试代码创建和维护相关的技术负担。有多种方法可以自动测试应用程序，其中主要是API测试和UI测试。可以以不同方式减轻每种产品的技术负担；

减少通过使用BDD进行API测试来实现测试代码的技术障碍

使非开发人员可以编写作为SOAtest测试执行的step-def，从而大大减少了编写测试所需的技术资源。使用SOAtest-Cucumber执行程序，每个步骤定义都映射到在执行该步骤时运行的可重用SOAtest测试或测试套件。

请考虑以下示例：

• 第一个步骤定义引用了调用特定API的SOAtest REST客户端

• 第二个步骤定义引用了连接到JSON声明器的SOAtest REST客户端，该客户端在来自其他API的响应中验证数据

• 第三个步骤定义引用了连接到Value Assertor的SOAtest DB Tool，该工具执行DB查询并验证结果集中的数据。

步骤定义还可以引用单个SOAtest测试或其中包含许多测试的测试套件。

使用Selenium和BDD降低UI测试自动化的日常维护成本

将UI测试集成到BDD解决方案中时，还会遇到其他独特的技术挑战。与的API测试解决方案类似，Selenic能够从浏览器记录UI动作并创建可以与您的step def相关联的纯Selenium代码，以驱动UI测试自动化。为了减少对纯Selenium脚本的日常维护，Selenic利用页面对象模型创建Selenium测试。页面对象模型是一种UI测试设计范式，用户可以在其中定义与它们所在的页面相关联的UI元素，由于元素位置是在一个位置定义的，因此可以更轻松地维护脚本在您的测试套件中。首先降低了创建初始测试脚本所需的技术技能。

但是，创建是一次性的成本，并且BDD测试代码所产生的大部分负担都在维护中。随着时间的流逝，随着您的应用程序更改元素定位符，底层Selenium测试代码中最初定义的等待条件可能会中断。在查看测试结果时，这会引起混乱，因为很难确定测试是否由于应用程序中的实际缺陷或简单的UI更改而失败。这会侵蚀BDD提供的价值。

在您的IDE中激活，或者对于CI/CD，通过将一行代码更改为命令行执行来激活，Selenic对测试执行进行运行时分析。当测试失败时，它将应用其AI启发式方法来确定如何避免该失败（例如，通过更新定位器或等待条件），然后尝试在运行时自行修复测试，以便管道可以继续进行。您可以避免浪费时间来调试由于不稳定的测试而导致的构建失败调试，并且它可以同时了解有关测试的更多信息。

所有这些都减少了您花费在维护、修复和修复损坏的测试上的时间，并让您获得BDD的真正好处，即由于测试自动化而增强了协作并增强了信心。

降低与测试自动化和BDD相关的成本

将更多的控制权交给测试人员，使他们充满信心，以确保他们已经完全涵盖了测试中的功能。利用成熟的、功能丰富的端到端测试解决方案，可以轻松进入测试自动化、测试维护，并自然地集成到现有CI/CD工作流程中。从较高的角度看，它使组织可以利用较少的技术资源来实施BDD、释放开发资源、更改创建区域，如下所示：

结论

BDD是一种强大的开发实践，可以确保构建正确的功能。但是，将BDD扩展到企业级别可能很困难，因为实施该实践需要大量技术资源。通过使用户能够使用简单易懂的UI将行为语句映射到步骤执行定义来降低技术障碍。步骤定义作为SOAtest测试执行，使测试人员和非技术人员更容易为验证过程做出贡献。Selenic通过为定位器和运行时的等待条件提供AI生成的建议，减少了通过Selenic与UI测试相关的日常维护。

如果您有兴趣了解有关SOAtest-Cucumber执行器的更多信息，请，或通过单击下面的。