性能测试思维导图模板_ProcessOn思维导图、流程图

1、理论知识

什么叫性能测试

性能测试

通过自动化的测试工具或者代码来模拟多用户的正常、峰值或者异常负载的场景来观察系统的反应，收集一些既定的指标数据并进行分析从而做出相应优化的一个过程

负载测试

目的是找到最大并发用户数，体现系统的最大承载能力

压力测试

目的是测试系统的稳定性，对系统施加一定的压力是资源使用达到极限然后运行一段时间，检查这个时间段内系统运行是否稳定（比如7*24小时）

容量测试

数据库中数据量达到一定级别后的性能测试；或者处理超大文件等等；性能预测

性能测试的目的

应用程序是否能够很快的响应用户的要求？

应用程序能承载多大的业务量？

应用程序能否7*24小时运行

是否能够确保用户在真正使用软件时获得舒服的体验？

性能问题的表现

用户层面

响应时间长，慢

不稳定，一会能访问，一会不能访问

技术层面

前端性能

服务端性能

程序处理的速度

数据库

容量，cpu使用率，内存使用率

网络

传输速率

服务器资源

cpu使用率

内存使用率

性能模型

压力曲线拐点模型

分支主题

吞吐量负载模型

分支主题

性能测试原理

基于协议，基于代码

模拟多用户，多线程

模拟多用户真实使用场景

性能测试关注点

响应时间是否满足要求

服务器的资源使用情况是否合理

最大用户数等承载能力如何

系统处理业务的能力如何

能否支持7*24小时运行

如果出现不稳定的情况，能否快速的恢复

常用性能指标以及意义

响应时间

接口响应时间

200ms

分支主题

用户层面的响应时间

2-5-8原则

responese time

rt

平均响应时间，95%响应时间，99%响应时间

吞吐量

请求和响应过程中的总的字节大小

throughput

吞吐率

单位时间内的吞吐量

每秒事务数

指用户的某一个操作或者多个操作的组合

1、打开京东首页 2、登录京东 3、浏览商品

tps

transcation per second

用户数

注册用户数

用户已经注册并且在数据库中存储的用户

并发用户数

广义的并发

对于服务端的并发，不区分用户的具体操作

狭义的并发

所有用户都进行同一个操作

最佳并发用户数

在满足某些指标的情况下能支撑的用户数

最大并发用户数

不考虑指标是否满足用户需求，只要系统能正常运行时支撑的用户数

活跃用户数

每天来访问网站或者应用程序的用户数

资源利用率

cpu使用率

不超过80%

内存使用率

不超过80%

硬盘的读写速度

网络资源

每秒查询次数

数据库：每秒执行的查询次数

web端：每秒钟执行的请求次数

qps

queries per second

每秒点击次数

hps：一个http请求算一个点击

2、性能测试过程

需求收集

有明确需求

无明确需求

pv模型，数据模型

8-2原则计算

跟客户沟通得出一些性能需求

制作性能模型得出最大并发数和最佳并发数

内部用的系统：并发数要求大于总用户*30%

响应时间要求：2-5-8原则

场景设计

并发

持续

门型

拱型

大容量

复杂场景/全链路

准备测试脚本

python多线程

jmeter

loadrunner

ab/siege

测试执行

代码实现（多线程）

工具

监控

tomcat日志：异常，内存溢出（outofmemory）

服务端资源

jstack，top，vmstat

zabbix，serveragent

客户端

客户端资源不够了会影响测试工具自身的性能，影响请求的发送

监控执行过程中的错误率

结果分析

指标概念再次回顾，结合loadrunner讲解响应时间细分

性能模型再讲解，自己制作性能模型

讲解方法，实操练习

jvm监控

jconsole

内存监控：查看内存使用以及回收是否正常

线程监控：检测线程死锁

监控远程服务

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"

7、拓展知识

分布式介绍简介

nginx+tomcat

前后端分离

mysql分布式，读写分离，主从

故障演练简介

ChaosBlade

监控工具简介

jconsole/jstack/jmap

Arthas

...

环境

生产环境：prd、pro

真实用户在用的环境

