零基础学习性能测试第十二章：流量录制与回放-概念及实操-CSDN博客

本文链接：https://blog.csdn.net/u011537504/article/details/132351977

按照以下结构化的学习内容和实操步骤进行。这个方案聚焦核心概念、主流工具实操、实战注意事项，力求高效实用。

核心目标： 通过录制真实用户操作产生的流量（HTTP/HTTPS等请求），将其转化为性能测试脚本，并能在压测工具中回放，模拟真实用户行为进行压力测试。

学习内容大纲与实操步骤：

阶段一：核心概念扫盲 (1-2天)

什么是流量录制与回放？
- 概念： 利用工具捕获用户（或系统）与应用程序交互过程中产生的网络请求（如HTTP/HTTPS），将这些请求及其参数、顺序、依赖关系记录下来，生成一个可执行的测试脚本。这个脚本可以被性能测试工具加载并大规模、并发地重复执行（回放），模拟真实用户行为对系统施加压力。
- 类比： 就像用摄像机录下顾客在超市购物的全过程（拿商品、扫码、付款），然后让很多机器人按照录像里的动作去重复购物。
为什么需要流量录制与回放？
- 真实性高： 基于真实用户行为录制，能最大程度模拟生产环境的业务场景和用户操作路径，比手动写脚本更贴近实际。
- 效率高： 尤其对于复杂业务流（如登录->搜索->加购->下单->支付），手动编写脚本耗时耗力且易错。录制可以快速生成基础脚本。
- 覆盖关键路径： 确保压测覆盖了用户最常使用、最重要的业务功能。
- 降低学习成本： 对协议细节（如认证方式、参数加密）要求相对较低，工具可以自动捕获很多信息。
核心组成部分：
- 录制器/代理： 捕获网络流量的工具组件（如JMeter的HTTP(S) Test Script Recorder, Gatling的Recorder, LoadRunner/Badboy的Proxy）。
- 目标应用： 你要测试的Web应用、API服务等。
- 客户端： 用户操作的浏览器或移动App（流量经过录制代理）。
- 生成的脚本： 录制完成后产生的包含请求、URL、参数、Header、Cookies、关联/参数化逻辑的测试脚本（如JMX文件, Scala脚本）。
- 回放引擎： 性能测试工具的核心，负责加载脚本、管理虚拟用户、并发执行、收集结果（如JMeter, Gatling, LoadRunner）。
关键术语：
- HTTP(S)请求/响应： 录制和回放的基本单位。
- Header： 请求/响应的元数据（如Cookie, Content-Type, Authorization）。
- Cookie/Session： 维持用户会话状态的关键，回放时需正确处理关联。
- 参数化： 将脚本中的固定值（如用户名、商品ID）替换为变量，以便用不同数据回放，模拟不同用户。
- 关联： 处理动态值（如Session ID, Token, 订单号）。录制时捕获的值在回放时可能失效，需要从服务器响应中提取并替换到后续请求中。这是录制回放的核心难点！
- 思考时间： 用户操作之间的间隔时间。录制时会捕获，回放时需合理设置或参数化。
- 并发用户数/虚拟用户： 模拟同时在线操作的用户数量。

阶段二：工具选择与基础环境搭建 (1天)

选择主流工具 (推荐零基础首选)：
- Apache JMeter： 强烈推荐！ 开源、免费、功能强大、社区活跃、插件丰富。学习曲线相对平缓，是学习性能测试和录制回放的绝佳起点。支持HTTP(S) Test Script Recorder。
- Gatling： 开源、免费、基于Scala（脚本可读性好）、性能开销小、报告美观。Recorder功能强大。适合有一定编程基础或追求高性能压测。
- 商业工具： LoadRunner (强大但昂贵复杂)， K6 (现代，基于JS，云原生友好)， BlazeMeter (JMeter云服务)。零基础可先了解，暂不深入。
- 建议： 从JMeter开始！ 资源丰富，遇到问题容易找到解决方案。
环境搭建：
- 安装JMeter：
  - 访问 Apache JMeter官网下载最新稳定版 (Binaries zip/tgz)。
  - 解压到本地目录。
  - (推荐) 安装 Java 8 或更高版本 (运行 java -version 确认)。
  - 运行 bin/jmeter.bat (Windows) 或 bin/jmeter.sh (Linux/macOS) 启动。
