性能测试过程中你需要了解的专业及非专业术语

一、与用户相关的术语

虚拟用户: 

测试工具产生的用户（Jmeter和LoadRunner都可以产生虚拟用户），用来模拟真实用户进行的一系列的操作。

虚拟用户模拟的步骤都被记录在虚拟用户脚本里。

Vuser脚本用于描述Vuser在场景中执行的操作。

虚拟用户和真实的在线用户是有一定的比例关系的，也就是虚拟用户：在线用户！=1:1

用户数: 

在实际场景中我们经常会遇到如下的系统描述:"一个系统注册用户达到8000万，其中每小时的活跃用户大概90万左右”。

这句话给我们传达如下信息，一个是8000万指的是注册用户、另一个90万指的是真实在线用户。

注册用户： 8000万指的注册用户也就是存在系统中数据库表里面的基础用户量，这一部分用户是系统拥有的所有用户群体，这里面的用户是不会全部对系统造成压力的，唯一的压力是这些用户用了系统的存储，影响了数据库的容量。

在线用户： 90万指的就是同时在线人数，这部分也就是真实产生压力的用户，这些用户是系统压力的根源。也就是我们系统需要能支持最大90万人同时在线做业务。

并发用户：在线用户是真实的用户，但是不是所有的在线用户会在系统上做操作，可能有些用户在浏览网页，有些在做业务。有些开着浏览器就什么事都不做了。这时候90万用户中能对系统产生压力的用户大概在90个，而这90个就是90万用户中的有效并发用户。

在线用户数：用户同时在一定时间段内的在线数量

并发用户数：某一时刻同时向服务器发送请求的用户数

并发与在线的比例约为5%~20%。

对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发基本上就足够了。

二、与软件系统相关的术语

TPS

系统每秒处理交易的数量，单位是笔/秒。其是衡量系统处理能力的重要指标。

针对服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能。如果必须要用并发用户数来衡量的话，需要一个前提：交易在多长时间内完成，因为在系统负载不高的情况下，将思考时间（思考时间的值等于交易响应时间）加到脚本中，并发用户数基本可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。

RPS

Requests Per Second的缩写，每秒能处理的请求数目，等效于QPS

QPS

QPS：Queries Per Second，顾名思义：“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

QPS基本类似于TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入QPS之中。每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

如果是对一个接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么TPS等于QPS，否则，TPS不等于QPS  。

网络吞吐量

网络吞吐量指单位时间内通过网络成功传输的数据量。单位为Byte/s。通俗讲就是：服务端返给客户端的数据量，是指对网络单位时间内成功地传送数据的数量，是单位时间服务器处理事务的总数。

随用户数逐渐增多，吞吐量应该是递增，如果吞吐量下降，服务器处理事务能力下降，响应时间变长，达到系统瓶颈。

QPS和并发量的关系 

QPS = 并发量/平均响应时间

举例：单日访问量在2000W，通常情况下，80%的访问量集中在20%的时间，那么QPS需要达到多少才能满足呢？

QPS=（2000W*80%）/（24*3600*20%）=920.9

并发量和吞吐量之间的关系

并发量(或叫并发用户数): 是指同一时间点对业务功能同时操作的用户数。

吞吐量(TPS): 一段时间内系统处理用户的请求数量。

虽然两者关系并不紧密，但是往往会有同学将它们搞混淆。其实我们可以用多线程模型来解释他们，并发量就相当于线程数，吞吐量就是所有线程处理请求数之和。

通常我们做性能测试主要考察和评估的是TPS，而并发量是一个相对较虚的概念，比如我们说一个系统支持同时1k人操作，一般不在评估的范围内。

资源使用率

资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关，如下图所示

图片

资源指标

CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%；

内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%；

磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能；

网络带宽：一般使用计数器Bytes Total/sec来度量，其表示为发送和接收字节的速率，包括帧字符在内；判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较；

系统指标

并发用户数：单位时间内与系统发生交互的用户数；

在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求；

平均响应时间：系统处理事务的响应时间的平均值；事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间；

事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，单位时间内系统可以成功完成多少个定义的事务，在一定程度上反映了系统的处理能力，一般以事务成功率来度量；

超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率.

三、非专业相关术语

性能测试中的非专业术语通常指的是那些在日常对话中使用的、较为通俗易懂的词汇，它们并不涉及太多技术细节或行业特定知识。

跑分

指进行性能测试时得到的分数，用于比较不同系统或配置之间的表现。

压测

对软件或系统施加高负载以测试其稳定性和响应时间的过程。

每秒连接数

每秒连接数实现Web应用程序在运行过程中每秒建立的HTTP连接数。理想情况下，很多HTTP请求都应该使用同一个连接也就是长连接，而不是每个请求都新打开一个连接。如果程序中不断的打开长连接或者频繁的创建达到上千个短连接，那么应用服务器的响应会越来越慢。通过每秒连接数可以看出服务器的处理情况。

扛得住

描述系统在高负载下仍能正常运行，没有出现崩溃或严重性能下降的情况。

集合点

插入集合点是为了衡量加重负载情况下的性能情况

在计划中，可能会要求系统承受1000人同时提交数据，在提交数据操作前加入集合点，当虚拟用户运行到提交数据的集合点时，会自动检查同时有多少用户运行到集合点，当达到指定用户数时，将命令指定用户数同时提交数据，从而达到同时提交的要求

集合点是相对的，因为没有绝对的并发，集合点只是尽可能的在同一时间发送请求，但是服务器是没办法在同一秒接受并处理请求的

卡顿

用户在使用软件或系统时遇到的不流畅现象，可能是由于性能问题导致的。

反应慢

指系统或应用程序对用户输入或请求的响应速度较慢。

迭代

迭代是重复执行过程，性能测试中就是一个事务流程重复执行的过程。通过调整每次迭代的时间，就能控制整个事务流程完成的时间，进而控制TPS的大小。

瓶颈

影响系统整体性能的关键限制因素，通常是硬件资源（如CPU、内存）或软件设计上的缺陷。

步调

步调是指两次迭代之间的间隔时间，可以通过设置步调来调整各个Action之间的执行等待时间。从定义上看，步调和迭代是绑定在一起的，可以认为是Iteraction Pacing

优化

为了提高系统或程序的效率和性能而进行的调整工作。

峰值

系统所能承受的最大负载量，在此之后性能可能会急剧下降或失败。

稳定性

系统在长时间运行或高负载情况下保持良好性能的能力。

用户体验

从最终用户的视角出发，衡量一个应用或网站在性能方面的感受，包括加载时间、交互流畅度等。

并发

狭义定义：所有用户在同一时刻做同一件事情或操作。

广义定义：多个用户对系统发出了请求或者进行了操作，这些请求和操作可以是不同的。

举例：狭义上，100个用户同时登录系统就是并发；广义上，100个用户在同一时间段内分别进行登录、查询、下单等操作也是并发。

场景

定义：为了模拟真实用户的业务处理过程，在测试工具中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等一系列动作的集合。

举例：在测试电商平台的性能时，可以构建一个模拟用户从登录到浏览商品、下单、支付等完整业务流程的场景。

思考时间

定义：用户在进行操作时，每个请求之间的间隔时间。

举例：在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。它模拟了真实用户在操作过程中的停顿和犹豫时间。

阅读后若有收获，不吝关注，分享，留言评论等操作！！！