JMeter压力测试实战：从Vue应用到后端API的完整性能评估指南

1. 项目概述：从面试题到实战，压力测试的完整闭环

最近在带团队和面试新人的时候，发现一个挺有意思的现象：很多朋友，尤其是刚入行或者准备跳槽的测试工程师，一提到“压力测试”和“JMeter”，脑子里蹦出来的可能就是面试题库里那几个标准答案，比如“什么是并发用户数？”、“TPS和RT的关系是什么？”。背得滚瓜烂熟，但真给一个现成的Vue前端项目，让去设计并执行一次完整的压力测试，反而有点无从下手。这中间的断层，其实就是理论到实践的鸿沟。今天，我就以“手把手”的方式，拆解如何用JMeter对一个典型的Vue前端应用（及其后端API）进行压力测试，并把这些测试实践，反过来理解成那些2024年高频面试题最生动的答案。这不是一篇简单的工具教程，而是一次完整的测试思维和实战演练，目的是让你不仅能“做”出压力测试报告，更能“讲”清楚背后的每一个为什么。

我们假设一个最常见的场景：你所在的公司开发了一个基于Vue.js的单页面应用（SPA），比如一个电商平台或者内容管理系统。前端负责渲染页面、处理用户交互，而真正的业务逻辑（登录、查询商品、下单）则通过调用后端的RESTful API来完成。你的任务，就是评估这个系统在大量用户同时访问下的表现。我们将使用JMeter这个行业标准的开源工具来完成这一切。整个过程，我会穿插着解释那些面试常考的概念在实际中对应什么，让你下次面试时，能举出自己亲手做过的例子。

2. 测试策略与场景设计：不只是“点开始”

在打开JMeter之前，我们必须先想清楚：我们要测什么？以及为什么要这么测？盲目地发起大量请求，除了可能把测试环境打挂，得不到任何有价值的结论。这一部分，是区分一个测试执行者和测试设计者的关键。

2.1 理解Vue应用的压力测试对象

首先必须明确：对Vue这类前端应用进行“压力测试”，直接对象并不是浏览器里运行的JavaScript代码。我们无法用JMeter去压测Vue组件的渲染速度或虚拟DOM的diff算法（那是前端性能测试工具如Lighthouse、WebPageTest的范畴）。我们的压力测试对象，是支撑这个Vue应用运行的后端API服务、数据库以及它们之间的中间件。

当用户在前端点击一个按钮，Vue会发起一个或多个HTTP请求到后端服务器。我们的压力测试，就是模拟成千上万个这样的HTTP请求，观察后端服务集群的响应。因此，测试的核心在于：准确地模拟前端产生的真实流量。这包括：

1. API接口识别：使用浏览器开发者工具的“网络（Network）”面板，录制用户在Vue应用中的关键操作（登录、浏览列表、提交表单），找出所有被调用的API端点（URL）、请求方法（GET/POST/PUT/DELETE）、请求头（特别是认证Token）和请求体格式（通常是JSON）。
2. 参数化与关联：用户登录后的session ID或JWT Token需要被后续请求使用；查询商品列表时，商品ID、分页参数需要动态变化。这要求我们的测试脚本是“智能”的、有状态的。
3. 思考时间与步调：真实用户不会毫秒不差地连续点击。他们会有浏览、阅读的停顿时间（思考时间），并且用户是一个接一个逐步进入系统的（步调）。在压力测试中模拟这些，能使测试场景更贴近生产环境。

实操心得：很多团队的压力测试失败，第一步就错了——他们直接用JMeter录制了浏览器对本地开发服务器的请求，但其中可能包含大量开发环境的特定资源（如热更新WebSocket连接、本地地图文件），这些请求在生产环境根本不存在。务必在模拟生产环境配置的测试环境中进行流量录制。

2.2 定义关键性能指标与测试目标

没有量化目标的测试就是“耍流氓”。我们必须和项目、运维、开发团队一起定义清晰的性能需求（Performance Requirement），它通常来源于业务预测或历史数据。以下是几个核心指标，也是面试中的必答题：

