性能测试常见面试题

性能测试相关文章
https://blog.csdn.net/lzz718719/article/details/130288200
https://blog.csdn.net/csdnchengxi/article/details/131228372
https://blog.csdn.net/xfw17397388089/article/details/132629793
https://www.cnblogs.com/doupi/p/13233788.html

1、一个完整的性能测试流程是怎样的？

• a. 做性能需求分析，挑选业务核心场景或用户最频繁使用的功能来进行性能测试，如：登录、搜索、提交订单、算法检测等
• b. 确定性能指标，如：
  • 错误率 < 0.01%
  • 90%响应时间 < 5 s
  • 吞吐量 > 1000笔/s
  • 并发用户1000时，CPU和内存使用率 < 70%
• c. 性能测试计划，明确测试时间、测试环境、测试工具等
  • 测试时间，一般选择在功能稳定后，如：第一轮测试后
  • 测试环境，独立搭建一套测试环境或者使用UAT环境，硬件配置与生产环境一致或等比例缩减
  • 测试工具，选择性能测试工具（JMeter）、监控工具（Prometheus/grafana）等等
• d. 搭建测试环境：根据性能测试计划的要求搭建
• e. 编写性能测试用例，编写测试脚本，准备性能测试数据
• f. 性能测试脚本调优，设计检查点、参数化、关联、集合点、实物，调整思考时间；
• g. 设计性能测试场景，监控服务器，运行测试场景
• h. 分析性能测试结果，判断性能瓶颈，反馈结果信息
• i. 回归性能测试，达到制定的性能测试目标

2 、介绍下最近做过的项目、背景、预期目标、系统架构、场景设计以及遇到的性能问题，定位分析及优化；

考察点：

• a. 对项目的了解情况
• b. 需求分析和场景设计思路
• c. 问题分析思路及优化验证手段

4、怎么确定并发用户数？

• 根据生产环境收集的用户访问数据进行预估，按二八原则预估
• 根据业务需求确定

5、 性能测试需求从哪里来？

从需求文档或用户故事来，如果需求不太合理或不明确，需和产品、业务等相关人员进行讨论；

5、项目处于什么阶段适合性能测试介入，原因是什么？

一般情况下，在功能测试，系统比较稳定时开展（至少一轮测试后）

6、介绍下你在工作中使用过的监控和分析工具，各自有什么特点？

• 监控工具我常用的时zabbix/Prometheus/grafana，分别用他们来查看 XXX 指标；
• 分析工具我常用的是arthas，jvm自带的命令分析工具，分别用他们来进行 XXX 分析；

7、了解过全链路压测吗？阐述一下你的理解或者实践经验？

8、如何排查CPU占用比较多的线程方法？

Linux 相关命令：

• top：找到CPU % 最高的进程PID；
• top -H -p pid：查看进程下的线程，找到资源耗用率最高的线程pid；
• shell 命令：printf “%x
  ” pid (%x，表示十六进制，
  是换行)
• jstack 分析：jstack pid（十六进制） 1> xxx.temp

9、线上系统出现了MQ的消息积压，这个时候应该怎么做？

处理步骤：

• 1. 首先要快速解决消息积压问题，如：加大consumer数量，消费频次；
• 2. 如果消息太多评估是否丢弃消息或者重启MQ；
• 3. 保留日志，线上业务止血后快速排查问题出现的原因，是否有其他类似场景存在同样的问题；
• 4.组织复盘，评估后续优化方案，及时跟进落地优化的进度和效果；

9、如果让你负责团队的性能测试，你会从哪方面考虑和开展工作？

考察点：

• 1. 是否有完整的性能测试技术体系总结；
• 2. 根据实际情况的分析和落地执行能力；
• 3. 是否注重团队配合、成员培养和质量把控能力；

10、性能测试关注的指标是什么？

从外部看应关注的指标：

• 并发用户数：指同时发起请求的用户数量
• 吞吐量：每秒钟系统能处理的请求数、任务数
• 响应时间：服务处理一个请求或者一个任务的耗时
• 错误率：一批请求中结果出错的请求所占比例
• 资源利用率：指系统在处理请求时出现错误的概率
  从服务器的角度关注的指标：CPU、内存、服务器负载、网络、磁盘IO

