电商性能测试知识分享
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
性能测试负载图解
轻负载区域:a,b,c,d 重负载区域:e,f,g,h 最优(最大)处理能力:d
性能测试方法
基准测试:
● 验证交易是否满足性能测试需求 ● 验证交易的响应时间,建立基线
● 通过不断增加压力,直到性能指标超过预定或达到饱和 ● 主要目的是找到系统在既定指标内处理能力的极限 ● 测试系统在一定饱和状态下,系统能够处理的会话能力, 以及系统是否会出现错误。
浏览器
网络
服务器
数据存储Байду номын сангаас
在如今讲求效率的当下,人们对于网站的响应速度和可靠性更为敏感。 SmartBear数据表明,页面加载时间增加1 秒,降低7%的用户访问量,如果 Amazon 的加载时间延长1秒,那么一年就会减少16亿美元的营收。用户与网 站互动的过程中,如果加载时间超过3秒,57%的用户会面临流失的可能。
性能测试指标
PV UV TPS RT
即Page View,即页面浏览量或点击量,用户每次刷新即被计算 一次。我们可以认为,用户的一次刷新,给服务器造成了一次请 求。 即Unique Visitor,访问您网站的一台电脑客户端为一个访客。 00:00-24:00内相同的客户端只被计算一次。
TPS(Transaction Per Second)每秒钟的交易或事务的数量,它是 衡量系统处理能力的重要指标。
Spike testing:短时间的极端负载测试 ; Extreme testing:在过量用户下的负载测试 ; Hammer testing:连续执行所有能做的操作 ;
容量测试( Volume Testing ) :确定系统可处理同时在线的最大用户数 关注点:how much(data),容 量测试通常和数据库有关,检查当系统运行在大量数据,甚至最大或更多的数据环境下,系统是否会出问题。 其中,容量测试、负载测试、压力测试的英文解释为:
Volume Testing = Large amounts of data . Load Testing = Large amount of users . Stress Testing = Too many users, too much data, too little time and too little room .
为什么使用并发? 通过模拟用户的并发访问,测试多用户并发访问同一个 应用、同一个模块或者数据记录时是否存在死锁或者其 他性能问题。 并发的分类: 在线用户(Online Users):指用户通过身份确认后, 处于能正常使用状态的用户个数。 并发用户(Concurrent users):指在某个时间范围内, 同时正在使用系统的用户个数。 严格并发用户(Strictly the number of concurrent users):指同一时刻都操作某个业务的用户数。
各种业务操作,对系统产生 压力;为了模拟此操作,性能测试工具提出虚拟用户的概 念,让虚拟用户通过执行测试脚本模拟真实用户与服务器 之间的交互动作,也叫并发 用户。
脚本:模拟用户操作的过程,叫做脚本。 事务:衡量业务操作时间。 场景:通过组织若干类型、若干数量的虚拟用户来模拟真 实生产环境中的压力情况。
响应时间是指从客户端发出一个请求开始计时,到客户端接受到 从服务器端返回的相应结果结束所经历的时间,响应时间由请求 发送时间、网络传输时间和服务器处理时间三部分组成。
TPS: Transaction Per Second,每秒处理的交易笔数,是 衡量系统性能非常重要的一
个指标。
最大(最优)处理能力:系统在各服务器资源处于安全警戒线值内TPS不再有明显的增长趋势或达到某些业务 指标限制(平均响应时间、成功率等)时,系统每秒能处理的最大的交易笔数。
并发的概念
性能测试需求分析
1. 性能需求获取 2. 功能规格说明书 3. 系统设计文档 4. 运营计划 5. 用户行为分析记录
模型的概念
业务模型:生产系统在某个特定时间段内运行的业务
种类及其业务占比。
测试模型:测试模型是在业务模型的基础上分析得到,
为后续测试场景做依据。一般情况下,测试模型和业
性能基础指标
1. 每秒事务数(TPS):是指系统每秒钟能处理完成的事务量,用来衡量在一定 的软硬件条件下,被测系统处于不同压力时的事务处理能力; 2. 平均事务处理时间(ART):是指从客户端发起事务请求到接收到来自服务器的 应答所经历的平均时间; 3. 事务成功率:指系统事务处理时成功事务数与总的完成事务数的比值,该值从 正面反映了被测试系统的可用性、可靠性和稳定性。 4. 最大虚拟用户数(MVU):在系统各项硬件指标满负荷运行,系统所能承受 的最大用户数; 5. 最优虚拟用户数:被测系统CPU 利用率不超过60%,事务成功率大于 99.9% 时,TPS 达到最高时的用户数量; 6. 思考时间(ThinkTime):用于模拟实际用户在不同操作之间等待的时间。例 如,当用户收到来自服务器的数据时,可能要等待几秒钟查看数据,然后做出响应, 这种延时就称为“思考时间”; 7. 资源占用率(服务器性能指标):是指在不影响系统正常运行的情况下各服务 器的CPU、内存、磁盘IO 等硬件资源的占用情况。
验证稳定性、可靠性:
在一个生产负荷下执行测试一定的时间是评估 系统稳定性和可靠性是否满足要求的唯一方法。
性能测试基本流程
性能测试流程表
Items 内容 负责方
制定方案
与项目组讨论需求和性能测试模块分配和优先级以及测试过程中项目相关的准 开发组&测试组 备事宜与风险 编写测试方案、项目组成员评审方案 开发组&测试组
2
3 4
搜索
加入购物 车 „„
20%
20% „„
4
„„
„„
性能测试方法
性能测试(Performance Testing ):通常收集所有和测试有关的所有性能,被不同人在不同场合下进行使 用。 关注点:how much和how fast
负载测试(Load Testing):负载测试是一种性能测试,通过在被测系统上不断增加并发压力,直到性能指 标,例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。主要目的是找到系统处理能力的 极限。关注点:how much (users) 压力测试(Stress Testing ):测试系统在极限或一定的饱和状态下,例如CPU、内存等在饱和使用情况下, 系统能够处理的会话能力,以及系统是否会出现错误。包括:
负载测试:
压力测试:
业务突变测试:
● 通过模拟业务突变,验证系统在突变下业务处理能力
性能测试方法
多业务场景测试 ● 根据线上可能出现的各种业务场景,进行多场景测试
稳定性测试
● 验证系统在一定的业务量下能否长时间平稳运行
可靠性测试
● 验证系统在切换或发生故障时,是否能可靠运行
配置测试
● 通过对被测系统的软/硬件环境的调整,了解各种不同业 务场景对系统性能影响的程度,从而找到系统各项资源的最 优分配原则。
性能测试的环境条件
直接在生产环境测试; 架构与生产环境相同; 软件版本与生产环境相同; 应用版本根据测试目的可与生产环境相同或者不同;
配置尽量与生产环境相同;
基础数据尽量与生产环境相同; 进程实例尽量与生产环境相同;
性能测试中的术语
虚拟用户:Vu简称,在现实的生产环境系统中,终端用户 (真实的人)将会对系统进行
被测网站的准备工作(保证网站的功能流程全部可用,影响测试的限制策略全 开发组 部失效,网站数据、测试数据准备等) 工作准备 压力测试机的环境准备(单独在生产中搭建独立VM,安装测试工具且正常使用、 测试组 以及相应的测试辅助工具安装等)
脚本开发
性能测试脚本编写、代码参数化、脚本调试(例如单个下单场景脚本编写需1天 测试组 的时间;根据场景的数量和复杂度不同,需要的时间也相应增加)
并发的概念
并发测试的作用 通过模拟用户的并发访问,测试多用户并发访问同一个应用、同一个模块或者 数据记录时是否存在死锁或者其他性能问题。 并发的分类:
在线用户(Online Users)
指在某个时间范围内,同时正在使用系统的用 户个数。
并发用户(Concurrent users)
指同一时刻都在操作某个业务的用户数 即某一时刻同时向服务器发送请求的用户数
本次分享目录:
1. 性能测试的重要性 2. 性能测试的目的 3. 性能测试的基本流程和准备事项 4. 性能测试中的术语 5. 性能测试方法 6. 宝尊性能测试方法 7. 性能测试指标
性能的重要性
据统计,大多数用户期望的网站加载时间是3秒,超过3秒,网站就开始流失 用户,在极限情况下网站的加载时间不能超过6秒。 页面加载时间组成:
作者:张崇麟
前言
随着电商的日益壮大,为了能够给用户带来更加流畅的购物体验和 更加可靠的网站架构系统一再精益求精,对于web性能也不断提出更高的要求。 当网站出现瘫痪或者缓慢的问题、业务流程和交易无法进行会导致巨 大的收入亏损,糟糕的用户体验会导致用户的流失,影响品牌和领导力。发 生一些临时突发事件或者大规模的促销活动时,如果网站缺少必要的测试准 备,可能会瘫痪,从而发生灾难性的业务影响。 所以有必要对网站的性能做一个完整充分的性能测试,用数据来辅助 判断网站是否能够达到预期的需求、找出潜在的性能问题,从而避免网站的 崩溃、连接错误等各种问题的出现。
使用调试完成的脚本对网站进行冒烟测试
测试组
执行性能测试、跟踪、资源实时监控(例如单个下单场景执行需1天时间;根据 测试组 场景组合复杂度的不同,需要的时间也相应增加) 执行测试、分析调优 收集测试数据,并针对测试数据进行分析总结 根据测试结果与项目组成员进行沟通调优事宜,等待开发进行代码性能调优 结果汇总 测试报告修改、定稿。 测试组 开发组 测试组
列举准备事项:
项目组准备及确认事项: 1. 商讨定制需要测试的环境、模块和模块优先级,提供网站的UV、PV等信息。 2. 保证压测环境中的流程功能正常使用。 3. 登录和下单过程中的验证码须失效或经过处理。 4. 网站中是否存在加密算法传输的字符串,且每次加密出的字符串都不同,如:登录密码等, 需要临时解除解密,否则无法使用登录模块测试。 5. 网站中的限购策略、白名单、IP限制须要临时解除。 6. 准备至少1000个登录用户数据,用户名有规律且密码相同。 7. 给到测试商品的URL,将对应商品的库存增加至1000W。 8. 测试之前可能需要关闭与后端系统的队列交互以及短信或邮件的发送功能。 9. 测试过程中会产生大量测试数据,之后可能需要进行必要的清理,请知晓。 10. 压测过程中暂时禁止相关人员对站点的访问和发布。 11. 生产环境是否与其他商城或其他环境共用一套环境,从而可能产生相互影响? 12. 告知站点的Server的架构信息、带宽信息(包含服务器的分布信息和CPU内存信息等)。 13. 运维在站点中需要搭建server资源监控平台(zabbix或grafana等)。 14. 去除server上对于单个IP频繁访问网站的限制,把压测机IP加入访问限制白名单。 15. 准备性能测试用的施压设备。
务模型是相同的,但是由于某些业务的安全性、业务
不能被脚本模拟等情况,测试模型会将这些业务去掉, 重新计算业务占比。
业务重 要性
业务频 率
业务模型
业务规 律性
业务模型1(正常高峰)
编号 1 交易名称 首页 业务模型 交易占比 30%
未来发 展趋势 编号 1 2 3
业务模型2(秒杀抢购)
交易名称 普通商品 PDP 秒杀商品 PDP 结算 业务模型 交易占比 10% 30% 35%
性能测试的目的
评估系统的能力:
测试中得到的负荷和响应时间数据可被用于验 证所计划的模型的能力,并帮助作出决策。
识别体系中的弱点:
受控的负荷被增加到一个极端水平,并突破它, 从而修复体系的瓶颈或薄弱的地方。
系统调优:
重复运行测试,检测系统中的问题,验证调整 系统,揭示程序中的隐含问题,从而改进性能。