BATJ大厂测试人员必知的经典性能问题

Time will tell.

1、性能测试包含了哪些测试？

负载测试：负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。

压力测试：强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。

容量测试：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。

并发测试：测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题

基准测试：比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。

争用测试：核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。

性能配置：核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。

负载测试：核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。

强度测试：核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。

容量测试：核实测试用户同时使用软件程序的最大数量

2、在给定的测试环境下进行，考虑被测系统的业务压力量和典型场景

负载测试，是用来测定系统饱和状态、确定阀值。其特点：

1. 这种方法的目的是找到系统处理能力的极限；通过 “检测、加压、阀值” 手段找到如 “响应时间不超过10秒” ， “平均CPU利用率低于65%” 等指标。
2. 这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景、另外HP Mercury LoadRuner在使用该方法进行“加压”的时候必须选择典型场景。
3. 这种性能测试方法一般用来了解系统的性能容量，或者是配合性能调优的时候来使用。特别是该的Weblogic 和库的性能调优。

3、什么是性能测试、负载测试、压力测试？

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

4、什么时候开始执行性能测试？

在产品相对比较稳定，功能测试结束后。灵活性比较强。

5、性能测试的步骤

熟悉应用、了解应用的架构、功能逻辑。

测试需求：

1. 需要将开发给定的需求转为吞吐量和响应时间。

2. 根据测试目的，细化需求

测试准备：

• 测试准备包括测试客户端机器准备、测试数据准备、测试脚本准备。

测试执行：

• 测试的执行中，需要监控测试客户端和服务器性能，监控服务器端应用情况：

1. 客户端的系统资源（cpu、io、memory）情况
2. 服务端的系统资源（cpu、io、memory）情况
3. 服务器的jvm运行情况
4. 服务端的应用情况，看是否有异常
5. 响应时间、吞吐量等指标
6. 系统资源监控，linux下可以采用的工具有：vmstat、top、meminfo等
7. JVM的监控，可以用jprofiler工具，linux下面的jmap、jhat等
8. 响应时间、吞吐量等，由grinder提供。

上述这些，一般在测试结束后，均需要归档整理，已备后续详细分析。

我们自己开发一套脚本，用于以固定的频率获取测试客户端和服务器的 vmstat 和 top 输出、 grinder 的 log ，并从中截取有用信息保存，用于事后分析。每次测试运行完以后，肯定会增加很多数据，需要考虑本次执行对数据量的影响，如果数据量的变化对后续测试会有影响，则需要清理数据。

6、你如何识别性能瓶颈？

RBI方法：重点测试“吞吐量”指标，因为RBI认定80%的系统性能瓶颈由吞吐量造成。

按照网络、硬件、数据库、应用服务器、代码的顺序自上而下分析性能工具：IBM、HP、OpenSource 工具都支持。需使用分析模块、根据 Weblogic、Oracle 区别有专门的工具实现RBI。

7、你如何设计负载？标准是什么？

负载测试计划多少用户数量、使用什么类型的机器、以及在什么环境下进行。

主要基于两个重要的文档，任务分布图和事务信息，任务分布图告诉我们在负载时间段内，某一个事务使用的用户数，高峰使用率及低峰使用率均来自该文档；事务信息告诉我们事务名及优先级，在设计场景时可以参考。

8、解释5个常用的性能指标的名称与具体含义

分别为：响应时间、并发用户数，吞吐量，性能计数器，TPS，HPS。

响应时间：

• 指的是 “系统响应时间” 定义为应用系统从发出请求开始到客户端接收到响应所消耗的时间。把它作为用户视角的软件性能的主要体现。

并发用户数：

• 有两种理解方式，一种是从业务的角度来模拟真实的用户访问，体现的是业务并发用户数，指在同一时间段内访问系统的用户数量。

• 另一种是从服务器端承受的压力来考虑，这里的“并发用户数”指的是同时向服务器端发出请求的客户数，该概念一般结合并发测试使用，体现的是服务端承受的最大并发访问数。

吞吐量：

• 是指“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力。

性能计数器：

• 是描述服务器或操作系统性能的一些数据指标。例如，对Windows 系统来说，使用内存数，进程时间等都是常见的计数器。

• 思考时间，也被称为 “休眠时间” ，从业务的角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。

• 从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个 Think 的函数，使得脚本在执行两个操作之间等待一段时间。