• 并发用户数（Concurrent Users）：这是最容易混淆的概念。在压力测试中，我们通常指“同时向服务器发起请求的虚拟用户数”。但要注意，一个在线用户（Session）可能并不时刻在发起请求。JMeter中通过“线程组”的线程数来模拟。
• 每秒事务数（TPS, Transactions Per Second）：这是衡量系统处理能力的黄金指标。指系统每秒成功完成的业务事务数量。比如“登录事务”、“下单事务”。一个事务可能包含多个HTTP请求。TPS越高，说明系统吞吐量越大。
• 响应时间（RT, Response Time）：从发送请求到接收到完整响应所花费的时间。通常我们关注平均响应时间、90%分位或95%分位响应时间（例如“90%的请求响应时间在200ms以内”）。后者更能反映大多数用户的体验。
• 错误率（Error Rate）：失败请求数占总请求数的百分比。在压力测试中，非5xx的服务器错误（如因超时返回的4xx，或因业务逻辑失败返回的200但包含错误信息）也需要被计入。
• 资源利用率：服务器端的CPU使用率、内存使用率、磁盘I/O、网络带宽等。这是定位瓶颈的关键。

一个具体的测试目标可能表述为：“在5000并发用户、持续运行30分钟的场景下，登录接口的TPS不低于100，95%响应时间小于1秒，错误率低于0.1%，且服务器CPU平均使用率不超过70%”。

2.3 设计阶梯加压场景

一次性将并发用户数拉到最高，是一种粗暴的“浪涌测试”，常用于探测系统极限，但不利于观察系统性能拐点。更科学的做法是使用阶梯式加压（Ramp-up）。

例如，我们计划测试最大5000并发用户。可以这样设计线程组：

• 0-2分钟：以每秒100用户的速度逐步增加并发至1000用户，并保持2分钟。观察系统在低负载下的稳定性和响应时间基线。
• 2-4分钟：继续以每秒100用户的速度增加至2500用户，保持3分钟。观察性能指标的变化趋势。
• 4-5分钟：增加至5000用户，保持15分钟。这是核心的稳定压力阶段，评估系统在预期最大负载下的长期稳定性。
• 5-20分钟：在5000用户并发下持续运行。
• 20-25分钟：逐步将并发用户数降为0。观察系统在压力释放后的恢复情况。

这种设计能帮助我们清晰地回答：“系统性能是从哪个并发点开始下降的？”、“在持续压力下，是否有内存泄漏？”等问题。在JMeter中，这可以通过“线程组”的“Ramp-Up时间”和“调度器”配合“吞吐量定时器”或“同步定时器”来实现更精细的控制。

3. JMeter测试计划核心构件详解

打开JMeter，创建一个新的“测试计划”。它就像一个容器，所有元件都按逻辑组织在里面。下面我们逐一拆解构建一个有效压力测试脚本所必需的核心元件。

3.1 线程组：虚拟用户的调度中心

线程组是任何场景的起点，它定义了虚拟用户（线程）的数量和行为模式。

• 线程数：即模拟的并发用户总数。根据你的测试目标设定，比如5000。
• Ramp-Up时间（秒）：所有线程在多长时间内启动完毕。例如，设置线程数5000，Ramp-Up为300秒，意味着JMeter将在5分钟内，均匀地启动这5000个线程（平均每秒启动约16.7个）。这模拟了用户逐步进入系统的过程。如果设为0，则表示立即启动所有线程，冲击力极大。
• 循环次数：每个线程执行测试脚本的次数。如果勾选“永远”，则会一直执行，直到手动停止或达到调度器设置的时间。对于时长固定的压力测试，通常勾选“永远”，然后用“调度器”控制持续时间。

注意事项：Ramp-Up时间设置过短（如5000线程在10秒内启动）会对测试机本身和被测系统造成巨大瞬时冲击，可能导致测试机网络端口耗尽或结果失真。一个经验法则是，Ramp-Up时间至少为线程数除以10（秒），给测试机和系统一个缓冲。

3.2 HTTP请求采样器：模拟API调用的核心

这是模拟浏览器向后端发送请求的元件。你需要为每一个关键的API接口配置一个HTTP请求采样器。

• 协议：通常是http或https。
• 服务器名称或IP：填写你的测试环境后端服务器地址。
• 端口号：对应的端口，如80、443或8080。
• HTTP请求：选择方法（GET, POST等），填写路径（如/api/v1/login）。
• 参数/消息体数据：
  • 对于GET请求或表单提交，可以在“参数”选项卡中添加键值对。
  • 对于REST API常用的JSON格式，切换到“消息体数据”选项卡，直接输入JSON字符串。这里强烈建议使用JMeter的变量和函数来动态生成数据，例如使用${__RandomString(10,abcdef123456)}来生成一个随机字符串作为用户名的一部分。
