性能测试
2021-12-15 16:09:29 3 举报AI智能生成
登录查看完整内容
为你推荐
查看更多
性能测试
作者其他创作
大纲/内容
通过自动化的测试工具或者代码来模拟多用户的正常、峰值或者异常负载的场景来观察系统的反应，收集一些既定的指标数据并进行分析从而做出相应优化的一个过程
性能测试
目的是找到最大并发用户数，体现系统的最大承载能力
负载测试
目的是测试系统的稳定性，对系统施加一定的压力是资源使用达到极限然后运行一段 时间，检查这个时间段内系统运行是否稳定（比如7*24小时）
压力测试
数据库中数据量达到一定级别后的性能测试；或者处理超大文件等等；性能预测
容量测试
什么叫性能测试
应用程序是否能够很快的响应用户的要求？
应用程序能承载多大的业务量？
应用程序能否7*24小时运行
是否能够确保用户在真正使用软件时获得舒服的体验？
性能测试的目的
响应时间长，慢
不稳定，一会能访问，一会不能访问
用户层面
前端性能
程序处理的速度
服务端性能
容量，cpu使用率，内存使用率
数据库
传输速率
网络
cpu使用率
内存使用率
服务器资源
技术层面
性能问题的表现
分支主题
压力曲线拐点模型
吞吐量负载模型
性能模型
基于协议，基于代码
模拟多用户，多线程
模拟多用户真实使用场景
性能测试原理
响应时间是否满足要求
服务器的资源使用情况是否合理
最大用户数等承载能力如何
系统处理业务的能力如何
能否支持7*24小时运行
如果出现不稳定的情况，能否快速的恢复
性能测试关注点
200ms
接口响应时间
2-5-8原则
用户层面的响应时间
rt
responese time
平均响应时间，95%响应时间，99%响应时间
响应时间
请求和响应过程中的总的字节大小
throughput
吞吐量
单位时间内的吞吐量
吞吐率
1、打开京东首页2、登录京东3、浏览商品
指用户的某一个操作或者多个操作的组合
transcation per second
tps
每秒事务数
用户已经注册并且在数据库中存储的用户
注册用户数
对于服务端的并发，不区分用户的具体操作
广义的并发
所有用户都进行同一个操作
狭义的并发
并发用户数
在满足某些指标的情况下能支撑的用户数
最佳并发用户数
不考虑指标是否满足用户需求，只要系统能正常运行时支撑的用户数
最大并发用户数
每天来访问网站或者应用程序的用户数
活跃用户数
用户数
不超过80%
硬盘的读写速度
网络资源
资源利用率
数据库：每秒执行的查询次数
web端：每秒钟执行的请求次数
queries per second
qps
每秒查询次数
hps：一个http请求算一个点击
每秒点击次数
常用性能指标以及意义
1、理论知识
有明确需求
8-2原则计算
pv模型，数据模型
跟客户沟通得出一些性能需求
制作性能模型得出最大并发数和最佳并发数
内部用的系统：并发数要求大于总用户*30%
响应时间要求：2-5-8原则
无明确需求
需求收集
并发
持续
门型
拱型
大容量
复杂场景/全链路
场景设计
python多线程
jmeter
loadrunner
ab/siege
准备测试脚本
代码实现（多线程）\t
工具
tomcat日志：异常，内存溢出（outofmemory）
jstack，top，vmstat
zabbix，serveragent
服务端资源
客户端资源不够了会影响测试工具自身的性能，影响请求的发送
监控执行过程中的错误率
客户端
监控
测试执行
指标概念再次回顾，结合loadrunner讲解响应时间细分
讲解方法，实操练习
性能模型再讲解，自己制作性能模型
内存监控：查看内存使用以及回收是否正常
线程监控：检测线程死锁
CATALINA_OPTS="$CATALINA_OPTS -Djava.rmi.server.hostname=10.10.10.133 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"
监控远程服务
jconsole
jvm监控
结果分析
2、性能测试过程
nginx+tomcat
前后端分离
mysql分布式，读写分离，主从
分布式介绍简介
ChaosBlade
故障演练简介
jconsole/jstack/jmap
Arthas
...
监控工具简介
真实用户在用的环境
生产环境：prd、pro
开发人员调试用的环境
开发环境：dev
测试人员执行测试用的环境
测试环境：test
用户验收使用的环境
验收环境：uat
在发布生产环境之前做预演
预发布环境：pre，stagging，堡垒环境
环境
7、拓展知识
ab，siege...
renren-fast压测平台
nGrinder
6、其他性能测试工具和平台
分布式部署、微服务，服务拆分
代码的优化
sql语句的优化：索引，计算的函数
tomcat的调优：线程数配置；jvm配置
数据库配置：查询缓存
前端优化
响应文本的大小
5、性能调优方法
web性能测试
接口性能
tcpcopy
流量复制
全链路压测
借用生产环境压测
腾讯GT
简单，但数据不准
实际项目中较少这么做
基于软件的模拟电量测试
在保持电压恒定的情况下，获取各场景平均电流值来统计系统耗电情况
腾讯电量仪
准确，但有成本
基于硬件仪器的电量测试
耗电量测试（APP使用期间）
PC时代Web端有个“2-5-8”法则
所以闪屏广告往往需要贴底素材，一旦超时就改为展示贴底素材
启动时间1-2秒内
移动端的要求比PC端更高
冷启动速度
热启动速度
有网络启动速度
无网络启动速度
界面秒开测试
App Start-Up（启动时间）
APP在后台运行
空闲状态
APP在前台运行，用户只做少量的操作
中负荷
可以用monkey来做压测
APP在饱和状态下运行（用户进行各种频繁持续的操作）
满负荷状态
三种状态
退出某个页面后，内存是否有回落
进行某个操作后，内存是否增长过快
旧版本和新版本比较
新版本和竞品比较
测试关注点
top
free
ps
time
uptime
vmstat
iostat
sar
Linux 命令
/system/xbin/下的一个命令
这个命令正常在debug/eng模式编译的时候才有
该进程独占的内存的大小
USS(Unique Set Size)
查找内存占用最多的进程
procrank
showmap
指定应用(dalvik进程)内存分析
例：dumpsys meminfo com.tencent.qqlive
dumpsys
Android 命令
Android Studio 自带 CPU 和内存检测功能
Android Monitor
DDMS
测试工具
引用没释放
把资源对象的引用置为null，系统层面缓冲就得不到回收，这会发生内存泄漏
资源没关闭
内存泄漏常见原因
内存占用/内存泄漏测试
CPU
安卓设备的屏幕刷新率为60帧/秒，每帧的时间不超过16.6ms，否则就会出现跳帧、画面卡顿
5秒内无法响应屏幕触摸事件或键盘输入事件
KeyDispatchTimeout，5s
在执行前台广播的onReceive()函数时10秒没有处理完成，后台为60秒
BroadcastTimeout，前台10s，后台60s
前台服务20秒内，后台服务在200秒内没有执行完毕
ServiceTimeout，前台20s，后台200s
什么情况会引发ANR？
3. 弹出一个ANR提示框
3. ANR提示框不一定会弹出，有些手机厂商会设为默认不显示，以避免带来不好的用户体验
2. 写入进程ANR场景信息，包含堆栈信息、CPU、IO等
1. 发生了ANR
ANR执行流程：
UI线程等待其他线程释放某个锁，导致UI线程无法处理用户输入
布局Layout过于复杂，无法在16ms内完成渲染
比如，在游戏中每帧动画进行了大量的计算，这种计算非常耗时，可能导致CPU忙不过来，从而卡顿
同一时间动画执行的次数过多，导致CPU和GPU负载过重
UI线程做了一些IO读写，可能导致阻塞
被其他APP占用着CPU，自身APP获取不到这个CPU的时间片
原因有哪些？
进程、包名、cpu占用率、IO、堆栈信息……
可以通过Logcat
线下监测
统计卡顿率、ANR率，在运营平台观察上报信息
线上监测
如何定位？
尽量避免在主线程（UI线程）中做耗时操作
如何避免？
卡顿时间过长，就会造成ANR
FPS(Frames Per Second)
不同设备、不同CPU、不同内存
软硬件变化（当软硬件不同的时候的表现）
切换被测试APP和其他APP（前后台切换会涉及中断测试的部分）
被测APP 和 其他APP 互相干扰
后台运行时是否会由于性能不足导致数据或状态丢失
单独采购一批性能非常低的主流移动设备
低资源测试
SDK埋点上报统计
Webview渲染时间
腾讯Bugly平台
异常上报
其他
设备性能（Client）
代码需要有处理抖动的逻辑，因此也需要被我们测试到
网络上接收信息存在延迟
网络抖动
比如“网络错误，请重试！”
在腾讯视频APP中就有这个场景
最好显示适当的信息，或者提示用户重试
在数据包完全丢失的情况下，该APP能够重新发送请求（http/https），或相应的生成警报
数据包丢失
在Wifi、2.5G(GPRS)、3G、4G网络进行测试
比如在坐地铁的时候，手机从4g切到wifi（花生地铁）或者wifi切到4g，APP可能会出现问题。此时很可能出现APP无响应的反应（可能再也无法读取数据或crash，可能需要重新启动这个APP才能用
特别是要覆盖这种场景：两个网络来回切换
网络速度
网络性能
Throughput
QPS(Queries Per Second)
TPS(Transactions Per Second)
PV(Page View)
UV(Unique Visitor)
RT(Response Time)
dau
Server端常见指标
意味着如果服务器运行一年它宕机的总时间大概在8-9小时
99.9%
意味着如果服务器运行一年它宕机的总时间大概在1个小时不到，已经很不错了！
99.99%
意味着如果服务器运行一年它宕机的总时间大概在5分钟左右
99.999%
意味着如果服务器运行一年它宕机的总时间大概在31秒
99.9999%
是服务可用性的指标，表示服务器故障修复的能力
SLA（Service Level Agreement）
可靠性（服务器宕机故障修复能力）
不管怎么测试，App测试都很难避免在线上才发现Bug，这个时候必须通过异常捕获和上报来监控
可以针对APP异常进行监控的
Bugsnag
开放了所有API，可以加入自己的指标
将App的各种数据以可视化的方式呈现出来，是一种Saas监测工具（云监控，即Docker监控）
DataDog
Elasticsearch是一个开源的分布式搜索引擎
Logstash是一款开源的日志收集处理框架，负责数据采集和格式化
Kibana负责提供web展示功能（dashboard）；可以帮助分析和搜索重要的数据日志
针对分布式系统检索日志，即通常说的ELK（Elasticsearch+Logstash+Kibana）
Kibana
Web transactions response time
Throughput(rpm)
可以找到关键事务，针对最耗时的进行性能优化
Transactions(app server time)
Error Rate
用来衡量用户对性能的满意度
最大值是1，表示所有的用户对性能都很满意
Apdex Score(App Performance Index)
也是性能监控用的
New Relic
Load time
Pageview
Pagesize
Single Page Visits / Total Visits
Bounce Rate
用来监测网页速度的
DNS查找过程：浏览器缓存、路由器的缓存、DNS缓存
浏览器查找域名对应的公网IP
Cookies随着一起发送给服务器
浏览器向Web服务器发送http请求
服务器根据刚才提交的http请求（参数、cookies）生成一个html的内容
服务器将刚才的html内容返回给浏览器（即Response）
浏览器渲染引擎开始渲染这个html页面内容
引申：浏览器显示网页的过程
可以看到域名解析（DNS）、SSL握手、建立连接、发送请求、等待响应、接收数据、阻塞各个环节的耗时
Pingdom
可以监控Nginx、MongoDB、Tomcat
可以监控网站的可靠性（High Available），即SLA
监控各种网络参数
Zabbix
常见的APP性能监控工具
xml/json 转换
数据转化及传输可能导致加载缓慢
Client端 和 Server端 往返的数据
调用代码进行http请求的时候应该尽可能合并它们，这样的开销比较小
同一个API被多次调用
其他关注点
API性能（Server）
crash
bugly
GT
app性能测试
4、性能测试细分
0 条评论
回复 删除
下一页
