很多开发问题都是源于沟通不畅。例如，开发人员可能会处理他们并不完全理解的规范，或者相关人员会在并不了解某项功能的情况下就提出需求。这导致的结果就是返工，从而导致增加成本和项目延误，而且很多情况下会造成项目因为远超预算而失败。
行为驱动开发（BDD）通过鼓励跨职能的协作来克服这些挑战。BDD并不是取代现有的敏捷开发过程，而是作为一个插件，提高敏捷开发成功的可能性——可靠、及时地交付工作软件，满足企业不断发展的需求。
BDD帮助您实现敏捷开发的承诺——可靠、按时交付可用软件，且满足不断演变的规格要求。
一起来看看BDD和自动化测试如何共同改进软件开发周期。
什么是BDD？
行为驱动型开发（Behavior-driven development，简称BDD）通过鼓励跨职业协作来建立对问题的共同理解，从而缩小业务和技术团队之间的差距，并且让团队在小迭代中工作，缩短反馈循环。还能生成业务友好的文档，这些文档会根据系统的行为自动进行检查。
该过程包括三个核心步骤：
-
发现：针对一个即将进行的小型更改（例如用户情景），协作创建新功能的具体示例，以此来明确问题的具体范围，最终实现对应该交付的内容详细的、共同的理解；
-
自动化：用可自动验证功能是否存在的方式制定具体用例。通常，这些用例会记录在Gherkin特性文件中，包含Given-When-Then场景。这些功能文件易于理解，即使对非技术人员来说也是如此；
-
编写自动化测试代码：根据每个场景描述编写自动化测试代码。然后将生成的自动化测试用于指导代码开发。
BDD流程中最重要的部分是“发现”阶段，即定期举办一个研讨会，这个研讨会中必须至少有三个视角的代表：相关人员、测试工程师和开发人员。在这个频繁召开的简短研讨会上，可以通过使用具体的例子来达成对要求的共识。常见的会议形式称为“Example Mapping”。
采用BDD时，开发团队最常见的错误是将其视为另一种测试。如果没有业务团队和技术团队之间的对话，这些测试将无法解决沟通不畅问题，这将导致项目延迟、预算超标。
测试自动化如何适应BDD
大多数的开发团队对测试驱动开发（TDD）中的测试自动化都很熟悉。例如，开发人员可以编写单元测试，测试工程师可以编写集成测试，在每次提交或部署之前，这些测试会作为构建过程的一部分自动执行。任何问题都会被标记出来给开发人员，让他们在投入生产之前解决。
BDD实践与TDD是相互配合、结合使用的。在将用户情景引入开发并开始TDD流程前，团队应用BDD实践来管理需求，生成具体用例，将其制定为易读的规范，并自动执行它们以创建动态文档。这些规范会与TDD测试一起，在像Jenkins这样的持续集成服务器上运行。
以下是典型的开发过程：
-
团队想出了一个用户情景；
-
在发现研讨会中，相关人员、测试工程师和开发人员创建具体的示例，来说明系统的预期行为；
-
将具体示例形成基于Gherkin的文档；
-
基于Gherkin的文档可以自动创建活动文档；
-
交付团队拉取用户情景，开始编写单元测试和特性，并构建集成测试；
-
当用户情景完成后，CI构建将确保所有单元和集成测试通过，以及确保满足业务案例的Gherkin BDD测试通过。
应用BDD实践生成的动态文档还有另一个好处。由于Gherkin是用简单的英语编写的，因此相关人员可以轻松地查看哪些功能已经通过了，哪些功能仍在开发中已被弃用。这让所有人都能保持同步，而无需在每个产品增量中手动更新文档。
TestComplete帮助团队实施BDD
在实施BDD时，开发团队面临一些挑战，尤其是在沟通和集成方面。
一个常见的挑战是将活动文档与其他测试套件一起管理，并继续向相关人员提供可操作的报告。
TestComplete通过原生支持Gherkin的Given-When-Then场景简化了这个过程。无需构建和维护跨多个不同工具的复杂技术堆栈，就可轻松地将功能文件转换为自动化测试，也不需要任何额外的插件。
与相关人员共享报表也很容易。TestComplete的Zephyr for Jira集成可以轻松地与业务团队共享BDD见解，无需技术团队定期生成和通过邮件发送报告。它提供了一个单一的界面，每个人都可以使用更广泛的Jira生态系统来查看测试状态和相关的bug报告。
除了创建BDD场景之外，TestComplete还可以通过其业界领先的记录和回放功能、报告特性和CI/CD集成，轻松构建自动化UI功能测试。测试工程师可以使用BDD来减少沟通问题并集成测试，确保在部署之前所有组件都能完美配合。
结论
归根结底，BDD有助于改善业务和技术团队之间的沟通。通过使用TestComplete，您可以简化流程，通过在同一平台上合作，并将BDD的实时文档纳入您的其他测试套件中。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
