性能测试场景(性能测试场景策略设计)

来源网友投稿 858 2022-12-22

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。
本篇文章给大家谈谈性能测试场景,以及性能测试场景策略设计对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 今天给各位分享性能测试场景的知识,其中也会对性能测试场景策略设计进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

本文目录一览:

性能测试包括哪些方面

性能测试包括负载测试和压力测试。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别的测试。
性能测试在软件的质量保证中起着重要的作用,它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面:应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下,三方面有效、合理的结合,可以达到对系统性能全面的分析和瓶颈的预测。

阿里云服务器ECS如何选择?性能测试PTS助你测试和选择阿里云服务器

阿里云服务器ECS如何选择?很多新手用户并不知道PTS是什么,如果你不知道如何选择阿里云服务器ECS产品,性能测试PTS可以很好的帮助你快速对云服务器进行压力测试,从而助你选择适合自己的阿里云服务器ECS,下面是性能测试PTS详解!

阿里云开发者社区最近推出了一个“ ECS 选款利器!PTS助您快速上云 ”活动,PTS性能压测包仅需0.99/月起,真实模拟,免去繁琐的搭建和维护成本!现在您可以只支付10块钱不到的试用成本,即可体验使用 PTS 来帮助 ECS 进行容量规划选择合适规格的整个流程!
完成动手实验的同学,即可参与抽奖活动,小米手环 6、蓝牙键盘、掌上游戏机、笔记本支架、 数据线、优惠券等丰富奖品等您来拿!限量 1500 份,抽奖即得,百分百中奖哦!

性能测试PTS(Performance Testing Service)是具备强大的分布式压测能力的SaaS压测平台,可模拟海量用户的真实业务场景,全方位验证业务站点的性能、容量和稳定性。

PTS旨在简化性能压测本身的工作。
PTS目标是将性能压测本身的工作持续简化,使您可以将更多的精力回归到关注业务和性能问题本身。在PTS平台上,您可以用较低的人力和资源成本,构造出最接近真实业务场景的复杂交互式流量,快速衡量系统的业务性能状况,为性能问题定位、容量配比、全链路压测的流量构造提供最好的帮助。进而提升用户体验,促进业务发展,最大程度实现企业的商业价值。

业务场景
PTS广泛应用于各种压力测试和性能测试场景,包括但不限于以下场景:

PTS孵化于服务阿里巴巴全生态五年以上的单链路、全链路压测平台,是阿里巴巴内部最佳实践的输出。该平台对内除了支持日常的外部流量压测之外,同时支持了大大小小的促销活动,如天猫双11、双12和年货节等。

压测流程
PTS提供全面高效的压测流程:

压测流程说明:
1.在PTS控制台上,准备压测API数据,构造压测场景,定义压测模式、量级等;支持随时启停压测,压测过程中可调速。
2.压测启动后,PTS后台的压测控制中心将自动调度压测数据、压测任务和压测引擎。
3.通过随机调度全国上百个城市和运营商的内容分发网络CDN (Content Delivery Network)节点,发起压测流量。保证从虚拟用户并发量、压测流量的分散度等维度都接近真正的用户行为,压测结果更加全面和真实可信。
4.通过压测引擎向您指定的业务站点发起压测。
5.压测过程中,通过集成云监控、ARMS(应用实时监控服务)产品,结合PTS自有的监控指标,实时采集压测数据。
6.在PTS控制台,实时展现压测数据,进行过程监控;压测结束后,生成压测报告。基于整个压测场景的性能表现,定位性能问题、发现系统瓶颈。

压测创建方式
PTS支持以下4种方式创建压测场景(或称压测用例),如下图所示:

说明:
方式一:PTS自研零编码可视化编排,使用自研强大引擎压测。
方式二: 使用PTS自研云端录制器,零侵入录制业务请求并导入1中的自研交互中进行进一步设置。
方式三: 将导入脚本压测 1中的PTS自研交互中,使用PTS自研引擎。
方式四:JMeter压测并使用原生JMeter引擎进行压测,PTS提供自定义的压力构造和监控数据汇聚等产品服务。
其中,方式一、二、三由于使用了PTS的自研引擎,具备RPS(Requests per Second)吞吐量压测模式、秒级启动、实时控制、定时压测和流量遍布全国运营商网络的差异化能力。
方式一是PTS最核心的一种压测场景创建方式,所有资源包均可使用。其他几种创建方式面向不同规格资源包开放。

