如何排查JMeter运行测试时与被测软件间的故障问题

第一步：优先确认JMeter自身配置正确性 #

• 核对采样器基础配置：重点检查请求协议、地址、端口、路径、请求方法、参数格式是否和接口要求完全一致，常见错误包括POST请求漏加Content-Type请求头、表单参数错写到请求体、路径拼写错误、HTTPS错写成HTTP。如果接口需要重定向，确认是否勾选了「跟随重定向」选项。
• 检查JMeter环境配置：确认是否配置了错误的全局代理导致请求未正常发出，本地hosts是否绑定了错误的被测服务IP，HTTPS接口是否已将服务端SSL证书导入JMeter信任证书库。
• 单请求调试验证：把线程组的线程数、循环次数都改为1，添加查看结果树监听器，运行后查看单请求的响应码、请求头/请求体、响应内容：
  • 4xx类响应码：属于请求端错误，404为请求路径不存在，401/403为权限校验失败，400为请求参数格式错误
  • 5xx类响应码：属于服务端错误，请求已经正常发到被测服务，是服务端处理出错
  • 连接超时/连接拒绝：请求根本没到达被测服务，属于网络或端口连通性问题

第二步：排除网络与被测服务基础可用性问题 #

• 脱离JMeter验证接口可用性：用Postman、curl等工具发送和JMeter完全一致的请求，检查是否能正常返回。如果其他工具也报错，说明问题和JMeter无关，是被测服务本身或网络链路问题；如果其他工具正常，100%是JMeter配置错误，回到第一步逐一核对配置项。
• 验证网络连通性：用ping 被测服务IP检查网络是否可达，用telnet 被测服务IP 端口或nc -zv 被测服务IP 端口检查服务端口是否开放、是否被防火墙拦截。

第三步：排除压测场景配置不合理问题 #

如果低并发请求正常，高并发时才出现100%错误率，按以下方向排查：

• 确认被测服务是否被压垮：检查服务端的CPU、内存、磁盘IO、网络带宽使用率，是否有资源耗尽的情况。
• 确认JMeter本机是否有性能瓶颈：高并发场景下如果JMeter部署在单台机器上，可能出现本机端口耗尽、出口带宽打满的情况，导致请求无法正常发出，可以调整JMeter的JVM堆内存参数，或改用分布式压测集群分摊压力。
• 确认是否完成参数关联与参数化：如果接口需要登录态、动态验证码等随请求变化的参数，直接用固定值并发请求会被服务端安全策略拦截；如果提交的业务参数重复，也可能被服务端去重规则拦截，需要对应做动态参数提取关联、业务参数参数化处理。

第四步：日志定位根因 #

• 查看JMeter日志：打开jmeter安装目录下的jmeter.log文件，查看是否有证书错误、请求解析错误、连接异常等具体报错信息。
• 查看被测服务日志：检查服务端的访问日志、错误日志，确认请求是否到达服务端，以及服务端处理报错的具体原因。

内容的提问来源于stack exchange，提问作者Jorge Edrian