TPS：

• Transaction per second，每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能力的重要指标。

点击率：

• HPS，每秒钟用户向WEB服务器提交的HTTP请求数。

9、描述不同的角色（用户、产品开发人员、系统管理员）各自关注的软件性能要点

用户：重点关注打开速度及响应时间。

开发：重点关注响应时间和数据库交互。

管理员：重点关注用户感受到的软件性能；如何利用管理功能进行性能调优；如何利用其他软硬件手段进行性能调优。

10、你是如何得到性能测试需求？怎样针对需求设计、分析是否达到需求？

在查看需求文档，从中提取性能测试需求，与用户交流，了解实际使用情况。结合业务信息设计操作场景总结出需测试的性能关键指标。执行用例后根据提取关键性能指标来分析是否满足性能需求。

11、性能测试的三个核心原理是什么？

1.基于协议。性能测试的对象是网络分布式架构的软件，而网络分布式架构的核心是网络协议。

2.多线程。人的大脑是单线程的，电脑的cpu是多线程的。性能测试就是利用多线程的技术模拟多用户去负载。

3.模拟真实场景。用户的访问时间，访问频率都不是固定的。

12、性能测试的核心关注点是什么？

1.用户关注。响应时间，稳定性、可恢复性

2.运维关注。服务器/数据库资源使用，服务器端处理速度,系统能否支撑7*24小时

3.测试关注。最大访问用户数量，最大业务处理数量，内存资源能否正常回收

4.开发关注。代码：算法、sql语句

13、简述性能测试流程

1.分析性能需求。挑选用户使用最频繁的场景来测试，比如：登陆，搜索，下单等等。确定性能指标，比如：事务通过率为100%，TOP99%是5秒，最大并发用户为1000人，CPU和内存的使用率在70%以下。

2.制定性能测试计划，明确测试时间(通常在功能稳定后，如第一轮测试后进行)和测试环境和测试工具。

3.编写测试用例

4.搭建测试环境，准备好测试数据

5.编写性能测试脚本

6.性能测试脚本调优。设置检查点、参数化、关联、集合点、事务，调整思考时间，删除冗余脚本

7.设计测试场景，运行测试脚本，监控数据

8.分析测试结果，收集相关的日志提单给开发

9.性能测试回归

10.编写测试报告

14、如何确定系统最大负载？

通过负载测试，不断增加并发，随着并发数的增加，各项性能指标也会相应产生变化，当出现了性能拐点，比如，当用户数达到某个数量级时，响应时间突然增长，那么这个拐点处对应的用户数就是系统能承载的最大用户数。Jmeter中可以用rps定时器或者阶梯加压线程组。

15、你们系统哪些功能做了性能测试？

选用了用户使用最频繁的功能来做测试，比如：登陆，搜索，提交订单。

16、你们并发用户数是怎么确定的？

1）会先上线一段时间，根据收集到的用户访问数据进行预估

2）根据需求来确定，使用高峰时间段，注册用户数，单次响应时间等

15、你们性能测试在什么环境执行？

搭建一套独立的性能测试环境进行测试。

16、你们性能测试什么时间执行？

基准测试：功能测试之后，系统比较稳定的时候再做。

负载测试：夜深人静，系统没人用的时候。

17、怎么分析性能测试结果？

首先查看事物通过率，然后分析其他性能指标，比如，确认响应时间，事务通过率，CPU等指标是否满足需求；如果测试结果不可信，要分析异常的原因，修改后重新测试

18、think_time 的作用是什么？

在业务基准测试中模拟用户的思考时间。

19、在确定性能测试结果可信后，如果发现以下问题，按下面提供的思路来定位问题。

问题一：响应时间不达标

• 查看事务所消耗的时间主要在网络传输还是服务器，如果是网络，就结合 Throughput (网络吞吐量) 图，计算带宽是否存在瓶颈，如果存在瓶颈，就要考虑增加带宽，或对数据的传输进行压缩处理；如果不存在瓶颈，那么，可能是网路不稳定导致。如果主要时间是消耗在服务器上，就要分别查看 web 服务器和数据库服务器的 CPU ，内存的使用率是否过高，因为过高的 CPU ，内存必定会造成响应时间过长，如果是 web 服务器的问题，就把 web 服务器对应上对应的用户操作日志取下来，发给开发定位；如果是数据库的问题，就把数据库服务器对应上对应的日志取下来，发给开发定位。

