性能测试基础

性能测试分类

客户端性能：测试APP自身的性能，例如CPU、内存消耗；web页面元素渲染速度
服务端性能：测试服务端项目程序的支持的并发、处理能力、响应时间等，主要通过接口来做性能测试

性能测试指标

并发

同时向服务器发送请求的用户数。

TPS/QPS

TPS：Transaction Per Second，每秒钟处理的事务数。在服务端接口性能测试中，事务可以理解成一次接口调用并返回，所以TPS其实就是每秒钟处理多少次接口调用。TPS越高，处理能力越高，性能越好。

QPS：也是指每秒处理的请求

平均响应时间

响应时间=网络传输的总时间+各组件业务处理时间

响应时间Response Time，简称RT，指的是服务端处理完一个请求所花费的时间，通常时间单位为毫秒ms。
平均响应时间就是n多个请求响应时间的平均值。
平均响应时间越短，代表性能越好，TPS就越高。

TOP响应时间

将所有请求的响应时间先从大到小进行排序，计算指定比例的请求都是小于某个时间。该指标统计
的是大多数请求的耗时。
Tp90（90%响应时间）：90%的请求耗时都低于某个时间
Tp95（95%响应时间）：95%的请求耗时都低于某个时间
Tp99（99%响应时间）：99%的请求耗时都低于某个时间

并发数/虚拟用户（Vuser）

压测工具中设置的并发线程/进程数量

成功率

请求的成功率

PV（Page View）

页面/接口的访问量

UV（Unique Visitor）

页面/接口的每日唯一访客

吞吐量

网络中的流量，TPS越高，吞吐量越大

TPS、响应时间和并发数的关系

在系统达到性能瓶颈之前，TPS和并发数成正比关系，即并发数越高，TPS越高；达到瓶颈后，并发数增加，TPS
不会继续增高（甚至会下降），这个最高的tps出现的点，叫做拐点
TPS和平均响应时间成反比关系，即平均响应时间越小，TPS就越高
响应时间单位为秒的情况下
TPS = 1 / 响应时间 * 并发数
TPS = 并发数 / 响应时间

性能监控指标

操作系统级别监控

CPU使用率、内存使用率、网络IO（input/output）、磁盘（read/write/util）

中间件监控

连接数、长短连接、使用内存

应用层监控

线程状态、JVM参数、GC频率、锁

DB层监控

连接数、锁、缓存、内存、SQL效率

性能测试流程

需求调研

项目背景
测试范围
业务逻辑 & 数据流向
系统架构
配置信息
测试数据量（量级要一致）
外部依赖
系统使用场景，业务比例
日常业务量
预期指标
上线时间

测试计划

项目描述
业务模型及性能指标
测试环境说明
测试资源
测试方法以及场景设计原则（基准测试、单交易负载测试、混合场景测试、高可用性测试、稳定性测试、其他特殊场景）
测试进度安排及测试准则

环境搭建

测试机器硬件配置尽量和线上一致
系统版本与线上一致
测试环境部署线上最小单元模块
应用、中间件、数据库配置要与线上一致
其他特殊配置

数据准备

测试数据分为两部分：基础数据和参数化数据
通常采用以下三种方法进行构造
调业务接口
– 适合数据表关系复杂
– 优点：数据完整性比较好
执行SQL
– 适合表数量少，简单
– 优点：速度最快

脚本编写

选择工具（Loadrunner、Jmeter、Locust等）
选择协议（Http、TCP、RPC）
参数化
关联
检查点
事务判断

压测执行

选择工具（Loadrunner、Jmeter、Locust等）
选择协议（Http、TCP、RPC）
参数化
关联
检查点
事务判断

调优回归

性能调优需要整个团队完成
反复尝试
回归验证
监控工具
全链路排查
日志分析
模块隔离

测试报告

概述
测试环境
结果与分析
调优说明
项目时间表
结论
建议

性能测试工具

Loadrunner（功能强大、重量级、商业软件）
Jmeter（小巧灵活、轻量级、开源）
Locust（Python开源框架）
Ngrinder（ 开源压测平台）