BDD(Behavior-Driven Development)行为驱动开发介绍

这篇具有很好参考价值的文章主要介绍了BDD(Behavior-Driven Development)行为驱动开发介绍。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

为什么需要BDD?

“开发软件系统最困难的部分就是准确说明开发什么” (“The hardest single part of building a software system is deciding precisely what to build” — No Silver Bullet, Fred Brooks) 。
看一下下面的开发场景:

  • 场景一:业务分析人员觉得自己分析的需求已经写的很清晰了,并且跟技术人员进行了足够的沟通,可是开发完做Desk check的时候,发现所开发的功能还是跟期望有差距。
  • 场景二:开发团队辛辛苦苦开发完一个功能,满怀信心的去给产品经理/客户展示的时候,才发现原来客户需求的功能不是这样的。
    这些场景是不是似曾相识?为什么会这样?

第一个场景是开发团队内部技术人员跟需求分析人员的理解有偏差,导致大家理解的需求其实是不一样的;
第二个场景是开发团队没有真正理解产品经理/客户所提出来的真实需求,导致开发的产品跟需求不一致。其实,产生这两个不一致的真正原因是因为不同角色有着不同的领域知识,说着不同的语言,大家在沟通的时候,如果都用自己领域语言,必然会产生沟通代沟,导致理解的不一致性。
领域知识不同、语言不通导致沟通障碍,这个客观存在的问题该如何解决呢?BDD正是为此而生。.

BDD究竟是什么?

BDD的提出者Dan North强调BDD不是关于测试的,它是在应用程序存在之前,写出用例与期望,从而描述应用程序的行为,并且促使在项目中的人们彼此互相沟通。

要给BDD下个清晰易懂的定义很难,包括大师们也这么认为,这里试着总结以下几点:

  1. 关注的是业务领域,而不是技术:BDD强调用领域特定语言(DSL, domain specific language)描述用户行为,定义业务需求,而不会关心系统的技术实现。
  2. 不是工具,强调的是一种协作方式:BDD要求各个角色共同参与系统行为的挖掘和定义,以实现对业务价值的一致理解。
  3. 不是关于测试的:BDD源自TDD,又不同于TDD,重点不是关于测试的,但可以指导更好的做自动化测试。
  4. 全栈敏捷方法:BDD促使团队所有角色从需求到最后的测试验证,进行高度的协作和沟通,以交付最有价值的功能。

BDD的作用

BDD的作用是把利益关系人、交付团队等不同方面的项目相关人员集中到一起,形成共同的理解,共同的价值观以及共同的期望值。它可以帮助我们:

  1. 关注用户行为
    2.交付最有用的功能
  2. 在团队内部维护一致的术语
  3. 探究需求实例
  4. 编写和维护需求
  5. 创建活的文档
  6. 消除协作与沟通障碍

BDD 中的常见概念

在BDD中,常用的概念如下:

  • Epic: 史诗,一般指一个版本或一批功能更新
  • Feature: 特性,一般指一个功能点,如登录,添加商品,查询商品等,在测试中对应一个测试套件
  • Scenario:场景,即Story,一个明确的场景,对应一个测试用例
  • Step: 步骤,测试步骤有Given/When/Then三种
  • Given: 假设,给定数据或前置条件,对应测试中的setup
  • When: 当…时,对应一个测试步骤
  • Then: 然后,即期望结果,对应一个测试断言
  • And: 同上,可以用于Given/When/Then后

什么样的项目适合BDD?

  • 简单的一次性项目,沟通交流成本都较低的情况下,没有必要使用BDD;
  • 业务比较轻量,重在技术方面的项目,可以使用简单的白板上的BDD,不需要在BDD工具记录需求用例文档;
  • 业务复杂、团队成员较多的项目,沟通成本高,BDD很有必要。

BDD规格怎么写?

用例场景的描述格式“GIVEN… WHEN… THEN… ”对大家都不陌生,但用这个格式写出好的用例却是非常的难,尤其是新手。这里总结几点供大家参考:

1.业务层抽取,业务语言描述

根据业务层的数据流,在每个数据停留点进行纵切,抽取出一个个用例场景。描述语言一定是业务领域可懂的,不要涉及任何实现相关的技术细节。所描述的场景一定是从业务层抽象出来,体现真实业务价值的。

2.技术人员可懂,自动化友好

所描述的用例场景要能驱动开发,必须要让技术人员易于理解;要指导自动化测试,还得要求对于自动化的实现是友好的。这一点似乎是跟第一点有些矛盾,但我们严格遵守BDD的格式要求还是可以做到的。其中,GIVEN从句描述的是场景的前提条件、初始状态,通常是一种现在完成时态;WHEN从句是采取某个动作或者是发生某个事件,一定是动词,通常是一般现在时;THEN从句用“应该…(should be…)”来描述一种期望的结果,而不用断言(assert),后者与测试关联更紧密。