• 头信息：至关重要！需要添加Content-Type: application/json、Authorization: Bearer ${access_token}等。access_token就是一个变量，从登录请求的响应中提取而来。

3.3 逻辑控制器与参数化：让脚本“活”起来

一个真实的用户会话包含多个有逻辑关系的请求。逻辑控制器帮助我们组织这些请求。

• 事务控制器：将多个采样器（如“输入用户名密码”、“点击登录按钮”对应的两个API调用）组合成一个逻辑事务。JMeter会统计这个事务整体的响应时间、TPS等，这对于衡量“登录”这个业务操作的整体性能至关重要。
• 仅一次控制器：放在里面的采样器在每个线程的整个生命周期内只执行一次。常用于“登录”操作，因为一个用户会话通常只需要登录一次。
• 循环控制器：控制其子元件的循环执行次数。可以用来模拟用户重复执行某个操作，比如不断刷新商品列表。

参数化是让压力测试真实有效的灵魂。我们绝不能所有用户都用同一个账号登录、查同一件商品。

• CSV数据文件设置：最常用的参数化方式。准备一个CSV文件，里面有多行数据，每行代表一个虚拟用户的凭证或测试数据（如 username,password,product_id）。在JMeter中配置CSV数据文件设置元件，为变量名（如USER,PWD）赋值。然后在HTTP请求中，使用${USER}、{PWD}来引用。JMeter会按顺序或随机为每个线程分配一行数据。
• 用户定义的变量：定义一些全局的、固定的变量，如服务器地址、端口等。
• 函数助手：使用{__Random},{__RandomString},${__time}等函数动态生成数据。

3.4 后置处理器与断言：提取与验证

服务器返回的响应中，往往包含我们后续请求需要的数据。

• JSON提取器：当前后端使用JSON通信时，这是提取数据的利器。你需要指定变量名、JSON路径表达式（如$.data.token）来从响应体中提取出特定的值（如登录返回的token），并存入一个JMeter变量（如access_token）中供后续请求使用。
• 正则表达式提取器：如果响应是HTML或其他文本格式，可以用正则表达式来提取所需内容。虽然强大，但比JSON提取器更复杂且容易出错。

断言用来验证响应是否符合预期，确保我们测试的是“正确的”功能，而不仅仅是“有响应”。

• 响应断言：可以检查响应文本中是否包含/匹配某个字符串，或者检查响应代码是否为200。这对于验证登录是否成功、查询是否返回了数据非常关键。一个失败的断言会计入错误率。

3.5 定时器与监听器：控制节奏与收集结果

定时器用于在请求之间插入停顿，模拟用户思考时间或控制请求速率。

• 固定定时器：在每个采样器后暂停固定的时间（如3000毫秒）。
• 高斯随机定时器：暂停一个随机时间，更符合真实用户行为。
• 同步定时器：用于制造瞬间的并发高峰。它可以阻塞一定数量的线程，直到达到指定的并发数，然后同时释放它们去执行下一个采样器。常用于模拟“秒杀”场景。

监听器用于收集和展示测试结果。注意：在正式执行高并发压测时，应禁用所有在GUI界面中的监听器（或使用最轻量的如“汇总报告”），因为它们会消耗大量测试机内存和CPU，影响测试结果准确性。我们通常将结果保存到文件，然后离线分析。

• 查看结果树：调试神器，可以查看每个请求和响应的详细信息。但压测时务必禁用。
• 聚合报告：提供所有请求的统计摘要，包括平均值、中位数、90%分位、TPS、错误率等。是核心的结果分析界面。
• 用表格查看结果：以表格形式实时显示每个样本的结果。
• Summary Report：与聚合报告类似，但格式略有不同。
• 后端监听器：可以将结果实时发送到时序数据库（如InfluxDB），然后配合Grafana展示漂亮的实时监控仪表盘，这是做专业压测的推荐做法。

4. 构建一个完整的Vue应用API压力测试实例

让我们以一个简化的电商Vue应用为例，构建一个完整的测试计划。核心业务流程是：用户登录 -> 浏览商品列表 -> 查看商品详情 -> 加入购物车 -> 下单。

4.1 第一步：环境准备与脚本录制/编写

1. 配置测试环境：确保你有一个独立于生产的测试环境，其服务器配置、数据库数据量应尽可能接近生产环境。准备好测试用的用户账号（至少5000个，存入CSV文件）和商品数据。

2. 录制或手动编写脚本：