11. 你们性能测试在什么环境开展？

测试环境分SIT（系统集成测试）和UAT（用户验收测试）两套测试环境
一般情况下，是在UAT环境进行性能测试，因为UAT比SIT环境稳定，UAT环境更贴近生产环境，有时也会从生产环境同步数据到UAT环境，数据真实性较高；

12. 怎么分析性能测试结果

收集好测试的数据，如：
JMeter压测结果报告，压测机硬件资源占用，被测服务器硬件资源占用情况，被测服务的日志等测试数据；
https://blog.csdn.net/weixin_40863562/article/details/127772919
分析过程：

• 1、确定测试结果是否可信
  • 分析整个性能测试执行期间，测试环境是否稳定。压测机存在硬件瓶颈、网络出现拥堵、待测系统参数配置错误（数据库连接、nginx连接等等）
  • 检查JMeter测试脚本参数设置是否合理。Ramp-Up Period(in seconds)设置为0或者1，会给待测服务器造成巨大压力，轻则造成服务器响应时间超长，重则部分请求超时而报错。正确应该是逐步加压，而不是瞬间达到目标压力。
  • JMeter运行模式是否合理。JMeter是否采用非GUI模式运行，GUI模式运行JMeter对CPU和内存占用较高；
  • 检测测试结果是否暴露出了系统瓶颈。测试结果正常，首先考虑，并发用户数是否足够多，对待测服务器施加的压力是否足够大。另外还需要考虑，待测系统是否有机制屏蔽了大部分压力（如：使用缓存技术）。
• 2、分析测试结果是否存在性能问题，主要从关注的性能指标进行分析，然后综合所有指标进行分析，找出系统瓶颈和问题，并提出改进建议。
  • 吞吐量：吞吐量是否偏低，低于需求需求目标；代码是否存在瓶颈；
  • 响应时间（RT）：响应时间是否过长；综合平均RT、最大RT、90%RT多种不同维度的RT进行分析，如果数据相差范围较大，RT分布没有规律，那需要进一步分析是否存在系统瓶颈。
  • 错误率：是否存在较高的错误率；
  • 资源利用率：是否存在较高的资源利用率（CPU> 80%，MEM > 80%，GPU > 80%、网络带宽、磁盘IO等等）
    • CPU：CPU占用是否稳定？CPU占用是否一直占用不下降？
    • 内存：内存是否一直增加不下降？
    • GPU：GPU占用是否长期100%？GPU占用是否异常？GPU占用是否及时得到释放？
    • 网络带宽：网络上行/下行与吞吐量不成正比，那有可能存在系统瓶颈
    • 磁盘IO：

13、有哪些常见的性能瓶颈？（参考：【性能测试】常见性能瓶颈解析及调优方案）

1. TPS波动较大
原因解析：一般有三种：网络波动、其他服务资源竞争、垃圾回收。

• 网络波动：性能测试环境一般在内网或者压测机和待测服务在同一网段，可通过监控网络的出入流量进行排查。网络波动的影响因素：CPU处理能力、网络带宽、网卡、防火墙等。
• 其他服务资源竞争：可通过top命令或者服务梳理方式来排查在压测时是否有其他服务运行导致资源竞争，测试资源充足的情况下，在服务器上只部署待测服务。
• 垃圾回收：造成TPS波动最常见的原因，可能会引起、CPU占用高、内存溢出、内存泄露等问题，可通过GC监控命令来排查。命令如下：

# 监控Full GC的发生情况

# 将GC信息实时打印到屏幕上
jstat -gc <pid> <interval> <count>
jstat -gcutil <pid> <interval> <count>

# 将GC信息输出到文件中
jstat -gc <pid> <interval> <count> >> /path/gc.txt 
jstat -gcutil <pid> <interval> <count> >> /path/gc.txt

# 参数解析
-gc 监控垃圾回收器的运行情况，显示各个垃圾回收器的运行次数、时间、堆内存使用情况等信息。
-gcutil 监控垃圾回收器的内存使用情况，显示各个内存区域（包括新生代、老年代、永久代等）的使用率、已使用空间、总空间等信息。
<pid>参数表示Java应用程序的进程ID，可使用top命令查询
<interval>参数表示显示信息的时间间隔，单位：ms
<count>参数表示显示信息的次数