- 配置浏览器代理 (用于录制)：
  - 了解你的浏览器代理设置位置 (Chrome/Firefox在设置->网络设置/高级->代理)。
  - 记住默认代理设置！ (方便录制后恢复)。
  - 准备将浏览器代理设置为JMeter的录制代理地址 (通常是 localhost 或 127.0.0.1) 和端口 (默认 8888，可在JMeter中改)。

阶段三：核心实操 - JMeter 流量录制与回放 (2-4天)

目标： 完成一次完整的流量录制、脚本优化、回放验证。

录制基础脚本：
- 打开JMeter。
- 创建测试计划： Test Plan -> 右键 Add -> Threads (Users) -> Thread Group。 (可以先保留默认设置)。
- 设置HTTP(S) Test Script Recorder：
  - 右键 Test Plan 或 WorkBench -> Add -> Non-Test Elements -> HTTP(S) Test Script Recorder。
  - 设置 Port (如 8888)。
  - 在 Target Controller 下拉框选择 Test Plan > Thread Group (这样录制的请求会直接放到线程组下)。
  - (重要) 点击 Start 按钮启动代理。JMeter会监听你设置的端口。
- 配置浏览器代理： 将浏览器的代理服务器地址设置为 localhost 或 127.0.0.1，端口设置为JMeter中设置的端口 (如 8888)。
- 执行用户操作： 在配置好代理的浏览器中，像真实用户一样操作你的目标应用 (如登录、浏览商品、下单等)。确保操作覆盖你想要压测的核心业务流程。
- 观察JMeter： 在 Thread Group 下会实时生成录制到的 HTTP Request 采样器。每个请求代表浏览器发出的一个请求。
- 停止录制： 操作完成后，回到JMeter，点击 HTTP(S) Test Script Recorder 上的 Stop 按钮。
- 恢复浏览器代理： 将浏览器代理设置恢复为默认或直接关闭，避免影响后续正常上网。
- 保存测试计划： 保存你的JMX文件 (如 my_first_record.jmx)。恭喜，基础脚本录制完成！
脚本审查与基础优化：
- 查看请求： 逐个展开 HTTP Request，查看：
  - Protocol (http/https)
  - Server Name/IP
  - Path
  - Method (GET/POST/PUT/DELETE)
  - Parameters (GET参数或POST的Form Data)
  - Headers (特别是 Cookie, Authorization, Content-Type)
  - Body Data (POST/PUT的请求体，如JSON)
- 删除无用请求： 录制通常会捕获很多静态资源请求 (如 .js, .css, .png, .jpg)。这些通常不需要压测，会浪费资源。选中它们，右键 Remove。
  - 技巧：在 View Results Tree 监听器中回放时更容易识别哪些是静态资源 (看URL后缀和响应内容类型)。
- 添加监听器 (用于调试)： 右键 Thread Group -> Add -> Listener -> View Results Tree。这是调试脚本的利器，可以看到每个请求的详细请求和响应。
核心挑战：处理动态数据 (关联)
- 问题： 登录后服务器返回的 sessionId, token, 下单后生成的 orderId 等，每次操作都不同。录制脚本里用的是录制时的固定值。直接回放时，后续请求使用旧的固定值会导致失败 (如提示会话过期、订单不存在)。
- 解决方案：关联！
  1. 识别动态值： 回放脚本 (用 View Results Tree)，找到哪个请求失败。查看失败请求的请求参数/Header，看哪个值应该变化但没变 (通常是登录后第一个失败请求)。在录制时的服务器响应中找到生成这个值的地方。
  2. 提取动态值 (后置处理器)： 在生成这个动态值的请求采样器下，右键 Add -> Post Processors -> 选择合适的提取器：
    - 正则表达式提取器 (Regular Expression Extractor)： 最常用，通过正则表达式匹配响应文本中的值。需要学习基本正则。
    - JSON提取器 (JSON Extractor)： 如果响应是JSON，更简单直接。
    - XPath提取器 (XPath Extractor)： 如果响应是XML/HTML。
    - 配置：给提取的值起一个变量名 (如 token, sessionId, orderId)，设置提取规则。
  3. 替换动态值： 在需要使用这个动态值的后续请求采样器中，找到原来写固定值的地方 (可能是参数、Header、Body Data)，用 ${变量名} (如 ${token}) 替换掉原来的固定值。
