测试派 Give testers a home.

前言

最近面试和找工作的同学都反馈，不管是一线城市还是二三线城市，很多公司面试都问了非常多的性能测试问题，说明现在性能测试的需求量还是比较大的。所以，今天我就把我最近的学生反馈的一些性能测试的面试题给大家做一些整理，帮助大家理解面试官的考察点是什么，以及应该要如何回答这些性能面试题，从而拿下高薪offer！

性能测试面试题精选

1、 以前做过性能测试么？请结合例子具体说明性能测试的流程

面试考察点：性能测试的流程

1. 首选做性能测试的需求分析，明确性能测试的目标、范围、场景和性能指标（如响应时间、吞吐量、并发用户数等）。
2. 测试性能测试环境搭建：搭建与生产环境尽可能一致的测试环境，包括硬件、网络、操作系统、数据库等。
3. 选择工具编写性能测试测试脚本，我们用的是Jmeter工具，根据测试场景编写性能测试脚本，模拟用户行为和数据交互。
4. 性能测试执行：使用CLI命令行执行脚本，分布式压测，包括负载测试、压力测试、稳定性测试等。
5. 性能测试结果分析：收集并分析测试结果，识别性能瓶颈和潜在问题。
6. 性能调优：根据分析结果进行性能调优，优化系统配置、代码实现等。
7. 测试报告编写：编写性能测试报告，总结测试结果、分析性能瓶颈、提出优化建议等。

2、 单台电脑Jmeter最大可以发多大的并发？JMeter分布式环境怎么搭建？

面试考察点：分布式压测

1）单机压测并发量受到多个因素的影响，比如机器配置（如CPU、内存）、网络带宽、JMeter本身的资源限制以及测试脚本的设计，单台电脑使用JMeter进行并发测试最大能够支持的并发量在几百到几千之间不等。我们之前公司就是300多就上不去了，需要使用分布式来执行。

2）JMeter分布式环境怎么搭建？

• 准备好助攻机和主控机：所有的主控机和助攻机都必须用有线连接网络，同一局域网；并都安装好同一个版本的jdk和Jmeter工具

• 助攻机配置：

  • 修改Jmeter的配置文件：jmeter.properties，去掉认证 server.rmi.ssl.disable=true 不使用加密认证传输数据；

• 主控机配置：

  • 修改Jmeter的配置文件：jmeter.properties，去掉认证：server.rmi.ssl.disable=true，remote_hosts=助攻机器ip:端口 ，如果有多个助攻机器信息之间用逗号分开 ；

• 启动助攻机：./jmeter-server -Djava.rmi.server.hostname=助攻机的IP地址。

3、性能测试有哪些指标？有专门看性能指标的软件吗？

考察点：性能测试结果分析和监控

1）性能测试的指标包括：

• 业务指标有：并发用户数，响应时间，TPS\QPS\RPS\HPS\吞吐量\吞吐率，错误率；
• 系统资源指标： CPU、 内存、 磁盘IO、网络IO，线程池、JDBC连接池、JVM内存（GC /FGC/YGC 堆栈）等。

2）有专门看性能指标的软件吗？

我们公司有专门搭建的性能监控平台，比如监控系统资源指标： prometheus + grafana+export，可以看CPU 内存 磁盘 网络等指标；并可以持久化存储；监控业务指标： influxdb + grafana+Jmeter，可以持久化存储 TPS ERR 并发用户数等业务指标。

4、假如你正在测试一个电商网站的性能，如何确定并设置合适的并发用户数？

考察点： 并发测试和负载测试执行

• 1）如果是已经上线过的老项目，可以根据历史用户数据去评估，比如高峰用户，在线用户数用二八原则去计算等方式确认并发用户数；

• 2）如果是新项目没有历史数据，进行负载测试【阶梯压测】，根据预期的用户数量和行为，逐渐增加并发用户数，同时监测系统的性能指标，以确定系统能承受的最大并发用户数的上限；标记该并发用户数为合适的并发用户数，后面的性能测试就使用这个并发用户数进行测试。关注的指标主要有：

  • 在多少并发用户数前出现连续报错
  • 平均响应时间超过预期范围
  • 服务器资源利用率超过80%

5、压测的过程中TPS无法随着并发数的增加而增加，CPU也上不去，可能有哪些原因？

考察点：性能测试的分析和调优

• 1）硬件资源限制

  • CPU资源未充分利用，比如虽然CPU使用率不高，但可能由于硬件性能瓶颈（如单核性能不足或CPU核心数限制）导致无法处理更多的并发请求
  • 内存不足或磁盘I/O性能瓶颈也可能影响TPS，当系统内存不足时，会频繁进行页交换，导致处理速度下降。磁盘I/O性能不足则会导致数据库读写操作延迟，进而影响TPS

• 2）软件和配置问题

  • 如果数据库连接池或服务器线程连接池的最大连接数设置过低，或者连接池中的连接无法及时释放，都可能导致在高并发情况下请求等待连接，从而影响TPS
  • 对于使用Java等语言的系统，频繁的垃圾回收（GC）会占用CPU资源，导致系统响应变慢。如果GC设置不当或内存分配不合理，可能会导致CPU使用率不高但TPS无法提升
  • 数据库查询效率低下、索引不合理、SQL语句未优化等都可能导致数据库处理速度变慢，进而影响TPS。此外，数据库锁冲突、主从同步延迟等问题也可能导致TPS下降

