简述性能测试

软件性能测试，英文是Performance Testing，主要是为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

性能测试的两个方向，分别是服务端方向和客户端方向（不过这里分享总结的性能测试都是关于服务端方向）：

• 客户端方向一般指的是具有图形界面的应用程序的性能，比如移动端（Android、iOS）APP的启动时间、内存、包大小、帧率，流量等客户端相关的指标，不过APP应用的操作不流畅，图形界面产生卡顿等现象，很容易的被测试人员感受到。
• 服务端方向主要关注服务器上运行软件的性能，当服务端的性能出现问题的时候，一般指的是服务器上某些服务配置遇到了性能问题。

一、服务端的性能测试的基本特点和类型

n个用户同时进行功能性操作的同时，在确保功能实现正确的前提下，考察服务端应用程序的各项性能指标，以及服务器硬件资源的使用情况

1、基本特点：

• 以功能实现正确为前提（假如有个站点访问速度非常快，秒开，但是返回的内容却是不可用的，比如返回了一个白板，这样一来度量这个站点的性能就不正确了）
• 通常有一定的并发用户
• 重点考察服务器端在一定并发压力下的性能指标

2、性能测试可以分为多种类型，常见的有如下几类：

• Benchmark
• 基准测试（Standard Testing）
• 负载测试（Load Testing）
• 压力测试（Stress Testing）

2.1、Benchmark

开发者对服务性能进行快速验证的方式。比如技术选型时有3种方案，开发者需要对比3种方案的性能，选择性能和资源消耗相对均衡的解决方案，Benchmark特点就是快速感知修改前后性能的变化、对调优的结果进行快速度量。

2.2、基准测试(Standard Testing)

基准测试指的是模拟单个用户执行业务场景时，考察系统的性能指标（严格意义上来讲，基准测试并不能算作性能测试范畴，它跟功能测试并没有太大区别），差异在于，基准测试的目的更多地是关注业务功能的正确性，或者说验证测试脚本的正确性，然后，将基准测试时采集得到的系统性能指标，作为基准测试结果，为后续并发压力测试的性能分析提供参考依据

2.3、负载测试(Load Test)

负载测试包含两种测试场景类型：

• 容量测试(volume testing)，模拟系统在正常负载压力场景下，考察系统的性能指标。这里说的正常负载，主要是指用户对系统能承受的最大业务负载量的期望值，即预计系统最大应该支持多大用户的并发量。通过负载测试，目的是验证系统是否能满足预期的业务压力场景
• 稳定性测试(endurance testing)，稳定性测试的加压策略跟负载测试也很接近，都是对系统模拟出系统能承受的最大业务负载量，差异在于，稳定性测试更关注系统在长时间运行情况下系统性能指标的变化情况，例如，系统在运行一段时间后，是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等问题

2.4、压力测试(Stress Test)

压力测试是为了发现在多大并发压力下系统的性能会变得不可接受，或者出现性能拐点（崩溃）的情况。在加压策略上，压力测试会对被测系统逐步加压，在加压的过程中考察系统性能指标的走势情况，最终找出系统在出现性能拐点时的并发用户数，也就是系统支持的最大并发用户数。

二、性能瓶颈定位的性能指标

在性能测试的过程中需要重点关注性能指标主要分为两大类，分别是业务性能指标和系统资源性能（通俗的讲就是服务器、数据库、网络等）指标。

1、业务性能常用的指标项（可以直观地反映被测系统的实际性能状况）：

• 并发用户数
• 事务吞吐率（TPS/RPS）
• 事务平均响应时间
• 事务成功率

2、系统资源性能指标（整个系统环境的硬件资源）：