- 实操练习： 必须找一个需要登录的应用录制，练习提取 sessionId 或 token 并替换到后续请求的Header (通常是 Authorization: Bearer ${token} 或 Cookie: JSESSIONID=${sessionId}) 中。这是能否成功回放的关键！
参数化：让用户更真实
- 问题： 所有虚拟用户都用录制时的同一个用户名登录、操作同一个商品？这不真实，也容易触发应用的限制 (如单用户限购)。
- 解决方案：参数化！
  - 准备数据源： 创建CSV文件 (如 users.csv)，包含多列数据 (如 username, password, productId)。
  - 添加CSV Data Set Config： 右键 Thread Group -> Add -> Config Element -> CSV Data Set Config。
    - 设置 Filename (指向你的CSV文件)。
    - 设置 Variable Names (如 username, password, productId，对应CSV列)。
    - 配置其他选项 (如 Recycle on EOF? - 数据用完是否循环, Stop thread on EOF? - 数据用完是否停止线程)。
  - 替换脚本中的固定值： 在脚本中找到用户名、密码、商品ID等需要变化的地方，用 ${变量名} (如 ${username}, ${password}, ${productId}) 替换原来的固定值。
  - 回放验证： 使用 View Results Tree 检查不同虚拟用户是否使用了不同的数据。
设置合理的负载 (线程组配置)
- 线程数： 模拟的并发用户数。
- Ramp-up时间： 多少秒内启动所有线程。例如：线程数=100, Ramp-up=10，表示每秒启动10个用户，10秒内达到100用户并发。
- 循环次数： 每个线程执行整个脚本流程的次数。勾选 Forever 表示持续运行，直到手动停止。
- 调度器： 设置测试的持续时间、启动延迟等。
- 初始设置： 刚开始调试脚本时，设置 线程数=1, 循环次数=1。确保单用户回放成功后再逐步增加负载。
添加关键监听器 (用于结果分析)
- 聚合报告 (Summary Report)： 核心指标！TPS (吞吐量)、平均响应时间、错误率、最小/最大响应时间等。
- 查看结果树 (View Results Tree)： 调试必备，查看每个请求的详情 (请求/响应头、体)。压测时不要开启！ 会消耗大量内存，仅用于调试脚本。
- 响应时间图 (Response Time Graph)： 可视化响应时间变化趋势。
- 聚合图 (Aggregate Graph)： 另一种汇总视图。
- 后端监听器 (Backend Listener)： 将结果实时发送到InfluxDB + Grafana等监控系统，做更酷炫的实时监控。

阶段四：回放、压测与分析 (1-2天)

本地回放验证：
- 配置好线程组 (1个用户)、关联、参数化。
- 启动测试 (Run -> Start)。
- 在 View Results Tree 中仔细检查每个请求是否成功 (绿色对勾)。重点关注登录后、涉及动态值的请求。失败请求 (红色叉叉) 要分析原因 (看响应内容)。
- 反复调试关联、参数化，直到单用户回放全程成功。
进行压力测试：
- 确定目标： 测试目的是什么？(例如：找出系统瓶颈、验证是否能支撑1000TPS、评估响应时间是否达标)。确定关键指标 (TPS, 响应时间, 错误率)。
- 设计负载模型： 逐步增加 线程数 和 Ramp-up时间 (如 50用户->100用户->200用户…)。使用 Scheduler 设置持续时间 (如持续运行5分钟)。
- 选择监听器： 只开启必要的监听器进行压测 (Aggregate Report, Response Time Graph, Backend Listener)。关闭 View Results Tree！
- 执行压测： 点击 Start。观察JMeter运行状态和监听器数据。
- 监控被测系统： 非常重要！ 压测工具只给出客户端数据。必须同时监控服务器：
  - CPU、内存、磁盘I/O、网络I/O。
  - 应用服务器指标 (如Tomcat线程池、连接数)。
  - 数据库指标 (连接数、慢查询、锁等待)。
  - JVM指标 (堆内存、GC情况 - 如果应用是Java)。
  - 使用工具：top/htop, vmstat, iostat, netstat, JConsole, VisualVM, Prometheus + Grafana, APM工具 (如SkyWalking, Pinpoint)。