开发环境：dev

开发人员调试用的环境

测试环境：test

测试人员执行测试用的环境

验收环境：uat

用户验收使用的环境

预发布环境：pre，stagging，堡垒环境

在发布生产环境之前做预演

6、其他性能测试工具和平台

loadrunner

ab，siege...

renren-fast压测平台

nGrinder

5、性能调优方法

分布式部署、微服务，服务拆分

代码的优化

sql语句的优化：索引，计算的函数

tomcat的调优：线程数配置；jvm配置

数据库配置：查询缓存

前端优化

响应文本的大小

4、性能测试细分

web性能测试

前端性能

接口性能

全链路压测

tcpcopy

流量复制

借用生产环境压测

app性能测试

设备性能（Client）

耗电量测试（APP使用期间）

基于软件的模拟电量测试

简单，但数据不准

腾讯GT

实际项目中较少这么做

基于硬件仪器的电量测试

在保持电压恒定的情况下，获取各场景平均电流值来统计系统耗电情况

准确，但有成本

腾讯电量仪

App Start-Up（启动时间）

PC时代Web端有个“2-5-8”法则

移动端的要求比PC端更高

启动时间1-2秒内

所以闪屏广告往往需要贴底素材，一旦超时就改为展示贴底素材

界面秒开测试

冷启动速度

热启动速度

有网络启动速度

无网络启动速度

内存占用/内存泄漏测试

三种状态

空闲状态

APP在后台运行

中负荷

APP在前台运行，用户只做少量的操作

满负荷状态

APP在饱和状态下运行（用户进行各种频繁持续的操作）

可以用monkey来做压测

测试关注点

退出某个页面后，内存是否有回落

进行某个操作后，内存是否增长过快

旧版本和新版本比较

新版本和竞品比较

测试工具

Linux 命令

top

free

ps

time

uptime

vmstat

iostat

sar

...

Android 命令

procrank

/system/xbin/下的一个命令

这个命令正常在debug/eng模式编译的时候才有

查找内存占用最多的进程

USS(Unique Set Size)

该进程独占的内存的大小

showmap

输出进程的虚拟地址空间, 可以辅助查看由于虚拟地址空间引起的内存问题

dumpsys

指定应用(dalvik进程)内存分析

例：dumpsys meminfo com.tencent.qqlive

工具

Android Monitor

Android Studio 自带 CPU 和内存检测功能

DDMS

内存泄漏常见原因

引用没释放

资源没关闭

把资源对象的引用置为null，系统层面缓冲就得不到回收，这会发生内存泄漏

CPU

FPS(Frames Per Second)

安卓设备的屏幕刷新率为60帧/秒，每帧的时间不超过16.6ms，否则就会出现跳帧、画面卡顿

卡顿时间过长，就会造成ANR

什么情况会引发ANR？

KeyDispatchTimeout，5s

5秒内无法响应屏幕触摸事件或键盘输入事件

BroadcastTimeout，前台10s，后台60s

在执行前台广播的onReceive()函数时10秒没有处理完成，后台为60秒

ServiceTimeout，前台20s，后台200s

前台服务20秒内，后台服务在200秒内没有执行完毕

ANR执行流程：

1. 发生了ANR

2. 写入进程ANR场景信息，包含堆栈信息、CPU、IO等

3. 弹出一个ANR提示框

3. ANR提示框不一定会弹出，有些手机厂商会设为默认不显示，以避免带来不好的用户体验

原因有哪些？

UI线程等待其他线程释放某个锁，导致UI线程无法处理用户输入

布局Layout过于复杂，无法在16ms内完成渲染

同一时间动画执行的次数过多，导致CPU和GPU负载过重

比如，在游戏中每帧动画进行了大量的计算，这种计算非常耗时，可能导致CPU忙不过来，从而卡顿

UI线程做了一些IO读写，可能导致阻塞

被其他APP占用着CPU，自身APP获取不到这个CPU的时间片

如何定位？

线下监测

可以通过Logcat

进程、包名、cpu占用率、IO、堆栈信息……

线上监测

统计卡顿率、ANR率，在运营平台观察上报信息

