1. 导入测试用例之前先搞清楚要导入哪些字段做接口测试做到中后期大家手里基本都攒了一份像样的用例表Excel也好、CSV也好列头大概是用例编号、接口名称、请求方式、请求URL、业务参数、预期结果。这套东西放在平常手工点点没什么问题可一旦你要把它批量导进Jmeter里跑就会发现一个现实问题Jmeter不认你的Excel它只认自己能解析的格式。说白了导入测试用例这件事本质不是把文件拖进界面就算完而是要把用例表格里的数据翻译成Jmeter的取样器、配置元件和断言器。这期我专门聊两个点一是测试用例怎么导入工程、怎么批量复用二是GET请求里URL本身就带参数的场景怎么处理才能不踩乱码、不漏参数、不误导断言。这两个点看着基础实际跑起来几乎所有新人都要卡一轮。1.1 一份能用得起来的用例表应该长什么样先说你手里的用例表格。我见过很多刚开始做Jmeter接口测试的同事导入失败或者导入后跑得不对返回来查第一问题永远出在表结构上。Jmeter里最常用的批量导入方案是CSV Data Set Config它要求你有一个规整的、列数统一的CSV文件每一行代表一条完整的测试用例每一列对应一个你要替换的变量。我建议你至少维护这几列顺序固定不要今天这样明天那样列名示例值作用case_name搜索-手机-第一页测试用例名称方便定位失败样本path/api/searchURL路径部分param_key1 / param_value1keyword / 手机参数键值对可扩展多组param_key2 / param_value2page / 1同上expect_code200预期HTTP状态码断言用expect_keyword搜索结果预期返回内容中的关键字业务断言用有人说列那么多是不是太啰嗦不啰嗦。等你用例数量上百条之后就知道没有这些字段你根本没法在聚合报告里快速判断是请求本身失败了还是断言没通过。列的设计直接决定了导入后的可维护性这一步省不得。1.2 环境准备里最容易被忽略的三个小点工欲善其事必先利其器。Jmeter本身不用多说重点说三个经常出问题的地方第一JDK版本。Jmeter 5.x版本的常规要求是JDK 8以上我用的是JDK 8和JDK 11各一套环境都能稳定跑。如果你打开Jmeter报UnsupportedClassVersionError不用查别的就是JDK版本太低或者太高不兼容直接换版本。第二CSV文件的编码。这是所有导入方案里最大的坑。你用Excel另存为CSV默认很可能是ANSI编码但Jmeter里CSV Data Set Config默认按UTF-8读取结果就是导入后全是乱码请求发出去参数也全是问号或乱码字符串。我的做法是统一用UTF-8编码保存CSV如果你不知道怎么确认用记事本打开CSV后点另存为右下角编码选择UTF-8再存一次就稳了。第三CSV文件里不要有多余的表头参与读取。CSV Data Set Config如果配置不当会把第一行表头也当成一条用例发出去。这个我们后面讲配置时会说到配合忽略首行选项就能解决。2. 三种主流导入测试用例的方式我实际用下来怎么选2.1 方式一CSV Data Set Config批量参数化最推荐这是最正宗的导入测试用例做法也是大家搜索最多的关键词背后真正的刚需。操作路径不复杂但配置细节值得一条条过。第一步在你的线程组下右键添加-配置元件-CSV Data Set Config。第二步配置元件参数关键项如下配置项推荐配置说明Filename填CSV文件的绝对路径绝对路径最稳妥别用相对路径换电脑跑就找不到了File encodingutf-8和前面说的编码问题对应Variable Namescase_name,path,param_key1,param_value1,...逗号分隔顺序和CSV列一一对应Delimiter,默认逗号如果CSV是用Tab分隔的这里改成\tIgnore first lineTrue跳过表头那行用例必开Recycle on EOFTrue循环读取跑性能测试时常用功能测试可以按需关闭Stop thread on EOFFalse读完所有用例后停止线程保证每条用例都跑到第三步在HTTP请求取样器里把URL、参数值替换成变量。比如URL路径填${path}参数keyword的值填${param_value1}。这样配置完只要CSV里的行数够线程组循环跑每一轮就会自动取下一行数据当成一组测试用例执行。整个流程就是导入测试用例的完整落地过程。2.2 方式二从已有请求模板复制改造适合少量用例如果你只有十几条用例而且场景差异比较大用CSV反而显得重。这时候直接把已有的HTTP请求取样器复制几份改路径、改参数值是最快的办法。具体做法在测试计划里选中一个已经调通了的HTTP请求CtrlC复制右键粘贴多次然后逐个修改。这里有个小习惯我每次复制后一定会顺手改名比如在注释里写上对应的用例编号避免跑挂了之后分不清是哪一个请求出了问题。这种方式不需要导入文件也不依赖Csv配置但是用例一多、一变化维护成本就上去了所以我的判断是超过30条用例老老实实用CSV。2.3 方式三用户自定义变量做用例分组适合按场景切换还有一类场景你的用例不是逐条批量的而是按环境或者按业务场景切换比如一套是测试环境参数一套是预发环境参数。这种就不用CSV也不用复制请求而是用用户自定义变量集中管理。添加路径线程组或测试计划下添加-配置元件-用户定义的变量。在里面把环境相关的host、token、公共参数配好HTTP请求里用${host}、${token}引用。之后切换环境只改变量值所有用例一起生效。我一般把它和CSV方案组合使用用户自定义变量管环境、管全局参数CSV管业务测试数据各管各的互不干扰。三种方式没有谁绝对好核心判断标准是用例数量和变更频率。量大、迭代快的用CSV量小、差异大的复制改造环境切换频繁的用用户自定义变量这套组合拳我用了很久基本覆盖了日常所有导入场景。3. GET请求里URL带参数的底层规则搞懂才能不踩坑标题里get请求中Url存在参数这个场景好多新人是真怕怕的原因是不理解URL参数到底在URL里是怎么组织、怎么编码、怎么被Jmeter识别的。这一节不聊操作先把这个底层的逻辑讲透。3.1 查询参数和路径参数不是一回事GET请求URL里带参数通常有两种形态第一种是查询参数标准格式是http://api.example.com/api/search?keyword手机page1。问号后面跟的就是查询参数多个参数之间用分隔每个参数是键值对如keyword手机。这种参数一般用来过滤条件、分页、排序是GET里最常见的。第二种是路径参数格式是http://api.example.com/api/user/1001。1001直接写在路径里是资源ID。这种参数在RESTful接口中出现频率极高。两种参数在Jmeter里的填法完全不同。查询参数可以用HTTP请求里的Parameters表格填Jmeter会自动拼到URL后面路径参数则只能通过路径里写占位符来替换比如路径填/api/user/${userId}。如果你把路径参数塞到Parameters表格里请求URL拼出来后一定是错的因为参数位置根本不对。这个点我见过太多次了新人一上来就把所有参数都丢进Parameters表结果路径参数完全没生效接口返回404或者参数缺失错误。3.2 为什么中文和特殊字符必须做百分号编码URL里能直接用的字符只有RFC 3986规定的保留字符和一部分非保留字符像a-z、A-Z、0-9、-、_、.、~是安全的但中文、空格、、、、?这些在特定位置都有特殊含义或者根本不被允许直接出现。比如参数值是手机平板如果你原样拼进URL服务端解析的时候会在处把参数切断原本一个keyword就变成了两个参数。中文则更麻烦URL里不允许出现非ASCII字符必须按照UTF-8编码后转成百分号形式。拿手机这两个字举例UTF-8编码后是%E6%89%8B%E6%9C%BA所以完整拼出来就是keyword%E6%89%8B%E6%9C%BA。这个转换过程叫URL编码也叫百分号编码。很多接口测试的怪问题比如为什么我传中文服务端收到的全是乱码为什么我的参数多了一个空格为什么服务端报URL解码失败十有八九都是URL编码环节出了岔子。Jmeter有一个相对智能的处理机制你只要把参数填在Parameters表格里它会按你设置的编码自动帮你做URL编码但如果你是自己手拼URL把中文直接写在地址栏里那Jmeter就不会主动编码大概率就要出乱码。3.3 Jmeter处理URL参数的两种路径混用必出事在Jmeter的HTTP请求取样器里传GET参数有两种途径。途径一直接写在URL里。比如协议填http服务器名称或IP填api.example.com路径填/api/search?keyword手机page1。这种方式简单直接URL一眼就能看全但如果URL里有中文或特殊字符你必须保证它已经是编码后的状态否则发送出去会乱码。途径二Parameters表格。在参数选项卡里一行填一个参数键值对比如第一行名称填keyword值填${param_value1}。Jmeter会自动根据内容编码的设置把参数编码后拼接到URL上。我强烈建议所有GET请求能走Parameters表就走Parameters表。理由有两个。第一参数和路径分离维护起来清楚哪一行是干什么的看表格就明白第二Parameters表天然解决编码问题你不需要自己手工把中文转成百分号编码Jmeter会代劳。混用的典型事故是路径里自己拼了?page1size10参数表里又填了keyword手机最终Jmeter拼出来的URL就变成/api/search?page1size10keyword%E6%89%8B%E6%9C%BA这种看着没问题但如果路径里已经带了?参数表再往URL后面追加时Jmeter有可能把原有查询串当成普通路径的一部分导致URL形如/api/search?page1size10keyword...部分服务端框架解析时会以第一个?为界后续参数丢失。这不是Jmeter的bug是你混用了两种传参方式。路径里干净地只放路径参数全部走表格就不会有这种幺蛾子。4. 实跑一轮带中文参数和分页参数的GET用例理论的东西讲多了上一波实操。我拿一个非常典型的场景跑一遍搜索接口GET请求路径是/api/search查询参数是keyword中文关键词、page页码、pageSize每页条数我要把CSV里的三组用例导入Jmeter全部跑通并且用断言校验结果。4.1 构造用例数据并完成CSV导入配置我先准备CSV文件一行一组测试数据我的表结构定义为case_namepathkeywordpagepageSizeexpect_codeexpect_keyword搜索-手机-第一页/api/search手机110200手机成功搜索-笔记本电脑-第二页/api/search笔记本电脑220200笔记本成功搜索-空关键词-默认分页/api/search00400参数错误注意我故意在第三行放了一个空关键词用例用来测服务端的参数校验。空值在CSV里就是一个空单元格Jmeter读取后变量值会给到${keyword}如果服务端对空参数有校验逻辑这条用例就能验证到。然后把CSV Data Set Config配置好Variable Names填case_name,path,keyword,page,pageSize,expect_code,expect_keywordHTTP请求里路径填${path}Parameters表格里分别填名称值keyword${keyword}page${page}pageSize${pageSize}此时点运行Jmeter会循环读取三行数据发出三个GET请求。这里最直观的体现就是用例通过CSV导入后每个线程组的迭代次数就是CSV行数你不用手动建三个HTTP请求一份文件全搞定。4.2 中文参数乱码的排查与解决我故意在第一版配置里不设置任何编码直接跑观察请求结果。查看结果树里点开第一个请求在请求正文/请求头部分看到URL变成了/api/search?keyword??page1pageSize10典型的乱码现象。这时候不要慌按顺序排查三个地方第一CSV Data Set Config的File encoding是不是UTF-8。如果这里填了ANSI或者留空Jmeter会用平台默认编码读取你的CSV而文件的真实编码是UTF-8的话读取就会错位。第二HTTP请求取样器里的内容编码字段。这个字段直接控制Jmeter对参数做URL编码时使用的字符集。我默认填UTF-8保证参数值编码和CSV读取编码一致。第三如果还乱码检查你的CSV文件本身。用记事本打开看中文是否正常显示。如果你手上只有Excel另存的CSV建议先转成UTF-8再导入。这三步按顺序做完中文参数就是正常的%E6%89%8B%E6%9C%BA形式服务端收到的也是正确的手机。4.3 用Beanshell断言校验返回结果关于jmeter beanshell断言这方面的经验我多说几句。断言的作用是自动判定用例是否通过不用人工盯着结果树看。对GET接口来说我常用的断言组合是两个第一个响应状态码断言。HTTP请求右键添加-断言-响应断言模式匹配填${expect_code}比如200。这一步确保服务端HTTP层面没问题。第二个Beanshell断言校验业务字段。响应断言只能判断状态码和简单文本如果我想校验返回JSON里是否含有关键业务信息就用Beanshell断言。在断言下添加Beanshell断言脚本大概思路是这样import org.json.JSONObject; import org.json.JSONArray; String response prev.getResponseDataAsString(); JSONObject json new JSONObject(response); String keyword json.getJSONObject(data).getString(keyword); String expect vars.get(expect_keyword); if (keyword.equals(expect)) { Failure false; } else { Failure true; FailureMessage keyword不匹配期望 expect 实际 keyword; }这个脚本用到了vars.get()方法去取CSV里的预期关键字用prev.getResponseDataAsString()拿当前请求的响应。跑完测试后断言失败的那条用例会被标红点击就能看到FailureMessage定位非常快。有一点提醒Beanshell断言脚本看起来简单但它跑在Jmeter的Java解释器里性能不如JSR223。如果你只是功能测试跑几十条用例Beanshell完全够用如果以后做性能测试建议把脚本挪到JSR223取样器里并切换语言为groovy性能差距非常大。5. 容易踩的坑每一条都是钱买来的教训5.1 分隔符、科学计数法、编码三连坑先说CSV文件的坑。第一个是分隔符Excel在部分语言环境下默认用分号当分隔符而Jmeter默认用的是逗号。你明明配好了CSV Data Set Config跑起来发现一个变量读出来了后面的全是null大概率就是分隔符不匹配。解决办法也很简单在配置元件里把Delimiter改成和文件一致或者干脆用专门的编辑器导出CSV时指定逗号分隔。第二个坑是科学计数法。如果你的用例表里有超长的数字比如手机号、身份证号甚至在接口参数里传时间戳Excel存成CSV时会自动把长数字转成科学计数法比如13800000001变成1.39E10。Jmeter读取后发出的参数就是这个1.39E10服务端直接懵。这种情况在Excel里把那列设置成文本格式再导出能有效避免。第三个坑还是编码但这个编码不是CSV编码而是参数本身的编码。很多人习惯把URL在浏览器里复制出来那上面已经有一堆百分号编码的字符比如%E6%89%8B%E6%9C%BA然后他想都不想就把整条URL贴进Jmeter。Jmeter在参数表里如果已经写的是编码后的值你又开启了自动编码它可能会二次编码把百分号再转一遍最终变成%25E6%2589%258B%25E6%259C%25BA。服务端拿到之后解一次码得到%E6%89%8B%E6%9C%BA这就不对了。所以我的建议是URL里尽量放明文中文让Jmeter统一编码如果你手头的URL已经是编码态那就别在参数表里再传一遍直接在URL里原样使用。5.2 GET请求的参数顺序对签名校验接口极其重要有的接口为了安全会做参数签名逻辑通常是把所有参数按字典序排列拼成字符串用密钥计算md5或hmac。这种接口的参数顺序就是生命线。你从用例表里导入参数如果CSV列的存储顺序和签名逻辑要求的排序不一致就算参数值全对签名也永远验不过。我碰到过一个真实案例开发写的签名逻辑要求把时间戳放最前面而我们的CSV列顺序是业务参数在前、时间戳在后结果整批用例全因为签名失败被服务端拒了。解决方案有两个。第一在Jmeter里用Beanshell或JSR223前置处理器在发送请求前动态计算签名把签名结果设成变量再引用到参数表里。第二如果你不想写代码那就从根上调整CSV列顺序让Jmeter拼出来的参数顺序和开发签名时的一致。我个人更推荐第一种因为接口签名规则一变你只需要改脚本不用重新整理一堆CSV。5.3 动态参数不能硬导入关联提取才是正解还有一种情况GET请求的URL参数里带了token、session之类的动态值。比如/api/order/list?tokenabc123page1token是登录接口返回的一会儿一变。如果你把token直接硬编码在CSV里跑几次就过期了整批用例开始报鉴权失败。这种场景的正确姿势是前置步骤登录从登录响应里用JSON提取器或正则表达式提取器拿到token存成变量再在URL参数表里引用${token}。CSV里只维护业务参数动态凭证走关联提取不要把动态值和静态用例数据混在一个文件里。我在多个项目里的落地原则是凡是可能过期的、每次执行都会变的全部动态提取凡是稳定的、描述业务场景的全部放CSV。这样测试用例表才经得起重复运行的考验而不是跑一次就要手动改一次token。5.4 测试用例导入不等于文件拖进来完事最后说一个方法论层面的坑。很多人理解的导入测试用例是把一个现成的文件拖进Jmeter就结束了但实际做接口测试项目你更需要的是一套用例数据驱动的思路测试脚本是固定的一套框架用例数据是随时可换的一组CSV。这样产品迭代的时候你只需要维护数据不需要动脚本本身。比如我上面这个搜索接口的案例如果以后要加一列期望排序规则我只要改CSV结构、在参数表里加一个变量、在断言里加一段校验逻辑就能覆盖新的测试点。测试团队的协作模式也从我改脚本你等着变成你给我数据我跑出报告。这个转变才是做导入测试用例这件事最大的价值。