• 方案A（录制）：在JMeter中配置“HTTP(S) 测试脚本录制器”，将浏览器代理设置为JMeter（如 localhost:8888），然后在Vue应用中手动操作一遍核心流程。JMeter会捕获所有HTTP请求。录制后，需要仔细清理脚本，移除无关的静态资源请求（.js, .css, 图片），只保留对后端API的调用，并参数化关键数据。
• 方案B（手动编写）：根据API文档，手动添加HTTP请求采样器。这种方式更清晰、可控，推荐在熟悉API后使用。

我们采用方案B，手动构建。

4.2 第二步：创建测试计划与线程组

1. 新建测试计划，命名为Vue_Ecommerce_Pressure_Test。
2. 添加线程组，命名为Main User Flow。
   • 线程数：5000
   • Ramp-Up时间：300 （5分钟内启动所有用户）
   • 循环次数：勾选“永远”
   • 调度器：勾选，设置持续时间：1200 （秒，即20分钟）

4.3 第三步：参数化与全局配置

1. 在测试计划下添加一个“CSV 数据文件设置”元件。
   • 文件名：指向你的user_credentials.csv文件（路径建议用绝对路径或相对于JMeter启动目录的相对路径）。
   • 变量名称：username,password,user_id（假设CSV文件有三列）。
   • 其他选项：忽略首行（如果CSV有标题头则选是），遇到文件结束符再次循环？选择true，这样当5000个线程用完CSV数据后，会从头开始分配。
2. 添加一个“HTTP信息头管理器”作为线程组的子元件，用于设置全局的HTTP头，比如Content-Type: application/json。

4.4 第四步：构建业务事务

在线程组下，我们按顺序添加逻辑控制器和采样器。

1. 登录事务（仅一次）：

• 添加一个“仅一次控制器”，命名为Login Once。
• 在其下添加一个“事务控制器”，命名为Login Transaction。
• 在事务控制器下，添加“HTTP请求”采样器。
  • 名称：API Login
  • 方法：POST
  • 路径：/api/auth/login
  • 消息体数据：{"username": "${username}", "password": "${password}"}
• 在登录请求后，添加“JSON提取器”。
  • 变量名称：access_token
  • JSON路径表达式：$.data.token（根据你的实际响应体结构调整）
• 再添加一个“响应断言”，验证响应码为200，并且响应文本中包含"success": true之类的成功标识。

2. 浏览商品列表（循环操作）：

• 添加一个“循环控制器”，循环次数设为5（模拟每个用户浏览5页商品）。
• 在循环控制器内，添加“HTTP请求”采样器。
  • 名称：Get Product List
  • 方法：GET
  • 路径：/api/products，并添加查询参数，如page=${__Random(1,10)}（随机看1-10页），pageSize=20。
• 添加一个“固定定时器”，延迟设为2000毫秒，模拟用户浏览列表的时间。

3. 查看商品详情（随机操作）：

• 这里我们需要一个商品ID列表。可以再准备一个product_ids.csv文件，用另一个“CSV数据文件设置”来读取，或者使用JMeter函数从某个范围随机选取。假设我们使用内联变量。
• 添加一个“如果（If）控制器”（需要配合“表达式”使用，确保JMeter版本支持）。
  • 条件：${__jexl3(${__Random(0,100)} < 30)}（模拟30%的概率会点进去看详情）。
• 在If控制器内，添加“HTTP请求”采样器。
  • 名称：Get Product Detail
  • 方法：GET
  • 路径：/api/products/${__Random(1000,2000)}（随机一个商品ID）。
• 添加一个“高斯随机定时器”，偏差1000毫秒，固定延迟偏移2000毫秒。

4. 加入购物车与下单（关键事务）：

• 添加一个“事务控制器”，命名为Add to Cart & Checkout。
• 首先，添加“HTTP请求”采样器（加入购物车）。
  • 名称：Add Item to Cart
  • 方法：POST
  • 路径：/api/cart/items
  • 消息体数据：{"productId": ${__Random(1000,2000)}, "quantity": ${__Random(1,3)}}
  • 注意：此请求的HTTP头需要添加Authorization: Bearer ${access_token}，从登录步骤提取的token。
• 添加“JSON提取器”，从加入购物车的响应中提取cart_id或order_sn（如果需要）。
• 然后，添加“HTTP请求”采样器（创建订单）。
  • 名称：Create Order
  • 方法：POST
  • 路径：/api/orders
  • 消息体数据：{"cartId": "${cart_id}", "addressId": 1}（地址ID可参数化）。
• 为这个事务控制器添加“响应断言”，确保两个步骤都成功。