调优方案：

• 网络波动：选择内网压测，切换网段，或者等网络较为稳定或空闲时进行压测验证；
• 其他服务资源竞争：找到压测时正在运行的其他服务，沟通协调暂时停止该服务，测试资源充足的情况下，更换新服务器，只部署待测服务。
• 垃圾回收：通过GC文件分析，如果发现有频繁的 Full GC，可以通过修改JVM的堆内存参数 -Xmx（Xmx的值不能超过服务节点内存的50%），然后再次压测验证，达到一个合适的值。

2. 高并发下大量报错
原因解析：短连接导致的端口被完全占用，线程池最大线程数配置较小及超时时间短导致。
调优方案：

• 短连接问题：修改服务节点的tcp_tw_reuse参数为1，释放TIME_WAIT_scoket用于新连接；
• 线程池问题：修改服务节点中容器的server.xml文件中的配置参数，主要参数有：

# 最大线程数，即服务端可以同时响应处理的最大请求数
maxThreads="200"                        
# Tomcat的最大连接线程数，即超过设定的阈值，Tomcat会关闭不再需要的socket线程       
maxSpareThreads="200"               
# 所有可用线程耗尽时，可放在请求等待队列中的请求数，超过该阈值的请求将不予处理，返回Connection refused错误
acceptCount="200"                 
# 等待超时的阈值，单位为毫秒，设置为0时表示永不超时
connectionTimeout="20000"    

3. 集群类系统，各服务节点负载不均衡

原因解析：出现这类问题的原因一般是SLB服务设置了会话保持，会导致请求只分发到其中一个节点。
调优方案：如果确认是如上原因，可通过修改SLB服务（F5/HA/Nginx）的会话保持参数为None，然后再次压测验证；

4. 并发数不断增加，TPS上不去，CPU使用率较低
原因解析：出现该类问题，常见的原因有：大量的数据库读写操作、SQL没有创建索引/SQL语句筛选条件不明确、代码中设有同步锁，高并发时出现锁等待；
调优方案：

• SQL问题：没有索引就创建索引，SQL语句筛选条件不明确就优化SQL、业务逻辑，数据量庞大（百万级以上）可进行数据库读写分离、引入Redis等数据库缓存工具；
• 同步锁问题：是否去掉同步锁，有时候不仅仅是技术问题，还涉及到业务逻辑的各种判断，是否去掉同步锁，建议和开发产品同事沟通确认；

5、压测过程中TPS不断下降，CPU使用率不断降低
原因解析：一般来说，出现这种问题的原因是因为线程block导致，当然不排除其他可能；
调优方案：如果是线程阻塞问题，修改线程策略，然后重新验证即可；

14、系统的性能需求不明确怎么判断标准？

• 参考行业标准：了解相关行业的标准和最佳实践，可作为一个参考。需要查询相关数据
• 参考竞争对手：观察竞争对手的系统性能表现，了解他们的响应时间、并发用户数等性能指标， 可作为一个参考。怎么获取竞争对手的系统性能数据
• 用户反馈和需求：（To B用得较多）与用户进行沟通，了解他们对系统性能的期望和需求。
• 进行用户调研：（To C较多）通过问卷调查、用户访谈等方式，主动收集用户对系统性能的评价和期望。
• 进行实验和评估：系统开发早期，可进行一些试验和评估，了解系统在不同负载下的性能表现，可作为一个参考。

15、 B/S 架构下，如果系统性能瓶颈在前端，需要怎么左做？

• 1. 压缩和优化资源：使用压缩算法（Gzip）降低图像、视频等资源的大小；
• 2. 使用浏览器缓存：设置适当的缓存策略，减少重复的网络请求；
• 3. 减少重定向：每次重定向都会增加额外的网络请求和延迟；
• 4. 异步加载资源：将不影响页面渲染的资源（脚本、样式表等）使用异步加载；
• 5. 延迟加载内容：适用于长页面或大量内容页面，使用分页或者滚动加载方式；
• 6. 使用CDN加速：使用CDN分发静态资源，缓存到全球各地的服务器上，提高加载速度；