• 服务器：CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等；
• 数据库：数据库连接数、数据库读写响应时长、数据库读写吞吐量等；
• 网络：网络吞吐量、网络带宽、网络缓冲池大小；
• 缓存（Redis）：静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等；
• 测试设备（压力发生器）：CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等。（性能测试会使用一些压力发生器去实现并发(加压)，压力发生器的性能会对测试结果产生影响。压力发生器在模拟高并发请求的过程中，设备本身也会存在较高的资源消耗，例如CPU、内存、网卡带宽吃满，磁盘IO读写频繁，处理器排队严重等；当出现这类情况后，压力发射器本身就会出现瓶颈，无法产生预期的并发压力，从而测试得到的数据也就不具有可参考性了）

性能指标之间通常都是有密切关联的，单纯地看某个指标往往很难定位出性能瓶颈，这需要我们对各项性能指标的含义了然于胸，然后才能在实际测试的过程中对系统性能状况综合进行分析，找出整个系统真正的瓶颈，总之: 性能瓶颈定位的重点在于性能指标的监控和分析

三、性能工具的介绍

性能测试的主要手段是通过产生模拟真实业务的压力对被测系统进行加压，与此同时监控被测系统的各项性能指标，研究被测系统在不同压力情况下的表现，找出其潜在的性能瓶颈。那么如何对系统进行加压，又如何对系统的指标进行监控呢？这里就需要引入性能测试工具了。

1、性能测试工具组成的核心模块：

• 压力生成器（Virtual User Generator）
• 结果采集器（Result Collector）
• 负载控制器（Controller）
• 系统资源监控器（Monitor）
• 结果分析器（Analysis）

在这些模块中，压力发生器处于核心地位。压力发生器有两个功能，一是真实模拟用户操作，二是模拟有效并发。

不过一般来说，性能工具模拟用户的操作往往不是特别真实。

如果熟悉浏览器的工作原理，就会知道浏览器在加载网页的时候，是同时并发多个TCP连接去请求页面对应的HTTP资源，包括HTML、JS、图片、CSS，当前流行的浏览器普遍会并发6-10个连接。然而，性能测试工具在模拟单个用户操作的时候，基本上都是单连接串行加载页面资源。产生的差异在于，假如页面有100个资源，每个HTTP请求的响应时间约为100毫秒，那么浏览器采用6个连接并行加载网页时大概会需要1.7秒（100/6_100毫秒），而测试工具采用单连接串行加载就需要10秒（100_100毫秒），两者结果相差十分巨大。这也解释了为什么有时候我们通过性能测试工具测试得到的响应时间挺长，但是手动用浏览器加载网页时感觉挺快的原因。

再说下有效并发。什么叫有效并发？有效并发就是我们在测试工具中设置了1000虚拟用户数，实际在服务器端就能产生1000并发压力。然而现实情况是，很多时候由于测试设备自身出现了性能瓶颈，压力发生器产生的并发压力远小于设定值，并且通常测试工具也不会将该问题暴露给测试人员；如果测试人员忽略了这个问题，以为测试得到的结果就是在设定并发压力下的结果，那么最终分析得出的结论也就跟实际情况大相径庭了。不过，我们可以通过保障测试环境不存在瓶颈，使得实际生成的并发压力尽可能地与设定值一致；另一方面，我们也可以通过在测试过程中监控Web层（例如Nginx）的连接数和请求数，查看实际达到服务器端的并发数是否跟我们的设定值一致，以此来反推压力发生器的压力是否有效。

2、性能工具对比：

 从功能特性的角度来讲，LoadRunner是最全面的，用户群体也是最多的，相应的学习资料也最为丰富。不过LoadRunner只能在Windows平台使用，并且并发效率比较低，单台压力机难以产生较高的并发能力，所以后面博文主要只会介绍Jmeter和Locust两款性能测试工具

引用

性能测试中的基本概念比较抽象，推荐两个模型：理发店模型、地铁站模型，来参考理解这些概念，另外本节和后续性能测试中的各种概念、博文参考了乙醇用gitbook分享的资料

性能测试

原文：https://www.cnblogs.com/doumingyi/p/12455397.html