4.5 第五步：添加监听器与运行配置

1. 在线程组层级，添加“聚合报告”和“用表格查看结果”监听器（用于调试和初步观察）。
2. 重要：为了正式压测，添加一个“Simple Data Writer”监听器（或使用“生成概要结果”到文件），将结果写入一个JTL文件（如result_20240527.jtl）。在“聚合报告”中也可以配置写入CSV文件。正式压测时，在GUI中禁用所有监听器，使用非GUI模式运行。
3. 保存测试计划为.jmx文件。

5. 执行压测与结果分析实战

5.1 执行压测：命令行模式是关键

在GUI界面点击运行，只适合调试和极低并发的测试。对于5000并发，必须使用命令行（非GUI）模式。

# 进入JMeter的bin目录 cd /path/to/apache-jmeter-5.6/bin # 运行测试计划，指定结果文件，并分配足够的JVM内存 jmeter -n -t /path/to/your/Vue_Ecommerce_Pressure_Test.jmx -l /path/to/results/result.jtl -e -o /path/to/report/output/folder -Jthreads=5000 -Jrampup=300 -Jduration=1200

参数解释：

• -n: 非GUI模式。
• -t: 指定测试计划文件。
• -l: 指定结果日志文件（JTL格式）。
• -e: 测试结束后生成HTML报告。
• -o: 指定HTML报告的输出目录（必须为空目录或不存在）。
• -J: 定义JMeter属性，可以在测试计划中通过${__P(threads)}引用，这样无需修改脚本即可灵活调整参数。

踩坑实录：高并发压测时，JMeter测试机本身可能成为瓶颈。务必监控测试机的资源（CPU、内存、网络、文件描述符数量）。Linux系统下，可能需要调整ulimit -n（打开文件数）和ulimit -u（用户进程数）。对于5000并发，建议测试机配置不低于4核8G，并使用多台机器进行分布式压测（JMeter支持分布式部署）。

5.2 结果分析：从数据到洞见

测试完成后，打开生成的HTML报告，或者将JTL文件导入JMeter GUI的“聚合报告”中查看。

1. 核心性能指标解读：

• TPS曲线：在整个测试期间，TPS是否平稳？在加压和减压阶段，TPS变化是否符合预期？如果TPS随着并发上升而达到一个平台后不再增长甚至下降，说明系统遇到了瓶颈。
• 响应时间曲线：平均响应时间和90%/95%分位响应时间是否在目标范围内（如1秒内）？响应时间是否随着并发增加而线性增长？突然的尖峰可能意味着GC（垃圾回收）或数据库锁。
• 错误率：是否低于目标（如0.1%）？错误主要集中在哪里个接口？是超时错误（如SocketTimeoutException）还是业务错误（如HTTP 500）？
• 吞吐量（Throughput）：单位时间内服务器处理的字节数，与网络带宽有关。

2. 关联服务器监控：孤立的JMeter数据意义有限。必须将压测时间线，与服务器的监控图表（如CPU、内存、磁盘IO、数据库连接数、慢查询日志）进行对照分析。

• 发现瓶颈：当TPS上不去而CPU使用率却很低时，瓶颈可能在I/O（磁盘或网络）或外部依赖（如数据库、缓存）。如果CPU使用率很高（如持续90%以上），则可能是应用代码或JVM本身存在性能问题。
• 数据库分析：检查压测期间数据库的活跃连接数、锁等待情况、慢SQL。很多时候，性能瓶颈的第一个迹象出现在数据库层。

3. 生成测试报告：一份专业的压力测试报告应包含：

• 测试目标与场景描述。
• 测试环境配置（服务器、网络、数据库规格）。
• 测试工具与脚本说明。
• 性能测试结果汇总（关键指标表格）。
• 性能趋势图（TPS、RT、错误率随时间变化图）。
• 服务器资源监控图。
• 性能瓶颈分析与定位。
• 结论与优化建议。

6. 常见问题、排查技巧与面试题映射

在实际操作中，你会遇到各种问题。下面是一些典型问题及其排查思路，它们也直接对应着常见的软件测试面试题。

6.1 JMeter本身报错或性能不佳

• 问题：java.net.BindException: Address already in use或java.net.SocketException: Too many open files。

• 排查：这是测试机本地端口耗尽或文件描述符不足。Linux下，临时提高限制：ulimit -n 65535。调整JMeter的client.tries和client.retry_delay属性（在jmeter.properties中）也可能有帮助。

