性能测试基础知识及性能指标

前言：最近公司接了个项目，领导开会突然来了句，让我出一份性能测试方案，后面性能测试工作交给我！我心里想之前面试没要求会这个啊（最少得加钱才能做吧~，没办法既然下达了指令，那就只能照做了！

硬着头皮开搞了，小菜鸡性能测试之路慢慢进行中

在做性能方案之前，先捋一下流程，出方案给老板看，要显得自己专业，哈哈哈~

性能流程：
制定性能指标 --> 编写测试方案-->方案评审--> 搭建测试环境--> 脚本编写（准备测试数据）--> 准备测试机器--> 执行测试--> 分析调优

终于费劲九牛二虎之力出了分方案给领导，结果他来了句没有性能指标，让我看着测(~~，没指标玩个毛) 在我一顿输出下领导妥协了，拉着产品，架构师开个会，讨论了下。结果让我先测，给出性能的最大并发和最优性能
（估计大多数小公司都是这样吧，不给性能指标，就是走个过程）那好吧给他出份报告先吧！

在做性能测试之前，我们先了解下性能基础

1.1、性能概述：

性能决定了一个系统支撑其业务的能力。可以描述为系统稳定运行，高并发访问服务

不会出现宕机，用户访问页面需要的时间，系统能够支撑多少用户并发访问。也可以

描述为对资源的消耗。报告cpu，磁盘，内存，IO，网络等。

普通用户关心的是响应时间和稳定性

⚫ 页面还要多久才能加载出来?

⚫ 页面怎么又报502 了?

开发关心的是架构和代码的性能

⚫ 应用架构是否合理？

⚫ 技术架构是否合理？

⚫ 数据架构是否合理？

⚫ 部署架构是否合理？

⚫ 代码是否存在性能问题？

⚫ Jvm 内存分配是否合理？

运维关心的是系统资源的稳定性

⚫ 资源使用率在正常范围吗？

⚫ 数据库连接数正常吗？

⚫ 系统有内存泄露吗？

⚫ 一个节点宕机了，剩下的还能用吗？

1.2 、测试目标

通过压测来观察系统能承载的并发量，响应时间，与最大TPS 了解系统各项性能指

标，以此来评估系统的各项能力

发现系统存在的性能问题，包括

连接池问题。包括Tomcat 连接池，Jdbc 连接池，Nginx 连接池，Tcp 连接队列

内存泄露问题。内存泄露指的是系统在长时间运行过程中，内存空间得不到释

放，最终导致可用内存空间耗尽，出现内存溢出

线程死锁问题。线程死锁指的是某些线程因为资源问题长期占用线程锁，导致其
它的线程因为无法拿到锁而出现大面积阻塞

负载均衡问题。流量过高的情况下，因为负载均衡策略设置不当导致每台服务器
接受的流量不均匀，部分机器压力过大而性能急剧下降，部分机器流量过小而资

源浪费

硬件参数配置问题。例如网卡中断不均，swapiness 比例设置不当，进程优先级
设置不当导致的一系列硬件资源性能问题

1.3 、性能测试方法

1.3.1、并发测试

广义并发：多个用户同时触发某个功能，或者在单位时间内同时向服务器发起多
个请求。此时设置的线程数可以表示为并发的用户数

狭义并发：单位时间内多个业务并行处理(这里强调的是业务流程，比如A-B-C
D)。此时设置的线程数可以表示为并行的业务数。

1.3.2、负载测试

持续稳定地增加系统的负载，测试系统性能的变化

找出指标阈值下的系统瓶颈和性能拐点

测试系统所能承受的最大负载量****

找到处理极限，为调优提供数据

找出系统在稳定情况下的最大压力值

1.3.3、压力测试

对系统持续保持高压运行，时间可以是几小时甚至几天。观察系统在资源饱和状态下

的处理能力。目的是发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患。同

时观察系统在长时间运行下可能出现的故障（例如反应变慢、内存泄漏系统崩溃）

2 .1 、需求分析

2.1 .1 、测试目的