问题二：服务器CPU指标异常

• 1：关注cpu利用率和负载情况，如果利用率过低负载过高，那么可能是进程队列过多，造成了阻塞
  2：关注上下文切换，如果主动切换过多，那么可能是内存/IO瓶颈；如果被动切换过多，那么可能时间片不够，可以考虑调整进程优先级来增加时间片

问题三：内存溢出，进程消失

• 1：观察堆内存的年轻代与老年代空间分配是否合理，调整内存参数
  2：swap空间是否不足，触发了oomkiller

问题四：程序在多用户运行时严重超时，甚至提示连不上服务器

• 程序可能是单线程处理机制，后续的线程全部在排队等待

问题五：如何识别系统瓶颈？

• 1：随着负载的增加，吞吐量是否能持续稳定的上升，找到吞吐量下滑的那个点
  2：随着负载的增加，响应时间是否开始变长，找到响应时间突然变长的那个点
  3：随着负载的增加，是否开始出现错误

20、常见的施压模型有哪几种？

1、并发模式（虚拟用户模式）

• 并发是指虚拟并发用户数，从业务角度，也可以理解为同时在线的用户数。从客户端的角度出发，摸底业务系统各节点能同时承载的在线用户数，可以使用该模式设置目标并发，也就是jmeter工具里面的线程数

2、RPS 模式（吞吐量模式）

• RPS（Requests Per Second）是指每秒请求数。RPS 模式即“吞吐量模式”，通过设置每秒发出的请求数，从服务端的角度出发，直接衡量系统的吞吐能力。

21、tps 无法上升原因有哪些？

1.网络带宽

在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，导致服务端接收到的请求数达不到服务端的处理能力上限。

2.连接池

可用连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。

3.GC

如果堆内存分配的不合理，就会导致频繁的gc，gc会导致线程暂停。尤其是fullgc，会造成线程长时间暂停

4.数据库配置

高并发情况下，如果请求数据需要写入数据库且需要写入多个表的时候，数据库的最大连接数不够，或者写入数据的SQL没有索引，或没有主从分离、读写分离，就会导致数据库事务处理过慢，影响到TPS。

5.硬件资源

包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）

6.压力机

单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，会影响TPS（这个时候就需要进行分布式压测来解决问题）

22、性能测试的应用领域有哪些？

能力验证：通过实际的测试结果证明自己系统的预期能力

瓶颈分析：通过一系列的测试手段发现系统的性能瓶颈（并发，负载，压力，失效恢复）

性能调优：通过一系列的技术手段优化系统性能，包括响应时间，吞吐量，资源利用率

容量规划：为了符合未来的规划预期（用户数，市场占有率），对资源做相应的调整

23、Jmeter如何设计性能测试场景？

并发测试：基础线程组（强调单位时间的并发，不存在绝对并发）

基准测试：反复对比结果，验证调优结果是否通过（tps是否提升，响应时间是否下降）

负载测试：持续不断地增加负载，发现性能瓶颈（阶梯加压线程组，Concurrency Thread Group）

并发用户模式的负载：不断增加并发用户数，发现瓶颈

吞吐量模式的负载：不断增加每秒请求数（rps）对服务端施压，发现tps瓶颈

压力测试：tps瓶颈点上持续负载

稳定性压力测试：tps保持高压稳定。一般取最大tps的80%持续运行

破坏性压力测试：目的是只需要服务端出现异常

失效恢复测试：出现异常之后，系统可以很快的恢复

容量规划测试：50万，高峰时间段2小时

好喽，如果你对更多面试题、Python自动化软件测试感兴趣，在这里推荐一个学习资料分享群：175317069。有各项已整理好的测试学习资源，也有行业深潜多年的技术人分析讲解。

测试工程师职业发展路线：
功能测试 — 接口测试 — 自动化测试 — 测试开发 — 测试架构师

新人学习自动化测试，最好能够掌握一门编程语言，掌握一些基础的知识，多在社区论坛交流，提升自己找问题以及解决问题的能力。加油，测试人！现在就行动，总比在路上观望要好。

最后希望看到这里的你终成为一名极具竞争力的高级测试工程师。

觉得还不错就【点赞】、【评论】、【关注】吧~

Time will tell.（时间会说明一切）