并发测试工具如何测试并发访问 - 电脑手机工具软件下载 - 免费实用工具合集

本文目录导读：

核心步骤概览以 JMeter 为例的详细操作流程除了 JMeter 的其他方案（根据场景选择）必须注意的坑与最佳实践并发测试工具的核心原理是模拟多个用户（或客户端）同时向目标系统发送请求，以观测系统在高负载下的性能表现（如吞吐量、响应时间、错误率）和稳定性。

下面以最流行的开源工具 Apache JMeter 为例，详细说明如何进行并发访问测试，其他工具（如 Locust、Gatling、wrk）逻辑类似。

核心步骤概览

设计测试场景：明确你要模拟什么用户行为（登录、搜索、下单？）。

配置线程组：这是“并发”的核心，设置有多少个“虚拟用户”同时干活。

添加取样器：定义虚拟用户具体要发什么请求（HTTP请求、JDBC请求等）。

添加监听器：收集并展示测试结果。

运行并分析：启动测试，观察系统反应。

以 JMeter 为例的详细操作流程

假设你要测试一个电商网站的商品搜索接口 https://api.example.com/search?q=手机。

创建测试计划

打开 JMeter，右键点击 “测试计划” -> 添加 -> Threads (Users) -> 线程组。

配置线程组（设置并发量）

这是最关键的步骤,你需要在这里定义“并发”的模型。

线程数：虚拟用户的数量，设置为 100，就代表同时有 100 个用户。

Ramp-Up Period (秒)：爬坡时间，设置为 10，代表 10 秒内启动 100 个用户（每秒启动 10 个）。不建议设为 0（瞬间全部启动），除非你真的需要模拟“闪电崩溃”。

循环次数：每个用户执行多少次请求，设置为 10，代表 100 个用户每人执行 10 次，共 1000 次请求。

调度器：可以设置测试持续时长，如运行 60 秒。

典型并发测试场景配置：

恒定负载：线程数=200，Ramp-Up=20，循环次数=无限，调度器时长=300秒，模拟 200 用户持续压测 5 分钟。

阶梯加压：使用“步进线程组”（jp@gc - Stepping Thread Group 插件），每 10 秒增加 20 个用户，直到达到 200，用于观察系统在哪个并发量开始崩溃。

突发测试：线程数=500，Ramp-Up=5，模拟 5 秒内突然涌入 500 人，看系统是否扛得住。

添加 HTTP 请求默认值（可选但推荐）

右键点击线程组 -> 添加 -> 配置元件 -> HTTP 请求默认值。

填写服务器 IP 或域名（api.example.com）、端口（443）、协议（https），这样所有请求都无需重复填写。

添加实际请求（取样器）

右键点击线程组 -> 添加 -> 取样器 -> HTTP 请求。

方法：GET

路径：/search

Parameters：添加参数 q，值为 手机。

添加监听器（看结果）

右键点击线程组 -> 添加 -> 监听器，最常用的几个：

查看结果树：调试用，可以看到每个请求的请求头、响应数据（比如返回的 JSON），高并发测试时务必关掉，否则会消耗大量内存导致测试结果不准。

聚合报告：核心报告，显示：

#Samples：总请求数。

Average：平均响应时间（ms）。

90% Line / 95% Line / 99% Line：最重要，表示 90%/95%/99% 的请求在多少毫秒内完成，反映了“体感”上的性能。

Throughput：吞吐量（每秒请求数，TPS），系统处理能力的核心指标。

Error%：错误率，超过0%通常表示有问题，超过1%需严重关注。

图形结果 / 用表格查看结果：可视化监控。

运行测试

点击绿色“启动”按钮。

除了 JMeter 的其他方案（根据场景选择）

工具

特点

适合场景

JMeter

功能全面，图形化，支持多种协议（HTTP、JDBC、FTP等）。

复杂业务流程（如登录->加购->下单）、非开发人员使用、企业级全链路压测。

Locust

基于 Python 编写，代码即脚本，灵活性极高，内置 Web UI。

开发团队、需要复杂逻辑（如动态关联、异步任务）的压测。

wrk

命令行工具，基于 C 语言，性能极高，占用系统资源极低。

简单 HTTP API 的高并发压力测试、基准测试（Benchmark）。

k6

脚本式（JavaScript），作为开源工具可集成到 CI/CD 流水线中。

DevOps 团队、性能即代码、自动化回归测试。

Gatling

基于 Scala/Java，Akka 架构，代码可读性好，生成 HTML 报告精美。

注重代码质量和报告美观度的开发团队。

必须注意的坑与最佳实践

不要在 GUI 模式下进行高并发测试！

JMeter 是 Java 写的，GUI 模式会消耗大量内存，高并发测试（如 >100 线程）应使用命令行模式：# 无GUI运行，参数：-n 非GUI, -t 脚本路径, -l 结果文件

jmeter -n -t MyTestPlan.jmx -l results.jtl -e -o /report

生成的 report 文件夹里就是漂亮的 HTML 报告。

确保客户端资源充足

瓶颈可能在测试机本身，如果你的电脑是 8G 内存，开 1000 个线程，JMeter 自己可能会卡死或报 OutOfMemoryError。

此时需要分布式压测：1 台 Master + N 台 Slave（Agent），分散压力。

使用关联和数据参数化

不要所有用户都搜索“手机”，使用 CSV Data Set Config 或函数助手 _RandomString 生成不同的商品名，模拟真实用户输入。

对于需要登录的系统,使用 正则表达式提取器 或 JSON 提取器 从登录响应中提取 token/cookie，并应用到后续请求中。

观察监控指标

不要只看响应时间，当系统扛不住时，响应时间会突然飙升（拐点），TPS 不再增长甚至下降，错误率开始出现。

需要同时看服务器端监控：CPU 使用率、内存、磁盘 I/O、网络、数据库连接数，CPU 已经 100%，那问题在服务器算力不够；CPU 只有 30% 但响应慢，那可能是代码锁等待或数据库慢查询。

确定“用户并发” vs “并发请求”

用户并发：如 100 个用户同时点击“登录”，每个用户发 1 个请求，并发请求数为 100。

并发连接数：HTTP 协议中，一个用户可能同时发送多个请求（如网页加载多个资源），这是更底层的东西，通常用 wrk 测试。

一个硬核的并发测试流程应该是：

明确目标：要求系统能支持 1000 用户同时在线，核心接口响应时间 < 200ms，TPS > 500。

脚本开发：用 JMeter/Locust 编写业务脚本，并做好参数化、关联和断言。

试运行：用少量用户（如 10 个）跑一次，检查脚本逻辑是否正确，结果树里数据是对的。

阶梯加压：从低到高逐步增加并发量（如 50->100->200->400），每次都观察TPS 和响应时间的拐点。

定位瓶颈：当 TPS 不增长或响应时间飙升时，联合运维人员一起查看服务器 CPU、内存、DB 慢查询、网络带宽等，找到根本原因。

优化与复测：开发修复代码或调整配置后，重新跑相同的测试用例，验证优化效果。

一句话总结：使用线程数模拟并发用户数，通过 Ramp-Up 时间控制爬坡速率，关注 TPS、90% 响应时间和错误率这三驾马车，并时刻警惕测试机成为瓶颈。

标签： Locust

本文地址：

https://lianqi.tech/post/485.html

版权声明：除非特别标注，否则均为本站原创文章，转载时请以链接形式注明文章出处。