14.1 性能测试怎么测试
性能测试其实就是通过自动化工具模拟多种正常、峰值以及异常负载来对系统的各项性能指标进
行测试。负载测试和压力测试都属于性能测试，二者可结合使用。
性能指标主要有平均响应时间、90%响应时间、吞吐量、吞吐率，每秒事务数，以及服务器的资
源使用率(CPU 占比，mem 内存占比等)等。当并发用户数超过 300 时，为了让测试数据更准确，可以
107
考虑分布式压测，通过司令机控制几台奴隶机进行测试。
性能测试要先调试好脚本，主要考虑对脚本的数据参数化和添加断言。因为有些接口需要对业务
逻辑或参数格式进行校验，为了能让所有线程数跑起来，需要将数据参数化。
数据参数化有这几种做法：
1、可以将一些固定值改成随机函数;
2、利用 JDBC 从数据库读取数据并关联变量；
3、Excal 数据参数化，
4、动态关联参数化，断言是为了判断用例是否
执行成功，并验证服务器的响应错误率。响应断言常用 json 断言，xml 断言用的最少，
性能测试的目的是为了检验系统能否满足客户的性能需求，若性能需求无法满足时，则
要考虑对系统进行性能调优，一般用排除法：
1、首先考虑网络方面问题：使用 ping 命令查看与目标服务器的连接是否正常、传输速度的快慢。通
过提升服务器的带宽，看响应时间是否相应降低。
2、考虑数据库的问题，可以单独去压测数据库，查看数据库的最大连接数和 SQL 语句的执行时间，
索引命中率和 sleep 等待时间等
3、考虑 Apache 中间件的问题，查看中间件设置的最大连接数是否合理，如果设置的连接数太小，会
话数超过设定的最大连接数时会导致等待时间变长，出现响应超时情况
4、考虑服务器的硬件配置，如内存、CPU、men、磁盘读写速度等，可以用 top 命令来监控，也可以
使用 nmom 工具来监控，nmom 会把监控的数据形成表格形式，方便我们查看。
5、最后考虑开发代码写的好不好，处理时间长不长的问题。
举例：在我之前的公司，我们主要是会考虑用户操作使用比较频繁的模块，比如借贷，充值，投资模
块，我们一般会通过增加并发数来压测，观察 CPU、mem、磁盘读写、吞吐量和每秒事务数等性能指
标，以前我老大要求我并发 100 个用户，我用 jmeter 把线程数设为 100，永久循环，持续时间半个
小时，设置启动延退 55，在 Linux 启用 mmom 工具监控服务器。
当我运行脚本的时候我看聚合报告 90%的平均响应时间达到了 6s，吞吐量也比较小，用 top 命令监控
资源发现 CPU 差不多到了 100%。于是我用 Navicat 工具通过 SQL 命令 show full processlist 取当前
运行的 SQL 语句，发现有许多语句用的是左关联，在查看了这条 SQL 语句的执行计划发现没有用索引，
再查看了索引的命中率，命中率倒是还行看了下 nmom 生成的报告，发现 CPU 一直是处于爆满状态，
其中主要是 mysql 的占比很大，这个时候我基本上判断数据库的问题。
于是我就照着前面的步骤再次压测，同样还是用 nmom 工具去监控 CPU，mem 网络等状态，这次我
是主要在 Navicat 上用命令去抓取 SQL 语句，还是一样有很多语句都是左关联，并发现很多空连接
108
(sleep)，我就用 show global variable like"wait_time"命令查看了设置的休眠时间(等待时间)发现
时间很长 28800s，然后我就把这个休眠时间改成了 20s，因为 SQL 语句使用了很多左连接，我就用 show
variables like"tables_size"查看了临时表的空间大小、发现临时表只有 16m，我将空间改成了 1G
再去压测了下，发现 CPU 只是降了 10%左右，nmom 报告上还是显示 mysql 占的 CPU 很大，然后运行的
时候，用 top 命令监控，发现有的时候有很多 mysq 进程同时运行(因为没有设置连接池)，我就用命
令查看了下 mysql 的最大连接数，因为 SQL 语句的执行速度还是挺快的，所以就把 mysql 的连接数调
小到 50，再去跑了一遍发现 CPU 降到了 40%左右，并且其他的性能指标也都还不错。最后把聚合报告
的数据以及 nmom 的数据整理成性能报告给老大，其实做接口性能主要就是用排除法个一个去排除，
发现性能问题就要先解决了性能问题再压测，不然其他的问题也有可能是这个性能问题导致的所以接
口性能基本上就是观察，各个性能指标都在范围之内就差不多了。
14.2 性能测试流程是怎么样的?
例外一种问法：简单介绍下你们公司的性能测试流程是怎么样的?
我们那个项目的性能做得不多，公司要求也不严格。
对于流程这块，首先就要对整个系统进行详细的分析，确定基本的测试范围，看下系统的哪些业务是
需要做性能测试的，还有就是做那方面的性能测试，对于我们那个项目，当时就做了几个业务做了些
简单的井发压测(稳定性)这块，像登录的，搜索查询，下单，还有就是购物车里面的几个接口都有做
过，然后就是对各个业务场景进行详细的场景分析与设计，确定每个业务场景的并发数，是否需要设
置集合点啊，压测时间是多长，还有各个业务场景的性能指标等等，场景设计这块基本上都是老大跟
产品哪个一起弄的，我参与的不是太多。
上面把个场景设置好了之后，提交给我们，我们就是根据老大设置好的那些场景编写了基本的性能测
试用例，其实做性能测试，我觉得前期最关键的还是业务场景一定要设计好，后期我们主要的任务就
是准备各自任务需要用到的一些测试数据，搭建好测试环境，还有就是测试脚本设计与开发，执行，
并生出测试报告，对于测试结果我们一般会简单的做个分析，如果没有什么问题，基本后期就写一个
性能测试报告。流程大概就是这样的。
14.3 你们性能观察哪些指标，大概指标范围是怎么样的。
对于指标这块，业务方面的指标主要有：并发数，90%用户的平均响应时间
错误率，吞吐量/吞吐率这些，例外还需要关注服务器资源的使用情况，像：CPU 的使用率、内存的
占有率，磁盘 IO，网络。
我们那个项目当时只针对，登录，搜索查询，下订单，购物车相关接口，支付等业务做了些简单的并
发，压测这块，指标大概是这样的：
单基准业务并发测试登录，注册，查询 1s 以内，下订单，购物车相关接口，支付 2s 以内，混合业务
109
性能：5s 以内
响应时间：登录，注册业务<2s 之内查询，下订单，购物车，支付业务<3s
充值，提现，查看充值日志，查看提现日志业务查询标的，<3s
投标，申请借款<5s
错误率：0
吞吐量/吞吐率：200 左右请求/sec
CPU：80%以内
内存：80%以内
I/O： %util<=80%，%nowait<=20%
%util: 磁盘一秒中有百分之多少的时间用于 I/O 操作，
% nowait：磁盘等待处理时间占比
带宽：<=系统带宽的 30%，无丢包，无延迟，无阻塞
14.4 这个测试的环境配置，如转速度
租用的服务器，一台数据库服务器，一台后端服务器
8 核 16G 网络带宽 100M，2.5GHZ 磁盘 15000pm 转数
14.5 性能测试计划有哪些内容
写过，主要是时间进度安排与工作安排，主要是环境，测试任务，测试需求，测试方法与策略，测试
环境准备，测试通过的标准。
比如说原来我们一个项目性能测试时做了 5 天，那我们计划是，测试策略与用例编写一天，测试准备
需要 1 天，测试执行 2 天，报告总结 1 天。
14.6 有没有写过性能测试报告，具体包括哪些内容
性能测试报告，需要每次 Jmeter 压测完成的 html 报告的数据跟 nmon 工具监控的数据，整理出一份
性能测试报告，性能测试报告，主要包含：
1，测试资源(环境，测试数据，表里面需要多少数据，测试工具)
2，测试设计(测试业务，测试类型，测试时间，并发用户数)
3，测试分析(每一个场景都需要分析)
4，测试结论(能不能上线，不上线的原因)
5，优化和建议
6，测试通过的标准，平均响应时间<5s，资源利用率<75%，事务失败率<5%
14.7 什么是内存泄漏，什么是内存溢出？
内存泄漏：
110
是指程序在申请内存后，无法释放已申请的内存空间，导致系统无法及时回收内存并且分配给其他进
程使用。通常少次数的内存无法及时回收并不会到程序造成什么影响，但是如果在内存本身就比较少
获取多次导致内存无法正常回收时，就会导致内存不够用，最终导致内存溢出。
内存溢出：OOM
1. 指程序申请内存时，没有足够的内存供申请者使用 1M 实际要占用 2M 内存，
就说分配的内存不够，导致内存溢出
2. 给了你一块存储 int 类型数据的存储空间，但是你却存储 long 类型的数据
3. 长期出现内存泄漏，导致系统内存越用越少，最终导致内存不够用，导致系统崩溃，出现 OOM
14.8 吞吐量，吞吐率
吞吐量：KB
指在一次性能测试过程中网络上传输的数据量的总和(单位应该 KB)也可以这样说，
在单次业务中，客户端与服务器端进行的数据交互总量；对交互式应用来说，吞吐量指标反映服务器
承受的压力。
并不是吞吐量越高越高，一个服务器的性能，要从多个方面去考虑：
90%用户的平均响应时间、错误率、吞吐量/吞吐量、CPU、内存、磁盘 I/O、网络的占用情况，
还有服务器的配置。
吞吐率：
吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它
是衡量网络性能的重要指标。
12s 800M 数
800 * 1024 / 12 = 66666 KB/sec
通常情况下，吞吐率用“字节数秒”来衡量，当然，也可以用“请求数/秒”来衡量;
14.9 吞吐量与吞吐率跟负载有什么关系?
吞吐量/率和负载之间的关系:
1、上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比;
2、平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动;
3、下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比;
总结：吞吐量/率干不过负载!!！
14.10 当你服务器满了之后，你们吞吐量和响应时间怎么变化的
吞吐量会所有下降，响应时间会变长
111
14.11 你们的 TPS 的指标是什么估算的?
假设一个系统的业务有登录、浏览帖子、发送新帖、回复帖子，访问高峰是上午 10 点，日访问高峰 PV
约 5208(含登录 1300、浏览 2706、发帖 526、回帖 676)，系统响应时间要求小于 3 秒，试计算此系
统的 TPS 以及并发数。
如果分析业务量的数据是以 PV 来统计的，我们需要把 PV 转化为 TPS。
PV 的统计一般可以通过监控埋点或者统计访问日志统计得出。
说到 PV 还有个特殊的情况，叫 PeakY，指一天中 PV 数达到的高峰 PV 值。
通过一些监控系统，也可以直观看到统计数据。
实际上一个 PV 即一次对服务器的客户请求，可能还包含了很多资源请求，比如图片、样式 JS 信息、
文字等。而浏览器具有资源缓存功能，下次访问同样资源将不会再从远程服务器上下载，这大大加快
了响应速度。如果我们使用代理服务器访问外网资源时，多数代理服务器也会缓存这些静态数据。也
就是说浏览器与服务器之间的动态数据的 Size 会小于静态数据。
所以浏览器是否缓存了静态数据对性能测试影响明显。我们在做性能测试时，其中就有许多用户可能
是新用户，在他们的浏览器上还没有缓存这些静态数据，为了更准确的模拟用户请求，我们有必要不
缓存这些静态内容.所以性能测试中是否缓存访问的静态资源要根据业务情况而定。
本例中，我们把一个请求放在一个事务中来统计服务器的响应时间。这么说，一个 PV 即是一个
事务(每秒的 PV 量并不直接等同于 TPS，因为一次客户请求可能包含了很多资源请求。如果我们不关
心页面刷新时请求资源的耗时，此时我们就把每秒 PV 数等同于 TPS)，比如一个功能页面(浏览帖子)
每秒会有 10 个 PV，那么此功能的 TPS 即为 10。
估算 TPS：
业务量一般要取系统业务高峰的值，才能代表系统的实际处理能力，系统在 10 点的访问高峰 PV 约
5208，那么这个时段的 TPS = 5208/3600 ≈ 1.45 吗?
答案是否定的，因为在一小时内的吞吐量未必是平均的。
如果我们采集到的业务量数据能够细分到每分钟，TPS 就越准确。如果不能，可以按照二八原则。即
80%的业务在 20%的时间内完成，TPS=(5208*80%)/(3600*20%)≈5.8
估算并发数：
1、由 TPS 进行估算 2、由在线活动用户数估算 3、根据经验估算
方法 1：由 TPS 进行估算
因为 TPS=事务数/时间，假设所有的事务都来自不同的用户，那么并发数=事务数=TPS * 时间。
具体如下：
Vu(业务名称)=TPS(业务名称)*( Runtime+ ThinkTime)
自动化测试相关教程推荐：
2023最新自动化测试自学教程新手小白26天入门最详细教程,目前已有300多人通过学习这套教程入职大厂！！_哔哩哔哩_bilibili
2023最新合集Python自动化测试开发框架【全栈/实战/教程】合集精华，学完年薪40W+_哔哩哔哩_bilibili
测试开发相关教程推荐
2023全网最牛，字节测试开发大佬现场教学，从零开始教你成为年薪百万的测试开发工程师_哔哩哔哩_bilibili
postman/jmeter/fiddler测试工具类教程推荐
讲的最详细JMeter接口测试/接口自动化测试项目实战合集教程，学jmeter接口测试一套教程就够了！！_哔哩哔哩_bilibili
2023自学fiddler抓包，请一定要看完【如何1天学会fiddler抓包】的全网最详细视频教程！！_哔哩哔哩_bilibili
2023全网封神，B站讲的最详细的Postman接口测试实战教学，小白都能学会_哔哩哔哩_bilibili
总结：
光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。
如果对你有帮助的话，点个赞收个藏，给作者一个鼓励。也方便你下次能够快速查找。
如有不懂还要咨询下方小卡片，博主也希望和志同道合的测试人员一起学习进步
在适当的年龄，选择适当的岗位，尽量去发挥好自己的优势。
我的自动化测试开发之路，一路走来都离不每个阶段的计划，因为自己喜欢规划和总结，
测试开发视频教程、学习笔记领取传送门！！
