做接口测试的JMeter是绕不开的工具。这个系列写到第四十七篇今天专门讲两件看起来基础、实际坑非常多的事怎么把测试用例批量导入JMeter以及GET请求里URL带参数时应该怎么处理。这两件事几乎每个从手工测试转接口测试的人都会遇到——用例导不进去数据量一大就只能手动一条条点时效性极差URL带参数时要么中文乱码要么变量没替换成功要么路径参数和查询参数分不清请求出去全是404。这篇就把导入测试用例和GET请求URL参数化拆开讲透顺带把CSV Data Set Config、URL编码、变量引用这些配套知识点补齐新手能照着搭出一套能用的测试计划老手也能回头查漏补缺。1. 为什么这两个问题值得单独拆一篇1.1 导入测试用例接口测试从手点走向数据驱动实际工作中我见过不少刚接触JMeter的测试同事打开JMeter第一件事就是添加一个HTTP请求填好服务器IP、路径、参数然后点一下绿色三角跑一次看到响应结果正常就觉得自己会接口测试了。这种“一次一个请求”的用法没有错但它只能算接口调试离真正的接口测试还差得很远。真正的接口测试尤其是版本回归阶段往往要覆盖几十个接口、几百条用例。一个接口要验证正常入参、缺参、错参、边界值、异常字符串等不同情况如果每一条用例都需要手改参数再点一次运行人就被工具绑死了。更别提还要统计通过率、看断言结果手工根本做不完。所以“导入测试用例”这件事本质上是把测试数据和测试脚本分离脚本只负责发请求、收响应、做断言数据放在CSV、Excel或数据库里JMeter通过配置元件循环读取一个HTTP请求就能跑完几百条数据。这就是接口测试里常说的数据驱动。有人会问既然要数据驱动为什么不直接用Python写脚本偏要用JMeter我的看法是JMeter在测试计划可视化、断言配置、压测参数调度、HTML报告生成这一块非常成熟团队协作时也不要求每个人都有编码能力。CSV Data Set Config配合循环控制就能让不写代码的测试人员也维护起大批量用例。1.2 GET请求的URL参数最容易“看起来对实际错”的地方GET请求在所有接口里占的比例非常高登录、列表查询、详情获取大部分都是GET。而GET请求的参数和POST不一样POST的参数可以放在请求体里JMeter在Parameters和Body Data两个页签中处理得很方便GET的参数需要全部塞进URL。URL带参数会引出几类典型问题。第一参数位置混乱。同样一个/user接口可能是/user/list?page1size20这种查询参数也可能是/user/1001这种路径参数。新人区分不开经常把路径参数写成query参数接口返回404都找不到原因。第二URL编码问题。URL里不能直接出现中文、空格、#、这些特殊字符参数值里有一个符号如果不处理服务端会把参数擅自截断成两个。很多人在这个细节上吃过亏。第三参数值动态获取。一个用例执行完下一个用例可能要依赖前一个接口返回的ID这就涉及关联。如果ID写死在URL里脚本就没有扩展性。所以GET请求URL带参数表面上是个格式问题实际上牵扯到参数设计、编码、关联、作用域等多个环节这也是接口测试里很关键的一个分水岭。2. 先把用例文件本身弄对CSV的格式、编码与字段设计2.1 用例文件的设计列出一套真正能用的字段很多新人把CSV文件当成Excel表格随手一填没表头、列也不固定结果导入JMeter后变量名对不上要花大量时间调试。CSV文件虽然不是严格的数据库表但既然要导入工具字段设计就必须稳定。这里列一套我实际用得最多的表头你可以根据项目情况调整case_name用例名称比如“用户列表_第一页_正常”path接口路径比如/api/user/listparam_key参数名param_value参数值expected_code期望状态码比如200expected_msg期望响应中包含的文本对应到JMeter里这份CSV的列名就是变量名。case_name、expected_code、expected_msg这些字段不一定都用在实际请求里它们可以配合断言使用。这里有两个原则要特别注意。第一表头要么用英文要么用拼音千万不要用中文。JMeter对编码的处理在不同平台上有差异中文表头在Windows下极容易出现乱码一旦变量名变成乱码脚本里引用变量就没法工作。第二不要把所有参数堆在一个单元格里。有的同事喜欢在param_value里写“name张三age18”这种写法会让数据驱动失去意义因为一行里包含多个参数组合CSV无法按列解析脚本也没法单独引用其中一个参数。一个参数一个单元格宁可列多一点。先在Excel里排好版最后另存为CSV。下面是一个最小示例case_name,path,param_key,param_value,expected_code,expected_msg 用户列表第一页,/api/user/list,keyword,测试,200,success 用户列表第二页,/api/user/list,keyword,测试,200,success2.2 编码、分隔符与Quoted data三个最容易翻车的细节CSV文件的编码问题非常关键。Excel在Windows上默认保存CSV是ANSI编码JMeter读取时如果按UTF-8解析中文字符就会变成乱码反过来也一样。最稳妥的办法是在Excel里使用“另存为CSV UTF-8”格式然后在JMeter的CSV Data Set Config里File encoding填写UTF-8两边保持一致。第二个容易翻车的是分隔符。CSV默认用英文逗号做分隔但如果参数值里本身有英文逗号比如keyword吃饭,睡觉CSV解析会把这一行拆成三列数据错乱。解决办法有两个一是数据中避免使用英文逗号改成中文逗号或空格二是用双引号把含有逗号的字段包起来然后在CSV Data Set Config里勾选Allow quoted data。第二种方式更通用但如果数据量大还是建议在设计阶段就避免英文逗号最省心。第三个细节是表头行。如果你的CSV第一行是表头且你在CSV Data Set Config里手工填了Variable Names那必须勾选Ignore first line让JMeter跳过第一行。如果你不填Variable Names某些版本会把第一行当成变量名。为了不受版本差异影响建议统一用“Variable Names中手工写变量名勾选Ignore first line”这个组合。2.3 不是CSV怎么办Excel与JSON数据的导入思路有人问手上只有xlsx文件或者用例是JSON导出的能不能直接导入JMeter可以但思路不一样。xlsx文件最省事的方法是先在Excel里打开另存为CSV格式注意选“CSV UTF-8”。如果文件特别多可以用WPS或Python做批量转换转换后保持路径一致。JMeter本身没有直接读取xlsx的配置元件想直接读xlsx需要靠Apache POI插件维护成本很高正常项目里没必要。JSON格式的用例文件不太适合直接喂给CSV Data Set Config因为这个组件只认识二维表数据。如果用例本身以JSON数组形式存在建议先转成二维表再存成CSV或者用JSR223脚本在运行前把JSON拆成行写入CSV。如果JSON是接口响应数据而不是用例文件那场景就变了应该用JSON Extractor提取器去取属于另一类问题。总结一句经验90%的接口测试用例用CSV就够了不要为了炫技去折腾新组件。工具最终是为效率服务的不是为复杂服务的。3. CSV Data Set Config导入用例的核心配置逐项拆解3.1 一份配置参数一个都不能漏CSV Data Set Config是导入用例的入口它放在线程组下的配置元件里作用是在每次请求前从CSV文件读取一行数据并把它赋值给对应的变量。面板上配置项不算多但每一项都能影响执行结果。Filename填CSV文件的路径。建议用绝对路径。JMeter的相对路径是基于启动目录来定位的有时候GUI里跑得好好的一用命令行跑就找不到文件。我踩过这个坑所以现在统一用绝对路径除非项目里有明确的bin目录约定。File encoding填UTF-8。如果你的CSV是别的编码改成对应的。Variable Names多个变量名用英文逗号分隔顺序要和CSV列顺序一致。变量名不要带空格和特殊字符。Delimiter默认英文逗号。如果改用制表符等这里要同步改。Allow quoted data当数据中带逗号且用双引号包住字段时勾选。Recycle on EOF与Stop thread on EOF这两个要一起看下一节单独展开。Sharing mode默认All threads指所有线程共享文件读取游标。多线程并发时默认即可保证每一行不会被重复读改成Current thread group后每个线程组有独立游标具体选择看并发模型。关于Filename我多说一句。如果团队习惯把测试脚本和测试数据放到JMeter的bin目录统一管理那用相对路径没有问题但如果你换了电脑、换了工作目录相对路径很容易失效。与其花时间排查“找不到文件”这种低级问题不如直接用绝对路径省心。3.2 EOF、循环与共享模式控制用例读取行为的三个关键开关Recycle on EOF和Stop thread on EOF让很多新手头疼其实理解起来很简单EOF就是文件读到末尾之后的行为。只想把用例从头到尾跑一遍那Recycle on EOF选FalseStop thread on EOF选True。这样CSV文件读完后线程会停止不会死循环。想做循环压测比如100条用例循环跑10轮那Recycle on EOF选TrueStop thread on EOF选False。文件读到底之后会回头从第一行继续读线程可以一直跑。如果两个都选False文件读完之后JMeter会继续发请求但变量取不到新值可能直接报错或者用上一次的旧值继续发。这个状态最容易出现在“循环次数设大了但CSV行数不够”的场景很多线上压测翻车就是这原因。Sharing mode的作用同样关键。All threads模式下所有线程组的所有线程共同使用一个文件读取游标适合模拟不同用户并发读取不同数据。Current thread group模式下游标在每个线程组内独立适合不同线程组跑不同数据集。Current thread模式下每个线程单独游标每个线程都会重新从第一行开始读取全部用例。选择原则只有一个想清楚你希望哪些线程去瓜分同一份用例数据。3.3 导入用例后怎么确认变量真的到位了这个环节很多人直接跳过结果脚本一跑全是原样传出去请求里显示的都是字符串。要确认变量是否真的导入成功最简单的办法是在线程组下添加一个Debug Sampler放在CSV配置之后。Debug Sampler会把JMeter变量、属性、系统属性输出到查看结果树里。运行一次在结果树里就能看到类似key:value形式的内容case_name用户列表第一页param_value测试。如果看到的还是原样字符串说明变量名拼错了或者CSV没被读取。另一个办法是在HTTP请求里加一个临时参数值写成变量运行后看请求是否被替换成真实值。不过Debug Sampler更直观新手建议优先用。确认变量到位后再去配置HTTP请求能省掉大量排查时间。我自己每次新建测试计划都保持这个习惯先跑一条看到变量被替换再放量跑全量。4. GET请求URL带参数先搞清楚参数放在URL的哪个位置4.1 Query参数与Path参数两种写法别混用GET请求的URL带参数至少分两种位置。第一种是Query参数也叫查询参数。典型形式是http://192.168.1.10:8080/api/user/list?page1size20keyword测试。问号后面的page1size20keyword测试就是Query参数服务端通常通过request.getParameter(page)这种方式获取。第二种是Path参数也就是路径参数。典型形式是http://192.168.1.10:8080/api/user/1001。这里的1001不是独立键值对而是路径的一部分服务端通过路径匹配来解析比如/api/user/{id}。很多新人混用的典型场景接口文档写的是/api/user/{id}结果请求里写成了/api/user?id1001。服务端根据路由匹配不到直接404。反过来文档写的是Query参数有人却拼成了/api/user/list/1001也一样对不上。在JMeter里这两类参数的配置位置不一样。Path参数要写在HTTP请求的Path输入框中比如/api/user/${userId}Query参数可以写在Path中也可以写在Parameters表格里。我的建议是不管哪种变量都要用方式引用这样数据驱动的用例才有意义。4.2 在JMeter里把URL参数写成变量三种写法与选择假设CSV里有两个变量userId、keyword想发一个GET请求路径是/api/user/${userId}Query参数keyword${keyword}有三种常见写法。写法一Path中拼接完整URLPath填/api/user/${userId}?keyword${keyword}服务器和端口在HTTP请求默认值里配好。这种写法直观适合参数少、需要快速查看完整URL的场景缺点是URL中的协议细节和路径混在一起可读性一般。写法二Path只写路径Query参数放Parameters表格Path填/api/user/${userId}然后在Parameters表格新增一行名称填keyword值填${keyword}。这种写法把路径和参数分离整齐干净参数多时特别推荐。写法三整个URL写在Path中服务器和端口留空Path填http://192.168.1.10:8080/api/user/${userId}?keyword${keyword}。适合快速调试但不利于环境切换。三种写法没有绝对好坏我的推荐是正式用例用写法二路径和参数分开临时调试用写法三也行关键是团队内统一。如果你用写法二JMeter发出请求前会自动对Parameters里的参数做URL编码这是默认行为一般不需要额外处理。手动拼URL则需要自己处理编码这也是下一小节要说的问题。4.3 URL编码中文和特殊字符不处理请求必炸URL编码存在的原因很简单URL里只能包含ASCII字符集中的一部分字符中文、空格、#、、%、等都不能直接出现在URL里。要传递这些字符必须转义成%XX的形式。举几个最常见例子中文“测试”在UTF-8编码后变成%E6%B5%8B%E8%AF%95空格变成%20变成%26#变成%23。于是问题就来了。如果keyword参数值是“测试”要么在CSV里直接存编码后的值%E6%B5%8B%E8%AF%95要么让JMeter自动编码。手动拼URL时最怕不加处理keyword测试直接发出去部分服务端能处理部分处理不了返回参数为空或乱码。更麻烦的是keyword的值里带有比如“吃饭睡觉”服务端会把“吃饭”和“睡觉”当成两个参数解析入库肯定出错。我的建议是能不手拼URL就不手拼。使用Parameters表格时保持Encode列默认勾选JMeter发送时会自动做URL编码。如果确实需要手动拼接可以在CSV里预先存放编码后的值或者用JSR223取样器对值做一次URLEncoder.encode再用变量引用。这里还有一个反方向陷阱参数值本身设计的就是%2F这种字符串本意是传递字面量结果被JMeter二次编码成%252F服务端拿到的不是预期内容。遇到这种情况可以在CSV里存好编码值或者把Parameters表格里对应行的Encode列取消勾选具体根据接口要求来。4.4 参数值从哪里来CSV、正则、JSON提取与BeanShell前面讲的参数主要来自CSV但接口测试里参数值不一定都来自用例文件有时需要动态生成。这里列一张参数来源对比表。参数来源适用场景典型写法优缺点CSV Data Set Config批量固定测试数据比如用户列表、手机号${userId}稳定可控但没有计算能力数据要提前准备正则表达式提取器从前一个请求的响应中提取内容token:(.?)通用性强但正则写起来繁琐性能一般JSON Extractor响应体是JSON时提取字段$.data.id比正则简洁是常用的关联方式BeanShell/JSR223动态生成时间戳、签名、随机数脚本计算后通过vars.put存储灵活但复杂JSR223配合Groovy性能更好举例说明关联的典型场景登录接口返回一个token下一个查询接口必须带上这个token。这时就需要在登录接口下添加JSON Extractor表达式写成$.data.token存入变量token然后在下一个请求的Header或参数中引用${token}。选择哪种方式取决于参数值从哪里来。固定数据用CSV依赖前序接口用正则或JSON提取动态生成用脚本。绝大多数GET请求的参数用CSV加JSON Extractor已经能覆盖日常需求。5. 完整实操导入用例并跑通一个带参数的GET请求5.1 测试计划搭建步骤直接照着点就行这里按一个完整的测试计划顺序说明大家照着建就行。第一步创建测试计划。右键测试计划名称建议写成“项目名模块名环境”比如“客户系统_用户模块_测试环境”日后找脚本不用打开看内容才能确认是哪一套。第二步添加线程组。右键测试计划选择ThreadsUsers→线程组。线程数、循环次数的配置放到后面单独说。第三步在线程组下添加配置元件→CSV Data Set Config。按第3章的内容配置好Filename、Variable Names、File encoding。一个线程组可以添加多个CSV Data Set Config但变量名不要重复。第四步添加配置元件→HTTP请求默认值。在这里填好协议、服务器名称或IP、端口号。同一个环境下的所有HTTP请求都不需要重复填这些公共信息以后换环境只需要改这一处。第五步添加Sampler→HTTP请求。Method选择GETPath部分写/api/user/${userId}Parameters表格填写Query参数。如果接口还有路径参数直接在Path里用${}替换。注意Path里的变量和Parameters里的变量不要重名。第六步添加断言。在HTTP请求上右键添加断言→响应断言。比较常用的是“响应文本包含expected_msg”匹配规则选“包含”要测试的模式里填${expected_msg}。第七步添加监听器。至少加上查看结果树和汇总报告。查看结果树用于调试汇总报告用于看整体通过情况。5.2 线程数、循环次数与用例条数怎么匹配线程组里有三个关键参数线程数、Ramp-Up时间、循环次数。它们决定用例怎么执行。假设CSV里有100条用例想跑一遍基准回归可以这样设置线程数填1循环次数填100。每次迭代读一行CSV100次迭代读完100条用例这是最简单、最好排查的方案。想模拟并发可以把线程数填10循环次数填10。10个线程并发共享同一个文件游标每个线程分别读取不同行同样能覆盖100条数据。这种方式能顺便观察接口并发表现但排查问题时数据归属会复杂一些。把一个接口打满可以设100个线程循环次数1。100个线程同时启各读一行。这个方案适合压测不适合功能回归。实际建议是功能回归阶段用1线程循环100次先保证数据都覆盖了压测阶段再改成多线程并发并重点关注CSV的EOF配置和Sharing mode。不要一上来就100个线程并发跑用例一旦有请求失败很难分清是接口问题还是数据问题。循环次数和CSV行数不一致时EOF设置非常重要。循环次数200、CSV只有100行时Recycle on EOF必须是True否则跑到100行后变量取不到值后续请求全变成空参或报错。如果希望跑完100行就结束就把循环次数设成-1无限循环让CSV的Recycle on EOFFalse、Stop thread on EOFTrue这样CSV读到最后一行后线程自然停止正好对应“每条用例执行一次”这也是我平时最常用的组合。5.3 用查看结果树和断言确认请求是真的对用例跑完后打开查看结果树点中任意一个请求右侧有三个页签取样器结果、请求、响应数据。看请求页签能看到JMeter实际发出的完整URL。如果URL里的变量已经被替换成CSV中的真实值说明CSV导入和变量引用都正确如果URL上仍然显示${userId}就说明链路出了问题。注意查看结果树有时会显示“未进行URL编码”和“已进行URL编码”两种形式的URL这是JMeter的两个展示字段关注真实发送的那一个即可。再看响应数据页签能直接看到服务端返回的响应体。如果响应体中出现预期结果并且响应断言显示通过这个用例就算过了。断言结果可以在监听器中的“断言结果”里查看能明确看到每条用例的断言通过或失败情况。我有个调试习惯第一次跑全量前故意在CSV里放两三条预期失败的数据检查断言是否真能抓出问题。如果断言结果里全绿但预期失败的数据也绿了说明断言配置太宽松没起到拦截作用。这个习惯帮我抓出过不少断言配置错误值得一试。6. 常见问题与排查技巧实录6.1 高频报错速查表下面这张表基本覆盖了导入用例和GET请求URL参数两个主题下的高频问题可按现象对照排查。现象原因解决办法请求发出后URL里的${name}没替换CSV Data Set Config没配好或变量名拼错检查Variable Names与脚本里的引用是否一致用Debug Sampler确认变量CSV中中文读取后变乱码CSV文件编码与File encoding配置不一致统一另存为CSV UTF-8File encoding填UTF-8参数值里有服务端把参数拆开手动拼URL时没对做编码或没用Parameters表参数值放进Parameters表格必须手拼时对编码为%26URL里出现%25、%252F等奇怪编码参数值本身包含%号被二次编码取消对应行的Encode勾选或存已编码值路径参数写成Query参数返回404分不清Path参数和Query参数按接口文档确认URI中的{}部分写在Path字段而不是参数表用例跑到中途线程停了CSV读完了且Stop thread on EOFTrue如果只想跑一轮这是预期行为如需多轮将Recycle on EOF设为True多线程跑同一份CSV部分线程读不到值CSV行数少于线程数或Sharing mode不合适行数不足时增大循环或调整线程数根据并发模型选择共享模式JMeter界面窗口控件重叠/撕裂Windows高DPI缩放导致Swing界面渲染异常在兼容性设置里开启“替代高DPI缩放行为”或调低系统缩放比例表格里还有一些衍生问题值得注意。比如CSV文件首行是表头但没勾Ignore first line结果第一条请求把“case_name、path”当成参数值发出去了。又比如CSV文件末尾有空行空行也会被当成一条用例导致请求参数为空。这两种问题都不会报错但会污染测试结果。6.2 排查工具与调试的几个实用小习惯我调试接口测试脚本有个固定套路先不看结果树先开Debug Sampler。把Debug Sampler放在线程组最开始运行一次后在结果树里看当前所有变量的值能迅速确认CSV导入是否成功。确认变量到位后再把Debug Sampler禁用继续跑HTTP请求。第二个小习惯是看响应结果之前先看响应Code。响应Code是200但断言失败问题大概率出在响应内容和预期值不匹配响应Code是404或500基本就是路径、参数或服务端逻辑的问题这时再回到URL和请求参数做检查。第三个习惯是用JSR223或BeanShell脚本输出关键值。在请求前加一个仅一次控制器里面放一个BeanShell Sampler用log.info把关键变量打印出来然后打开jmeter.log查看。这个方法在不方便开GUI的环境比如命令行压测时非常有效。最后一个习惯也是最重要的每次修改脚本后不要直接跑全量先手动把循环次数改成1跑通一条用例后再逐步扩大到全部。这个习惯看起来土但真的能省下大量定位时间。尤其是CSV、变量、断言一起调整的时候如果一次性跑全量出了问题你根本不知道是哪里改坏了。6.3 参数化用例设计的三点个人经验说到最后分享几点做接口测试这几年沉淀下来的经验。第一点CSV表头设计要站在复用角度别只考虑当前接口。哪怕今天只有一个GET请求、两个参数也建议把case_name、expected_code、expected_msg这些公共字段一起设计进去。以后加断言、做回归、出报告、排查问题都用得上。临时补字段意味着所有用例文件都要改一遍非常折腾。第二点URL和参数拆开维护。同一份CSV里path列只放路径query参数用独立的param_key和param_value列不要把“/api/user/list?keyword测试page1”整串写进一个单元格。整串写的坏处是一旦要改环境、改参数名、做变量替换文件根本没法复用。拆开后脚本和数据的边界才清晰。第三点环境切换不要靠改用例文件。域名、端口、协议这些和环境强相关的东西放在HTTP请求默认值里通过JMeter属性来管理。比如使用默认值配合命令行参数切换能够在不改动用例文件的前提下完成测试环境与预发环境的切换也避免把预发环境地址误用到测试环境这类低级事故。用例文件里只放业务数据脚本才能在不同环境间安全平移。数据驱动加上URL参数化算是JMeter接口测试里最基础的组合拳。把这套打熟后面再接触性能测试、持续集成也都是在同一套基础之上做扩展。说得再多不如亲手建一个测试计划拿一份带中文和特殊字符的CSV用例跑一遍。跑通了这些问题就都不是问题了。