JMeter做接口测试大家都不陌生但一旦碰上异步接口情况就完全不一样了。同步接口发个请求等响应收工异步接口呢请求发出去服务器先回你一个“已收到正在处理”真正的业务结果可能几秒甚至几分钟后才出来。你要是按同步的思路去做验证要么断言根本没数据可断要么傻等超时脚本直接飘红。我最早被这个问题卡住是在测一个批量导入任务请求返回后结果状态一直是“处理中”脚本断言失败不说整个压测流程也断在半路相当憋屈。这篇东西就是我后来把JMeter异步接口测试整个趟平之后的实战记录从原理拆解到两种可落地的方案再到踩坑实录全部交代清楚适合正在用JMeter做接口自动化或者在压测过程中被异步逻辑折磨的测试工程师朋友。很多人在搜索引擎里搜jmeter异步接口测试多半是已经撞上了同步脚本在异步场景下不好使的墙。JMeter给的答案是异步取样器或者手动组合循环轮询但网上的教程大多只讲单一方案要么太浅要么太老。我这次把两条路都走了一遍也对比了各自的优缺点。先说结论日常自动化接口测试用轮询模式最稳既有可见的请求日志和响应快照又方便调试和排查问题如果是要在性能压测里处理异步链路或者对响应延迟敏感那基于Async Sampling的直连方案更合适少了一层层轮询请求对施压机也友好一些。1. 异步接口为什么这么难测1.1 同步和异步的本质差异同步接口的模型是“请求-等待-响应”客户端发一个HTTP请求过去服务端业务处理完再返回结果整个链路在同一个连接里闭合。这种模型对测试工具极其友好JMeter就是为这种模型设计的你发出请求它拿到响应体然后断言、提取变量一步到位。异步接口完全不同。客户端发请求之后服务端通常直接返回202 Accepted或者自定义的状态码真正要的数据在另一个任务队列里慢慢跑。客户端想拿到最终结果只能靠两种方式主动轮询查询任务状态或者由服务端在处理完成后回调一个通知地址。轮询模式下测试脚本就得反复发查询请求直到状态变成成功或失败回调模式下测试脚本还得多起一个HTTP服务来接收通知。这就对JMeter的脚本结构提出了新要求你不能在拿到第一个响应之后立刻去做结果断言了。还有一个更隐蔽的差异是时序。同步接口的响应顺序是确定的异步接口里请求A的结果可能比请求B晚到哪怕你明明先发了A。一旦涉及关联和断言脚本很容易被这种乱序坑到。1.2 实际业务里的典型异步场景我碰到的异步接口大致有三类覆盖了绝大多数的情况批量任务类批量导入用户、批量处理订单、群发消息。服务端先受理请求后台按批次慢慢执行提供给客户端一个任务ID用于查询进度。外部系统交互类比如对接支付渠道、征信查询、短信网关。这些接口的返回往往依赖第三方系统的响应时间不可能让调用方干等所以做成异步等第三方回调后再更新结果。流式处理类比如视频转码、报表生成、大数据分析任务。处理耗时可能从几十秒到几十分钟必须走异步。不管你测的是哪一类测试脚本的核心逻辑都落到两件事上拿到任务标识然后想办法等到最终结果。下面要讲的两种JMeter实现方案本质上就是围绕这两件事展开的。2. 轮询模式下用JMeter实现异步测试的完整设计2.1 主流程拆分与取样器布局轮询模式的设计思路很直白把测试流程拆成“提交任务-轮询查状态-断言最终结果”三个逻辑段分别用不同的取样器承载。整体结构形态如下线程组一个用户一次业务的完整过程循环次数由压测场景决定事务控制器如果请求事务名可以包一层事务控制器把整个异步流程合并成一个事务来统计耗时HTTP请求取样器1提交异步任务比如POST /api/async/tasksJSON提取器从响应里取taskId循环控制器循环执行状态查询循环条件用Groovy脚本控制HTTP请求取样器2查询任务状态比如GET /api/async/tasks/${taskId}JSON提取器取出任务状态字段退出条件判断用If控制器配合Groovy脚本判断是否达到终态断言最终状态断言这个流程看起来简单但有几个细节必须处理到位。先说循环控制器里的退出条件。查询接口返回的状态字段可能是“RUNNING”“SUCCESS”“FAILED”等枚举退出条件要判断两种情况一是状态已经变成终态该停就停二是循环次数达到上限防止服务器状态异常时脚本永远轮询下去。这里的实现方式推荐用循环控制器的循环次数设置一个最大尝试次数比如30次再配合内部的If控制器来判断是否break。2.2 使用JSON提取器捕获任务ID任务ID一般藏在提交请求的响应体里。比如响应是{code:0,data:{taskId:abc123},msg:success}在HTTP请求取样器上添加JSON提取器配置如下Name of created variabletaskIdJSONPath expression$.data.taskIdDefault valueNOT_FOUND这里有个坑很多JMeter版本里JSON提取器有个“Match No.”参数默认填1就行。但如果服务端在异常情况下没返回taskId提取出来就是默认值NOT_FOUND。这样的值发到查询接口里大概率会得到一个错误的返回好在后面循环里会继续查最终也会因为超时退出不会无限循环。在有些真实的接口设计中服务器返回的任务标识可能不在响应体里而是放在响应Header中比如Location字段又或者是自定义的X-Task-Id。面对这种设计提取器就要从JSON改成正则表达式提取器配置相应调整。比如响应头里是X-Task-Id: abc123正则提取器配置Apply toJMeter Variable引用名称taskId正则表达式X-Task-Id:\s*(.)模板$1$用正则提取器响应体里取不到JSON任务ID时也能有兜底。如果你的项目两种响应格式都有那就同时挂两个提取器变量名相同后执行的会覆盖先执行的逻辑上要仔细捋一下优先级别搞反。2.3 循环控制器与最长等待时间控制循环控制器的核心配置是循环次数。我这里给一个参考配置想要最长等待60秒每次轮询间隔2秒那最大尝试次数就是30次。具体实现上在循环控制器里添加一个固定定时器Fixed Timer线程延迟设为2000毫秒然后把循环控制器的循环次数设为30。为什么要单独加定时器而不是直接在HTTP请求里配置延迟因为轮询的查询请求本身有执行时间可能在50毫秒到几百毫秒之间波动如果你在定时器里写死2秒实际轮询间隔会是2秒加查询耗时最长等待时间就偏长了。更精确的做法是循环次数不要盲目拍脑袋而是结合业务的SLA来定比如业务要求任务在30秒内完成那就把最大尝试次数设为20次每次间隔2秒留出余量并设置合理的失败超时阈值。循环内部再加一个If控制器用来判断是否已经到达终态如果是就通过脚本跳出循环。在JMeter中判断并跳出循环常用方式是Groovy脚本设置一个标志位再配合线程组里勾选“停止线程”或者用Flow Control Action取样器来中断循环。如果不想用If控制器加Flow Control Action的组合循环次数设置固定值也是一种简单粗暴但可靠的方案轮询30次不管中间是否已经成功都继续发完剩下的请求。这样做有很多无意义的查询请求在调试和排查脚本时会带来噪声但结构最简单不容易出错。我的建议是脚本初期验证阶段可以先用这种方式快速跑通后面再优化为提前退出。2.4 轮询模式脚本的断言与关联设计在循环退出之后需要检查状态是不是期望的终态。此时可以添加一个JSR223断言或者普通的响应断言来核对最终状态字段的值。JSR223断言用Groovy写起来很灵活可以拿到之前提取的变量做判断还可以把失败截图或者响应片段写入结果树里输出更友好的调试信息。举个例子我在轮询循环结束后在JSR223断言里写这么一段def status vars.get(taskStatus) if (!SUCCESS.equals(status)) { AssertionResult.setFailure(true) AssertionResult.setFailureMessage(Task final status is status , expected SUCCESS) }在JSR223断言里AssertionResult是预置对象不需要自己实例化。如果你之前用vars.put(taskStatus, extractedValue)存了变量在这里直接用vars.get取出来判断非常方便。轮询模式的关联还有一个容易被忽略的地方如果你要在一个线程里连续跑多个异步任务比如先提交任务A再提交任务B后一个任务的任务ID是独立的但JMeter的变量是线程作用域的所以第二次提交后taskId会自动被覆盖。这个没问题。但如果同一线程里并发跑多个任务把任务ID存成普通JMeter变量就会互相覆盖。遇到这种场景需要把taskId保存到数组或者使用唯一的变量后缀或者干脆在后续的查询请求中用参数而不是路径变量来传递。3. 手把手实现一个可复现的轮询模式脚本3.1 环境准备与文件结构说明假设你已经装好了JMeter环境。如果还卡在jmeter安装上建议直接解压官方二进制包到指定目录配置好JAVA_HOME需要JDK8及以上JMeter 5.x对JDK8兼容没问题然后运行bin目录下的jmeter脚本启动GUI。环境这块不展开太多重点讲脚本结构。我从实际项目中整理了一个典型轮询脚本的树形结构你可以照着搭Test Plan (异步任务测试计划) ├── Thread Group (异步任务线程组) │ ├── CSV Data Set Config (测试数据参数化) │ ├── Transaction Controller (异步流程事务) │ │ ├── HTTP Request - 提交异步任务 │ │ │ ├── JSON Extractor (提取taskId) │ │ │ └── Regular Expression Extractor (备用提取) │ │ ├── Loop Controller (轮询查询循环) │ │ │ ├── Fixed Timer (轮询间隔) │ │ │ ├── HTTP Request - 查询任务状态 │ │ │ │ ├── JSON Extractor (提取taskStatus) │ │ │ │ └── If Controller (判断终态并退出) │ │ └── JSR223 Assertion (最终状态校验) │ └── View Results Tree (调试用) └── Simple Data Writer (结果输出)参数化这步我习惯用CSV Data Set Config把业务数据放到外部文件里。异步任务的参数化比同步更要注意每条用户数据的任务ID必须唯一因为任务是异步执行的如果用重复参数并发提交服务端可能会做去重导致后提交的请求直接返回重复任务无法覆盖真实场景。CSV文件里的数据要有足够的区分度压测前自己先扫一遍。3.2 提交任务接口与查询接口的配置细节提交任务的HTTP请求配置常规的地址、路径、请求体都不多说关键是请求体的数据要正确参数化。假设提交任务接口的请求体是JSON格式{ bizType: IMPORT_USER, fileId: ${fileId}, callbackUrl: }在JMeter的HTTP请求取样器里Body Data标签页直接粘贴这段JSON其中${fileId}会从CSV变量读取。这里有一个JMeter细节Body Data里引用变量用${}语法即可但请求头必须在HTTP Header Manager里加上Content-Type: application/json否则服务器可能拒收或者按表单解析导致请求体里的JSON被解析成键值对提交任务直接失败。查询接口一般是GET带上路径参数或者查询参数。比如GET /api/async/tasks/${taskId}查询接口响应结构通常是{ code: 0, data: { taskId: abc123, status: RUNNING, progress: 45, resultUrl: http://xxx/result }, msg: success }这里用JSON提取器提取$.data.status变量名设为taskStatus。在If控制器的判断条件里写Groovy表达式判断taskStatus。If控制器的Condition一般这样写${taskStatus} SUCCESS || ${taskStatus} FAILEDIf控制器内放一个Flow Control Action取样器Action选择“Exit Loop”。这个组合的效果是当状态为SUCCESS或FAILED时跳出循环控制器继续执行后续的断言。这里注意Groovy表达式里的双引号转义变量包含空字符串时如果不加引号会报Groovy语法错误。3.3 轮询间隔与循环次数的参数计算方法轮询逻辑跑起来后关心的核心指标是任务的最长等待时间和实际轮询频率。假设业务要求任务必须在30秒内完成查询接口的平均响应时间是200毫秒每次轮询间隔设定为2秒那么循环次数N的计算方式是N ceil(30秒 / (2秒 0.2秒)) ceil(13.6) 14次加上一定的冗余量实际我一般会取20次这样一个任务的查询阶段最长等待时间是20*(20.2)44秒超过业务SLA约10秒这种冗余是为了防止查询接口慢导致轮询次数还没有发完、任务其实已经完成但没被识别到的情况。如果你的业务SLA很严格可以把冗余缩小到1.2倍并密切观察压测过程中有没有因为轮询过频给服务端造成额外负担。在实际压测时轮询请求会占据一部分服务端连接和线程资源。并发用户越多轮询请求在总请求数里的占比越高这个比例需要在报告里单独统计否则可能把性能瓶颈误判到业务接口上。我见过一个压测项目业务请求TPS只有80但轮询请求TPS已经到400了整体负载被轮询抬高了一大截如果没有分开统计调优方向会被带偏。3.4 用监听器与结果树验证轮询脚本正确性脚本第一次跑通之前强烈建议加View Results Tree监听器查看每个采样的请求和响应。你可以直观看到提交任务返回的taskId、查询请求的响应状态以及循环是否在预期时机退出。确认无误后再把这个监听器禁用或者移除换成聚合报告和Simple Data Writer这类轻量级结果输出组件。压测过程中查看轮询是否实现预期还有一个方法在聚合报告里勾选“Save Response Data”并配合错误日志输出或者直接在JSR223断言里把非预期状态打印出来。实际上更简单快捷的方式是查看Simple Data Writer生成的CSV结果筛选出查询请求的错误记录看看是连接超时还是状态断言失败。查询请求的响应体通常比较大如果不需要记录可以在HTTP请求取样器里勾选“Store Response as MD5 Hash”只存MD5减小结果文件体积。4. 异步取样器直连方案与回调地址的实战玩法4.1 异步取样器组件的工作原理轮询模式虽然直观但每发起一个业务请求至少要额外产生十几甚至几十个查询请求在压测场景下会让施压机的线程数和网络IO飙升。所以JMeter官方后来在5.x版本逐步强化了异步取样器Async Sampling的能力。异步取样器的原理是请求发出后不等待响应而是在发送时把回调地址一同发给服务器。服务器业务处理完成后主动向这个回调地址推送结果异步取样器会去接收并返回给JMeter线程然后继续执行后续逻辑。换句话说它把“轮询”变成了“监听回调”对施压端来说少了很多中间请求。JMeter的异步取样器核心组件是“Async Sampling”在组件列表里搜索即可找到也有个别版本叫“jpgc - Async Sampling”。这个取样器底层通过一个轻量的HTTP服务器来接收回调。配置项上必须指定监听端口、以及回调路径。回调地址可以写死也可以通过变量从测试计划里传入。为了与真实业务更贴近回调地址一般会带上任务标识比如回调路径里带taskId避免多个任务结果混淆。4.2 配置异步取样器的关键参数与回调接收实际操作中我会在测试计划里先添加一个HTTP请求用来提交异步任务然后在请求体里加上callbackUrl字段写明异步取样器要监听的地址。假设JMeter所在机器的IP是10.0.0.5异步取样器监听在8888端口路径是/callback/task那回调地址就是http://10.0.0.5:8888/callback/task/${taskId}如果你在提交任务的接口里调用时传入这个回调地址服务端任务完成后就会往这个地址发HTTP请求。JMeter的异步取样器会收到并把它作为取样器响应返回这样取样器的响应数据就是回调的body。配置异步取样器的核心参数有这几个端口号监听回调请求的端口要保证不被其他程序占用回调路径用于匹配接收的请求路径响应超时时间如果超过这个时间没有收到回调取样器就会超时失败通常设置为业务SLA上限比如60秒线程池大小异步取样器内部接收回调用到的线程数一般默认值就够并发回调太高时需要调大这里的端口号在压测机上要提前确认没有冲突可以用netstat命令查一下。如果和JMeter自身或者监控代理占用了同一个端口回调就收不到脚本挂到超时。4.3 回调模式与轮询模式的选择依据两种模式的选择不是拍脑袋。若你的业务接口支持回调且测试环境能稳定访问施压机那我更推荐直接用异步取样器因为从请求数量到结果获取效率都更优。如果回调地址压根配置不通或者被测接口只支持轮询查询那就老老实实用轮询。性能压测场景还要考虑一个特殊问题施压机防火墙。回调是服务器主动连施压机的如果压测环境有防火墙拦截了入站连接回调模式直接就废了。我在一个客户的压测环境里遇到过这种情况回调地址在测试环境能通但到了压测机房测试服务器访问施压机的回调端口被安全策略拦死导致所有异步任务都超时。最后只能切回轮询模式把查询参数调低才把压测跑完。5. 异步测试中的并发陷阱与数据一致性问题5.1 线程数与连接池的匹配关系异步接口测试在压测场景下并发模型比同步接口复杂因为一个线程可能同时持有到被测服务的多个HTTP连接提交任务连接一个轮询查询连接一个或多个。如果JMeter的HTTP请求默认使用HTTPClient4实现它的连接池大小需要调整。JVM默认的HTTP连接池行为有时候比较保守如果你把并发线程数调到200而连接池上限是100那么一半的线程会在等待连接时白白阻塞。具体到JMeter可以在bin/jmeter.properties里或者通过JVM参数调整最简单的办法是在测试计划中添加一个HTTP请求默认值设置Connections per host参数将这个值调到稍大于并发线程数避免连接排队。实际我一般取并发数的1.2倍比如200并发就设240测试完再根据实际的连接活跃数微调。5.2 异步响应乱序对测试结果的影响异步场景下乱序是常态。比如你在线程组里设了10个用户每个用户提交一个异步任务任务完成时间有快有慢提交快的不代表完成快。如果断言里用到了提交时的全局标识比如事务名变量就需要仔细处理。一个常见的错误是把任务ID存成全局属性然后用全局属性去断言。多个线程并发时全局属性会被互相覆盖断言结果就是假的。正确做法是使用JMeter的vars对象它是线程独立的不存在跨线程覆盖的问题。如果确实需要跨线程查询某个任务状态可以考虑把taskId和线程号组成唯一键存成Properties比如props.put(task_ threadNum, taskId)然后按需读取。但不建议在并发测试里这么干断言逻辑复杂容易犯错。5.3 回调模式下数据一致性的验证方案异步任务的测试难点不止在“等结果”还在于“验证结果是否一致”。比如你提交了一个批量导入任务回调返回了成功但后台的数据实际只导入了一半这种问题靠接口测试可能发现不了需要配合数据库或者其他下游系统来验证。我的建议是给异步测试脚本加一层“终态校验器”在断言最终状态为成功之后再调用一个查询接口或者直接查数据库核对业务数据是否完整。这一步可以用JDBC请求取样器查数据库记录行数也可以用HTTP请求查业务列表接口比对预期数据。只有状态和数据都对了这次异步任务才算真正通过。我在实际项目中做过的方案是提交任务前先记下当前数据表行数回调成功后查一次行数差值等于预期导入条数才算PASS。这个方案在JMeter里用两个JDBC请求取样器加上一个JSR223断言容易落地而且能发现不少接口状态和业务数据不一致的隐藏bug。6. 常见问题与排查技巧实录6.1 循环轮询脚本为什么总是等到超时这是我最常被问到的问题。脚本逻辑看着没问题taskId提取到了查询请求也发出去了状态一直停在RUNNING最后循环次数耗尽断言失败。排查步骤按顺序执行第一步用View Results Tree截图确认手动执行这个查询接口时最终状态到底能否变成SUCCESS。如果手动查也一直是RUNNING那问题出在被测服务而不是脚本。第二步确认循环里是否用了正确的变量引用。很多人把taskId提取成局部变量却在循环外部的If控制器里用${taskId}作用域不对自然取不到值。第三步检查查询接口的响应内容是否和你预想一致。有的接口失败时返回的错误体里没有status字段JSON提取器提取结果为空后续判断永远不成立。如果你发现自己脚本里JSON提取器变量提取不到值优先看响应正文是不是被服务端包了一层加密或者压缩格式。常见的有GZIP压缩JMeter默认会处理但有些环境需要手动在HTTP Request里配置解压缩。6.2 异步取样器收不到回调的排查方向收不到回调问题可能出在三个环节提交任务时回调地址是否真的写对了。建议在提交任务接口的响应或者数据库记录里查看服务器存储的callbackUrl是不是包含了正确的IP和端口。有的服务器会把非法的回调地址直接丢弃但接口返回照样成功这时候必须要查存储。防火墙或安全策略是否拦截了回调端口。在施压机上用netstat -an | grep 8888确认端口有没有监听再用tcpdump或者wireshark抓包确认有没有来自被测服务的SYN包进来。如果在测试机以外访问该端口不通就要联系网络管理员开放策略。异步取样器的回调路径配置是否和提交的callbackUrl匹配。如果回调请求发到了/callback/task而异步取样器监听的是/callback/task/result路径对不上请求会被丢弃或者返回404。路径匹配这一项最好在配置好之后用一个简单的curl命令模拟回调来验证取样器是否能正确接收。6.3 JMeter GUI模式压测异步接口的内存溢出用GUI模式跑高并发异步测试内存溢出是家常便饭。View Results Tree在GUI模式会保存所有请求和响应数据异步接口的查询链路又长很容易就把堆内存塞满。解决办法分两步走。第一步压测一定要用命令行模式jmeter -n -t test.jmx -l result.jtl -e -o report不要开着GUI跑。第二步jmeter.sh里的JVM堆参数要调高默认的1GB肯定不够。我一般设置到4GB起步HEAP-Xms4g -Xmx4g如果施压机内存足够直接给到压测进程可用内存的80%都行。但注意别把机器的物理内存全给JMeter还要给操作系统和监控工具留余量。另外一个常被忽略的点是施压机的网络连接数。异步模式下的短连接特别多如果施压机本身的文件描述符限制过低会出现“Too many open files”的错误线程直接挂掉。建议压测前用ulimit -n检查并调大限制比如到65535。6.4 断言失败后如何快速定位是业务问题还是脚本问题异步接口测试失败时脚本问题和业务问题会在界面上混在一起。我的排查习惯是先看失败发生在哪个取样器。提交任务失败基本属于参数或鉴权问题查询阶段失败需要区分是被测服务查询接口本身不稳定还是因为轮询太频繁触发了限流最终断言失败则大概率是业务逻辑问题。快速定位的实用技巧是在JSR223断言里把相关的上下文信息拼进失败信息。比如失败时把taskId、taskStatus、当前循环次数、最近一次查询响应体前200个字符都拼到失败信息里。这样结果文件里就能直接看到失败原因不用再去日志里翻半天。6.5 JMeter提取token到全局变量的联动问题异步接口测试通常也需要登录态很多人的实际场景是先调登录接口拿token再带到异步任务中。JMeter里提取token到全局变量这个操作和异步接口的关联组合有特殊之处轮询查询阶段也必须带token否则查询接口可能返回未登录错误。我习惯把token放到HTTP Header Manager里作用于整个线程组的所有请求这样提交和查询都会自动携带。但如果脚本里有多个线程组比如登录线程组和业务线程组分开那就需要用setProperty和getProperty做跨线程传递具体来说就是登录接口后通过BeanShell或JSR223后置处理器把token存成全局属性业务线程组里的HTTP Header Manager再引用${__P(token)}。这个做法是网上jmeter提取token到全局变量搜索量很大的原因大家几乎都会碰上但要注意跨线程组之间启动顺序要控制好业务线程组必须在登录完成后再启动可以用Thread Group的setUp Thread Group或者测试计划级的调度器来保证顺序。7. 异步测试脚本的扩展与后续优化建议7.1 把异步测试嵌入CI流水线的调整点本地脚本跑通了还不够嵌到CI流水线里才是自动化测试的完整形态。CI环境里跑JMeter异步脚本我建议做几个调整把轮询循环次数改成环境变量可配置比如用__P(maxRetries, 20)这种方式开发和CI里用的值不一样时可以灵活调。结果断言不要依赖GUI树查看全部通过JSR223断言生成结构化结果再在CI里解析jtl文件判断构建是否通过。在流水线里带上测试环境的重置步骤。异步任务跑完会残留大量后台任务和数据如果不清理下一轮测试会受到干扰。7.2 从功能测试到性能压测的扩展思路异步接口的性能压测指标口径和同步接口不一样。同步接口看TPS和响应时间就够了异步测试还需要关注提交接口的TPS反应服务端受理任务的能力任务完成吞吐量异步处理系统单位时间内实际完成的任务数任务在队列中的平均等待时间能反映后台处理能力是否跟得上提交速率轮询查询接口的压力贡献如果轮询请求量过大可能成为压测瓶颈需要和业务请求分开统计报告里要把这些指标分开呈现而不是只给一个总TPS。异步系统的调优通常不是只看JMeter结果要结合队列深度、处理线程数、数据库连接池等一起分析脚本这边能给出的关键数据是提交速率和完成速率之间的关系。7.3 我对异步测试工具选型的个人心得最后说一点个人感受。很多时候团队纠结用JMeter还是别的工具来做异步接口测试我个人的观点是JMeter在异步测试这一项上确实没有专门的商业工具或者代码型测试框架那么直接但它的优势在于脚本化的配置足够灵活轮询和回调都能落地而且和性能压测、结果分析是同一个工具链不用来回切换。对于已经在用JMeter的团队把异步测试这块补上远比引入一套新工具的成本低。异步接口测试的本质不在于你会不会用某个取样器而在于你能否清晰地描述出这个异步流程的状态迁移过程提交、排队、执行、成功、失败、超时。把状态迁移弄清楚了脚本结构自然就出来了。希望这篇东西能帮你在碰到异步接口时少走几步弯路。