3.数据驱动,需求实例化

抽象的业务语言描述的需求,往往由于太抽象而缺失掉很多关键信息,导致不同人员对需求理解的不一致。想要既抽象又能包含细节信息,就需要采用需求实例来描述。简单说来,就是给场景用例举例说明。举例就会需要列举数据,如果在场景用例描述里边直接添加数据实例,那样的用例将会很混乱,可读性和可维护性都非常差。如果我们能够在描述场景的用例里边用一些变量来代替,把变量对应的值(数据)提取出来存为一个表格或者独立的文件,这样将会使得用例的可读性很好,而且也不会缺失细节信息(数据),后期的维护和修改也较为方便。这就是数据驱动的方法来描述实例化的需求。

下面举几个例子,大家体会一下:

场景一:检查收件箱,可以看出第三个清晰明了且能体现业务价值,比较符合上面的要求。

BDD(Behavior-Driven Development)行为驱动开发介绍,440-系统测试与性能调优,驱动开发,BDD,行为驱动开发

场景二:限制非法用户查看某些受限内容,BDD要强调什么(What),而不是怎么(How),第二个写的比较好。

BDD(Behavior-Driven Development)行为驱动开发介绍,440-系统测试与性能调优,驱动开发,BDD,行为驱动开发

场景三:添加图书到购物车并计算总额

BDD(Behavior-Driven Development)行为驱动开发介绍,440-系统测试与性能调优,驱动开发,BDD,行为驱动开发

实现BDD 的工具

BDD不只是测试, 但是BDD可以很好的指导测试。
在实际的场景中, 实现BDD 主要包括两个部分:

  1. 使用通用领域语言编写规格
  2. 实现规格的自动化测试

可以帮助实现BDD 的工具有:

  1. Cucumber: Cucumber 是最常用的 BDD 工具之一,它使用简洁的自然语言(Gherkin)编写测试用例,并支持多种编程语言和测试框架。

  2. JBehave: JBehave 是另一个流行的 BDD 工具,它使用类似 Gherkin 的语法编写测试用例,支持 Java 平台的自动化测试。

  3. SpecFlow: SpecFlow 是为 .NET 平台开发的 BDD 工具,它能够将 Gherkin 语法的测试用例与 .NET 代码结合起来执行。

  4. Behave: Behave 是一个 Python BDD 工具,它使用 Gherkin 语法编写测试用例并支持 Python 测试框架。

  5. Jasmine: Jasmine 是一个用于 JavaScript 的 BDD 框架,它提供了简洁的语法和丰富的断言库,适用于前端开发的 BDD 测试。

  6. Robot Framework: Robot Framework 是一个通用的自动化测试框架,它支持 BDD 风格的测试,并提供了许多扩展库和插件。

BDD测试在CI/CD 阶段的位置

在CI/CD(持续集成/持续部署)流程中,BDD(行为驱动开发)测试持续被执行并且在各个阶段都起到关键性的角色。

以下是经典的CI/CD流程中,BDD测试可能出现的位置:

  1. 持续集成(Continuous Integration)阶段:

    • 这是开发者提交代码更改到代码存储库的阶段,所有新的代码更改都会自动触发构建和测试过程。在这个阶段,BDD测试(以及单元测试和集成测试)通常会运行,以确保新代码的更改或新增功能没有引入新的错误或改变了预期的行为。
  2. 持续交付(Continuous Delivery)阶段:

    • 在这个阶段,所有的提交都会通过实际生产环境的完全自动化的测试。在这个阶段,BDD测试可以用来验证工作流程和业务场景,保证软件的行为与预期一致。
  3. 持续部署(Continuous Deployment)阶段:

    • 这个阶段指的是自动将更新的应用版本部署到生产环境的过程。虽然BDD测试通常在持续部署之前就完成了,但是如果你在部署之后有进行任何形式的后期验证(例如: 实时监控,日志分析等),那么这些验证应该再次验证所有预期的行为仍然按预期工作。

整个CI/CD流程中,BDD测试有助于快速捕捉和修复软件错误,并确保应用符合预期的行为。如果发现测试失败或行为不匹配,CI/CD流程会被中断,从而避免将错误的代码推送到生产环境。文章来源地址https://www.toymoban.com/news/detail-800580.html



