您是否听说过 行为驱动开发(behavior-driven development)(BDD),并好奇这是个什么东西?也许你发现了团队成员在谈论“嫩瓜”(LCTT 译注:“ 嫩瓜(gherkin)” 是一种简单的英语文本语言,工具 cucumber 通过解释它来执行测试脚本,见下文),而你却不知所云。或许你是一个 Python 人(Pythonista),正在寻找更好的方法来测试你的代码。 无论在什么情况下,了解 BDD 都可以帮助您和您的团队实现更好的协作和测试自动化,而 Python 的 behave 框架是一个很好的起点。
最近业务上使用的自动化测试项目在改进项目执行方案,优化框架,正好结合实践记录一下最近遇到的问题和解决方法,打算从以下几个部分跟大家探讨一下:
cucumber是一款测试工具。可用于大多数主流编程语言。比如JAVA、JS、Ruby、C++、Lua、Android、Kotlin、C#/F#、PHP、Python、Go、Groovy、Scala等等。其中JAVA、JS、Ruby的代码托管在cucumber下。官方建议选择与生产代码相同的平台或编程语言的实现。本文主要是JAVA平台下的介绍教程。使用方法非常简单,创建一个mvn工程,在pom.xml文件引入以下依赖即可。
1.1 什么是BDD(行为驱动开发) 首先了解一个概念,BDD(BehaviorDrivenDevelopment:行为驱动开发)为用户提供了从 开发人员和客户的需求创建测试脚本的机会。因此,开始时,开发人员,项目经理,质量保证,用户验收测试人员和产品所有者(股东)都齐聚一堂,集思广益,讨论应该传递哪些测试场景,以便成功调用此软件/应用程序。这样他们想出了一组测试场景。所有这些测试脚本都是简单的语言,所以它也可以服务于文档。
Leo Li,携程高级软件工程师,负责度假 BDD-Test UI 自动化测试框架的研发、维护和迭代等工作。
这几天产品线这里要搞LLT(Low level Test)重点工作,保障版本的高质量发布。工作当然包括一系列的规范、培训、编码、检视,不过具体看下来主要还是提取了下面的一些度量要点:
行为驱动开发(BDD)似乎非常容易。测试以易于阅读的格式编写,允许产品所有者,业务赞助商和开发人员提供反馈。这些测试是团队的有效文档,因此不需要任何要求。这些工具易于使用,可让自动化测试套件。每次测试运行都会生成报告,以记录每个步骤并向您显示测试失败的地方。
cucumber早在ruby环境下应用广泛,作为BDD框架的先驱,cucumber后来被移植到了多平台,简单来说cucumber是一个测试框架,就像是juint或是rspec一样,不过cucumber遵循的是BDD的原则。
工业时代流水线的发明将生产任务的效率大大提升。同样,在软件开发过程中流水线的建立也能帮助我们更好的产出、提升效率。
相信大部分的人都听说过 BDD,即:行为驱动开发,但并未涉及到它的使用方和项目实战。
BDD,行为驱动开发是 敏捷软件开发 的一种技术,鼓励软件项目的所有成员之间的相互协助
为了确保服务按预期工作,必须编写测试来验证服务是否可以正确地与基础设施服务和其他服务进行交互。一种方法是启动所有服务并通过其API进行测试,而这是所谓的端到端测试,缓慢、脆弱而且昂贵,它位于金字塔顶端,有其价值,但应该最大限度减少端到端测试的数量。
测试驱动开发(TDD)相信大家已经很熟悉了,而行为驱动开发(BDD)其实是TDD的一种演化。那什么是BDD,为什么要使用BDD, BDD下的自动化测试该如何做呢?本文将通过简单的例子,向大家展示如何使用Cucumber 描述需求,编写、执行测试用例,并输出测试报告。
ScalaTest几乎已经成为Scala语言默认的测试框架,而在JVM平台下,无论是否使用Scala进行开发,我认为仍有尝试ScalaTest的必要。这主要源于它提供了多种表达力超强的测试风格,能够满足各种层次的需求包括单元测试、BDD、验收测试、数据驱动测试。正如ScalaTest的创建者Bill Venners所说: A guiding design principle of ScalaTest is that different people on a team should be able look
作为一个自动化测试工具,这些已经足够了。然而,Cucumber的首页清楚地写着“making BDD fun”,即让行为驱动开发充满欢乐。行为驱动开发(BDD)是什么?Cucumber的开发者为什么又要给它扣上这个帽子呢?
自动化测试一直是敏捷开发和敏捷测试的重要基石,也是DevOps和CI/CD必不可少的组成部分。由于不同项目的测试需求不同,以及各种不同的限制,导致需要的自动化测试框架和工具也不同。比如很多金融和能源类的企业就倾向于选择收费的企业级自动化测试框架或者工具,而新型互联网企业则倾向于开源免费的自动化测试框架或者工具,或者基于它们进行二次定制开发,或者重新开发适合自己的自动化测试框架、工具或者平台。 我之前写过一篇文章——《自动化测试框架Cucumber和RobotFramework的实战对比》仅仅针对两种自动化测
今天我们来谈一谈TDD 和 BDD 两项实践。我们先来说说 TDD,也就是测试驱动开发(Test Drvien Development)。
移动端APP是一个复杂的系统,不同功能之间耦合性很强,很难仅通过单元测试保障整体功能。UI测试是移动应用开发中重要的一环,但是执行速度较慢,有很多重复工作量,为了减少这些工作负担,提高工作效率,需要引入可持续集成的自动化测试方案。
今日洞见 文章作者来自ThoughtWorks:毛超。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任。 1 引言 在Ruby社区中,测试和BDD一直是一个被热议的话题,不管是单元测试,集成测试和功能测试,你总能找到能帮助你的工具,Cucumber就是被广泛
在test目录下建一个resources目录,在该目录下建一个test.feature的文件
因为各种事,这篇本来属于上周的拖到了就今天,一篇关于移动端测试工具Calabash的文章,看着篇幅比较小,就接受了。本身精力不在Android和iOS开发,所以也就没按部就班的复原教程中的实例,仅当开阔视野了。
总第242篇 2018年 第34篇 前言 关于测试领域的自动化,已有很多的文章做过介绍,“黑科技”也比比皆是,如通过Java字节码技术实现接口的录制,Fiddler录制内容转Python脚本,App中的插桩调试等,可见角度不同,对最佳实践的理解也不一样。这里想要阐述的是,外卖(上海)QA团队应用相对“小众”的Ruby,在资源有限的条件下实现自动化测试的一些实践与经验分享。 背景 加入外卖上海团队时,共2名QA同学,分别负责App与M站的功能测试,自动化测试停留在学习北京侧接口测试框架的阶段,实效上近乎为0
自动化测试在产品测试上有着非常重要的作用。实现测试自动化有多种积极的方式,包括最大限度地减少测试执行时间;在关键的发布阶段,用更少的时间确保更大的覆盖范围;在产品开发阶段,可靠又重复性地运行以确保没有
在现代软件开发中,编写和维护高质量的测试用例已经成为我们日常工作的重要部分。而JavaScript作为全球最流行的编程语言之一,拥有大量的库和框架,能够帮助我们更好地进行测试。
在Istio中,灰度发布是通过指定不同版本的流量路由规则来实现的。这些规则描述了如何将传入的流量分配到不同的版本中,从而实现逐步推出新版本的目的。
在这篇文章中,我们将介绍一下开源的Web-API自动化测试框架——Karate介绍
来源:https://cucumber.io/docs/guides/overview/
测试驱动开发(TDD)是一种开发软件的过程,其中在编写代码之前先编写测试。一旦完成,开发人员将努力编写足够的代码以通过测试,然后开始重构。
下面的Test Pyramid摘自Martin Fowler的 文章,越高层次产生的用户价值会更高且更慢,越低层次的产生的价值更低且更快,你所写的任何一行单元测试代码对于你的用户来说都是不可见的,他能感知到的只能通过UI来体现。可以看出我们需要很多的单元测试来保证我们的代码质量,这对开发人员来说是有巨大价值的,它能够帮开发人员快速发现且定位问题。
服务编排是Fizz网关提供的一个强大的功能,能够基于现有的业务微服务通过在线配置的方式快速的生成一个聚合接口,减少中间层胶水代码以及降低编码投入。本文介绍服务编排三个常见场景的使用:单API结果裁剪、多API数据聚合、多API之间传递依赖。
前篇介绍了,使用 Newbe.Pct 之前的准备工作。本篇将开始介绍如何使用本项目运行第一个测试用例。
为了适应快速发展的行业生态系统的步伐,必须加快应用程序交付时间,而且必须不能以质量为代价。在更短的时间内达到质量的目的至关重要,因此质量保障倍受关注。为了满足对卓越质量和更快迭代的要求,越来越多的企业引入自动化,并将优先进行自动化测试。敏捷开发模型使其测试过程自动化变得越来越必要,但是最关键的方面是选择正确的测试自动化框架。
上周初步完成了LLVM入门教程的翻译,这几天了解了下LLVM项目中的MLIR架构,整体感觉MLIR目的是在高层语言转换到机器码的过程中能够重用更多的优化,核心思想是采用了多层IR,并定义了IR间相互转换的框架。本系列文章将对LLVM项目中的MLIR教程进行翻译。
原文地址:Functional-Light-JS 原文作者:Kyle Simpson-《You-Dont-Know-JS》作者 第 8 章:列表操作 你是否还沉迷于上一节介绍的闭包/对象之中?欢迎回来
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计了测试用例并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果与期望结果的比较。在此过程中,为了节省人力、时间或硬件资源,提高测试效率,便引入了自动化测试.如果说测试工程师今年应该学习什么的问题,答案可能包括编程语言、库和框架,但如果你需要改进或学习一件事,那么下面这些框架是你绕不开的技能。
这篇文章基于实际使用场景总结了 24 个 ES6 代码段,可用来解决项目中可能遇到的一系列问题。
软件行业正迈向自主、快速、高效的未来。为了跟上这个高速前进的生态系统的步伐,必须加快应用程序的交付时间,但不能以牺牲质量为代价。快速实现质量是必要的,因此质量保证得到了很多关注。为了满足卓越的质量和更快的上市时间的需求,自动化测试将被优先考虑。对于微型、小型和中型企业(SMEs)来说,自动化自身的测试过程是非常必要的,而最关键的方面是选择正确的自动化测试框架。
循环神经网络的神经网络体系结构,它针对的不是自然语言数据,而是处理连续的时间数据,如股票市场价格。在本文结束之时,你将能够对时间序列数据中的模式进行建模,以对未来的值进行预测。 1.上下文信息 回到学校,我的一个期中考试仅由真的或假的问题组成时。假设一半的答案是“真的”,而另一半则是“假的”。我想出了大部分问题的答案,剩下的是靠随机猜测。我做了一件聪明的事情,也许你也可以尝试一下这个策略。在计数了我的“真”的答案之后,我意识到它与“假”这个答案不成比例。于是我的大部分猜测是“假”的,这样就可以平衡分配。
背景 测试作为质量保证极其重要的一环,在移动App开发流程中起到非常关键的作用。从开发工程师到测试工程师,人人都应具备良好的测试意识,将隐患和风险在上线之前找出并解决,可以有效的减少线上事故。 美团和大众点评App作为美团点评平台的主要入口,支持承载着美团点评各大业务。其中美团点评境外度假业务主要包括了出境游相关业务以及所有的境外城市站,也是美团点评非常看重和大力发展的业务线。为了保证质量,需要进行各项测试:冒烟测试[1]、功能测试、集成测试、专项性能测试,回归测试[2]。其中冒烟测试和回归测试大多由开发自
简介 移动APP的UI自动化测试长久以来一直是一个难点,难点在于UI的”变”, 变化导致自动化用例的大量维护。从分层测试的角度,自动化测试应该逐层进行。最大量实现自动化测试的应该是单元测试,最容易实现也最容易在早期发现问题;其次是接口级测试,以验证逻辑为目的进行自动化,由于接口的相对稳定,自动化测试成本相对也可以接受;自动化成本最大的便是UI级自动化测试,然而UI界面是直接反馈给用户的效果展示,适度的尤其是BVT级的自动化测试也是非常必要的。本文通过分析几种自动化框架的异同,使测试人员在选
当今软件开发领域中,测试是确保代码质量和功能稳定性的关键步骤。而测试框架是在软件开发过程中使用的工具,有助于组织、管理和执行测试。在这篇文章中,我们将介绍几种常见的测试框架类型:TDD(测试驱动开发)、DDT(数据驱动测试)、BDD(行为驱动开发)和ATDD(行为驱动开发)以及 DevOps,本文就给大家介绍一下它们的特点及异同。
简介 移动APP的UI自动化测试长久以来一直是一个难点,难点在于UI的”变”, 变化导致自动化用例的大量维护。从分层测试的角度,自动化测试应该逐层进行。最大量实现自动化测试的应该是单元测试,最容易实现也最容易在早期发现问题;其次是接口级测试,以验证逻辑为目的进行自动化,由于接口的相对稳定,自动化测试成本相对也可以接受;自动化成本最大的便是UI级自动化测试,然而UI界面是直接反馈给用户的效果展示,适度的尤其是BVT级的自动化测试也是非常必要的。本文通过分析几种自动化框架的异同,使测试人员在选择自动化框架时有所
作者:赵丽娜 简介 移动 APP 的 UI 自动化测试长久以来一直是一个难点,难点在于UI的”变”, 变化导致自动化用例的大量维护。 从分层测试的角度,自动化测试应该逐层进行。 最大量实现自动化测试的
英文 | https://madza.hashnode.dev/24-modern-es6-code-snippets-to-solve-practical-js-problems 作者 | Madza 译者 | 王强 策划 | 李俊辰
https://juejin.cn/post/6906398702269628424
本项目为测试工作者提供了一套“简易的 Web E2E 自动化测试脚手架”。测试工作者可以通过该脚手架,实现编写一些简单的 Web E2E 自动化测试。
MVP的全称为Model-View-Presenter,Model提供数据,View负责显示,Controller/Presenter负责逻辑的处理。MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,它们之间的通信是通过Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter内部。 用一句话来概括MVP:所有数据仅能保存在称为 Model 的类对象(简单说就是一种文件)中,Presenter是视图(View)与Model之间的纽带,View只能通过Presenter来读取数据。 MVP优点:
诞生于上世纪末的测试驱动开发(TDD)已经算是很深入人心了,一定程度上来说它通过既有的约定(测试)减少了开发人员间的沟通成本。但这些测试也只是开发人员自己对需求的理解,有时候开发人员、业务人员、市场部门和用户对需求的理解是有分歧的,传统的方案是厚厚的需求说明书,从测试驱动开发引申来的行为驱动开发BDD(Behavior Driven Development)可以有效的解决这个问题。
随着软件系统规模的持续增大,业务复杂度的持续增加,软件测试的复杂度也随之越来越大。而软件测试工作复杂度的直接体现就是测试用例编写、维护、执行和管理,所以编写易读、易维护和易管理的测试用例可以有效的降低测试工作的复杂度。本文主要系统的介绍了测试用例的几种经典编写和管理方法,包括每种的特点,适用场景以及实例。帮助不同的项目和团队,根据自己的情况选择适合的测试用例编写和管理方法,从而降低测试工作的复杂度,提高测试工作的效率。
领取专属 10元无门槛券
手把手带您无忧上云