适用于多业务场景
不论您处于哪个行业,在以下业务场景(但不限于),PTS都是您值得信赖的性能测试工具。

适用行业广泛
PTS应用行业广泛,涉及电商、多媒体、金融保险、物流快递、广告营销、社交等等。
PTS服务阿里巴巴全生态多年,支持了天猫双11、双12、年货节等大促活动。植根于电商行业的PTS,对电商的典型业务模型支持得更友好,压测来源更广泛,脉冲能力和流量掌控能力更强。
PTS自商业版发布以来,吸引了来自多媒体、金融保险、政务等众多行业的用户,以其强大的压测场景编排能力和报表能力,帮助用户快速发现问题,进行针对性地调优,提升了系统承压能力。

适用于多种网络环境
不论您的业务位于公有云、专有云、混合云或者自建IDC中,只要能够通过公网访问,PTS都能够通过遍布全国上百个城市和各运营商的CDN节点发起压测流量,最大程度地模拟真实业务场景。

适用于使用HTTP/HTTPS/WebSocket等协议的客户端
PTS本身的GUI模式支持HTTP/HTTPS协议的压测,无论您的客户端是自研的App、移动端网页、PC端网页、微信小程序还是C/S结构的软件,都可以使用PTS进行压测。PTS同时集成了开源JMeter,支持更多的协议和场景,例如您可以通过“JMeter + WebSocket插件”的方式,对使用WebSocket协议的客户端进行压测(在PTS上传相应的插件JAR文件即可),其他协议以此类推。

下面以电商典型业务场景为例,为您介绍如何在PTS中编排压测场景。
什么是压测场景
要发起一次性能压测,首先需要创建一个压测场景。压测场景中包含一个或多个并行的业务,每个业务包含一个或多个串行的请求。

示例
淘宝网需要对产品A和B相关的页面(即存在多个API)进行压测,假设其主要业务场景为:
业务A:浏览产品A。
业务B:购买产品B(登录 → 浏览产品B → 加入购物车 → 提交订单)。
那么在压测场景中的设置如下。

串联链路1:浏览产品A 和串联链路2:购买产品B是并行关系。
根据业务逻辑,一部分用户在浏览产品A,另一部分用户在进行购买产品B的一系列操作,即两个业务是同时发生的,所以将它们设置为两个串联链路,压测中会并行发起请求。

串联链路中的多个API是串行关系。
根据业务逻辑,串联链路2:购买产品B中的一系列用户行为是存在先后顺序的,所以将这些存在先后关系的API添加到一个串联链路中,PTS压测中会按照顺序发起压测。

综合来看,在压测中,示例中的浏览产品A的API和登录的API,会同时发起压测流量。更多性能测试PTS场景示例,可参考阿里云帮助资料: 性能测试 PTS最佳实践

性能测试-概念篇(三)

通过分析业务逻辑和技术架构性能测试场景,创建性能模型,制定性能方案,准备应用环境,设计并实施性能部署监控,实现符合真实业务逻辑的压力,通过监控手段获取各组件的性能计数器,分析计数器采集出的数据,查找出性能瓶颈的根本原因并优化,最后通过环比生产环境的性能数据修正场景。

2.2.1、时间指标
2.2.2、容量指标
2.2.3、资源利用率指标

2.3.1、业务模型
2.3.2、监控模型

2.4.1、测试环境
2.4.2、测试数据
2.4.3、测试模型 - 基于业务模型构造测试数据
2.4.4、性能指标
2.4.5、压力测试-阶梯压力测试高并发压力测试
2.4.6、准入准出
2.4.7、进度风险

2.5.1、软硬件环境(包括压力机)
2.5.2、应用版本
2.5.3、基础设施
2.5.4、网络结构
2.5.5、基础数据
2.5.6、压力工具