到了这里,关于BDD(Behavior-Driven Development)行为驱动开发介绍的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • ET介绍——更为便捷高效的AI框架-行为机(Behavior Machine)

    顾名思义,类比状态机每个节点是一个状态,行为机每个节点是描述一种行为。行为机每个节点之间是互斥的,并且节点相互之间完全不用关心是怎么切换的。这里就不讲状态机跟行为树是怎么做ai的了,这里只讲用行为机怎么做一个ai。举个例子 mmo中的小怪策划案,大致会

    2024年02月05日
    浏览(39)
  • 公开 学生课堂行为数据集 SCB-Dataset Student Classroom Behavior dataset

    公开 学生课堂行为数据集 SCB-Dataset Student Classroom Behavior dataset b站:https://www.bilibili.com/video/BV1Fv4y1H7sa/ arxiv: https://arxiv.org/pdf/2304.02488.pdf github: https://github.com/Whiffe/SCB-dataset 百度云:https://pan.baidu.com/s/1y3lGEYd-I-jxZKyAyw4MPw?pwd=zdbg extraction code: ZDBG

    2024年02月12日
    浏览(41)
  • AGI之Agent:《Generative Agents: Interactive Simulacra of Human Behavior生成代理:人类行为的交互模拟》翻译与解读

    AGI之Agent:《Generative Agents: Interactive Simulacra of Human Behavior生成代理:人类行为的交互模拟》翻译与解读 目录 《Generative Agents: Interactive Simulacra of Human Behavior》翻译与解读 Figure 1: Generative agents are believable simulacra of human behavior for interactive applications. In this work, we demonstrate generat

    2024年01月25日
    浏览(43)
  • 【威胁情报挖掘-论文阅读】学习图表绘制 基于多实例学习的网络行为提取 SeqMask: Behavior Extraction Over Cyber Threat Intelligence

    🌈你好呀!我是 是Yu欸 🌌 2024每日百字篆刻时光,感谢你的陪伴与支持 ~ 🚀 欢迎一起踏上探险之旅,挖掘无限可能,共同成长! 前些天发现了一个人工智能学习网站,内容深入浅出、易于理解。如果对人工智能感兴趣,不妨点击查看。 论文涉及7位专家的评估,不方便模仿

    2024年03月20日
    浏览(52)
  • 领域驱动设计(Domain Driven Design)之建立领域模型

    在实际项目中,模型设计者往往过早陷入具体构造块类型的识别,比如实体、聚合、领域服务,而忽略了领域模型表达领域概念的目的。我们应该基于领域概念设计领域模型,然后再采用合适的模式降低领域模型的复杂度,进一步增加领域模型的表达能力。 领域模型的作用,

    2024年02月03日
    浏览(37)
  • 【论文导读】- Cluster-driven Graph Federated Learning over Multiple Domains(聚类驱动的图联邦学习)

    Cluster-driven Graph Federated Learning over Multiple Domains 原文链接:Cluster-driven Graph Federated Learning over Multiple Domains:https://openaccess.thecvf.com/content/CVPR2021W/LLID/papers/Caldarola_Cluster-Driven_Graph_Federated_Learning_Over_Multiple_Domains_CVPRW_2021_paper.pdf Federated Learning (FL) deals with learning a central model (i.e.

    2024年02月03日
    浏览(61)
  • 软件开发方法论:TDD、BDD、DDD、ATDD、DevOps

    一、TDD:测试驱动开发 测试驱动开发(Test-Driven Development, TDD)是敏捷开发中的一项核心实践和技术。针对每个功能点抽象出接口代码,然后编写单元测试代码。目前的一些模式对TDD的支持都非常不错,比如MVC和MVP等。 适合TDD这种模式的项目必须具备: 项目的需求必须足够清

    2024年02月06日
    浏览(61)
  • quarkus实战之三:开发模式(Development mode)

    这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos 前文咱们曾提到过几种启动方式,有一种用maven命令启动的,可以进入开发模式,命令如下: 当时只提到此模式能看到详细系统信息,并未展开说明更多信息,实际上,此模式下还有很多实用的功能

    2024年02月16日
    浏览(33)
  • SDL 软件安全开发周期 Security Development Lifecycle

    本文参考多篇文章写作而成,出处在文末注明。 SDL的是安全开发生命周期,Security Development Lifecycle。由微软最早提出,是一种专注于软件开发的安全保障流程。为实现保护最终用户为目标,它在软件开发流程的各个阶段引入安全和隐私问题。 SDL的核心理念就是将安全考虑集

    2024年02月08日
    浏览(38)
  • 篇十八:状态模式:状态驱动的行为

    篇十八: \\\"状态模式:状态驱动的行为\\\" 开始本篇文章之前先推荐一个好用的学习工具,AIRIght,借助于AI助手工具,学习事半功倍。欢迎访问:http://airight.fun/。 另外有2本不错的关于设计模式的资料,分享出来与大家学习参考。 链接:https://pan.baidu.com/s/1RmhQF_o1CdK8U7s5KeILog?pwd=

    2024年02月13日
    浏览(28)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包