并发测试工具如何测试并发访问

本文目录导读：

1. 核心步骤概览
2. 以 JMeter 为例的详细操作流程
3. 除了 JMeter 的其他方案（根据场景选择）
4. 必须注意的坑与最佳实践

并发测试工具的核心原理是模拟多个用户（或客户端）同时向目标系统发送请求，以观测系统在高负载下的性能表现（如吞吐量、响应时间、错误率）和稳定性。

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

核心步骤概览

1. 设计测试场景：明确你要模拟什么用户行为（登录、搜索、下单？）。
2. 配置线程组：这是“并发”的核心，设置有多少个“虚拟用户”同时干活。
3. 添加取样器：定义虚拟用户具体要发什么请求（HTTP请求、JDBC请求等）。
4. 添加监听器：收集并展示测试结果。
5. 运行并分析：启动测试，观察系统反应。

---

以 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 报告精美。	注重代码质量和报告美观度的开发团队。

---

必须注意的坑与最佳实践

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

   • JMeter 是 Java 写的，GUI 模式会消耗大量内存，高并发测试（如 >100 线程）应使用命令行模式：

     # 无GUI运行，参数：-n 非GUI, -t 脚本路径, -l 结果文件
     jmeter -n -t MyTestPlan.jmx -l results.jtl -e -o /report

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

2. 确保客户端资源充足

   • 瓶颈可能在测试机本身，如果你的电脑是 8G 内存，开 1000 个线程，JMeter 自己可能会卡死或报 OutOfMemoryError。
   • 此时需要分布式压测：1 台 Master + N 台 Slave（Agent），分散压力。

3. 使用关联和数据参数化

   • 不要所有用户都搜索“手机”，使用 CSV Data Set Config 或函数助手 _RandomString 生成不同的商品名，模拟真实用户输入。
   • 对于需要登录的系统,使用 正则表达式提取器 或 JSON 提取器 从登录响应中提取 token/cookie，并应用到后续请求中。

4. 观察监控指标

   • 不要只看响应时间，当系统扛不住时，响应时间会突然飙升（拐点），TPS 不再增长甚至下降，错误率开始出现。
   • 需要同时看服务器端监控：CPU 使用率、内存、磁盘 I/O、网络、数据库连接数，CPU 已经 100%，那问题在服务器算力不够；CPU 只有 30% 但响应慢，那可能是代码锁等待或数据库慢查询。

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

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

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

1. 明确目标：要求系统能支持 1000 用户同时在线，核心接口响应时间 < 200ms，TPS > 500。
2. 脚本开发：用 JMeter/Locust 编写业务脚本，并做好参数化、关联和断言。
3. 试运行：用少量用户（如 10 个）跑一次，检查脚本逻辑是否正确，结果树里数据是对的。
4. 阶梯加压：从低到高逐步增加并发量（如 50->100->200->400），每次都观察TPS 和响应时间的拐点。
5. 定位瓶颈：当 TPS 不增长或响应时间飙升时，联合运维人员一起查看服务器 CPU、内存、DB 慢查询、网络带宽等，找到根本原因。
6. 优化与复测：开发修复代码或调整配置后，重新跑相同的测试用例，验证优化效果。

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

标签： Locust