1.性能测试概述
1.1概念
性能测试是通过工具或代码模拟正常/峰值/异常的负载条件,对系统的各项性能指标进行测试和评估的过程
1.2目的
- 评估当前系统的能力,例如:新出的手机/电脑进行跑分测评
如果有不足之处,则寻找性能瓶颈,进行优化
- 评估软件是否满足未来的需要,例如:未来用户量增长,服务器是否能承受得住大量的请求
1.3分类
性能测试:验证系统性能是否能满足某些用户场景,是负载测试和压力测试的统称
- 负载测试:加压,查看系统运行情况,甚至找出系统能承受的最大负载
- 压力测试: 分为稳定性和破坏性
- 稳定性压力测试:高负载下长时间运行,找出系统稳定运行的时长
- 破坏性压力测试: 高负载下继续加压,直到导致系统崩溃,关注极限负载和系统恢复能力
为方便大家理解,这里讲一个农民和驴的故事:
- 有一个农夫决定买一匹骡子,他认为这个骡子至少得能扛动3袋大米(相当于性能需求),他来到农贸集市上,试了好几匹骡子,都不合适,最后终于有一匹骡子能够比较轻松的扛动这3袋大米,而且还潇洒的走了几步(相当于性能测试通过)
- 然后农夫高兴地牵着这匹骡子回家,因为想看看它到底能有多强,所以农夫决定,让它扛着4袋大米走回家(加压,相当于负载测试),这骡子虽然没那么潇酒了,但也能正常赶路(相当于负载测试结束,测试结果中骡子的最大负载是4袋大米)
- 因为集市离家比较远,骡子走了8个小时后,就开始两步一歇了(高负荷长时间运行,相当于稳定性压力测试)再走一会儿,终于到家,农夫心想:"这骡子路上光驮大米了,没有驮我,我也得坐上去”(相当于破坏性压力测试),结果骡子不堪重负,连同农夫和大米都摔倒了(相当于系统崩溃)
- 后来骡子……
2.性能需求
2.1 常见性能需求
以日常我们经常能用到的产品为例:
web首页打开速度在3s以内
邮箱系统需要支持100万在线用户,每秒至少需要能处理1000个发邮件的请求
某系统需要支持每天1000万人次的访问
系统需要在实际运行压力2倍的情况下,稳定运行24小时
2.2 需求来源
那么需求来源都来自于哪里呢?一般是客户方提出或者开发团队内部提出:
客户方提出:
一般金融、银行、电信、医疗等企业,对性能有明确需求
开发团队内部提出:
产品:一般基于核心业务提出需求
开发:一般会基于编码实现复杂度或资源占用较高的功能提出需求
测试
参照竞品
参照自己:根据历史运营数据进行分析,找出用户量、用户增长、用户频繁使用的功能
测试人员往往面对的是不太明确的需求,需要通过分析得到具体需求 一般需要进行性能测试的系统,用户量大,需要优先保证核心业务的性能,那么什么才算核心业务呢?
核心业务示例 :
商城: 登录 ->浏览商品 ->添加商品到购物车->下单 ->支付 ->查看订单直播软件: 登录 ->搜索直播间 ->进入直播间 ->观看直播 ->发送弾幕 ->赠送礼物
仓储管理系统:登录 ->查看入库信息/新增入库信息/编辑入库信息/删除入库信息 ->出库等
性能测试场景:
高并发
大量用户同时访问服务器,如:淘宝双十一,12306抢票,商城秒杀,主播开播瞬间涌入大量观众等
高频率
大量用户在同一个时间段高频访问服务器,如:商城黄金时间段下订单,外卖软件用餐时段点餐,上班打卡,直播弹幕等
2.3 用户量分析
有了核心业务还不够,如已知需要对 商城秒杀 或 wms更新入库信息 这两个功能做性能测试,具体需求是什么?可以看出如果没有用户数据,无法得出具体条件,而数据的来源可以是客户/产品/开发/运营等,下面将以具体需求进行案例分析:
分析过程示例:
商城秒杀:属于高并发场景,关键是需要计算出今年参与秒杀活动的人数
- 去年参加秒杀的人数
- 用户增长率
例如去年参加秒杀人数10w人,今年用户增长率为10%,则今年参加秒杀活动的人数为1.1w人
WMS更新入库信息:属于高频率场景,关键是计算出服务器每秒需要处理请求数
跟单员人数
跟单的时间段
如,公司有500名跟单员,每周一早上集中更新入库单信息(平均每人10单),高峰期是周一早上9:00~9:20
#此处计算需要借用一些算法 --二八原则
#二八原则:指80%的业务量需在20%的时间内完成
#计算过程:
业务量:500*10=5000
时间:20*60=1200秒
服务器应达到的处理能力=(5000*80%)/(1200*20%)=16.7个/秒 取整 17个/秒
实际上,请求的分布是一个正态分布,最高峰肯定高于平均值
二八原则的计算结果是系统需要达到的处理能力(吞吐量)
如果系统性能要求高,也可以使用一九原则或更严格算法,二八原则只是比较通用
最后,我将以一道性能测试的笔试题带领大家进一步深入用户量分析过程:
系统每年的业务集中在8个月完成,每个月平均有20个工作日,每个工作日8小时
去年全年处理业务约100万笔0
- 其中15%的业务处理中每笔业务需对应用服务器提交7次请求
- 其中70%的业务处理中每笔业务需对应用服务器提交5次请求
- 剩余15%的业务处理中每笔业务需对应用服务器提交3次请求
- 根据以往的统计结果,每年的业务增长量为15%
- 考虑到今后3年的业务发展需要,测试需按现有业务量的两倍进行计算。
计算过程:
每年总请求数:(100万*15%*7+100万*70%*5+100万*15%*3)*2=1000万
(10000000*80%)/(8*20*8*3600*20%)=8.68取整为9
总结:性能需求=(业务总请求数*80%)/(总时间*20%) ,注意结果一定要向上取整,例如计算结果为4.1,那么服务器需要每秒处理5个请求才能达到性能需求。
3.性能指标
3.1 指标内容
1.平均响应时间
2.吞吐量
- QPS:服务器每秒处理请求数
- TPS:服务器每秒处理的事务数
3.错误率
4.各种硬件指标
- CPU占用率
- 内存占用率
- 硬盘I/O(读写速度)
- 网络I/O(下载上传)
性能指标可能涉及到的面试题:
1、什么是吞吐量?
吞吐量是服务器的一个性能指标,指的是服务器每秒处理的请求数或事务数,代表着服务器的处理能力
2、QPS和TPS有什么区别?
二者都属于代表服务器性能的吞吐量的指标 (事务,就是业务)一个事务可以对应一个或多个请求:
- 一个事务对应一个请求时:QPS = TPS
- 一个事务对应n个请求时:QPS = TPS*n
3、吞吐量和平均响应时间成什么关系?
- 吞吐量越大,说明服务器处理能力越强,平均响应时间就会越短
- 吞吐量越小,说明服务器处理能力越弱,平均响应时间就会越长 - 二者成反比关系
4、性能测试,通常需要关注哪些性能指标?
服务器的处理能力 - 平均响应时间 - 吞吐量 - 错误率
5、服务器的资源瓶颈问题
CPU占用率 内存占用率 网络带宽消耗情况 硬盘读写速度情况等
6、你们做性能测试的通过标准是什么?怎么样才算性能测试通过?
平均响应时间: - 3-5-8原则 - 对比其他同类产品或站在用户体验角度
吞吐量:需经过计算的服务器应该达到的处理能力(吞吐量=需要处理的请求数/平均响应时间) 错误率:一般在1%以下,建议0容忍
各种硬件指标:阈值设定在80%,超出会导致系统不稳定
4.性能测试流程
什么时候进行性能测试?一般是功能测试通过之后
性能需求分析
制定测试计划(资源分配,通过标准,技术实现,风险评估)
设计测试用例和发起用例评审
搭建性能测试环境【可选】
执行性能测试
输出测试报告
性能测试结果分析和调优【进阶课】+再次测试