2.6.1、系统监控
2.6.2、中间件监控
2.6.3、缓存监控
2.6.4、队列监控
2.6.5、负载均衡监控
2.6.6、熔断限流
2.6.7、链路监控

2.7.1、基准场景
2.7.2、容量场景
2.7.3、稳定性场景
2.7.4、异常场景

2.8.1、场景结果整理
2.8.2、监控结果整理
2.8.3、性能整体分析
2.8.4、性能结论
2.8.5、优化建议
2.8.6、运维建议

性能验证:验证系统是否达到指定的指标。 举例:RT是300ms,QPS/TPS是否可以达到800。
性能调优:验证是否达到系统的最大容量。 举例:限制或者不限制RT、内存水位、CPU水位,QPS/TPS可以达到多少。
容量验证:需要多少台机器。 举例:50 w UV,需要配置多少台机器。

1000万的用户,在场景A中,业务1占比10%,业务2占比20%,业务3占比30%;
1000万的用户,在场景B中,业务1占比20%,业务2占比30%,业务3占比40%;
1000万的用户,在场景C中,业务1占比30%,业务2占比40%,业务3占比50%。

包括接口响应时间+业务响应时间
参考:
互联网企业:500ms以下,例如淘宝业务10ms左右。
金融企业:1s以下为佳,部分复杂业务3s以下。
保险企业:3s以下为佳。
制造业:5s以下为佳。

包括接口容量+业务容量

如果是接口层性能测试,TPS中的T 可以直接定义为接口级;
如果业务级性能测试,TPS中的T 可以直接定义为每个业务步骤和完整的业务流;

举例:

start事务(接口1)
商品详情页接口A
end事务(接口1)
start事务(接口2)
商品详情页接口B
end事务(接口2)

start事务(业务A)
加入购物车(接口1)-下单(接口2)-支付(接口3)
end事务(业务A)

start事务(业务A)
点击-加入购物车(接口1)-下单(接口2)-支付(接口3)
end事务(业务A)

a、操作系统:CPU、Memory、Network、IO、System、Swap
b、JVM:GC、classes
...

对于长连接来说,最大并发用户数即系统的并发接入能力。实际上,就算是长连接,如果实际业务已经丢掉性能测试场景了异常的请求,那么最大并发用户数不等于系统的并发接入能力。
对于短连接来说,最大并发用户数并不等于系统的并发接入能力。

并发是在单位时间内完成的事务(T)的个数。

在线用户数和压力线程之间的关系:

从以上的计算逻辑中,我们可以看到,这其中有几个关键数据:

举例:
1) 在线用户数:1个用户,100个请求,响应时间是250s

用户数:1个
响应时间:250s
请求数:100
tps计算: 1*100/250=0.4(请求数/秒)

在线用户数(有停顿时间):100000个用户,100个请求,响应时间是3600s
用户数:100000个
响应时间:3600s
请求数:100
tps计算:100000100/3600=2777.8 tps

2) 并发用户数(无停顿时间):1个用户,100个请求,响应时间是6s

用户数:1个
响应时间:6s
请求数:100
tps计算:1*100/6=16.67 tps

3) 压力线程=(在线用户数×单用户请求数)/峰值采样时间段÷一个压力线程的请求级TPS
压力线程 = 2777.8(100000在线用户的请求级TPS)/16.67(1个压力线程的请求级TPS)=167

4) 并发用户数=在线用户数×有停顿时间的单线程TPS÷无停顿时间的单线程TPS
并发用户数 = 100000(在线用户数)*0.4(有停顿时间的单线程TPS)/16.67(无停顿时间的单线程TPS)=2399

5) 并发度=在线用户÷并发用户×100%(取值要在同一时间段)
并发度 = 100000/2399*100%=41.68%

参考:高楼老师的课程

关于性能测试场景和性能测试场景策略设计的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。 性能测试场景的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于性能测试场景策略设计、性能测试场景的信息别忘了在本站进行查找喔。
上一篇:中国联通成立边缘云创新实验室,自主研发Cube-Edge平台
下一篇:华为助PBTL CDMA快速成长 用户数增长超50%
相关文章

 发表评论

暂时没有评论,来抢沙发吧~