• 面试题映射：“如何进行高并发压力测试？”—— 你需要谈到分布式压测、测试机资源调优。

• 问题：JMeter GUI运行高并发测试时卡死或无响应。

• 排查：永远不要用GUI模式进行正式压测。GUI模式消耗大量资源用于渲染。务必使用命令行非GUI模式。

• 面试题映射：“JMeter的GUI模式和非GUI模式有什么区别？”

6.2 被测系统相关错误

• 问题：大量请求返回HTTP 5xx错误（如500, 502, 503, 504）。

• 排查：

  1. 504 Gateway Timeout：通常是Nginx等代理服务器在等待应用服务器响应时超时。检查应用服务器（如Tomcat）的线程池是否已满、是否有死锁或长时间GC。
  2. 502 Bad Gateway：上游应用服务器进程崩溃或无响应。检查应用日志。
  3. 500 Internal Server Error：应用代码异常。查看应用服务器的错误日志，定位具体异常栈。

• 面试题映射：“压力测试中常见的HTTP错误码有哪些？可能是什么原因？”—— 这是一个经典的运维和测试结合的问题。

• 问题：TPS上不去，但服务器CPU和内存使用率都不高。

• 排查：

  1. 外部依赖瓶颈：检查数据库连接池是否耗尽、数据库CPU/IO是否饱和、Redis/MQ等中间件是否达到性能极限。使用慢查询日志、数据库监控工具。
  2. 应用配置限制：检查Web服务器（如Tomcat）的maxThreads连接数、数据库连接池的maxActive参数是否设置过低。
  3. 锁竞争：检查应用代码或数据库是否存在激烈的锁竞争（如 synchronized 关键字使用不当、数据库行锁/表锁）。

• 面试题映射：“如何定位性能瓶颈？”—— 你需要描述一个从外到内、从整体到局部的排查链条：网络 -> 负载均衡 -> 应用服务器（线程池、GC）-> 应用代码（Profiling工具）-> 数据库/缓存。

6.3 测试结果分析与调优建议

• 问题：响应时间随着测试时间推移逐渐变长。

• 排查：很可能是内存泄漏。监控应用服务器的堆内存使用情况，如果呈现“锯齿状”上升（每次GC后最低点越来越高），则基本可以确定。使用jmap,jstack或VisualVM等工具分析堆转储。

• 面试题映射：“如何分析JVM内存问题？”

• 问题：如何确定系统的最大承载能力？

• 方法：采用逐步增压测试。从低并发开始，逐步增加并发用户数，观察TPS和响应时间的变化。当TPS不再随着并发数增加而线性增长，且响应时间开始显著上升时，这个拐点对应的并发数，就可以认为是系统在当前配置下的一个最大承载参考值。同时，错误率不应超过可接受范围。

• 面试题映射：“什么是压力测试、负载测试、容量测试？”—— 你可以用这个实操案例来解释：负载测试是验证在预期负载下的性能表现；压力测试是超过预期负载，找到系统崩溃点；容量测试是确定系统能处理的最大负载量。

6.4 针对Vue（前端）的特殊考量

虽然JMeter不直接压测前端，但我们的测试设计必须考虑前端行为对后端的影响。

• API调用频率：Vue单页面应用可能在用户无感知的情况下频繁调用API（例如，输入框的实时搜索防抖、滚动加载更多）。在录制脚本时，要识别这些“隐性”请求，并决定是否需要在压力测试中模拟。过高的频率可能成为后端的不必要负担。
• WebSocket：如果Vue应用使用了WebSocket进行实时通信（如聊天、通知），JMeter本身支持有限。你需要使用额外的插件（如WebSocket Samplersby Peter Doornbosch）或考虑其他工具（如Gatling）来模拟这种长连接压力。
• 静态资源缓存：确保你的测试脚本不会重复请求不变的静态资源（如图标、字体），这可以通过配置HTTP请求默认值中的“从HTML文件获取所有内含资源”选项来管理，或者在测试计划中排除这些请求。

最后，把这次完整的压力测试实践，内化成你自己的经验。当面试官问你“如何对一個Web系统进行压力测试？”时，你就可以从容地从“需求分析与目标制定”、“测试策略与场景设计”、“工具选型与脚本开发（以JMeter为例）”、“测试执行与监控”、“结果分析与瓶颈定位”以及“报告编写与优化建议”这几个步骤来阐述，并且每一个步骤都能说出具体的实操细节和踩过的坑。这才是从“知道答案”到“拥有能力”的蜕变。