Leo Li,携程高级软件工程师,负责度假 BDD-Test UI 自动化测试框架的研发、维护和迭代等工作。
您是否听说过 行为驱动开发(behavior-driven development)(BDD),并好奇这是个什么东西?也许你发现了团队成员在谈论“嫩瓜”(LCTT 译注:“ 嫩瓜(gherkin)” 是一种简单的英语文本语言,工具 cucumber 通过解释它来执行测试脚本,见下文),而你却不知所云。或许你是一个 Python 人(Pythonista),正在寻找更好的方法来测试你的代码。 无论在什么情况下,了解 BDD 都可以帮助您和您的团队实现更好的协作和测试自动化,而 Python 的 behave 框架是一个很好的起点。
在现代软件开发中,编写和维护高质量的测试用例已经成为我们日常工作的重要部分。而JavaScript作为全球最流行的编程语言之一,拥有大量的库和框架,能够帮助我们更好地进行测试。
cucumber是一款测试工具。可用于大多数主流编程语言。比如JAVA、JS、Ruby、C++、Lua、Android、Kotlin、C#/F#、PHP、Python、Go、Groovy、Scala等等。其中JAVA、JS、Ruby的代码托管在cucumber下。官方建议选择与生产代码相同的平台或编程语言的实现。本文主要是JAVA平台下的介绍教程。使用方法非常简单,创建一个mvn工程,在pom.xml文件引入以下依赖即可。
cucumber早在ruby环境下应用广泛,作为BDD框架的先驱,cucumber后来被移植到了多平台,简单来说cucumber是一个测试框架,就像是juint或是rspec一样,不过cucumber遵循的是BDD的原则。
作为一个自动化测试工具,这些已经足够了。然而,Cucumber的首页清楚地写着“making BDD fun”,即让行为驱动开发充满欢乐。行为驱动开发(BDD)是什么?Cucumber的开发者为什么又要给它扣上这个帽子呢?
最近业务上使用的自动化测试项目在改进项目执行方案,优化框架,正好结合实践记录一下最近遇到的问题和解决方法,打算从以下几个部分跟大家探讨一下:
行为驱动开发(BDD)似乎非常容易。测试以易于阅读的格式编写,允许产品所有者,业务赞助商和开发人员提供反馈。这些测试是团队的有效文档,因此不需要任何要求。这些工具易于使用,可让自动化测试套件。每次测试运行都会生成报告,以记录每个步骤并向您显示测试失败的地方。
测试驱动开发(TDD)相信大家已经很熟悉了,而行为驱动开发(BDD)其实是TDD的一种演化。那什么是BDD,为什么要使用BDD, BDD下的自动化测试该如何做呢?本文将通过简单的例子,向大家展示如何使用Cucumber 描述需求,编写、执行测试用例,并输出测试报告。
1.1 什么是BDD(行为驱动开发) 首先了解一个概念,BDD(BehaviorDrivenDevelopment:行为驱动开发)为用户提供了从 开发人员和客户的需求创建测试脚本的机会。因此,开始时,开发人员,项目经理,质量保证,用户验收测试人员和产品所有者(股东)都齐聚一堂,集思广益,讨论应该传递哪些测试场景,以便成功调用此软件/应用程序。这样他们想出了一组测试场景。所有这些测试脚本都是简单的语言,所以它也可以服务于文档。
来源:https://cucumber.io/docs/guides/overview/
自动化测试在产品测试上有着非常重要的作用。实现测试自动化有多种积极的方式,包括最大限度地减少测试执行时间;在关键的发布阶段,用更少的时间确保更大的覆盖范围;在产品开发阶段,可靠又重复性地运行以确保没有
前篇介绍了,使用 Newbe.Pct 之前的准备工作。本篇将开始介绍如何使用本项目运行第一个测试用例。
任跃华,携程机票前台软件工程师,参与了国际机票 RN Clean Architecture 落地和 MEC 中文测试框架研发工作。
相信大部分的人都听说过 BDD,即:行为驱动开发,但并未涉及到它的使用方和项目实战。
BDD,行为驱动开发是 敏捷软件开发 的一种技术,鼓励软件项目的所有成员之间的相互协助
webstorm mac中文版是WebStorm for Mac的最新本,被称为最好用的Web前端开发神器。WebStorm 新版对JavaScript,TypeScript和CSS支持更好,改进了Vue.js的体验,并为Jest集成增加了新功能。
工业时代流水线的发明将生产任务的效率大大提升。同样,在软件开发过程中流水线的建立也能帮助我们更好的产出、提升效率。
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计了测试用例并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果与期望结果的比较。在此过程中,为了节省人力、时间或硬件资源,提高测试效率,便引入了自动化测试.如果说测试工程师今年应该学习什么的问题,答案可能包括编程语言、库和框架,但如果你需要改进或学习一件事,那么下面这些框架是你绕不开的技能。
简介 移动APP的UI自动化测试长久以来一直是一个难点,难点在于UI的”变”, 变化导致自动化用例的大量维护。从分层测试的角度,自动化测试应该逐层进行。最大量实现自动化测试的应该是单元测试,最容易实现也最容易在早期发现问题;其次是接口级测试,以验证逻辑为目的进行自动化,由于接口的相对稳定,自动化测试成本相对也可以接受;自动化成本最大的便是UI级自动化测试,然而UI界面是直接反馈给用户的效果展示,适度的尤其是BVT级的自动化测试也是非常必要的。本文通过分析几种自动化框架的异同,使测试人员在选
简介 移动APP的UI自动化测试长久以来一直是一个难点,难点在于UI的”变”, 变化导致自动化用例的大量维护。从分层测试的角度,自动化测试应该逐层进行。最大量实现自动化测试的应该是单元测试,最容易实现也最容易在早期发现问题;其次是接口级测试,以验证逻辑为目的进行自动化,由于接口的相对稳定,自动化测试成本相对也可以接受;自动化成本最大的便是UI级自动化测试,然而UI界面是直接反馈给用户的效果展示,适度的尤其是BVT级的自动化测试也是非常必要的。本文通过分析几种自动化框架的异同,使测试人员在选择自动化框架时有所
作者:赵丽娜 简介 移动 APP 的 UI 自动化测试长久以来一直是一个难点,难点在于UI的”变”, 变化导致自动化用例的大量维护。 从分层测试的角度,自动化测试应该逐层进行。 最大量实现自动化测试的
为了确保服务按预期工作,必须编写测试来验证服务是否可以正确地与基础设施服务和其他服务进行交互。一种方法是启动所有服务并通过其API进行测试,而这是所谓的端到端测试,缓慢、脆弱而且昂贵,它位于金字塔顶端,有其价值,但应该最大限度减少端到端测试的数量。
移动端APP是一个复杂的系统,不同功能之间耦合性很强,很难仅通过单元测试保障整体功能。UI测试是移动应用开发中重要的一环,但是执行速度较慢,有很多重复工作量,为了减少这些工作负担,提高工作效率,需要引入可持续集成的自动化测试方案。
随着移动互联网的兴起,APP 测试的越来越被重视!Android 系统因为自己的开源性,测试工具和测试方法比较广为流传,但是 iOS 系统的私密性,导致很多测试的执行都有点麻烦。
自动化测试一直是测试领域桂冠上的明珠,几乎所有的测试团队都有建立团队的自动化。测试团队的自动化建设也被认为是团队提效的必经之路,但搭建和使用自动化路但路却并非一帆风顺。搭建自动化但时候有很多框架可以选用,合理但选择适合该团队的框架可以事半功倍,同时选择了框架之后就要受制于框架。使用自动化很多时候因为学习以及维护成本高,让初衷是提效为目的的自动化,成为了加重测试工作量之殇。
因为各种事,这篇本来属于上周的拖到了就今天,一篇关于移动端测试工具Calabash的文章,看着篇幅比较小,就接受了。本身精力不在Android和iOS开发,所以也就没按部就班的复原教程中的实例,仅当开阔视野了。
免费的开源框架和工具由于其开源特性,现在逐渐成为自动化测试的首选解决方案。区别在于,你是喜欢使用类库编写一个全新的自动化测试框架,或者喜欢使用一个现成的工具。
下面的Test Pyramid摘自Martin Fowler的 文章,越高层次产生的用户价值会更高且更慢,越低层次的产生的价值更低且更快,你所写的任何一行单元测试代码对于你的用户来说都是不可见的,他能感知到的只能通过UI来体现。可以看出我们需要很多的单元测试来保证我们的代码质量,这对开发人员来说是有巨大价值的,它能够帮开发人员快速发现且定位问题。
在这篇文章中,我们将介绍一下开源的Web-API自动化测试框架——Karate介绍
这几天产品线这里要搞LLT(Low level Test)重点工作,保障版本的高质量发布。工作当然包括一系列的规范、培训、编码、检视,不过具体看下来主要还是提取了下面的一些度量要点:
今日洞见 文章作者来自ThoughtWorks:毛超。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任。 1 引言 在Ruby社区中,测试和BDD一直是一个被热议的话题,不管是单元测试,集成测试和功能测试,你总能找到能帮助你的工具,Cucumber就是被广泛
今天我们来谈一谈TDD 和 BDD 两项实践。我们先来说说 TDD,也就是测试驱动开发(Test Drvien Development)。
软件获取:复制箭头里面内容→%77%77%77%2e%70%74%70%74%31%2e%74%6f%70←粘贴到浏览器搜索即可
自动化测试已成为软件开发生命周期中不可或缺的一部分。随着现代应用程序的复杂性不断增加,仅靠手动测试已不足以确保软件产品的质量和可靠性。在这种情况下,测试自动化框架在简化和优化测试流程方面发挥着至关重要的作用。设计和开发此类框架的一种流行方法是关键字驱动测试(KDT)。
Behavioural Driven Development (BDD)是从TDD发展来的(什么,TDD你都不知道?!),它通过自然语言定义系统行为,以功能使用者的角度,编写需求场景,且这些行为描述可以直接形成需求文档,同时也是测试标准。
背景 测试作为质量保证极其重要的一环,在移动App开发流程中起到非常关键的作用。从开发工程师到测试工程师,人人都应具备良好的测试意识,将隐患和风险在上线之前找出并解决,可以有效的减少线上事故。 美团和大众点评App作为美团点评平台的主要入口,支持承载着美团点评各大业务。其中美团点评境外度假业务主要包括了出境游相关业务以及所有的境外城市站,也是美团点评非常看重和大力发展的业务线。为了保证质量,需要进行各项测试:冒烟测试[1]、功能测试、集成测试、专项性能测试,回归测试[2]。其中冒烟测试和回归测试大多由开发自
验收标准标准表明用户故事满足客户的需求、期望和目标。最好的验收标准依靠敏捷方法中的流程团队成员的意见,客户成功经理、用户体验设计师、服务台工作人员以及能提供客户视角的任何人。
最早的有TDD, 测试驱动开发, 而BDD 是行为驱动开发, 更加关注用户的行为,
根据 Tricentis 主导的一项全球调查为我们提供了几个有关测试趋势的重要观察。趋势表明,团队倾向于使用功能测试(自动化测试)。
时间回到2022年,我参与了一个使用了Flutter技术构建的Web前端项目。在这个项目上,我们小组的目标是实施Flutter前端自动化测试。
Shopify CLI(命令行界面)是开发人员在 Shopify 平台上构建和部署 Theme、App、Hydrogen 店面时的重要工具。它提供了按照最佳实践创建新项目的工作流,实现了与开发平台的集成,并可以将产品工件分发给商家。我的团队,即 CLI Foundations,负责为设计和构建 Shopify CLI 的最佳实践和核心功能打基础。我们知道,开发人员在开发 Shopify App 时会大量用到终端,而他们使用 CLI 时并不总是能够获一致而愉快的体验。因此,我们开始使用 Node 彻底重写 Shopify CLI 2(那原本是用 Ruby 编写的),并在去年夏天推出了 Shopify Editions。在这篇博文中,我将介绍下我们团队之前为什么做出了重写的决策以及当时所做的权衡,我们在这个新的迭代中所遵循的原则,以及我们后续要克服的挑战和探索的想法。
Allure 报告是基于标准的 xUnit 结果输出,再添加补充数据而生成的,其报告的生成基于如下两个步骤。
随着 DevOps 的出现频率越来越高,很多企业都在蠢蠢欲动,想要设计和开发 DevOps 平台。工欲善其事必先利其器,本文为大家总结了 DevOps 各个阶段可以选择的工具,也许 DevOps 平台的技术选型在这一篇文章中就可以完成。
java进程的启动依赖于唯一的main函数,java中的junit采用插件隐藏main函数的方式,我们右键运行某测试用例。其本质上传入的是测试用例的路径。而插件启动的main函数通过args去接受传入的用例路径,并解析出测试用例的前后执行方法(包括一些注解),并对具体的方法进行排序,最后采用多线程submit任务,从而进行测试用例的执行。在idea中选中包路径运行整个包下的测试用例,相当于启动了若干个runner任务。
原文地址:Functional-Light-JS 原文作者:Kyle Simpson-《You-Dont-Know-JS》作者 第 8 章:列表操作 你是否还沉迷于上一节介绍的闭包/对象之中?欢迎回来
如今,已经有大量的Android自己主动化測试架构或工具可供我们使用,当中包含:Activity Instrumentation, MonkeyRunner, Robotium, 以及Robolectric。另外LessPainful也提供服务来进行真实设备上的自己主动化測试。 Android自身提供了对instrumentation測试的基本支持,当中之中的一个就是位于android.test包内的ActivityInstrumentationTestCase2类,它扩展了JUnit的TestCase类来提供Android activities的功能測试。在应用測试中,每个activity首先会被Instrumentation初始化,然后再载入到Android模拟器或设备的Dalvik虚拟机中来运行。 Android SDK自带一个測试工具MonkeyRunner,它提供的API和执行环境能够执行Python语言编写的測试代码。它提供API来连接设备,安装/卸载应用,执行应用,截屏,比对图片来推断特定命令执行后的屏幕是否包括预期信息,以及执行相应用的測试。MonkeyRunner使用ActivityInstrumentationTestCase2, ProviderTestCase,ServiceTestCasek, SingleLaunchActivityTestCase及其它类来定义測试用例,并使用InstrumentationTestRunner类来执行測试。 Robotium是还有一种通过InstrumentationTestRunner来完毕Android交互式測试的架构,它横跨多个activities,支持功能測试,系统測试和接收測试。Robotium支持Activities、Dialogs、Toasts、Menus、Context Menus甚至Honeycomb,而且它能够同Maven和Ant集成来完毕持续集成測试。Robotium被称之为针对Android应用的又一个Selenium。 Robolectric另辟蹊径,它并不依赖于Android提供的測试功能,它使用了shadow objects而且执行測试于普通的工作站/serverJVM,不像模拟器或设备须要dexing(Android dex编译器将类文件编译成Android设备上的Dalvik VM使用的格式),打包,部署和执行的过程,大大降低了測试执行的时间。Pivotal实验室声称使用Robolectric能够在28秒内执行1047个測试。 LessPainful将Android測试又推进了一步,它提供了一个多设备平台自己主动化測试的服务。用户上传应用(*.apk)和用Cucumber(一种业务相关的DSL)编写的測试文件,选择測试执行须要的设备配置,最后測试将自己主动执行并生成測试报告。它支持的设备包含Garmin Asus,几款HTC,LG,Samsung Galaxy,Sony Xperia和Motorola Motodefy。 为了了解很多其它LessPainful提供的服务细节,我们採訪了LessPainful公司的CEO Jonas Maturana Larsen。以下就是这次简短的訪问: InfoQ:在不同版本号的Android上执行应用程序,存在什么问题?为了保证程序能正常执行,开发人员须要在Android的每个版本号上測试他的应用吗? JML:举个样例,SAXParser在Android 2.2之前有一个bug存在于对ContentHandler.startElement的回调中,它导致应用产生错误的行为。 到眼下为止,我们已经在非常多方面发现了不同操作系统版本号间的差异性。当中一些可能在2.1-update1上导致崩溃,但能够正常执行于2.1-update3和2.2. InfoQ:不同的设备对Android来说,有没有真正的差别?你是否能给我们举个样例,比方Android2.2应用能够执行在HTC但不能执行于Samsung?(或其它各种Android版本号和设备制造商的组合) JML:在LG手机,HorizontalScrollViews有时会导致子视图上的背景图片消失。这个问题存在于我们測试的全部的LG手机,无论Android版本号是多少。 假设你不自己处理这类问题,它将导致你的应用在不同设备上不尽相同。比如,Motorola将会用红色边框来高亮一个输入域。在我以前參与的一个项目中,我们用相同的红色边框来表示输入有误。 另一些问题,与其说和制造商相关,不如说是和硬件相关:比方,一些手机使用了较小的RAM和高分辨率的摄像头,当你处理手机上的图像时就会将导致崩溃。 InfoQ:这些測试是怎样运行的? JML:測试就如同执行一个ActivityInstrument
领取专属 10元无门槛券
手把手带您无忧上云