分析结果：
- JMeter结果：
  - Aggregate Report：关注整体TPS、平均/最大响应时间、错误率。是否达到预期目标？
  - Response Time Graph：响应时间是否随负载增加而急剧上升？是否有异常波动？
  - 错误请求：查看错误类型和数量。是脚本问题 (关联失败) 还是服务器问题 (5xx错误)？
- 系统监控数据：
  - 哪个资源最先达到瓶颈？(CPU 100%？内存耗尽？磁盘打满？网络带宽满？)
  - 应用服务器/数据库是否有异常 (线程池满？连接池满？大量慢查询？频繁Full GC？)
- 关联分析： 将JMeter的TPS/响应时间曲线与服务器的CPU/内存/数据库指标曲线对比，找出性能拐点和瓶颈根源。
生成报告：
- 整理关键结果：测试目标、负载模型、TPS、响应时间、错误率、资源使用率、发现的主要瓶颈/问题。
- JMeter监听器可以导出为CSV或图片。
- 系统监控数据截图。
- 给出结论和建议 (如：系统在200用户并发时响应时间陡增，原因是数据库CPU成为瓶颈，建议优化SQL查询XXX)。

阶段五：进阶与快速应用要点 (持续实践)

处理HTTPS：
- JMeter录制HTTPS需要安装JMeter的CA证书到浏览器的信任根证书库。否则会报SSL错误。
- 参考JMeter文档：HTTP(S) Test Script Recorder 设置中有详细说明和 Start 按钮旁边的证书安装提示。
处理异步请求 (AJAX/WebSocket)：
- 录制工具可能不会完美捕获所有异步请求。需要仔细审查脚本，手动补充可能遗漏的XHR/Fetch请求。可能需要结合抓包工具 (如Chrome DevTools, Fiddler, Wireshark) 分析。
- WebSocket需要专门的采样器支持 (JMeter有插件)。
思考时间与定时器：
- 录制会捕获操作间的间隔 (Think Time)。回放时，这个时间被记录在 Constant Timer 或类似定时器里。
- 压测时，通常需要调整或参数化思考时间：
  - 完全去掉：模拟最大压力 (极限测试)。
  - 使用固定值：模拟用户平均操作速度。
  - 使用随机值 (如高斯随机定时器)：模拟更真实的用户操作间隔。
快速应用到工作的关键点：
- 聚焦核心业务流： 优先录制用户最常用、最重要的流程 (如登录、核心交易)。
- 搞定关联： 这是脚本能否成功回放的命门。花时间理解应用的关键Token/Session机制，熟练掌握正则/JSON提取器。
- 参数化基础数据： 至少参数化登录用户，避免单一用户限制。
- 循序渐进增加负载： 从1个用户开始调试，逐步增加并发数。监控系统资源，及时发现问题。
- 结果分析重于压测本身： 压测是手段，找出瓶颈和问题才是目的。一定要结合系统监控数据分析。
- 记录和复用： 保存好成功的脚本、参数化文件、测试配置。建立简单的脚本库。
- 寻求帮助： 遇到问题 (特别是关联问题)，善用搜索引擎、JMeter官方文档、社区论坛 (如 Stack Overflow)。描述清楚现象和你的尝试。

学习资源推荐：

Apache JMeter 官方文档- 最权威，必读！特别是 HTTP(S) Test Script Recorder 和 Building a Web Test Plan 章节。
BlazeMeter JMeter 教程： - 质量很高的免费教程。
Gatling 官方文档 - 如果选择Gatling，文档是主要学习资料。
在线课程平台 (Udemy, Coursera, 慕课网, 极客时间)： 搜索 “JMeter”, “性能测试”, “Load Testing” 等关键词，选择评价好的入门实战课程。
社区论坛：
- Stack Overflow
- JMeter 邮件列表/用户论坛。

总结：

零基础学习流量录制与回放，遵循“概念理解 -> 工具安装 -> 基础录制 -> 脚本优化 (删静态、关联、参数化) -> 负载设置 -> 执行压测 -> 监控分析 -> 报告结果”的路径。核心突破口在于熟练掌握关联技术。 选择JMeter作为起点，勤加练习核心流程的录制、关联和参数化，并始终结合系统监控进行分析，就能快速将这项技术应用到实际工作中，为系统性能评估和优化提供有力支持。祝你学习顺利！