聊性能测试选型，JMeter和阿里云PTS是绕不开的两个名字。一个是从开源社区成长起来的老牌压测工具，几乎成了接口压测的代名词，另一个是云原生时代的全托管压测服务，近几年在容量评估、大促压测里出镜率非常高。很多团队在这两个工具之间来回纠结，始终没想清楚到底该用哪个，或者说，两个都用了，却没捋清各自的边界。
这篇横评我会从安装配置、脚本编写、压测执行、结果分析到成本代价，把两个工具完整捋一遍，顺带把大家在搜索时高频遇到的JMeter安装、JDK环境配置、HTTPS证书、并发数估算、参数化、上传文件、断言、响应体格式化这些问题一并讲透。内容适合刚入行的测试同学，也适合手里压测机资源吃紧、想评估云压测方案的团队参考。
1. 这篇横评想聊点什么：工具对比的底层逻辑
1.1 从搜索热词看大家的真实困惑
你去搜JMeter相关的关键词，会发现一个很有意思的现象：搜“jmeter下载”“jmeter安装教程”“jmeter设置中文”“jmeter压测简单步骤”的人特别多。这说明大部分人其实不是被某个高级功能卡住，而是卡在最基础的地方——工具都还没顺利跑起来，更不要说完成一轮完整压测了。
再往深看，还有一批关键词明显属于进阶场景：“压测怎么确认系统的并发数”“jmeter上传文件”“jmeter接口测试性能测试实战”“jmeter md5加密”“jmeter提取身份证的生日”“jmeter人脸识别系统压力测试”。这些词的背后，是具体业务场景对压测工具提出了定制化要求，比如上传图片做AI识别服务的并发验证、登录接口做签名加密、从接口响应中提取动态参数做上下游关联。
把这些关键词串起来，其实就是一条非常清晰的JMeter学习路径：先把工具装好跑通，再做简单请求压测，然后处理参数化、关联、断言等复杂度，最后才能面对真实业务场景。而阿里云PTS的搜索词相对少，更多是“PTS压测”这类，侧面反映它是被当作一个整体解决方案来用的，而不是需要一行行调的工具。这也是我在全文里想反复强调的一个底层差异：JMeter给你的是无限灵活性，PTS给你的是数据中心里的流水线。
1.2 对比框架：开源本地派 vs 云上托管派
这次横评我不打算做成“参数列表PK”，而是想先建立一条对比主线。JMeter属于“开源本地派”，核心特征是：免费、插件生态丰富、脚本完全可控，但从压测机准备到结果分析，所有环节都得自己负责。你的压测机就是自己那台电脑或几台服务器，压测过程中CPU、内存、带宽都是共享的，一不小心压测结果就被本机资源干扰了。
阿里云PTS则属于“云上托管派”，思路完全不同：你把压测脚本传上去，平台帮你分配施压资源，流量从云端产生，压测完自动输出报告和瓶颈诊断。它更像一条流水线，把压测这个事“工程化”了，你不需要关心压测机从哪里来、IP够不够用、带宽会不会打满。
这个差异决定了所有后续对比。比如脚本编写，JMeter细节非常多，CSV参数化、正则提取器、JSR223脚本都是必学项；PTS支持直接导入JMX脚本，又把很多JMeter脚本里的“体力活”进一步封装了。再比如结果分析，JMeter给你一堆监听器，聚合报告、图形结果，怎么看全靠经验；PTS则直接告诉你瓶颈可能在CPU、内存还是数据库慢查询。理解了这个底层逻辑，你再看后面的实操细节，就不会觉得是两个工具在PK，而是两种思路在不同层面的取舍。
2. 先把手上的JMeter跑起来：安装、配置与首个请求
2.1 环境与安装：JDK版本、目录、启动命令
先解决最前置的一步。JMeter是纯Java应用，安装前必须确认JDK环境。JMeter 5.x要求JDK 8以上，如果你用的是较新版本，比如JMeter 5.5及以上，建议直接上JDK 11或17，老版本JDK 8在高并发压测下内存管理会吃点亏，GC停顿会更明显。
Windows下配置JDK，核心就三个环境变量：JAVA_HOME指向JDK根目录，PATH里加%JAVA_HOME%\bin，再确认java -version能正常输出版本信息。很多人装完Java不配JAVA_HOME，直接双击JMeter的bat启动，大概率闪退或报找不到主类，原因就在这里。Linux和macOS下同理，用export JAVA_HOME=/path/to/jdk设置即可。
JDK弄好后，从官网下载apache-jmeter压缩包，解压到固定目录，我一般放在/opt/jmeter或D:\tools\jmeter这种不含空格和中文的路径下，避免后续脚本引用路径时出幺蛾子。启动方式很简单，Windows下运行bin/jmeter.bat，macOS/Linux下运行bin/jmeter.sh。如果你在命令行输入jmeter提示找不到命令，那是没配置环境变量，不配置也行，直接进bin目录运行脚本就好，更省事。
这里有个实操细节：首次启动时弹出的黑色命令行窗口千万别关，那是JMeter运行时的日志窗口，关闭后图形界面也会跟着退出。很多人第一次跑起来，随手把那个黑窗关了，结果整个工具都没了，还以为是软件崩溃。
2.2 中文界面与基础配置：一次改完，后顾无忧
JMeter默认是英文界面，对英文不熟练的人确实影响效率。设置中文很简单：打开bin/jmeter.properties，找到这一行：
#language=en改成：
language=zh_CN保存后重启JMeter，界面就变中文了。注意不要直接在图形界面里的“Options”菜单切换语言，那个只对当前会话有效，下次启动又变回英文。
同一个配置文件里，还有两个参数我建议顺手改掉。一个是堆内存设置，找到HEAP，默认值是-Xms1g -Xmx1g，本地做几万请求的小压测还够，但线程数一旦拉高，很容易OOM（内存溢出）。我一般改成-Xms1g -Xmx4g，具体调多大看压测机内存，总内存8G的机器分4G给JMeter比较合理，再多就容易影响操作系统自身运行。
另一个是mode=Standard，这个不用改，但如果你在压测时发现结果统计延迟很大，可以把监听器模式改掉，后面CLI一节会细说。
2.3 HTTPS录制与证书信任：为什么录不上脚本
JMeter早期最常用的脚本生成方式就是录制。做法是：测试计划下添加线程组，线程组下添加“HTTP代理服务器”，把代理端口设为8888，然后让浏览器或手机的流量指向这台代理，操作一遍业务流程，JMeter就把请求全录下来了。
这个方案到现在依然有效，但HTTPS场景下大多数人会卡在证书环节。你访问HTTPS网站时，浏览器会警告证书不受信任，此时需要先运行JMeter的bin/ApacheJMeterTemporaryRootCA.crt导出证书，然后把证书导入操作系统的“受信任的根证书颁发机构”中，浏览器才不再拦截。
实操经验是：录制适合快速抓取请求，但录完的脚本通常不能直接用于压测。一是因为录制会把静态资源（图片、CSS、JS）全部录进来，这些请求会干扰你对关键接口的观察，建议删除或过滤掉；二是录制的动态参数没有关联，比如登录返回的token，后续接口拿着旧token去请求，必然报错。所以我现在的习惯是：用浏览器F12手动抓包，然后手动构建HTTP请求，比录制再优化脚本要高效得多，也更可控。
2.4 脚本调试三板斧：查看结果树、正则提取器、JSR223加密
脚本写好后，第一件事不是直接拉高并发，而是先跑通单个请求。查看结果树监听器是调试阶段最常用的工具，它能展示每个请求的请求体、响应体。新版JMeter里，JSON格式的响应体可以直接格式化查看，这就是很多人搜“请求体响应体json格式化”时在找的功能。遇到复杂JSON，我还会用JSON路径提取器去验证某个字段是否取到值，比肉眼从一堆字符串里找可靠得多。
第二个高频需求是正则提取器。比如从登录接口的响应里提取token，供下一个接口使用，这属于“关联”的范畴。做法是在登录请求上添加“后置处理器 -> 正则表达式提取器”，填写响应字段、正则表达式和模板。举个例子，如果响应是{"data":{"birth":"19950115"}}，想提取生日，正则写"birth":"([^"]+)"就够。如果你想从身份证号里提取生日，正则就是\d{6}(\d{8})\d{4}，模板填$1$，就能把中间8位生日取出来。很多人搜“jmeter提取身份证的生日”，本质就是在做这类关联。
第三个高频需求是签名参数。很多接口为了防篡改，会把请求参数做MD5加密后拼在报文里。JMeter里用JSR223前置处理器配合Groovy脚本就能实现，举个例子：
import java.security.MessageDigest; String raw = vars.get("param") + "固定Salt"; MessageDigest md = MessageDigest.getInstance("MD5"); byte[] digest = md.digest(raw.getBytes("UTF-8")); StringBuilder sb = new StringBuilder(); digest.each { b -> sb.append(String.format("%02x", b)) } vars.put("sign", sb.toString());写完脚本后用查看结果树验证，sign参数是否与接口要求的加密结果一致。如果一致，说明前置处理器生效，后续压测环境里所有请求都会自动带上正确的签名。
3. 把JMeter玩到“能压测”：线程组、参数化与结果分析
3.1 并发数怎么算：从业务目标到线程组参数
我见过太多人做压测时，线程数直接拍脑袋填个500、1000，然后压完发现系统早就崩了，却说不清这个并发数到底代表什么业务场景。并发数的确定，至少应该走一条可推导的路径。
最常用的方法是结合目标TPS和平均响应时间推导，公式很简单：并发数 = 目标TPS × 平均响应时间（秒）。举个例子，某登录接口目标是支撑每秒300次登录请求，平时压测测得平均响应时间是0.5秒，那并发数理论值就是300 × 0.5 = 150。这背后的逻辑是Little's Law，不展开数学推导，但你可以这么理解：每个请求在服务器上停留约0.5秒，期间要维持每秒300个请求完成，系统里就必须同时存在约150个正在处理的请求。
另一种常见方法是从在线用户数推断。比如业务高峰期在线用户是1万人，平均每个用户每分钟操作2次接口，那每秒请求数就是10000 × 2 / 60 ≈ 333，再结合响应时间换算成并发数。这种方法更适合业务指标已知、还没开始压测的阶段。
有了目标并发数后，在线程组里怎么填参数也要讲究。线程数填并发数，Ramp-Up Period（启动时间）不能填0或1，否则所有线程瞬间并发，相当于模拟了一次“突然袭击”，压力曲线不符合真实流量爬坡过程。我习惯设置Ramp-Up为线程数除以10，也就是每秒增加10个并发，这样既能观察系统在缓慢加压过程中的表现，也能记录吞吐量和响应时间的变化拐点。
3.2 参数化与文件上传：模拟真实用户的必经之路
真正做压测时，每个请求都用同一份数据是很大问题。比如压测登录接口，100个并发全是同一个账号发请求，服务器可能命中了缓存或鉴权逻辑，结果虚高，完全不能反映真实情况。解决办法是参数化，让每个线程或每次请求用不同的数据。
最常用的参数化工具是CSV数据文件配置元件。操作步骤：先准备一个CSV文件，里面放好一批账号密码，比如user1,pass1，一行一个用户，然后在“配置元件 -> CSV Data Set Config”中指定文件路径、变量名（比如u和p），最后在HTTP请求的参数里引用${u}和${p}即可。CSV组件还有一个重要选项：线程间共享模式，控制每个线程是拿一行数据还是所有线程轮流拿，设置不当会导致数据重复或越界。
文件上传场景也属于参数化的变种，典型如人脸识别服务的压力测试——压测时每张图片都是独立样本，如果所有并发请求都上传同一张图片，接口缓存命中率会很高，压出来的结果没有参考价值。JMeter里的实现方式是在HTTP请求的Files Upload区域，添加文件路径、参数名称和MIME类型。图片选MIMEimage/jpeg，文件参数名要与服务端约定一致，否则请求发出去服务端解析不到文件。更接近真实业务的做法是准备一个图片目录，用${__CSVRead}或Groovy随机选一张图片路径，把文件路径参数化。
3.3 断言、监听器与报告解读：别拿错误率当摆设
很多新手跑完压测，只盯着聚合报告里的Throughput，看到数字高就以为系统很稳，这是很危险的。没有断言保护的压测，相当于考试没有标准答案，只要请求返回了就算“成功”，哪怕服务端其实返回了一个错误码或一段异常页面。
JMete的断言组件里，最常用的是“响应断言”，可以匹配响应文本中是否包含特定字符串、响应码是否等于200。另一个是JSON断言，适合直接校验JSON某字段值，比如校验code==0。还有Duration断言，判断响应时间是否超过阈值，比如超过3秒即算失败。正式压测前，一定要用几个已知的正确和错误样例把断言验证一下，确保障碍能被准确捕获。
监听器方面，最实用的是聚合报告。里面的关键字段包括：Samples（样本数）、Average（平均响应时间）、Error%（错误率）、Throughput（吞吐量，接近TPS）。判断系统瓶颈时，我一般看三样东西：错误率是否随并发上升突然抬高、平均响应时间和P99响应时间是否出现拐点、吞吐量是否在某一并发后不再增长甚至下降。这三者同时出现，基本可以断定系统达到了性能极限。
3.4 从图形到报告：结果该怎么解释
JMeter自带的图形监听器，比如图形结果、响应时间图，在调试阶段看看可以，正式压测报告里用它们反而显得业余。我更推荐直接在压测结束后使用CLI模式生成HTML报告，包含吞吐量趋势、响应时间分布、错误率等，图表完善，可以直接作为团队内部汇报材料。
需要提醒的是，聚合报告的Throughput单位是“请求/秒”，但JMeter里还可以设置成“请求/分钟”或“请求/小时”，如果你习惯了读秒级TPS，记得把这里的单位确认好，否则容易误读成“性能很差”。还有一个经常让新手困惑的点：同一轮压测，聚合报告里的平均响应时间和查看结果树里的某个请求耗时对不上，这不代表数据有问题，查看结果树是单个请求的明细，聚合报告是全部样本的统计汇总，两者本来就不是一个粒度的数据。
4. 再进一步：命令行压测与分布式部署
4.1 用CLI替代GUI压测：为什么正式压测不能用图形界面
我知道很多人图省事，直接在JMeter图形界面里点击“启动”，拉高并发跑完了事。但在并发数比较高的压测里，这种方式很容易让结果失真。原因是GUI本身会占用大量CPU和内存，你一边压测一边渲染图形，相当于压测工具自己也在和服务器抢资源。更关键的是，GUI模式下的监听器要实时刷新数据，会产生大量IO，进一步拖累压测机性能，最终压出来的TPS可能是压测机瓶颈而不是服务端瓶颈。
正确的做法是用命令行模式执行压测。命令格式如下：
jmeter -n -t /path/to/test.jmx -l /path/to/result.jtl -e -o /path/to/report参数含义：-n表示非GUI模式，-t指定测试计划文件，-l指定原始结果文件，-e和-o表示压测结束后生成HTML报告并输出到指定目录。跑完后，直接用浏览器打开/path/to/report/index.html就能看到完整报告。
CLI模式还方便做参数传值。脚本里用${__P(threads,100)}定义一个默认100的并发参数，压测时用-Jthreads=500覆盖，这样同一份jmx文件可以灵活设定不同并发，不用多份脚本。我经常在Jenkins里做定时压测，把JMeter的CLI命令封装成脚本，每次构建后自动执行并归档HTML报告，这样性能回归就成了日常自动化的一部分。
4.2 分布式压测的配置与局限
当单机压测机的资源撑不住目标并发时，很多人会想到JMeter的分布式模式。原理很简单：一台Master负责调度，多台Slave负责实际施压，最后Master汇总所有Slave的数据。
配置上，先在每台Slave上运行bin/jmeter-server，然后在Master的bin/jmeter.properties里配置remote_hosts=slave1_ip:1099,slave2_ip:1099，最后用jmeter -n -t script.jmx -R slave1_ip,slave2_ip发起分布式压测。注意所有机器的JMeter和JDK版本要一致，脚本用到的CSV文件、JAR包也要同步到每台机器，否则会报各种找不到文件的错误。
但分布式压测的坑不少。一是网络带宽，几台机器如果放在同一个机房，出口带宽可能成为新的瓶颈，整个压测看起来像是并发上去了，实际请求根本没有到达目标服务端。二是跨地域的时延，Master和Slave在不同地区时，同步时钟、汇总数据都可能出现偏差。三是资源调度，每次压测前检查所有Slave的CPU和内存是不是已经被占满，不清理就复用，压测数据会很难看。所以我的经验是：本地分布式压测适合几百到几千并发的场景，真要做万级以上的并发，还是建议用云压测方案，因为它们就是把分布式压测这件事托管运维了。
5. 云上方案：阿里云PTS在补什么短板
5.1 团队从JMeter转向PTS的典型场景
我接触到的一些团队，一开始都用JMeter自建压测，到后面不可避免会遇到三个痛点。第一个是压测机资源不够。本地压测机跑5000并发时，经常是压测机CPU先100%，服务端还远没到瓶颈，你根本分不清是压不动还是没到顶。第二个是带宽和IP受限。内网压测只能模拟内网访问，无法真实反映公网用户从不同地域发起请求的路径，会低估CDN、网络链路对响应时间的影响。第三个是报告能力薄弱。JMeter的HTML报告功能是够用的，但要拿到一份“服务端到底哪里慢了”的诊断报告，还得自己接监控、拉指标、看GC日志，整体链路很长。
大促压测是另一个典型场景。比如电商平台做全链路压测，目标并发可能是几十万甚至上百万，这个量级不是靠堆几台压测机就能解决的，需要的是流量调度、施压地域分布、全链路监控、限流降级联动等一系列工程能力。这些已经远远超出了JMeter本身能解决的问题范围，阿里云PTS这类云压测服务正是为这些场景设计的。
5.2 PTS的压测流程与核心能力
PTS的使用流程整体比自建JMeter要“短”很多。在控制台创建一个压测场景，然后做两件事：要么直接上传JMeter的JMX脚本，要么在场景编辑器里配置接口和施压参数。对于已经有JMeter脚本资产的团队，我强烈建议直接上传JMX，因为PTS原生兼容JMeter脚本，CSV参数化文件、正则提取器、断言这些组件都能识别，几乎不用改就能直接在云端执行。
施压参数的配置上，PTS支持按并发数直接设置，也支持阶梯递增、持续时间等策略，可以模拟真实流量的爬坡过程。压测开始后，实时监控面板能看到TPS、响应时间、错误率等指标，同时能绑定云监控中的后端指标，比如CPU、内存、数据库连接数，把客户端指标和服务端指标放在同一个时间轴上对比，定位瓶颈会快很多。
压测结束后，PTS会自动生成报告，除了常见的吞吐量、响应时间统计外，还会基于压测数据给出瓶颈分析，比如CPU使用率过高、数据库慢SQL、GC频率上升等。这种“一键定位”的能力，自建JMeter要做出来，至少得额外搭一套监控告警系统，调试成本不低。
5.3 一张表看懂JMeter和PTS怎么选
为了便于对比，我把两者在不同维度上的差异整理成了一张表。这张表的结论不是“谁更好”，而是“谁更适合什么场景”。
| 对比维度 | JMeter | 阿里云PTS |
|---|---|---|
| 部署方式 | 本地安装，完全自建 | 云上全托管，控制台操作 |
| 成本结构 | 免费开源，但需自备压测机和运维人力 | 按量计费，无需关心基础设施 |
| 并发上限 | 视压测机资源而定，可分布式扩展，万级以上运维成本陡增 | 百万级并发，云端调度流量 |
| 脚本开发 | 灵活性强，插件生态丰富，但学习曲线较陡 | 支持JMX原生脚本导入，也支持场景化配置 |
| 压力来源 | 本地IP或自建压测机IP，模拟公网场景较困难 | 多地域公网流量，更贴近真实用户分布 |
| 结果分析 | 聚合报告与HTML报告，需要自己结合服务端指标定位 | 自动生成报告，提供瓶颈诊断建议 |
| 适用场景 | 接口功能验证、中小规模压测、脚本调试 | 大促容量评估、全链路压测、规模化压测 |
选型时我的建议也很简单：如果你处于学习阶段或日常中小规模压测，JMeter完全够用，而且它培养的是理解压测底层逻辑的能力，这个能力换到任何工具都不会过时。如果你的目标是快速回答“系统能不能扛住这次活动流量”，或者需要在短时间内做大量并发验证，PTS更省心，因为它把压测过程中最琐碎的部分——压测机、网络、报告——都替你管好了。
还有一个实际的做法是组合使用：JMeter负责脚本开发和调试，毕竟控制台可视化配置再怎么方便，复杂脚本的灵活性还是比不上JMeter里一行行组件搭出来的结果；开发好的JMX脚本直接上传到PTS执行大规模压测。这套流程很多团队都在用，兼顾灵活性和工程效率。
5.4 云压测使用中的几个注意点
用PTS这类云压测服务，有几点经验值得提醒。第一，压测数据的合规性要先想清楚。做登录业务压测时，脚本里的CSV文件往往包含了真实用户手机号、身份证信息，上传到云端前一定要脱敏处理，或者改用造数工具生成虚拟数据。之前见过团队把生产环境的账号数据直接传到压测脚本里，事后才意识到隐私风险，处理起来很麻烦。
第二，公网压测对目标系统的影响要提前评估。PTS的流量来自多个地域的公网出口，如果目标系统没有做可靠的限流降级，压测很容易误伤同集群里的其他业务。稳妥的做法是先小并发试压，确认服务端监控指标响应正常后再放开压力。
第三，云端压测的成本和本地压测不同。本地压测的边际成本集中在压测机和维护人力，云端压测则是按量计费，并发高、时间长，费用也会线性增加。大促前的容量验证建议集中压测，日常小规模回归用本地JMeter就足够，没必要每次都上云。
6. 高频问题速查与个人踩坑记录
6.1 JMeter使用中的高频问题速查
结合平时收到的提问，我把JMeter相关的高频问题整理成了一张速查表，方便遇到问题时直接对号入座。
| 高频问题 | 常见原因 | 解决思路 |
|---|---|---|
| JMeter启动时闪退或无响应 | JDK未安装或版本不兼容，JAVA_HOME未配置 | 先确认java -version正常，重新配置JDK环境变量 |
| HTTPS录制脚本失败 | 浏览器未信任JMeter根证书 | 双击ApacheJMeterTemporaryRootCA.crt并导入受信任根证书 |
| jtl结果文件已存在时弹窗 | resultcollector.action_if_file_exists触发 | 压测前清理旧结果文件，或用时间戳命名输出文件 |
| 聚合报告TPS很低 | 压测机CPU、内存或带宽达到上限 | 检查压测机资源，关闭GUI改用CLI模式，必要时分布式执行 |
| 上传文件接口返回失败 | MIME类型或文件参数名与服务端约定不一致 | 核对接口文档中的参数名与Content-Type，用查看结果树定位具体错误 |
| 脚本内存溢出（OOM） | HEAP默认过小 | 修改bin/jmeter中的-Xmx参数，推荐1g~4g |
| 参数化数据读取不到 | CSV路径错误或编码问题 | CSV文件使用UTF-8编码，路径用绝对路径，确认变量名引用正确 |
| 响应体JSON无法解析 | 响应非标准JSON或字符编码问题 | 查看原始响应体，确认编码格式，必要时加HTTP头管理器指定Content-Type |
这个表里特别想说一下“弹窗问题”，也就是resultcollector.action_if_file_exists。JMeter在非GUI模式下如果输出文件已经存在，默认会弹一个交互窗口询问是否覆盖，这在自动化脚本里会直接卡住任务，看起来就像是压测挂起了。解决办法很简单，要么每次压测前删除旧的jtl文件，要么在输出文件名里加上时间戳变量，比如result_${__time(yyyyMMddHHmmss)}.jtl，一劳永逸。
6.2 我在压测里反复踩过的坑
第一，压测前没有先做小并发预热。很多人直接把并发拉到目标值，压完发现前几分钟数据波动极大，根本不能说明问题。正确做法是先小并发（比如10个线程）跑一遍，确认脚本、断言、参数化都正常，再逐步加压。预热过程至少持续几分钟，让服务端缓存、连接池等组件完成初始化，后面压出来的数据才稳定。
第二，只看客户端指标，忽略服务端状态。JMeter能告诉你“响应时间升高了、错误率涨了”，但它不能告诉你“为什么”。定位瓶颈一定需要服务端视角，至少要看目标机器的CPU、内存、磁盘IO、GC日志，有条件还要看数据库连接池和慢SQL。我见过T队压测时TPS突然掉了，查了半天是压测机网卡被打满，而服务端其实很健康，这种乌龙如果早点看服务端监控就能快速排除。
第三，压测时间太短。很多人为了赶时间，压测只跑一两分钟就收工。短时间压测在服务端有缓存预热、连接池建立等前期波动时，根本没有进入稳定状态，数据是不可信的。常规建议压测时长至少5到10分钟，观察稳定期曲线。如果是稳定性测试，最少压半小时以上。
第四，压测数据没有脱敏就到处传。这个在云压测里尤其要注意，CSV文件里的手机号、身份证号、人脸图片等敏感数据，一定要做脱敏或使用合成数据。特别是人脸识别系统这类涉及生物特征信息的业务，压测数据的安全合规要求更高，不能在这一点上掉链子。
第五，JMeter脚本在GUI和CLI模式下表现不一致。有时候GUI跑通了，CLI却报错，大概率是路径问题。GUI模式下相对路径还可以解析，CLI模式下脚本引用的CSV文件路径很可能会失效。所以我建议脚本里所有外部文件路径都写成绝对路径，并且把依赖文件放到JMeter的bin目录或统一目录下，降低这类问题出现的概率。
说实话，工具横评写到这，我最大的体会是：JMeter和阿里云PTS不是替代关系，而是互补关系。JMeter帮你把压测这件事的底层逻辑练扎实——并发模型怎么设计、参数怎么关联、结果怎么分析，这些基本功在任何工具上都能复用。PTS则帮你把手动运维的琐碎事接管过去，让你把更多精力放在业务容量评估本身。我目前的习惯是：日常接口验证和中小规模压测直接在本地JMeter搞定，一旦需要做容量评估或者给团队一个确定的性能结论，就把调试好的JMX脚本导入PTS，压一轮云上全链路。工具终究是手段，关键是你在哪个阶段适合用哪种手段，以及手里的脚本能不能在关键时候平滑地迁过去。
