随着微服务架构的兴起,服务之间的依赖关系变的越来越复杂,软件测试也面临新的挑战:系统升级频繁、服务依赖众多等等。
近几年,vivo互联网领域处于高速发展状态,同时由于vivo手机出货量一直在国内名列前茅,经过多年积累,用户规模非常庞大。因此,vivo手机出厂内置很多应用,如浏览器、短视频、直播、资讯、应用商店等都是直面用户的高并发、复杂系统。这些面向用户的系统对使用体验要求非常高,对这些业务的质量保障是重中之重。
前几天在技术交流群,大家又讨论起了流量录制回放的话题。我观察了一下,讨论的人不少,大体有这两种观点:第一种观点认为,流量录制回放的应用前景很广阔,能大幅度提高测试效率和技术逼格,都想在自己团队落地,但需要一些最佳实践参考;第二种观点则认为只有大厂才能做这个实践,小公司就别想了。
GoReplay是一款开源的用来进行http流量录制与回放的工具,因此可以通过它来进行线上真实流量录制然后将录制的流量回放到测试环境用来确认新开发的功能是否有问题,这样可以极大的提高新功能发布的信心,不得不说是一款神器。
Moonbox:月光宝盒 Moonbox(月光宝盒)是[JVM-Sandbox]生态下的,基于[jvm-sandbox-repeater]重新开发的一款流量回放平台产品。在jvm-sandbox-repeater基础上提供了更加丰富功能,同时便于线上部署和使用 使用场景 你是否遇到过以下的问题? 线上有个用户请求一直不成功,我想在测试环境Debug一下,能帮我复现一下吗? 压测流量不知道怎么构造,数据结构太复杂,压测模型也难以评估,有什么好的办法吗? 不想写接口测试脚本了,我想做一个流量录制系统,把线上用户
作者 | 汪成坤 策划 | 褚杏娟 在泛敏捷思潮变革、DevOps 大行其道的背景下,小步快跑的模式极大程度压缩了质量保障活动的时间,传统的自动化测试工具已无法满足持续交付的需求。流量录制回放的概念近年来愈发火热,从业界大会到社区论坛,众多工程师进行了大量的思辩悟,肯定了 API 录制回放能有效地解决测试、研发工程师在质量活动中的核心痛点从而带来可观测的研发效能提升。 流量录制回放的核心价值是通过直接录制生产的高保真数据,快速地在测试环境中进行回放比对接口返回值和中间链路的验证。录制回放很热,行业
关于流量录制回放目前是一个比较火的方向,也看过一些测试开发团队在关于流量录制回放的一些文章介绍以及案例,多数还是在现有开源工具的基础上做的一些贴合各自团队业务方向的二次开发,如:go replay、jvm sandbox repeater....
回归测试是软件生命周期一个十分重要的环节,但项目在随着版本的逐步迭代,功能日益增多,系统愈加复杂,在测试过程中测试人员常常需要回归稳定版本的功能以保证不被待发布版本需求所影响。若要对系统进行全方位回归,这个测试的工作量将会非常庞大,而且可能几百上千用例中才会发现一个甚至是0个问题,测试投入产出不成比例。
什么是流量录制回放?流量录制回放是应用端通过挂载注入录制器探针自动注册到服务端形成录制流量回流,将所有外部调用依赖的响应内容(如数据库、分布式缓存、外部服务响应等)进行完整记录。由平台向回放器分发流量回放指令。其核心价值是通过直接录制生产的真实数据,将生产真实数据转化成可复用、可执行的流量,快速地在测试环境中进行回放比对接口返回值和中间链路的验证。
测试用例不足或者遗漏难以覆盖所有场景,导致回归测试费时费力,线上稳定存在隐患,通过真实流量录制在回归测试时进行覆盖。
压测是目前科技企业及传统企业进行系统容量评估、容量规划的最佳实践方式,本文将基于京东ForceBot平台在大促(京东618、京东双11)备战中的实践历程,给大家分享平台在压测方面的技术变革。ForceBot平台是一款分布式性能测试平台,能够为全链路压测构造千万量级的压测流量,并结合全域流量录制回放、瞬时发压、智能寻点等能力,为整站容量评估与规划提供一站式的解决方案。
对比完了,对于一些类似时间戳的值,其实就是噪音,这些不一样很正常,我们需要剔除,不然差异没有价值。
Tech 导读 本文介绍了一种基于线上流量实现对重构系统进行功能和性能验证的实践方案。针对线上流量如何拦截、如何录制、如何存储、如何回放以及如何发压均作了详细说明,为具有类似需求的读者提供了一种可供参考的思路。 01 业务背景 在今年的敏捷团队建设中,我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢?由此我的Runner探索之旅开始了! 随着百川项目的启动,中台需要对订单流量收口,将ECLP、各BP的接单入口全部切换至百川统一接单系统。且各个接
现在全链路越来越火,各大厂商也纷纷推出了自己的全链路压测测试方案。特别是针对全链路压测流量模型,各家方案都有所不同。最近我看了一些这方面的资料,有一些感悟。分享给大家。
滴滴这家公司,不管它每年所说的亏了多少?赔了多少?也不管它到底有没有方便我们出行?我们只讨论它开源的几个强悍的产品对我们开发的帮助和影响。
本篇背景是另外一同事朋友,最近在利用流量回放技术应用在服务端接口自动化测试方面,还在各部门全力推进阶段,未来效果暂且不好说,但这部分内容确实各大公司,测试技术大会等等的热词,由于我没参与但我很感兴趣,所以邀请普及一篇,后边应该还会带来实战篇,本公众号坚持原创和干货分享,欢迎长期关注,一同成长,如果你有好的实战分享也欢迎投稿。
腾讯云高级工程师,腾讯云压测 OTeam 发起人,目前主要负责腾讯云可观测系统的开发与设计。
数据平台利用大数据智能分析、数据可视化等技术,对公司内外部经过采集、建设、管理、分析的多源异构数据进行呈现和应用,实现了数据共享、日常报表自动生成、快速和智能分析,深度挖掘数据价值,满足企业各级部门之间的数据分析应用需求。因而也具有数据量大,场景多,数据准确性要求高,查询性能要有保障等特点。
本文主要介绍了流量录制与回放技术在压测场景下的应用。通过阅读本篇文章,你将了解到开源的录制工具如何与内部系统集成、如何进行二次开发以支持 Dubbo 流量录制、怎样通过 Java 类加载机制解决 jar 包版本冲突问题、以及流量录制在自动化测试场景下的应用与价值等。文章共约 1.4 万字,配图17张。本篇文章是对我个人过去一年所负责的工作的总结,里面涉及到了很多技术点,个人从中学到了很多东西,也希望这篇文章能让大家有所收获。当然个人能力有限,文中不妥之处也欢迎大家指教。具体章节安排如下:
上半年公司的网关系统进行了重构,需要把零售业务已有的网关接口迁移到新网关上。这些接口每天都有成千上万次请求,为商家提供各种服务,稍有不慎就容易出现较大故障,所以如何迁移是个比较慎重的问题。
录制:将某个方法的执行过程录制下来,形成MockRecord并序列化成JSON文件
haibing,携程研发能效经理和SRE,关注自动化测试,能效提升方向的工具技术。
上次跟大家分享了 Service Mesh 双十一后的探索和思考(上)。在过去的一年多时间里,蚂蚁在 Service Mesh 上建设了大量能力,而这些基础设施能力的快速演进正是得益于 Service Mesh 将业务和基础设施的解耦。
已录制的流量进行回放,如果回成功率较低,比如20000个请求错误率5%,也有1000个错误, 对开发测试排查成本过高,疲惫抱怨也会增加。本文降低排查成本提升开发测试效率,侧重在智能降噪这块涉及的知识点进行整理,主要内容有:
测试是产品发布上线的一个重要环节, 但随着业务的不断壮大和快速迭代, 每次上线需要回归的功能会越来越多, 周期越来越长, 测试同学的压力会越来越大, 老板越来越不满意, 恶性循环就此开始...
作者简介 康猛,携程网站运营中心资深技术支持工程师。在互联网系统架构设计、后端开发、性能测试领域有多年实战经验。喜欢钻研新技术,善于转化研究成果,提升工作效率。 一、背景 众所周知,在产品迭代过程中,功能测试与性能测试是必不可少的两个环节。在产品上线的过程中,做容量预估离不开性能测试,在产品迭代过程中,测试Case覆盖率是功能测试必须要关注重要指标,甚至是一行代码的修改,没有经历过严格的功能与性能测试,都有可能导致大的生产故障。 近年来,携程生产环境应用改造项目逐渐增多,快速构造贴近生产的测试用例,压力可调
jvm-sandbox-repeater 是阿里开源的一款可基于 jvm-sandbox (阿里另一开源项目)可对应用目标 jvm 进行动态增强同时对目标服务的指定流量进行录制及回放的工具,使用过程中遇到如下问题:
接口自动化测试是个老生常谈的话题,基本上每个测试团队都会涉及,市面上大部分文章会从如何设计框架去讲解。但是这一次我想回归自动化的根本价值,从持续演进的解决方案出发,讲解有赞测试团队的心路历程和对于接口自动化的理解,欢迎交流。
SoloPi是阿里在移动端上一个无线化、非侵入式、免 Root 的 Android 自动化工具,公测版拥有录制回放、性能测试、一机多控三项主要功能,能为测试开发人员节省宝贵时间。
AutoMeter 是一款针对分布式服务,微服务 API 做功能和性能一体化的自动化测试平台,一站式提供发布单元,API,环境,用例,前置条件,场景,计划,报告等管理
关于景区直播,我们有很多不同平台的解决方案,由于很多景区要求统计人流量,自身也配备了人流统计摄像头,同时还会对票务系统进行审计,保证摄像机人流量的统计和票务系统一致性,此外,还需要将原始的满足条件的视频数据和现有的直播进行整合对外输出提供。
日常大部分的测试工作都是在测试环境下,通过模拟用户的行为来对系统进行验证,包括功能以及性能。在这个过程中,你可能会遇到以下问题:
随着流量增长,服务的节点越来越多,对服务性能要求也越来越大,在服务启动时经常会发现存在抖动,针对这些服务抖动,就需要采取一些预热措施,下面就简单介绍下系统相关的服务预热、中间件预热、数据库预热等
酷家乐自某次故障后开始升级演练平台,旨在提高系统在面对真实故障时的应急响应效率。面对业务线真实场景演练中高达39%的人工验证比例这一瓶颈,酷家乐构建了自动化流水线,设计了针对性的自动化用例,并选择了合适的自动化框架,确立了清晰的自动化流程。这些措施显著提升了自动验证效率,2023年第三季度演练次数超过100次,展现了自动化演练平台在提升系统稳定性和可靠性方面的显著成效。详细的解决策略和方法,请参阅文章正文。
在性能测试中,有一个无法避免的问题,就是如何处理性能测试用例使用到的数据,其中包括前置数据、运行时数据和后置脏数据清理。
只有当我们正确认认识到自动化测试能给我们带来的预期收益和目标后,结合团队的具体情况,避免对自动化测试有过高的预期,避开一些常见的误区,逐步的引入自动化测试,给予一定的时间,慢慢沉淀和发展,才有可能真正实现自动化测试的价值。
小程序直播解决方案发布以来,受到越来越多的客户关注。同时,因小程序的类目、准入政策、插件集成等原因,在产品使用选择上有点小困惑~ 小编结合大家最关心的问题,来详细讲解一下吧~ 科谱名词 微信小程序申请必懂名词 做小程序直播,首先需要注册一个小程序,那么科普两个名词解释: 1、【小程序主体】:即创建微信小程序时选择的小程序账号类型。(注:个人主体的小程序不支持微信小程序直播。) 2、【类目】:微信小程序的服务类目,可以理解为实际微信小程序提供的服务场景。 * 类目可在微信小程序后台的【设置】-【基本设置
游戏直播等场景中,大多数会用到聊天框、弹幕消息、爱心点赞,主播端会有美颜增白、动效蒙皮、连麦互动等功能。如果没有这些功能,想象一下关闭美颜功能的主播,会是什么样子。
对于流量回放这个词,很多同学并不陌生,但绝大多数公司因种种原因并没有进行实践,最现实的原因是由于做全链路的流量回放有大量的写操作,必然要涉及到系统改造,数据加工脱敏等,技术难度和风险相对较高,并非每一家公司都如阿里巴巴一样具备大流量的应用场景,在系统改造不彻底的情况下,存在投入产出失衡的现象,这不仅是技术的问题,也需要文化的支持,从个人角度而言我们依然可以进行一些模拟,这次我总结了以goreplay工具的轻量级流量回放使用方法。
在之前的文章《真香系列之1-Hoverfly服务虚拟化,你不2的选择》中简单介绍了Hoverfly。本文将介绍如何在JUnit5中使用Hoverfly,并讨论入参匹配、延迟、特性增强等话题。
在业内如火如荼的 DevOps 转型过程中,自动化测试始终是热点之一,毕竟提供快速质量反馈是达成 DevOps 目标的关键。于是,作为测试领域的“皇冠”,自动化测试的落地实施始终为人们所关注。但是落地当中产生了种种问题甚至是争论,经久不衰,无形中给自动化测试体系建设蒙上了层层迷雾,让人疑惑。下面我们就一些踩过的“坑”进行探讨,期望这些经验分享能够有助于揭开迷雾、看清方向。
在产品需求迭代过程中,功能测试与回归测试是必不可少的两个环节。对于改动较大的项目,首先,确保功能的实现符合产品逻辑并做到100%没有问题离不开有效的功能测试;其次,项目中很多逻辑的改动都是在原有功能的基础上进行的,这时候就需要一定的回归测试。通常,在功能测试时,人工case不能模拟线上用户的所有行为,且具有一定的主观性;回归测试时,采用全面回归的方式往往也伴随着测试成本的增加。一个好的方式就是利用线上流量来验证。
疫情期间,线下经济受到了严重的打击,线上经济爆火的同时也将直播行业推到了风口之上。一方面,直播为各类平台带来流量,推动业务增长;另一方面,直播的即时性、互动性特质又为日常生活增添色彩。现今,如何建立一个全链路的平台为直播高效赋能,值得我们进行一番审视。 最近,腾讯云推出了一款新产品——云创多媒体引擎!为企业提供在线视频创作工具,主要包含智能媒资库、在线视频编辑、直播剪辑、云转推和云导播台等核心功能,并提供可被集成的 PaaS 交付模式和一键换肤的 SaaS 模式,满足现今直播领域的多样化需求。下面
作者:faithchen,腾讯 PCG 测试开发工程师 一、背景 自动化测试对于我们提升研发效能、CI/CD(持续集成/持续交付)是不可或缺的部分。在后台自动化测试中,接口测试尤为重要,它能够保证被测后台服务的质量,以及接口逻辑的正确性等,帮助我们快速测试功能、提高测试覆盖率、把控质量风险等。 1.1 后台接口测试 接口测试是功能测试的一种,是测试系统组件间接口的一种测试,重点在于检验对于服务接口的数据交换的正确性,一般全部依赖真实链路,测试时需要启动被测服务。如下图是某个Server A的接口测试
今日头条丨一点资讯丨腾讯丨搜狐丨网易丨凤凰丨阿里UC大鱼丨新浪微博丨新浪看点丨百度百家丨博客中国丨趣头条丨腾讯云·云+社区
录制回放模式可以比智能化Monkey模式更进一步地指定测试场景。开发者可以通过开发者工具操作提前录制好,然后通过执行录制脚本来实现测试过程的回放。
简单来说就是后端服务通过API的形式对外暴露,作为前端访问后端的中间层。API Everything会将SOA服务接口适配给外部各端进行访问。
winrunner经验总结 1.1 脚本录制规范: 基本原则是录制脚本要分开、gui文件要合并、批调用回放验证、可移植回放验证。 1.1.1 录制脚本要分开: 脚本太大,不仅不利于以后的维护,并且会导致WinRunner的不可预测的错误产生(具体可以参考WinRunner 的Readme文档)。录制时,可以根据测试用例的流程,拆分为几个小流程,对每个小流程分别录制成不同的脚本。 1.1.2 gui文件要合并: 首先,要在系统参数中,设置gui的录制模式为“Global GUI Map File 录制过程中,WinRunner会自动产生gui文件,一个测试用例要确保生成一个公用gui文件。用一个gui文件主要是为了以后gui对象的维护,脚本回放时gui对象的查找。但是由于我们的测试用例是分开录制的,每个小流程录制时都会产生一个gui临时文件,因此录制完脚本后要把临时gui文件合并到该测试用例的公用gui文件中。但是也要注意,开始新的录制前,一定要先手工加载测试用例的公用gui文件。 如果划分的子流程超过20个,则按每20个子流程录制一个gui文件的方式。Gui文件太大,会影响WinRunner的回放效率。 1.1.3 批调用回放验证: 为了提高脚本的正确性,每录制完成一个子流程后,都要恢复数据库,其他初始环境进行回放,以近早发现脚本错误。 单个测试用例脚本录制完成后,要专门写一个主脚本,进行各子脚本的主次调用处理,然后恢复数据库和其他初始环境进行回放,以验证整个脚本是否可以正确回放。 1.1.4 可移植回放验证: 由于WinRunner 工具的限制,在本机回放成功后,如果把脚本移植到其他机器上,往往无法成功。这其中既有自己编写的脚本问题,又有WinRunner录制自动生成的脚本问题。 自己编写脚本问题:往往是编写的可移植性较差,如加载gui文件时用的是绝对地址,如gui_load(“c://aa//aa.gui”),这样的脚本换到其他机器必然出错。 WinRunner录制自动生成的脚本问题: WinRunner的录制脚本往往和机器的环境有关,如果换了其他机器环境,往往回放不成功,这就需要手工修改脚本。 因此,可移植性回放是非常必要的。 1.1.5 脚本中使用的ODBC数据源名称统一命名为WR。 1.1.6 录入中文数据时统一使用简体。 1.1.7 数据表列名称规定 录入数据驱动的脚本时,数据表列名称统一采用英文,使用PB数据窗口中列对象的名称。数据表列名称下的第一行用中文对英文列名称做注释,使用PB数据窗口中列对象的中文标签,这一行不作为有效的录入数据。与数据表相关的循环语句请修改脚本从数据表的第二行开始读取数据。典型的例子是将数据驱动脚本中For循环的第一个表达式改为table_Row = 2。 1.1.8 脚本成功回放判定规定 一个子测试录制完成后,一定要及时回放测试,直到测试报告显示测试结果为OK,且子测试明细报告中没有红色的出错提示。如果是回放主测试,回放成功的标准是:主测试的结果报告显示为OK,同时所有子测试的结果报告也为OK,且子测试明细报告中没有红色的出错提示。 1.1.9 WinRuner主脚本中关于设置系统日期时间设置的规定,以保证脚本所描述的业务过程按业务逻辑在时间上有序。 因为脚本回放与脚本录制时的系统日期时间不一致,会导致与系统时间关系密切的测试脚本回放时失败。 为了消除时间差导致的回放错误,要求每一个测试用例的主测试在第一个子测试前加上date_set_system_date(年,月,日,时,分,秒)函数,以修改本地机器的日期时间等于这个主测试在接力式验收回放成功执行后的日期时间.这样再次回放时系统的日期时间就和上一次成功回放时的日期时间一致。
领取专属 10元无门槛券
手把手带您无忧上云