为什么测？目的在于测试系统相关性能能否满足业务需求。通常分以下两种情况：

1. 新项目上线

2. 老项目优化

2.2 、测试对象
测什么？测试对象可以归结为“业务功能”。测试前需要了解待测试的业务功能（不深入

细节）有哪些，比如“购买商品”、“下单支付”。

有没有必要测？需求来源哪里？有没有数据支撑需求的必要性？

可以从以下几个方面考虑

是否核心功能，是否要求严格的质量

是否常用、高频使用的功能

可能占用系统较多资源的功能

使用人数多还是少

在线人数多还是少

2.3 、拆分对象
业务上拆分，业务包含哪些流程、环节

登录->搜索商品->提交订单->支付订单->退出

需要从功能实现上来看是怎么实现的。通常这些业务功能操作都对应着一个或多个可

能是不同类型的请求。我们要做的是找出这些操作对应的请求与请求之间的关联性。

2.4 、指标分析
分析性能需求指标（如“支持300 人并发登录”）是否合理？有没有必要测试这个需

求，考虑需求指标是否合理？有没有数据支撑？支撑数据可以从以下方面考虑：

采样时间段内系统使用人数

采样时间段内系统在线人数

采样时间段内系统(页面)访问量

采样时间段内请求数

2/8 法则

80%的业务量在20%的时间里完成。这里，业务量泛指访问量，请求数，数据量等

2-5-8 原则

当响应时间在2 秒以内，用户会感觉系统速度很快；

当响应时间在2-5 秒，用户会感觉系统的响应速度还可以；

当响应时间在5-8 秒以内，用户会感觉系统的速度很慢，

当响应时间超过8 秒后，用户会认为系统已经无法响应，直接离开

3.1 、用例设计

4.1、性能监控关键指标

4.1.1 、系统指标：系统指标则与用户场景及需求直接相关

并发用户数
平均响应时间
吞吐量
4.2 、服务器资源指标
CPU使用率： 一般可接受上限85%

内存使用率：一般可接受上限85%

磁盘I/O

网络带宽

4.3 、 JVM 应用
Java运行内存划分机制：

堆区内存没有被及时释放，则存在内存泄漏

在性能测试过程中关注JVM堆区的内存，如持续在上升没有下降，则可能存在内存泄漏

内存泄漏原理：

FULL GC 机制：

垃圾回收：将内存中已申请并使用完成的那部分内存空间回收，供新申请使用

垃圾回收机制针对堆区的内存进行的

JVM(JAVA虚拟机)垃圾回收机制原理：

系统在做垃圾回收时，不能处理任何用户业务，如果垃圾回收太频繁，导致系统处理业务能力下降

FULL GC内存比较大，垃圾回收一次时间较长，这段时间不能处理业务，对系统影响比较大，因此在性能测试过程中需要关注FULL GC的频率

4.4 、数据库指标

慢查询
缓存命中率
数据链接池
Mysql锁

Mysql锁概念：

对比：

l 页面锁：处理效率低，但不会出现死锁

l 处理效率高，但是可能出现死锁

监控点：

需要监控在性能测试过程中，是否死锁出现，如果出现需要对代码优化

4.5 、压测机资源：

CPU ---不超过80%

内存---不超过80%

网络

磁盘

好了，以上便是性能的一些基础知识，和性能的一些指标

在了解这些性能基础及指标知识后，再进行性能测试便可以更加轻松了，不然照着网上按葫芦画瓢也只是了解皮毛，反而得不出结果，完成不了上级交代的工作

1. 通常在做性能测试的时候，编写脚本和执行只是一部分，在性能测试过程中脚本编写和执行只是占比30%
2. 例如功能测试需求分析和用例编写一样，做性能测试也是一样，要先分析，这部分也占比30%，
3. 最后再是分析调优了--占比40%

结尾：

学会了这些，便可以理直气壮的拍老板桌子，提出升值加薪啦！

先了解基础知识和指标，等下个月项目做完，再出一份性能执行和分析调优的分享