1. 项目概述从登录到性能测试的必经之路做性能测试尤其是Web应用或者API接口的性能测试一个绕不开的经典场景就是用户必须先登录拿到认证凭证然后才能去访问那些需要权限的接口。这个场景太常见了几乎每个带用户体系的系统都会遇到。比如你要压测一个电商系统的“提交订单”接口用户总得先登录吧不然服务器怎么知道是谁在买东西很多刚开始接触JMeter的朋友包括我自己早年也踩过不少坑以为录个脚本、设置一下线程数就能开跑结果发现大量请求都卡在登录这一步返回一堆401或者403错误测试结果完全失真。这个项目要解决的就是如何用JMeter这个强大的开源工具优雅且正确地模拟这个“先登录后操作”的完整用户行为流。它不仅仅是把登录请求和业务请求放在一个线程组里那么简单核心在于如何让登录成功后得到的“令牌”Token常见如JWT、Session ID等能够被后续的请求自动、准确地使用。这涉及到JMeter的多个核心组件HTTP请求、正则表达式提取器、JSON提取器、HTTP信息头管理器以及线程组的逻辑控制。理解并掌握这套流程是进行任何有意义、贴近真实场景的性能测试的基础。无论你是测试工程师、开发人员还是对系统负载能力感兴趣的技术爱好者这套实战方法都能让你设计的性能测试脚本立刻变得专业和可靠。2. 核心思路与组件选型解析2.1 为什么“先登录”是性能测试的关键一环在功能测试里我们可能用一个固定的账号登录然后手动点点点。但在性能测试中我们要模拟的是成百上千的虚拟用户VUsers并发操作。每个虚拟用户都应该被视为一个独立的、拥有自己会话状态的个体。如果所有虚拟用户都共用同一个登录后的Token会产生几个严重问题会话冲突服务器端可能会检测到同一个Token从大量不同IP或会话中发起请求从而判定为异常行为导致Token失效或请求被拒绝。数据污染与失真例如测试“用户查询自己的订单”这个接口如果大家都用同一个用户Token那么查到的都是同一个用户的订单无法真实模拟多用户并发查询不同数据集的场景缓存命中率等指标也会严重失真。无法测试登录环节的性能登录接口本身也是性能测试的重要对象。我们需要知道系统在每秒处理N次登录请求时的响应时间、吞吐量和错误率。如果只登录一次就完全忽略了这个关键环节的压力。因此一个标准的性能测试脚本应该为每一个虚拟用户或每一个线程执行一次独立的登录获取专属于该线程的认证凭证并用这个凭证去执行后续的系列操作。这模拟了真实世界中每个用户打开浏览器、输入账号密码、进入系统的完整过程。2.2 JMeter实现方案的核心组件选型要实现上述流程我们需要在JMeter中搭建一个逻辑清晰的架构。以下是核心“四大件”及其选型理由1. 线程组 (Thread Group)这是所有测试计划的起点它定义了虚拟用户的数量线程数、启动时间Ramp-Up Period和循环次数。我们将把登录和业务请求都放在同一个线程组内确保每个线程用户的执行流程是独立的。选择“线程组”而不是“ setUp 线程组”来包含登录是因为setUp通常用于所有线程执行前的全局初始化如创建测试数据而这里的登录是每个用户行为的一部分更适合放在主线程组中。2. HTTP请求采样器 (HTTP Request Sampler)用于模拟发送登录请求通常是POST到登录接口和后续的各种业务请求GET/POST/PUT/DELETE等。这是与服务器交互的直接工具。配置时关键点在于登录请求的“消息体数据”中需要参数化用户名和密码。3. 后置处理器 (Post-Processor)这是整个流程的“灵魂”。登录请求成功后服务器会在响应中返回Token。我们需要把它“提取”出来保存到一个变量里供后续请求使用。根据响应格式主要有两种选择正则表达式提取器 (Regular Expression Extractor)如果响应是HTML、文本或者非标准JSON正则表达式是万金油。例如如果返回的文本中包含token:(.*?)我们可以用正则表达式来捕获它。JSON提取器 (JSON Extractor)这是目前更推荐、更主流的方式。因为现代API绝大多数都采用JSON格式返回数据例如{code:200, data:{access_token:eyJhbGciOiJ...}}。JSON提取器通过JSONPath表达式如$.data.access_token来定位和提取值比正则表达式更精确、更易维护不易因响应格式的微小变动如换行、空格而失效。4. HTTP信息头管理器 (HTTP Header Manager)Token提取出来后如何传递给下一个请求通常认证Token是通过HTTP请求头来传递的最常见的是放在Authorization头中格式如Bearer 你的Token。我们需要在业务请求前添加一个HTTP信息头管理器并将值设置为Bearer ${token_variable}其中token_variable就是你用后置处理器提取并保存的变量名。这样每个线程的业务请求都会自动带上自己登录成功后获取的Token。注意有些老系统可能将Token放在Cookie中如JSESSIONID。对于这种情况JMeter默认会自动管理Cookie需确保HTTP请求默认配置中“同请求一起发送Cookie”是启用的只要登录请求成功后续请求就会自动携带相同的Cookie无需手动提取和设置。但为了方案的通用性和清晰性我们主要讲解基于Token请求头的方案。3. 实战步骤构建一个完整的带登录的性能测试脚本下面我们以一个典型的 RESTful API 为例一步步搭建测试脚本。假设我们有登录接口POST /api/auth/login请求体{username:testUser, password:123456}响应体{code: 200, message: success, data: {access_token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...}}业务接口需要认证GET /api/user/profile3.1 第一步创建测试计划与线程组打开JMeter右键“测试计划” - 添加 - 线程用户 -线程组。配置线程组属性线程数用户数例如 100。这表示模拟100个并发用户。Ramp-Up时间秒例如 10。表示在10秒内启动全部100个线程平均每秒启动10个。循环次数例如 5。表示每个线程用户执行整个流程5次。勾选“永远”则表示持续运行直到手动停止。3.2 第二步添加并配置登录请求右键线程组 - 添加 - 取样器 -HTTP请求。将其重命名为“用户登录”。配置该HTTP请求协议http或https服务器名称或IP填写你的被测服务器地址如api.yourdomain.com端口号默认80或443根据实际情况填写。HTTP请求选择POST路径/api/auth/login内容编码通常为utf-8参数/消息体数据切换到“消息体数据”标签页输入JSON格式的登录凭证。但这里不要写死为了模拟多用户我们需要参数化。参数化用户名和密码我们使用JMeter内置的__CSVRead函数或“CSV数据文件设置”元件来读取外部数据文件。这里以CSV文件为例更贴近真实压测场景。右键线程组 - 添加 - 配置元件 -CSV数据文件设置。配置CSV数据文件设置文件名指向一个准备好的users.csv文件例如C:\testdata\users.csv。文件编码UTF-8变量名称username,password用逗号分隔对应CSV文件的列。其他选项默认即可。Recycle on EOF和Stop thread on EOF根据需求设置。users.csv文件内容示例user1,pass1 user2,pass2 ... 至少准备和线程数相当的数据行回到“用户登录”HTTP请求在“消息体数据”中填写{ username: ${username}, password: ${password} }添加HTTP信息头管理器到登录请求下右键“用户登录” - 添加 - 配置元件 - HTTP信息头管理器设置Content-Type为application/json告诉服务器我们发送的是JSON数据。3.3 第三步从登录响应中提取Token右键“用户登录”HTTP请求 - 添加 - 后置处理器 -JSON提取器。配置JSON提取器名称提取登录TokenApply toMain sample and sub-samples通常选择这个即可Names of created variablesaccess_token这是你定义的变量名后面用${access_token}来引用JSON Path Expressions$.data.access_token这是JSONPath表达式意思是取根节点下data对象中的access_token字段值Match No.1通常取第一个匹配项如果返回是数组需要其他值Default Values可以留空或者填写一个错误值如NOT_FOUND方便调试。实操心得强烈建议在添加JSON提取器后先添加一个调试取样器 (Debug Sampler)和查看结果树 (View Results Tree)运行一下单个线程的测试看看access_token变量是否被正确提取出来。这是排查提取器配置错误的最快方法。3.4 第四步添加需要认证的业务请求在线程组下登录请求之后添加一个新的HTTP请求重命名为“获取用户信息”。配置该HTTP请求协议、服务器、端口通常与登录请求相同如果不同则修改。HTTP请求GET路径/api/user/profile关键步骤为业务请求添加认证头右键“获取用户信息”HTTP请求 - 添加 - 配置元件 -HTTP信息头管理器。在这个信息头管理器中添加一个头名称Authorization值Bearer ${access_token}这样当这个请求发出时就会自动在请求头中带上Authorization: Bearer eyJhbGciOiJ...这样的格式服务器就能识别出是哪个用户发起的请求。3.5 第五步添加监听器查看结果为了观察测试结果需要添加监听器。常用的有查看结果树用于调试查看每个请求和响应的详细信息。注意正式压测时不要开启因为它会消耗大量内存影响压测机性能。聚合报告查看整体的响应时间、吞吐量、错误率等关键指标。用表格查看结果以表格形式展示每个样本的结果可以看到随时间推移的变化。图形结果直观的响应时间趋势图。建议的实践是调试脚本时使用“查看结果树”正式运行压力测试时只保留“聚合报告”等汇总型监听器。至此一个完整的“先登录后请求”的JMeter脚本骨架就搭建完成了。每个线程虚拟用户都会从CSV文件读取一对用户名密码 - 发送登录请求 - 从响应中提取自己的Token - 使用这个Token去请求个人资料接口。4. 高级技巧与常见问题排查4.1 参数化与数据关联的进阶用法使用随机函数如果不需要严格的用户对应关系可以使用JMeter函数助手生成随机用户名。在“消息体数据”中可以使用__RandomString__Random等函数。例如{username: user${__Random(1,1000,)}, password:123456}。Token过期与刷新有些系统的Token有较短的有效期。你需要设计逻辑在执行业务请求前先检查Token是否过期可能需要解析JWT的exp字段如果过期则重新发起登录请求获取新Token。这通常需要用到BeanShell取样器或JSR223取样器推荐性能更好来编写一些判断逻辑。关联多个值登录后返回的可能不止Token还有user_id、refresh_token等。可以在同一个JSON提取器中设置多个变量名和表达式用分号隔开。如变量名token;userId表达式$.data.access_token;$.data.user_id。4.2 常见问题与排查清单在实际操作中你几乎一定会遇到下面这些问题。这里提供一个快速排查指南问题现象可能原因排查步骤与解决方案业务请求大量返回401未授权1. Token未成功提取。2. Token未正确传递给业务请求。3. Token格式错误如缺少Bearer前缀。4. Token已过期。1. 添加“调试取样器”检查${access_token}变量是否有值。2. 在“查看结果树”中检查业务请求的请求头看Authorization头是否存在且值正确。3. 确认信息头管理器的值格式是否正确是否为Bearer ${access_token}。4. 检查服务器Token有效期或设计Token刷新逻辑。登录请求本身失败返回4xx1. 请求参数错误用户名密码格式。2. 请求头缺失如缺少Content-Type: application/json。3. 服务器地址/端口/路径错误。1. 在“查看结果树”中对比请求的“请求”标签页看发送的JSON体是否和预期一致。2. 检查登录请求的HTTP信息头管理器。3. 核对HTTP请求采样器中的基础配置。变量值为空或NOT_FOUND1. JSON提取器路径写错。2. 服务器响应格式与预期不符。3. 登录请求失败无有效响应。1. 使用“查看结果树”查看登录请求的“响应数据”标签页确认JSON结构。可以用在线JSONPath测试工具验证$.data.access_token路径是否正确。2. 检查响应是否是JSON有时错误时返回的是HTML页面。3. 确保登录请求本身是成功的状态码200。所有用户都用同一个Token1. 误将JSON提取器放在了测试计划或线程组层级且作用域选择不当。2. 使用了全局变量。1.确保JSON提取器是作为登录请求的“子元件”添加的。这样它的作用域仅限于该请求提取的变量属于线程局部变量。2. 避免使用__setProperty等函数设置全局属性除非你确实需要跨线程共享。性能测试时登录接口先扛不住登录接口本身成为瓶颈业务接口还没开始压测登录就超时或报错了。1. 检查登录接口的响应时间如果过长需要先优化该接口或调整测试策略。2. 可以考虑使用“仅一次控制器”将登录操作放在里面但这违背了真实场景仅用于临时绕过登录瓶颈专注于测试业务接口不推荐长期使用。3. 更真实的做法是准备更强大的登录集群或者使用已经提前批量生成好的Token池但这同样会失去对登录环节的压测。4.3 一个容易被忽略的优化点连接复用与超时设置在“HTTP请求默认值”配置元件中有两个设置对性能测试结果影响很大Use KeepAlive务必勾选。这允许JMeter复用TCP连接避免每次请求都进行三次握手能极大提升压测效率也更贴近现代浏览器的行为。超时设置根据测试场景合理设置“连接超时”和“响应超时”。在压测初期可以设置得稍短一些如2000-5000毫秒快速发现接口瓶颈。在稳定性测试时可以设置得和产品要求一致。最后记住性能测试脚本的核心是“模拟真实”。你设计的这个“登录-业务”流程越贴近真实用户的操作顺序、间隔时间使用“定时器”元件来模拟思考时间和数据差异得到的测试结果就越有价值越能发现系统中潜在的性能瓶颈和风险。把这个基础流程搭建牢固后续无论是添加更复杂的业务链、参数化还是分布式压测你都会得心应手。
1. 项目概述从登录到性能测试的必经之路做性能测试尤其是Web应用或者API接口的性能测试一个绕不开的经典场景就是用户必须先登录拿到认证凭证然后才能去访问那些需要权限的接口。这个场景太常见了几乎每个带用户体系的系统都会遇到。比如你要压测一个电商系统的“提交订单”接口用户总得先登录吧不然服务器怎么知道是谁在买东西很多刚开始接触JMeter的朋友包括我自己早年也踩过不少坑以为录个脚本、设置一下线程数就能开跑结果发现大量请求都卡在登录这一步返回一堆401或者403错误测试结果完全失真。这个项目要解决的就是如何用JMeter这个强大的开源工具优雅且正确地模拟这个“先登录后操作”的完整用户行为流。它不仅仅是把登录请求和业务请求放在一个线程组里那么简单核心在于如何让登录成功后得到的“令牌”Token常见如JWT、Session ID等能够被后续的请求自动、准确地使用。这涉及到JMeter的多个核心组件HTTP请求、正则表达式提取器、JSON提取器、HTTP信息头管理器以及线程组的逻辑控制。理解并掌握这套流程是进行任何有意义、贴近真实场景的性能测试的基础。无论你是测试工程师、开发人员还是对系统负载能力感兴趣的技术爱好者这套实战方法都能让你设计的性能测试脚本立刻变得专业和可靠。2. 核心思路与组件选型解析2.1 为什么“先登录”是性能测试的关键一环在功能测试里我们可能用一个固定的账号登录然后手动点点点。但在性能测试中我们要模拟的是成百上千的虚拟用户VUsers并发操作。每个虚拟用户都应该被视为一个独立的、拥有自己会话状态的个体。如果所有虚拟用户都共用同一个登录后的Token会产生几个严重问题会话冲突服务器端可能会检测到同一个Token从大量不同IP或会话中发起请求从而判定为异常行为导致Token失效或请求被拒绝。数据污染与失真例如测试“用户查询自己的订单”这个接口如果大家都用同一个用户Token那么查到的都是同一个用户的订单无法真实模拟多用户并发查询不同数据集的场景缓存命中率等指标也会严重失真。无法测试登录环节的性能登录接口本身也是性能测试的重要对象。我们需要知道系统在每秒处理N次登录请求时的响应时间、吞吐量和错误率。如果只登录一次就完全忽略了这个关键环节的压力。因此一个标准的性能测试脚本应该为每一个虚拟用户或每一个线程执行一次独立的登录获取专属于该线程的认证凭证并用这个凭证去执行后续的系列操作。这模拟了真实世界中每个用户打开浏览器、输入账号密码、进入系统的完整过程。2.2 JMeter实现方案的核心组件选型要实现上述流程我们需要在JMeter中搭建一个逻辑清晰的架构。以下是核心“四大件”及其选型理由1. 线程组 (Thread Group)这是所有测试计划的起点它定义了虚拟用户的数量线程数、启动时间Ramp-Up Period和循环次数。我们将把登录和业务请求都放在同一个线程组内确保每个线程用户的执行流程是独立的。选择“线程组”而不是“ setUp 线程组”来包含登录是因为setUp通常用于所有线程执行前的全局初始化如创建测试数据而这里的登录是每个用户行为的一部分更适合放在主线程组中。2. HTTP请求采样器 (HTTP Request Sampler)用于模拟发送登录请求通常是POST到登录接口和后续的各种业务请求GET/POST/PUT/DELETE等。这是与服务器交互的直接工具。配置时关键点在于登录请求的“消息体数据”中需要参数化用户名和密码。3. 后置处理器 (Post-Processor)这是整个流程的“灵魂”。登录请求成功后服务器会在响应中返回Token。我们需要把它“提取”出来保存到一个变量里供后续请求使用。根据响应格式主要有两种选择正则表达式提取器 (Regular Expression Extractor)如果响应是HTML、文本或者非标准JSON正则表达式是万金油。例如如果返回的文本中包含token:(.*?)我们可以用正则表达式来捕获它。JSON提取器 (JSON Extractor)这是目前更推荐、更主流的方式。因为现代API绝大多数都采用JSON格式返回数据例如{code:200, data:{access_token:eyJhbGciOiJ...}}。JSON提取器通过JSONPath表达式如$.data.access_token来定位和提取值比正则表达式更精确、更易维护不易因响应格式的微小变动如换行、空格而失效。4. HTTP信息头管理器 (HTTP Header Manager)Token提取出来后如何传递给下一个请求通常认证Token是通过HTTP请求头来传递的最常见的是放在Authorization头中格式如Bearer 你的Token。我们需要在业务请求前添加一个HTTP信息头管理器并将值设置为Bearer ${token_variable}其中token_variable就是你用后置处理器提取并保存的变量名。这样每个线程的业务请求都会自动带上自己登录成功后获取的Token。注意有些老系统可能将Token放在Cookie中如JSESSIONID。对于这种情况JMeter默认会自动管理Cookie需确保HTTP请求默认配置中“同请求一起发送Cookie”是启用的只要登录请求成功后续请求就会自动携带相同的Cookie无需手动提取和设置。但为了方案的通用性和清晰性我们主要讲解基于Token请求头的方案。3. 实战步骤构建一个完整的带登录的性能测试脚本下面我们以一个典型的 RESTful API 为例一步步搭建测试脚本。假设我们有登录接口POST /api/auth/login请求体{username:testUser, password:123456}响应体{code: 200, message: success, data: {access_token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...}}业务接口需要认证GET /api/user/profile3.1 第一步创建测试计划与线程组打开JMeter右键“测试计划” - 添加 - 线程用户 -线程组。配置线程组属性线程数用户数例如 100。这表示模拟100个并发用户。Ramp-Up时间秒例如 10。表示在10秒内启动全部100个线程平均每秒启动10个。循环次数例如 5。表示每个线程用户执行整个流程5次。勾选“永远”则表示持续运行直到手动停止。3.2 第二步添加并配置登录请求右键线程组 - 添加 - 取样器 -HTTP请求。将其重命名为“用户登录”。配置该HTTP请求协议http或https服务器名称或IP填写你的被测服务器地址如api.yourdomain.com端口号默认80或443根据实际情况填写。HTTP请求选择POST路径/api/auth/login内容编码通常为utf-8参数/消息体数据切换到“消息体数据”标签页输入JSON格式的登录凭证。但这里不要写死为了模拟多用户我们需要参数化。参数化用户名和密码我们使用JMeter内置的__CSVRead函数或“CSV数据文件设置”元件来读取外部数据文件。这里以CSV文件为例更贴近真实压测场景。右键线程组 - 添加 - 配置元件 -CSV数据文件设置。配置CSV数据文件设置文件名指向一个准备好的users.csv文件例如C:\testdata\users.csv。文件编码UTF-8变量名称username,password用逗号分隔对应CSV文件的列。其他选项默认即可。Recycle on EOF和Stop thread on EOF根据需求设置。users.csv文件内容示例user1,pass1 user2,pass2 ... 至少准备和线程数相当的数据行回到“用户登录”HTTP请求在“消息体数据”中填写{ username: ${username}, password: ${password} }添加HTTP信息头管理器到登录请求下右键“用户登录” - 添加 - 配置元件 - HTTP信息头管理器设置Content-Type为application/json告诉服务器我们发送的是JSON数据。3.3 第三步从登录响应中提取Token右键“用户登录”HTTP请求 - 添加 - 后置处理器 -JSON提取器。配置JSON提取器名称提取登录TokenApply toMain sample and sub-samples通常选择这个即可Names of created variablesaccess_token这是你定义的变量名后面用${access_token}来引用JSON Path Expressions$.data.access_token这是JSONPath表达式意思是取根节点下data对象中的access_token字段值Match No.1通常取第一个匹配项如果返回是数组需要其他值Default Values可以留空或者填写一个错误值如NOT_FOUND方便调试。实操心得强烈建议在添加JSON提取器后先添加一个调试取样器 (Debug Sampler)和查看结果树 (View Results Tree)运行一下单个线程的测试看看access_token变量是否被正确提取出来。这是排查提取器配置错误的最快方法。3.4 第四步添加需要认证的业务请求在线程组下登录请求之后添加一个新的HTTP请求重命名为“获取用户信息”。配置该HTTP请求协议、服务器、端口通常与登录请求相同如果不同则修改。HTTP请求GET路径/api/user/profile关键步骤为业务请求添加认证头右键“获取用户信息”HTTP请求 - 添加 - 配置元件 -HTTP信息头管理器。在这个信息头管理器中添加一个头名称Authorization值Bearer ${access_token}这样当这个请求发出时就会自动在请求头中带上Authorization: Bearer eyJhbGciOiJ...这样的格式服务器就能识别出是哪个用户发起的请求。3.5 第五步添加监听器查看结果为了观察测试结果需要添加监听器。常用的有查看结果树用于调试查看每个请求和响应的详细信息。注意正式压测时不要开启因为它会消耗大量内存影响压测机性能。聚合报告查看整体的响应时间、吞吐量、错误率等关键指标。用表格查看结果以表格形式展示每个样本的结果可以看到随时间推移的变化。图形结果直观的响应时间趋势图。建议的实践是调试脚本时使用“查看结果树”正式运行压力测试时只保留“聚合报告”等汇总型监听器。至此一个完整的“先登录后请求”的JMeter脚本骨架就搭建完成了。每个线程虚拟用户都会从CSV文件读取一对用户名密码 - 发送登录请求 - 从响应中提取自己的Token - 使用这个Token去请求个人资料接口。4. 高级技巧与常见问题排查4.1 参数化与数据关联的进阶用法使用随机函数如果不需要严格的用户对应关系可以使用JMeter函数助手生成随机用户名。在“消息体数据”中可以使用__RandomString__Random等函数。例如{username: user${__Random(1,1000,)}, password:123456}。Token过期与刷新有些系统的Token有较短的有效期。你需要设计逻辑在执行业务请求前先检查Token是否过期可能需要解析JWT的exp字段如果过期则重新发起登录请求获取新Token。这通常需要用到BeanShell取样器或JSR223取样器推荐性能更好来编写一些判断逻辑。关联多个值登录后返回的可能不止Token还有user_id、refresh_token等。可以在同一个JSON提取器中设置多个变量名和表达式用分号隔开。如变量名token;userId表达式$.data.access_token;$.data.user_id。4.2 常见问题与排查清单在实际操作中你几乎一定会遇到下面这些问题。这里提供一个快速排查指南问题现象可能原因排查步骤与解决方案业务请求大量返回401未授权1. Token未成功提取。2. Token未正确传递给业务请求。3. Token格式错误如缺少Bearer前缀。4. Token已过期。1. 添加“调试取样器”检查${access_token}变量是否有值。2. 在“查看结果树”中检查业务请求的请求头看Authorization头是否存在且值正确。3. 确认信息头管理器的值格式是否正确是否为Bearer ${access_token}。4. 检查服务器Token有效期或设计Token刷新逻辑。登录请求本身失败返回4xx1. 请求参数错误用户名密码格式。2. 请求头缺失如缺少Content-Type: application/json。3. 服务器地址/端口/路径错误。1. 在“查看结果树”中对比请求的“请求”标签页看发送的JSON体是否和预期一致。2. 检查登录请求的HTTP信息头管理器。3. 核对HTTP请求采样器中的基础配置。变量值为空或NOT_FOUND1. JSON提取器路径写错。2. 服务器响应格式与预期不符。3. 登录请求失败无有效响应。1. 使用“查看结果树”查看登录请求的“响应数据”标签页确认JSON结构。可以用在线JSONPath测试工具验证$.data.access_token路径是否正确。2. 检查响应是否是JSON有时错误时返回的是HTML页面。3. 确保登录请求本身是成功的状态码200。所有用户都用同一个Token1. 误将JSON提取器放在了测试计划或线程组层级且作用域选择不当。2. 使用了全局变量。1.确保JSON提取器是作为登录请求的“子元件”添加的。这样它的作用域仅限于该请求提取的变量属于线程局部变量。2. 避免使用__setProperty等函数设置全局属性除非你确实需要跨线程共享。性能测试时登录接口先扛不住登录接口本身成为瓶颈业务接口还没开始压测登录就超时或报错了。1. 检查登录接口的响应时间如果过长需要先优化该接口或调整测试策略。2. 可以考虑使用“仅一次控制器”将登录操作放在里面但这违背了真实场景仅用于临时绕过登录瓶颈专注于测试业务接口不推荐长期使用。3. 更真实的做法是准备更强大的登录集群或者使用已经提前批量生成好的Token池但这同样会失去对登录环节的压测。4.3 一个容易被忽略的优化点连接复用与超时设置在“HTTP请求默认值”配置元件中有两个设置对性能测试结果影响很大Use KeepAlive务必勾选。这允许JMeter复用TCP连接避免每次请求都进行三次握手能极大提升压测效率也更贴近现代浏览器的行为。超时设置根据测试场景合理设置“连接超时”和“响应超时”。在压测初期可以设置得稍短一些如2000-5000毫秒快速发现接口瓶颈。在稳定性测试时可以设置得和产品要求一致。最后记住性能测试脚本的核心是“模拟真实”。你设计的这个“登录-业务”流程越贴近真实用户的操作顺序、间隔时间使用“定时器”元件来模拟思考时间和数据差异得到的测试结果就越有价值越能发现系统中潜在的性能瓶颈和风险。把这个基础流程搭建牢固后续无论是添加更复杂的业务链、参数化还是分布式压测你都会得心应手。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