如何避免？

尽量避免在主线程（UI线程）中做耗时操作

其他

软硬件变化（当软硬件不同的时候的表现）

不同设备、不同CPU、不同内存

被测APP 和其他APP 互相干扰

切换被测试APP和其他APP（前后台切换会涉及中断测试的部分）

后台运行时是否会由于性能不足导致数据或状态丢失

低资源测试

单独采购一批性能非常低的主流移动设备

Webview渲染时间

SDK埋点上报统计

异常上报

腾讯Bugly平台

网络性能

网络抖动

网络上接收信息存在延迟

代码需要有处理抖动的逻辑，因此也需要被我们测试到

数据包丢失

在数据包完全丢失的情况下，该APP能够重新发送请求（http/https），或相应的生成警报

最好显示适当的信息，或者提示用户重试

比如“网络错误，请重试！”

在腾讯视频APP中就有这个场景

网络速度

在Wifi、2.5G(GPRS)、3G、4G网络进行测试

特别是要覆盖这种场景：两个网络来回切换

比如在坐地铁的时候，手机从4g切到wifi（花生地铁）或者wifi切到4g，APP可能会出现问题。此时很可能出现APP无响应的反应（可能再也无法读取数据或crash，可能需要重新启动这个APP才能用

API性能（Server）

Server端常见指标

Throughput

QPS(Queries Per Second)

TPS(Transactions Per Second)

PV(Page View)

UV(Unique Visitor)

RT(Response Time)

dau

可靠性（服务器宕机故障修复能力）

SLA（Service Level Agreement）

是服务可用性的指标，表示服务器故障修复的能力

99.9%

意味着如果服务器运行一年它宕机的总时间大概在8-9小时

99.99%

意味着如果服务器运行一年它宕机的总时间大概在1个小时不到，已经很不错了！

99.999%

意味着如果服务器运行一年它宕机的总时间大概在5分钟左右

99.9999%

意味着如果服务器运行一年它宕机的总时间大概在31秒

常见的APP性能监控工具

Bugsnag

可以针对APP异常进行监控的

不管怎么测试，App测试都很难避免在线上才发现Bug，这个时候必须通过异常捕获和上报来监控

DataDog

将App的各种数据以可视化的方式呈现出来，是一种Saas监测工具（云监控，即Docker监控）

开放了所有API，可以加入自己的指标

Kibana

针对分布式系统检索日志，即通常说的ELK（Elasticsearch+Logstash+Kibana）

Elasticsearch是一个开源的分布式搜索引擎

Logstash是一款开源的日志收集处理框架，负责数据采集和格式化

Kibana负责提供web展示功能（dashboard）；可以帮助分析和搜索重要的数据日志

New Relic

也是性能监控用的

Web transactions response time

Throughput(rpm)

Transactions(app server time)

可以找到关键事务，针对最耗时的进行性能优化

Error Rate

Apdex Score(App Performance Index)

用来衡量用户对性能的满意度

最大值是1，表示所有的用户对性能都很满意

Pingdom

用来监测网页速度的

Load time

Pageview

Pagesize

Bounce Rate

Single Page Visits / Total Visits

可以看到域名解析（DNS）、SSL握手、建立连接、发送请求、等待响应、接收数据、阻塞各个环节的耗时

引申：浏览器显示网页的过程

浏览器查找域名对应的公网IP

DNS查找过程：浏览器缓存、路由器的缓存、DNS缓存

浏览器向Web服务器发送http请求

Cookies随着一起发送给服务器

服务器根据刚才提交的http请求（参数、cookies）生成一个html的内容

服务器将刚才的html内容返回给浏览器（即Response）

浏览器渲染引擎开始渲染这个html页面内容

Zabbix

监控各种网络参数

可以监控Nginx、MongoDB、Tomcat

可以监控网站的可靠性（High Available），即SLA

其他关注点

Client端和 Server端往返的数据

数据转化及传输可能导致加载缓慢

xml/json 转换

同一个API被多次调用

调用代码进行http请求的时候应该尽可能合并它们，这样的开销比较小

bugly

crash

GT