测试自动化遇上行为驱动开发（BDD）：协同合作，助力软件开发成功

很多开发问题都是源于沟通不畅。例如，开发人员可能会处理他们并不完全理解的规范，或者相关人员会在并不了解某项功能的情况下就提出需求。这导致的结果就是返工，从而导致增加成本和项目延误，而且很多情况下会造成项目因为远超预算而失败。

行为驱动开发（BDD）通过鼓励跨职能的协作来克服这些挑战。BDD并不是取代现有的敏捷开发过程，而是作为一个插件，提高敏捷开发成功的可能性——可靠、及时地交付工作软件，满足企业不断发展的需求。

BDD帮助您实现敏捷开发的承诺——可靠、按时交付可用软件，且满足不断演变的规格要求。

一起来看看BDD和自动化测试如何共同改进软件开发周期。

什么是BDD？

行为驱动型开发（Behavior-driven development，简称BDD）通过鼓励跨职业协作来建立对问题的共同理解，从而缩小业务和技术团队之间的差距，并且让团队在小迭代中工作，缩短反馈循环。还能生成业务友好的文档，这些文档会根据系统的行为自动进行检查。

该过程包括三个核心步骤：

发现：针对一个即将进行的小型更改（例如用户情景），协作创建新功能的具体示例，以此来明确问题的具体范围，最终实现对应该交付的内容详细的、共同的理解；
自动化：用可自动验证功能是否存在的方式制定具体用例。通常，这些用例会记录在Gherkin特性文件中，包含Given-When-Then场景。这些功能文件易于理解，即使对非技术人员来说也是如此；
编写自动化测试代码：根据每个场景描述编写自动化测试代码。然后将生成的自动化测试用于指导代码开发。

BDD流程中最重要的部分是“发现”阶段，即定期举办一个研讨会，这个研讨会中必须至少有三个视角的代表：相关人员、测试工程师和开发人员。在这个频繁召开的简短研讨会上，可以通过使用具体的例子来达成对要求的共识。常见的会议形式称为“Example Mapping”。

采用BDD时，开发团队最常见的错误是将其视为另一种测试。如果没有业务团队和技术团队之间的对话，这些测试将无法解决沟通不畅问题，这将导致项目延迟、预算超标。

大多数的开发团队对测试驱动开发（TDD）中的测试自动化都很熟悉。例如，开发人员可以编写单元测试，测试工程师可以编写集成测试，在每次提交或部署之前，这些测试会作为构建过程的一部分自动执行。任何问题都会被标记出来给开发人员，让他们在投入生产之前解决。

BDD实践与TDD是相互配合、结合使用的。在将用户情景引入开发并开始TDD流程前，团队应用BDD实践来管理需求，生成具体用例，将其制定为易读的规范，并自动执行它们以创建动态文档。这些规范会与TDD测试一起，在像Jenkins这样的持续集成服务器上运行。

以下是典型的开发过程：

应用BDD实践生成的动态文档还有另一个好处。由于Gherkin是用简单的英语编写的，因此相关人员可以轻松地查看哪些功能已经通过了，哪些功能仍在开发中已被弃用。这让所有人都能保持同步，而无需在每个产品增量中手动更新文档。

在实施BDD时，开发团队面临一些挑战，尤其是在沟通和集成方面。

一个常见的挑战是将活动文档与其他测试套件一起管理，并继续向相关人员提供可操作的报告。

TestComplete通过原生支持Gherkin的Given-When-Then场景简化了这个过程。无需构建和维护跨多个不同工具的复杂技术堆栈，就可轻松地将功能文件转换为自动化测试，也不需要任何额外的插件。

与相关人员共享报表也很容易。TestComplete的Zephyr for Jira集成可以轻松地与业务团队共享BDD见解，无需技术团队定期生成和通过邮件发送报告。它提供了一个单一的界面，每个人都可以使用更广泛的Jira生态系统来查看测试状态和相关的bug报告。

除了创建BDD场景之外，TestComplete还可以通过其业界领先的记录和回放功能、报告特性和CI/CD集成，轻松构建自动化UI功能测试。测试工程师可以使用BDD来减少沟通问题并集成测试，确保在部署之前所有组件都能完美配合。

归根结底，BDD有助于改善业务和技术团队之间的沟通。通过使用TestComplete，您可以简化流程，通过在同一平台上合作，并将BDD的实时文档纳入您的其他测试套件中。