• 3）网络问题

  • 网络带宽限制：如果网络带宽不足或网络延迟较高，数据传输速度会受到影响，导致请求处理时间延长，进而影响TPS
  • 网络配置问题：如网络协议选择不当、网络拥塞控制机制不合理等都可能影响网络性能，进而影响TPS

• 4）应用程序问题：

  • 代码逻辑问题：应用程序中存在低效、死循环、资源竞争等问题都可能导致并发处理能力下降
  • 缓存策略不当：缓存策略不合理（如缓存命中率低、缓存过期策略不当等）会导致系统频繁访问数据库或其他慢速资源，从而影响TPS。

• 5）压测工具和环境问题：

  • 压测工具配置不当：压测工具的并发数设置过低、请求时间间隔不合理等都可能导致TPS表现不稳定。此外，如果压测工具本身存在性能瓶颈或配置问题，也可能影响测试结果
  • 测试环境差异：测试环境与生产环境之间的差异（如硬件配置、网络配置、软件版本等）可能导致测试结果不准确。因此，在进行压测时应尽量模拟生产环境以获取更准确的测试结果

6、 例如100个用户同时登陆，你如何进行测试的

我使用的是Jmeter工具来编写脚本，使用csv参数化来实现100个用户同时登录：

1）先在本地创建txt文件/或者CSV文件，录入100组用户名和密码（逗号分隔），将用户名和密码参数化

2）Jmeter中创建线程组，设置线程数为100个用户并发，1秒内执行，循环一次

3）创建CSV data set config配置元件，引用本地txt/csv文件

4)创建http请求，填入登录接口参数信息,并讲用户名和密码信息进行csv的参数调用；

5）创建同步定时器，设置100个用户，1秒并发执行。

7、 性能测试中，tps和qps的区别是什么？

• QPS[Queries Per Second]每秒查询率，是服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

• TPS[TransactionsPerSecond]每秒事务数，它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

Tps即每秒处理事务数，包括了

• 1）用户请求服务器
• 2）服务器自己的内部查询等处理
• 3）服务器返回给用户

这三个过程，每秒能够完成N个这三个过程，Tps也就是N；

QPS基本类似于TPS，但是不同的是，对于一个页面的一次访问形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求就可计入QPS之中。所以，QPS >= TPS.

8、jmeter录制脚本有了解吗？

有了解的，Jmeter可以用 ：非配置元件 > http代理服务器来录制脚本；配置一个本地的代理： 127.0.0.1 和端口跟Jmeter的代理端口一致，就可以录制脚本了。

不过我们很少会用录制脚本，基本上都是自己编写的脚本，因为录制的脚本有很多垃圾报文，做很多的筛选和修改。

9、怎么保障Jmeter工具端的性能

1）在执行性能测试时，禁用所有监听器；

2）脚本中，能不写断言的不写；

3）性能脚本尽量简单一些，不写逻辑复杂的脚本；

4）能少用元件就少用；不用beanshell元件，性能不好；

5）尽量不用定时器元件；

10、性能测试监控工具nmon安装及使用方法？

• 安装：在使用nmon对linux服务器进行资源监控前，我们需要查看linux的版本，然后下载支持对应版本的nmon软件，然后，在linux服务器上解压软件包，即可使用。
• nmon有三种运行模式，屏幕交互模式，数据收集模式和定时任务模式；
  • 日常性能测试时，监控服务器资源使用情况，常用数据收集模式，如./nmon_x86_64_centos7 -f -s3 -c10 就会每隔3秒收集一次，收集10次,将结果标准输出到一个机器名_年月日_时分的nmon文件中。
  • 然后可以把文件拿出来用nmon分析客户端进行解析，得到详细的性能监控结果，供性能结果分析用。

11、什么是系统瓶颈?

瓶颈主要是系统某一方面或者几个方面能力不能满足用户的特定业务要求，严格的从技术角度讲所有的系统都会有瓶颈，因为大多数系统的资源配置不是完全协调的，例如CPU使用率刚好达到100%时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论，关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。 　

因此我们测试系统瓶颈主要是实现下面两个目的：

• 发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。
• 发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化。

12、是否参与过性能分析，都需要看哪些地方？

参与过性能结果分析的，主要关注以下的点：

1）性能的各项指标：

• 响应时间：是满足要求，我们公司要求是平均响应时间小于1.5s；
• 吞吐量TPS： 是否能随着用户数增加而增加，并达到的值满足项目的需求；
• 资源使用率：包括CPU、内存、磁盘和网络等资源的使用情况，一般不能超过80%；
  • 可以通过一些Linux分析命令，比如top vmstat等查看
  • 我们公司也有一些监控平台： prometheus + grafana可收集和统计服务器的资源使用情况。
• 错误率：一般小于0.1%，不能有连续的报错，保证系统的稳定性和健壮性。

2）通过分析这些指标，发现了异常之后，再通过日志、arthas、MAT等这种分析工具具体分析性能问题的原因，如代码问题，数据库问题，网络问题或者中间件的问题等，然后依次去优化。

总结

以上是最近的一些学生反馈的比较高频的性能测试面试及参考的答案。大家需要结合这些考察点自己结合自己做过的项目的实际案例和场景去组织成为自己的语言，才能拿下offer哦！