做接口测试的同学十有八九都遇到过这么个尴尬场景脚本一路绿灯跑到登录、注册或者下单这一步服务器突然丢回来一张歪歪扭扭的图片验证码上面还缠着几根干扰线。手工点一下倒没什么可自动化脚本就僵在这儿了——这就是典型的“Jmeter接口测试碰到图片验证码”的困局。今天不绕弯子直接把我这几年用JMeter处理图片验证码的几种方案、完整配置步骤和踩过的坑一次性讲透适合正在做接口联调、自动化回归和压测脚本改造的同学参考。放心不管你团队有没有OCR资源、允不允许改测试环境这篇都有对应路线。1. 图片验证码到底卡住了什么先看懂它在接口链路里的位置1.1 验证码从下发到校验的完整流程想对付一个东西先得知道它在哪儿。图片验证码在接口链路里从来不是孤立的它本质上是“一次请求下发、一次提交校验、一段时效内有效”的状态型数据。完整的业务闭环通常是这样的客户端先请求一个验证码接口服务端生成一张图片返回给前端同时把正确答案保存在服务端会话里用户看图输入内容再带着验证码文本、唯一标识很多系统会返回一个uuid或captchaId以及业务参数一起提交给业务接口服务端把这个文本和会话里存的答案做比对匹配就放行不匹配就报错。放到JMeter的视角来看麻烦的点就出来了。脚本需要先发一次请求拿图片数据再从图片里提取出正确答案最后带着这个答案去请求业务接口。三步缺一不可而且验证码图片往往不是给你一个纯文本而是二进制流、Base64编码或者一个临时图片URL。更头疼的是验证码还有时效性一般60到120秒过期脚本慢一点就作废。1.2 为什么说验证码是自动化测试的“拦路虎”很多人不理解为什么一个验证码能卡住接口测试。它跟普通的动态参数比如token、时间戳还不一样。token你可以通过正则提取器提取一下就直接传入下一个请求但验证码的答案是“不可直接解析的目标文本”它藏在图像里被扭曲、加了噪点和干扰线你得先做一轮图像识别才能拿到那个四五个字符的结果。而且验证码强依赖会话状态。只要你的JMeter脚本在请求验证码接口和提交业务接口之间换了会话或者HTTP Cookie管理器没有覆盖到这两个请求服务端就认为验证码校验失败。更隐蔽的问题还在于并发。压测时如果所有线程共用同一个验证码前几个人提交成功后面的人全部报“验证码错误”或“验证码已过期”。这些坑普通接口参数根本不会出现。换个角度想这也是好事。正因为它牵连了图像识别、状态管理、并发隔离这些点你把它处理好了整套脚本的健壮性会明显上一个台阶。接下来我按“全自动优先、人工兜底、环境绕行”三条路线展开讲具体做法。2. 方案一OCR识别验证码——全自动但要精度和服务2.1 图片验证码的前置获取Base64还是图片地址做OCR之前第一件事是在JMeter里把验证码图片拿到手。不同系统的验证码接口返回格式不一样常见的有三种第一种是直接返回二进制图片流响应头一般是Content-Type: image/jpeg或image/png身体里就是一张图第二种是返回JSON里面有个img字段值是Base64编码的图片数据有时候还带data:image/png;base64,前缀第三种是返回一个JSON里带图片URL前端再用这个URL去加载图片。这三种处理方式差别很大。如果你的验证码接口直接返回图片流最简单的方法是加一个“保存响应到文件”的后置处理器文件名填${__time()}.pngJMeter会自动把响应体存成文件。但要注意如果响应里带了图片头信息或者base64的文本包装存下来的文件可能是坏的。如果是Base64格式就得用JSR223后置处理脚本去解码。这是我在项目里最常用的一种方式因为现在很多前后端分离的项目验证码接口都统一返回JSONBase64是主流。示例脚本长这样import org.apache.commons.codec.binary.Base64; import java.io.FileOutputStream; // 假设前面已经用正则或JSON提取器取到了Base64字符串存进了变量 imgBase64 String base64Str vars.get(imgBase64); // 兼容带 data:image/png;base64, 前缀的数据 if (base64Str.contains(base64,)) { base64Str base64Str.split(base64,)[1]; } byte[] data Base64.decodeBase64(base64Str); FileOutputStream fos new FileOutputStream(C:/tmp/verify_ System.currentTimeMillis() .png); fos.write(data); fos.flush(); fos.close();写这段代码的时候有两点要注意第一JMeter的vars.get()拿到的只可能是字符串如果原始返回里有换行Base64解码可能报错可以先用.replace(\n, ).replace(\r, )清理一下第二保存图片的目录必须存在否则fos会直接抛FileNotFoundException脚本在那里就断了。2.2 接入OCR识别服务的完整配置拿到图片之后OCR识别这步选择很多。有公有云OCR接口有开源的Tesseract还有一些团队自建的识别服务。这里我给两条主路线你们按环境条件挑就好。先说公有云OCR接口。这个路线的前提是公司允许调用外网服务而且你要有对应的AK/SK。流程不复杂在JMeter里加一个HTTP请求方法POST请求体用JSON大概长这样{ image: 图片Base64字符串, type: common }图片Base64字符串这里直接用正则或JSON提取器从上一个请求响应里提取出来的原始值就可以不需要自己做二次拼接。云OCR的返回格式一般是标准JSON比如{ code: 0, data: { text: 8aF2 } }拿到这个返回之后加一个JSON提取器表达式填$.data.text变量名设为ocrResult后面业务接口直接用${ocrResult}传递即可。另一条路线是Tesseract本地识别。说实话Tesseract对那种带扭曲、干扰线、彩色背景的验证码识别率一般但对付纯数字、纯字母、白底黑字的验证码很顶用。要在JMeter里用Tesseract不需要写一堆Java集成代码我见过很多团队直接用一个叫“OS Process Sampler”的取样器来执行命令行tesseract C:/tmp/verify_12345.png stdout -l eng --psm 7注意--psm 7这个参数它告诉Tesseract把图片当作一行文本处理专门适合验证码这种短文本场景。如果默认参数去识别Tesseract可能会把几个字符拆成多行导致结果对不上。2.3 OCR识别准确率优化和兜底策略OCR方案的阿喀琉斯之踵就是识别不准。这里有几个提升准确率的实操经验都是我一点点试出来的第一识别前先对图片做预处理。很多验证码图片如果直接用原图提交给OCR识别率低得感人。你可以在保存图片后用ImageMagick或者Java的BufferedImage做一下灰度化和二值化把干扰线去掉。不过这个操作在JMeter里写起来稍微复杂我更推荐在OCR服务端这边解决或者直接把图片丢给云识别接口云服务本身对这些做了优化。第二重试机制必须有。一次识别不出来脚本别直接失败。可以用一个循环控制器把“识别-校验”这两步包起来循环三次每次重新请求验证码接口、重新识别。如果三次都失败再跳过或者断言失败。这个思路在接口回归里尤其重要因为验证码本身的随机性决定了不可能百分百识别成功。第三有些系统的验证码只包含数字而且位数固定可以在拿到OCR结果之后做一个简单的逻辑判断比如用vars.get(ocrResult)去匹配^[0-9]{4}$不匹配的话就认为识别失败触发重试。别小看这个判断有时候OCR会把“0”识别成“O”把“1”识别成“l”对业务接口来说这两个就是完全不同的值先做一层合法性校验能省很多冤枉时间。3. 方案二人工看图输入验证码——最笨但最稳的方法3.1 全局变量与手工介入的实现思路有些团队OCR服务不好申请或者验证码过于变态机器识别率不到三分之一。这时候人工介入反而是最有效的方案。你可能觉得都做自动化了还人工看图那不是倒退吗但实际项目里“半自动”从来都是不可忽视的过渡状态。尤其是功能测试阶段你只是想验证一下登录之后的业务链路是否能跑通没必要为了一个验证码去引入一套OCR系统。在JMeter里做人工介入的思路并不复杂。第一步还是先通过请求拿验证码图片并保存到本地第二步把脚本停下来等测试人员看图后在JMeter里或外部文件里输入验证码第三步脚本继续跑把验证码值传给业务接口。关键点在于第二步的“停止等待”怎么实现。我自己用得比较顺的一种方式是用__StringFromFile函数配合一个本地文件。比如你可以加一个JSR223采样器里面的逻辑是读取一张本地图片的验证码等待测试人员打开某个指定文件并写入验证码内容然后脚本继续。这里放一段简化的实现你们感受一下思路import java.nio.file.*; Path p Paths.get(C:/tmp/manual_code.txt); String code ; while (true) { if (Files.exists(p)) { code Files.readAllLines(p).get(0).trim(); if (code.length() 0) { break; } } Thread.sleep(3000); // 每3秒轮询一次 } vars.put(manualCode, code);这种写法看起来有点野路子但实际调试场景非常好用。测试人员听到脚本停下来之后看一眼本地保存的验证码图片把答案写入那个txt文件脚本自动捡起来继续跑。3.2 让图片自动弹出到屏幕的小技巧如果你觉得“让测试人员去特定目录找图片”太低效可以在保存图片之后用JSR223脚本直接调用系统命令把图片弹出来。比如Windows环境下用Desktop类或者cmd /c start命令。Java代码大致是这样的Desktop.getDesktop().open(new File(C:/tmp/verify_12345.png));这行代码放到保存图片的后置脚本最后一句就行图片保存完自动打开测试人员直接在屏幕上看到验证码体验会好很多。Linux或Mac环境下也可以用Runtime.getRuntime().exec(new String[]{/bin/sh, -c, open filePath})类似的命令。还有一个细节值得注意图片文件名最好带上时间戳或者线程号否则多个线程同时跑的时候后保存的图片会覆盖前面的。我在实际项目里用的是verify_${__time()}_${__threadNum}.png这种命名方式线程号和时间的组合可以保证不冲突。3.3 手动方案怎么配合并发场景使用提到线程号就得说一个重要限制人工方案本质上是“串行”的。你在调试单接口时没什么但如果要对登录接口做压测不可能让每个线程都弹出图片让人工输入。人工方案最合适的场景是接口调试和功能回归——跑一个线程、过一遍核心链路、验证业务正确性。那如果团队非要拿这种半自动方式去做小并发场景也不是完全没办法。可以在脚本里加入一个synchronized块让所有线程共用同一个验证码文件但同一时刻只有第一个线程触发人工输入后续线程直接复用已经输入的值。由于JMeter每个线程是并发的这里需要用到临界区控制我一般是在JSR223脚本里用一个静态锁对象synchronized (ManualLockHolder.class) { // 检查是否已经有验证码值没有则触发人工输入 if (vars.get(sharedCode) null) { // 等待人工输入并写入vars } }不过说句实在话这个方案只适合“不得不做”的情况。如果你已经要上压测了我更建议直接走向后两种方案——让开发给你开个口子或者从会话维度绕过验证码。4. 方案三从源头绕开验证码——工程效率最高的选择4.1 测试环境“万能验证码”的落地条件绕开验证码不是作弊而是测试环境治理里的常规操作。你要测的是“登录之后的功能”或“注册之后的流程”不是验证码本身的扭曲字符识别能力。在这种前提下最干净利落的方式是让开发在测试环境提供一个“万能验证码”。所谓万能验证码一般是在服务端校验逻辑里加一个后门如果传入的验证码等于一个特殊值比如8888就直接放行否则走正常校验流程。这个开关通常由配置中心控制只在测试环境打开预发和生产绝不开启。落到JMeter脚本里你什么都不用改直接把业务请求里的验证码参数值写死成8888就行什么OCR、什么人工看图统统不需要。为了保险你还可以加一个断言判断返回结果里如果出现“验证码错误”这样的提示就说明万能验证码没生效尽早暴露环境配置问题。4.2 用已有会话和Cookie跳过验证码校验这个方案的精髓在于验证码只在校验的那一次请求里有意义。如果你能先通过一次人工或OCR方式完成登录拿到了登录后的Cookie或者Token后面所有请求都带着这个有效会话走那验证码根本不会再出现第二次。在JMeter里这个做法落地起来分两步。第一步你可以在浏览器里手动登录一次从开发者工具里把关键Cookie复制出来然后在JMeter的HTTP Cookie管理器里直接填入这些Cookie值第二步脚本里所有需要登录态的请求都放在这个Cookie管理器作用域之下运行时自动携带。你可能担心“那登录请求本身不就测不了了吗”对这个方案放弃了反复测试登录接口的能力但它换来了“非登录类接口”全流程回归的自由。很多项目的自动化测试是希望快速回归核心业务链路而不是反复抠登录按钮这个取舍完全划算。另外如果你们的系统是基于Token鉴权处理方式也类似。先在外部调一次登录接口拿到Token然后通过JMeter属性或者CSV文件统一注入到脚本里// JSR223 前置脚本中动态设置请求头 import org.apache.jmeter.protocol.http.util.HTTPConstants; vars.put(token, Bearer ${tokenFromFile});4.3 打桩Mock验证码校验服务的另一种思路还有一种比较进阶的做法是直接针对验证码校验接口做Mock。如果你们的验证码下发和校验是分开的两个接口比如GET /captcha负责下发图片POST /captcha/check负责校验答案那么测试侧完全可以把这个校验接口打到Mock服务上让Mock永远返回“校验通过”。这些Mock服务绝对不能用JMeter的HTTP代理来冒充但JMeter本身可以通过一种很巧妙的方式实现干这事把校验接口的请求复制一份加一个预设的成功响应断言再用IfController判断命中该校验请求时直接跳到下一个业务请求。说白了是在脚本层面把校验这一步“跳过去”而不是真正发出去。这种方式适合那些校验接口独立于业务接口的系统而且要求你有修改脚本流程的权限。如果团队有条件更建议用专门的Mock工具比如WireMock或MockServer来做配置简单且干净。Mock方案的最大好处是稳定、不依赖外部环境但也存在一个问题你绕过了服务端校验逻辑万一服务端哪天改了校验规则你也不知道。所以Mock方案一定要和“定期回归真实校验链路”配合使用别把测试环境整个变成假环境。5. 并发与断言场景下的验证码处理细节5.1 压测时验证码不该成为瓶颈很多人做压力测试的时候一跑到登录接口就抓瞎——验证码怎么处理如果你真要压测的是登录接口本身我的建议是直接走线上说的“万能验证码”或“会话绕过”路线。原因很简单压测看重的是吞吐率和响应时间如果脚本里塞了一堆OCR识别的计算那测出来的根本不是服务器的性能而是你本地机器的CPU识别速度。比如你用Tesseract在本地做OCR每个线程识别一次验证码可能要耗掉几百毫秒甚至几秒这会把整个压测的TPS曲线拉出一个巨大的假象服务器明明没到瓶颈但TPS就是上不去。如果你非要验证完整链路请确保OCR服务是独立的、不会成为压测瓶颈。5.2 BeanShell断言怎么判断验证码逻辑是否正确热词里有Jmeter Beanshell断言我得说两句。在处理验证码的脚本里断言的核心是“验证码错误”这类响应信息的捕捉。比如你提交验证码之后服务器返回了一段JSON{ code: 401, message: 验证码错误或已过期 }这时候用Beanshell断言去判断响应体是否包含“验证码错误”可以快速定位是识别问题还是会话问题。我一般这么写String response prev.getResponseDataAsString(); if (response.contains(验证码错误)) { // 置一个标记方便后续重试 vars.put(captchaFailed, true); } else { vars.put(captchaFailed, false); }外层再套一个While控制器判断条件是${captchaFailed} true。这样遇到识别失败就自动重新请求验证码、重新识别脚本容错率会高很多。如果你用的是JSR223 Groovy语法一样只是注意Groovy环境下直接用prev变量即可。5.3 多用户并发时验证码与账号怎么绑定最后一个高发雷区参数化登录时不同用户各自需要独立的验证码。很多JMeter脚本会配置一个CSV文件里面存了几十个测试账号然后用${username}和${password}参数化。但验证码接口如果被放在登录请求的上游只请求一次那所有线程拿到的就是同一个验证码图片。这种情况下OCR识别出的结果只有一个被N个线程同时拿去提交结果必然是大部分线程报“验证码错误”。正确的做法是把“获取验证码 - 保存图片 - OCR识别 - 提交登录”这四步全部放到线程组里让每个线程各自跑完整个闭环。这样每个线程拿到的验证码都是自己请求来的、独立有效的。如果只想复用一次获取验证码的结果也不是不行但必须同时把整个登录接口也串行化或者保证只有一个线程执行登录、其余线程复制这个线程的Cookie。这在JMeter里通常要借助临界控制器让所有线程等待第一个线程完成登录后再继续后面的请求。不过说实话这种做法只适合“登录态准备”场景真正要测登录接口的并发能力还是得回归到独立验证码方案。6. 常见问题排查实录我从现场踩过的坑6.1 正则提取图片数据时总是拿不到值这种问题十有八九是“响应数据格式跟预期不一致”。比如你以为验证码接口返回JSON里有个data.img字段存Base64结果实际返回的是result.imageBase64嵌套层级变了。排查方式很简单在JMeter里加一个“查看结果树”直接看验证码接口的真实响应体形态然后照着真实结构去写正则或JSONPath表达式。另一个容易被忽视的点是如果验证码接口设置在“仅一次控制器”里你跑第二遍迭代时这个Sampler不会重新执行变量自然取不到新值。确保它在线程组主流程里而不是被套进只执行一次的控制器里。6.2 OCR识别出的内容混入干扰字符OCR结果里多出一个空格、一个竖线或者一个引号是家常便饭。我在项目里吃过一次亏Tesseract把验证码“z3Df”识别成了“z3Df|”脚本没做清理直接传给登录接口结果接口返回“验证码错误”。查了半天才发现是多了个竖线字符肉眼看不出来但程序里它就是个实实在在的校验失败。处理办法是在提交之前对OCR结果做一次正则清洗只保留字母和数字String raw vars.get(ocrResult); String clean raw.replaceAll([^a-zA-Z0-9], ); vars.put(captchaText, clean);6.3 提交提示“验证码已过期”或“未登录请登录”这类报错的根源基本在会话管理上。验证码接口和业务接口没有走同一个Cookie管理器或者Cookie管理器作用域只覆盖了前半段请求。解决方案是把HTTP Cookie管理器放在线程组的顶层让它作用于线程组内所有HTTP请求如果系统用的是Token机制同样要确保验证码接口返回的captchaId被正确提取并传给登录请求。顺便提一嘴很多人遇到过类似{code:401,message:未登录,请登录!}的报错而且经常不是验证码问题是前面的登录请求压根没成功脚本还硬着头皮去请求后置接口。排查时要按顺序来先看登录接口返回再看Cookie有没有生效最后才怀疑验证码。6.4 并发场景所有线程报“验证码已被使用”这个跟前面说的“多用户并发”问题类似还有个变种一个验证码只能使用一次。就算你并发四个线程同时提交同一个验证码服务端处理第一个之后后三个都会报“已被使用”。遇到这种系统唯一的方案就是每个线程独立获取验证码或者干脆绕过验证码逻辑。注意还有个细节验证码重新获取后之前提取到的captchaId可能也变了。很多系统的验证码接口每次调用都会生成一个新的uuid你必须同步更新请求参数里的captchaId否则服务端会认为“提交的验证码与当前验证码不匹配”。6.5 现场踩坑经验速查表典型问题常见原因处理方式图片保存后打不开base64没解码或响应内容是文本包装先看响应体确认格式解码前清理换行和前缀OCR识别结果永远少一位验证码有干扰线或粘连字符调整--psm参数增加灰度/二值化预处理请求报“未登录”Cookie未作用于后续请求顶层放Cookie管理器确认用户名密码正确并发报“验证码错误”多线程共用一个验证码每个线程独立获取验证码或使用万能验证码TPS远低于预期OCR识别耗时占用线程压测时改用绕行方案OCR只用于功能链路7. 一点个人建议不同阶段怎么选方案我自己的经验是处理图片验证码这事儿没有银弹得分阶段选策略。功能调试阶段直接上人工看图输入最轻松脚本写得不复杂还能人工盯业务链路对不对接口回归阶段如果能申请到OCR服务就花点时间把全自动方案搭起来重试逻辑一定要做真正到了压测阶段别再纠结验证码识别直接找开发开万能验证码或做会话绕过这是工程效率最高的选择。另外多说一句图片验证码只是接口测试中“动态不可解析参数”的一个代表。你能把这套“获取动态数据 - 处理解析 - 关联到后续请求 - 异常重试”的思维学会后面遇到滑块验证、短信验证码、图形点选验证时思路也能顺利迁移过去。拦截器也好、函数也罢JMeter的核心从来不是某个组件而是你串联这些组件去解决实际问题的能力。 
长河君 · 2026/10/13 16:09:00 · 阅读 1.2k JMeter接口测试图片验证码处理：OCR识别、人工兜底与绕行方案全解析
做接口测试的同学十有八九都遇到过这么个尴尬场景脚本一路绿灯跑到登录、注册或者下单这一步服务器突然丢回来一张歪歪扭扭的图片验证码上面还缠着几根干扰线。手工点一下倒没什么可自动化脚本就僵在这儿了——这就是典型的“Jmeter接口测试碰到图片验证码”的困局。今天不绕弯子直接把我这几年用JMeter处理图片验证码的几种方案、完整配置步骤和踩过的坑一次性讲透适合正在做接口联调、自动化回归和压测脚本改造的同学参考。放心不管你团队有没有OCR资源、允不允许改测试环境这篇都有对应路线。1. 图片验证码到底卡住了什么先看懂它在接口链路里的位置1.1 验证码从下发到校验的完整流程想对付一个东西先得知道它在哪儿。图片验证码在接口链路里从来不是孤立的它本质上是“一次请求下发、一次提交校验、一段时效内有效”的状态型数据。完整的业务闭环通常是这样的客户端先请求一个验证码接口服务端生成一张图片返回给前端同时把正确答案保存在服务端会话里用户看图输入内容再带着验证码文本、唯一标识很多系统会返回一个uuid或captchaId以及业务参数一起提交给业务接口服务端把这个文本和会话里存的答案做比对匹配就放行不匹配就报错。放到JMeter的视角来看麻烦的点就出来了。脚本需要先发一次请求拿图片数据再从图片里提取出正确答案最后带着这个答案去请求业务接口。三步缺一不可而且验证码图片往往不是给你一个纯文本而是二进制流、Base64编码或者一个临时图片URL。更头疼的是验证码还有时效性一般60到120秒过期脚本慢一点就作废。1.2 为什么说验证码是自动化测试的“拦路虎”很多人不理解为什么一个验证码能卡住接口测试。它跟普通的动态参数比如token、时间戳还不一样。token你可以通过正则提取器提取一下就直接传入下一个请求但验证码的答案是“不可直接解析的目标文本”它藏在图像里被扭曲、加了噪点和干扰线你得先做一轮图像识别才能拿到那个四五个字符的结果。而且验证码强依赖会话状态。只要你的JMeter脚本在请求验证码接口和提交业务接口之间换了会话或者HTTP Cookie管理器没有覆盖到这两个请求服务端就认为验证码校验失败。更隐蔽的问题还在于并发。压测时如果所有线程共用同一个验证码前几个人提交成功后面的人全部报“验证码错误”或“验证码已过期”。这些坑普通接口参数根本不会出现。换个角度想这也是好事。正因为它牵连了图像识别、状态管理、并发隔离这些点你把它处理好了整套脚本的健壮性会明显上一个台阶。接下来我按“全自动优先、人工兜底、环境绕行”三条路线展开讲具体做法。2. 方案一OCR识别验证码——全自动但要精度和服务2.1 图片验证码的前置获取Base64还是图片地址做OCR之前第一件事是在JMeter里把验证码图片拿到手。不同系统的验证码接口返回格式不一样常见的有三种第一种是直接返回二进制图片流响应头一般是Content-Type: image/jpeg或image/png身体里就是一张图第二种是返回JSON里面有个img字段值是Base64编码的图片数据有时候还带data:image/png;base64,前缀第三种是返回一个JSON里带图片URL前端再用这个URL去加载图片。这三种处理方式差别很大。如果你的验证码接口直接返回图片流最简单的方法是加一个“保存响应到文件”的后置处理器文件名填${__time()}.pngJMeter会自动把响应体存成文件。但要注意如果响应里带了图片头信息或者base64的文本包装存下来的文件可能是坏的。如果是Base64格式就得用JSR223后置处理脚本去解码。这是我在项目里最常用的一种方式因为现在很多前后端分离的项目验证码接口都统一返回JSONBase64是主流。示例脚本长这样import org.apache.commons.codec.binary.Base64; import java.io.FileOutputStream; // 假设前面已经用正则或JSON提取器取到了Base64字符串存进了变量 imgBase64 String base64Str vars.get(imgBase64); // 兼容带 data:image/png;base64, 前缀的数据 if (base64Str.contains(base64,)) { base64Str base64Str.split(base64,)[1]; } byte[] data Base64.decodeBase64(base64Str); FileOutputStream fos new FileOutputStream(C:/tmp/verify_ System.currentTimeMillis() .png); fos.write(data); fos.flush(); fos.close();写这段代码的时候有两点要注意第一JMeter的vars.get()拿到的只可能是字符串如果原始返回里有换行Base64解码可能报错可以先用.replace(\n, ).replace(\r, )清理一下第二保存图片的目录必须存在否则fos会直接抛FileNotFoundException脚本在那里就断了。2.2 接入OCR识别服务的完整配置拿到图片之后OCR识别这步选择很多。有公有云OCR接口有开源的Tesseract还有一些团队自建的识别服务。这里我给两条主路线你们按环境条件挑就好。先说公有云OCR接口。这个路线的前提是公司允许调用外网服务而且你要有对应的AK/SK。流程不复杂在JMeter里加一个HTTP请求方法POST请求体用JSON大概长这样{ image: 图片Base64字符串, type: common }图片Base64字符串这里直接用正则或JSON提取器从上一个请求响应里提取出来的原始值就可以不需要自己做二次拼接。云OCR的返回格式一般是标准JSON比如{ code: 0, data: { text: 8aF2 } }拿到这个返回之后加一个JSON提取器表达式填$.data.text变量名设为ocrResult后面业务接口直接用${ocrResult}传递即可。另一条路线是Tesseract本地识别。说实话Tesseract对那种带扭曲、干扰线、彩色背景的验证码识别率一般但对付纯数字、纯字母、白底黑字的验证码很顶用。要在JMeter里用Tesseract不需要写一堆Java集成代码我见过很多团队直接用一个叫“OS Process Sampler”的取样器来执行命令行tesseract C:/tmp/verify_12345.png stdout -l eng --psm 7注意--psm 7这个参数它告诉Tesseract把图片当作一行文本处理专门适合验证码这种短文本场景。如果默认参数去识别Tesseract可能会把几个字符拆成多行导致结果对不上。2.3 OCR识别准确率优化和兜底策略OCR方案的阿喀琉斯之踵就是识别不准。这里有几个提升准确率的实操经验都是我一点点试出来的第一识别前先对图片做预处理。很多验证码图片如果直接用原图提交给OCR识别率低得感人。你可以在保存图片后用ImageMagick或者Java的BufferedImage做一下灰度化和二值化把干扰线去掉。不过这个操作在JMeter里写起来稍微复杂我更推荐在OCR服务端这边解决或者直接把图片丢给云识别接口云服务本身对这些做了优化。第二重试机制必须有。一次识别不出来脚本别直接失败。可以用一个循环控制器把“识别-校验”这两步包起来循环三次每次重新请求验证码接口、重新识别。如果三次都失败再跳过或者断言失败。这个思路在接口回归里尤其重要因为验证码本身的随机性决定了不可能百分百识别成功。第三有些系统的验证码只包含数字而且位数固定可以在拿到OCR结果之后做一个简单的逻辑判断比如用vars.get(ocrResult)去匹配^[0-9]{4}$不匹配的话就认为识别失败触发重试。别小看这个判断有时候OCR会把“0”识别成“O”把“1”识别成“l”对业务接口来说这两个就是完全不同的值先做一层合法性校验能省很多冤枉时间。3. 方案二人工看图输入验证码——最笨但最稳的方法3.1 全局变量与手工介入的实现思路有些团队OCR服务不好申请或者验证码过于变态机器识别率不到三分之一。这时候人工介入反而是最有效的方案。你可能觉得都做自动化了还人工看图那不是倒退吗但实际项目里“半自动”从来都是不可忽视的过渡状态。尤其是功能测试阶段你只是想验证一下登录之后的业务链路是否能跑通没必要为了一个验证码去引入一套OCR系统。在JMeter里做人工介入的思路并不复杂。第一步还是先通过请求拿验证码图片并保存到本地第二步把脚本停下来等测试人员看图后在JMeter里或外部文件里输入验证码第三步脚本继续跑把验证码值传给业务接口。关键点在于第二步的“停止等待”怎么实现。我自己用得比较顺的一种方式是用__StringFromFile函数配合一个本地文件。比如你可以加一个JSR223采样器里面的逻辑是读取一张本地图片的验证码等待测试人员打开某个指定文件并写入验证码内容然后脚本继续。这里放一段简化的实现你们感受一下思路import java.nio.file.*; Path p Paths.get(C:/tmp/manual_code.txt); String code ; while (true) { if (Files.exists(p)) { code Files.readAllLines(p).get(0).trim(); if (code.length() 0) { break; } } Thread.sleep(3000); // 每3秒轮询一次 } vars.put(manualCode, code);这种写法看起来有点野路子但实际调试场景非常好用。测试人员听到脚本停下来之后看一眼本地保存的验证码图片把答案写入那个txt文件脚本自动捡起来继续跑。3.2 让图片自动弹出到屏幕的小技巧如果你觉得“让测试人员去特定目录找图片”太低效可以在保存图片之后用JSR223脚本直接调用系统命令把图片弹出来。比如Windows环境下用Desktop类或者cmd /c start命令。Java代码大致是这样的Desktop.getDesktop().open(new File(C:/tmp/verify_12345.png));这行代码放到保存图片的后置脚本最后一句就行图片保存完自动打开测试人员直接在屏幕上看到验证码体验会好很多。Linux或Mac环境下也可以用Runtime.getRuntime().exec(new String[]{/bin/sh, -c, open filePath})类似的命令。还有一个细节值得注意图片文件名最好带上时间戳或者线程号否则多个线程同时跑的时候后保存的图片会覆盖前面的。我在实际项目里用的是verify_${__time()}_${__threadNum}.png这种命名方式线程号和时间的组合可以保证不冲突。3.3 手动方案怎么配合并发场景使用提到线程号就得说一个重要限制人工方案本质上是“串行”的。你在调试单接口时没什么但如果要对登录接口做压测不可能让每个线程都弹出图片让人工输入。人工方案最合适的场景是接口调试和功能回归——跑一个线程、过一遍核心链路、验证业务正确性。那如果团队非要拿这种半自动方式去做小并发场景也不是完全没办法。可以在脚本里加入一个synchronized块让所有线程共用同一个验证码文件但同一时刻只有第一个线程触发人工输入后续线程直接复用已经输入的值。由于JMeter每个线程是并发的这里需要用到临界区控制我一般是在JSR223脚本里用一个静态锁对象synchronized (ManualLockHolder.class) { // 检查是否已经有验证码值没有则触发人工输入 if (vars.get(sharedCode) null) { // 等待人工输入并写入vars } }不过说句实在话这个方案只适合“不得不做”的情况。如果你已经要上压测了我更建议直接走向后两种方案——让开发给你开个口子或者从会话维度绕过验证码。4. 方案三从源头绕开验证码——工程效率最高的选择4.1 测试环境“万能验证码”的落地条件绕开验证码不是作弊而是测试环境治理里的常规操作。你要测的是“登录之后的功能”或“注册之后的流程”不是验证码本身的扭曲字符识别能力。在这种前提下最干净利落的方式是让开发在测试环境提供一个“万能验证码”。所谓万能验证码一般是在服务端校验逻辑里加一个后门如果传入的验证码等于一个特殊值比如8888就直接放行否则走正常校验流程。这个开关通常由配置中心控制只在测试环境打开预发和生产绝不开启。落到JMeter脚本里你什么都不用改直接把业务请求里的验证码参数值写死成8888就行什么OCR、什么人工看图统统不需要。为了保险你还可以加一个断言判断返回结果里如果出现“验证码错误”这样的提示就说明万能验证码没生效尽早暴露环境配置问题。4.2 用已有会话和Cookie跳过验证码校验这个方案的精髓在于验证码只在校验的那一次请求里有意义。如果你能先通过一次人工或OCR方式完成登录拿到了登录后的Cookie或者Token后面所有请求都带着这个有效会话走那验证码根本不会再出现第二次。在JMeter里这个做法落地起来分两步。第一步你可以在浏览器里手动登录一次从开发者工具里把关键Cookie复制出来然后在JMeter的HTTP Cookie管理器里直接填入这些Cookie值第二步脚本里所有需要登录态的请求都放在这个Cookie管理器作用域之下运行时自动携带。你可能担心“那登录请求本身不就测不了了吗”对这个方案放弃了反复测试登录接口的能力但它换来了“非登录类接口”全流程回归的自由。很多项目的自动化测试是希望快速回归核心业务链路而不是反复抠登录按钮这个取舍完全划算。另外如果你们的系统是基于Token鉴权处理方式也类似。先在外部调一次登录接口拿到Token然后通过JMeter属性或者CSV文件统一注入到脚本里// JSR223 前置脚本中动态设置请求头 import org.apache.jmeter.protocol.http.util.HTTPConstants; vars.put(token, Bearer ${tokenFromFile});4.3 打桩Mock验证码校验服务的另一种思路还有一种比较进阶的做法是直接针对验证码校验接口做Mock。如果你们的验证码下发和校验是分开的两个接口比如GET /captcha负责下发图片POST /captcha/check负责校验答案那么测试侧完全可以把这个校验接口打到Mock服务上让Mock永远返回“校验通过”。这些Mock服务绝对不能用JMeter的HTTP代理来冒充但JMeter本身可以通过一种很巧妙的方式实现干这事把校验接口的请求复制一份加一个预设的成功响应断言再用IfController判断命中该校验请求时直接跳到下一个业务请求。说白了是在脚本层面把校验这一步“跳过去”而不是真正发出去。这种方式适合那些校验接口独立于业务接口的系统而且要求你有修改脚本流程的权限。如果团队有条件更建议用专门的Mock工具比如WireMock或MockServer来做配置简单且干净。Mock方案的最大好处是稳定、不依赖外部环境但也存在一个问题你绕过了服务端校验逻辑万一服务端哪天改了校验规则你也不知道。所以Mock方案一定要和“定期回归真实校验链路”配合使用别把测试环境整个变成假环境。5. 并发与断言场景下的验证码处理细节5.1 压测时验证码不该成为瓶颈很多人做压力测试的时候一跑到登录接口就抓瞎——验证码怎么处理如果你真要压测的是登录接口本身我的建议是直接走线上说的“万能验证码”或“会话绕过”路线。原因很简单压测看重的是吞吐率和响应时间如果脚本里塞了一堆OCR识别的计算那测出来的根本不是服务器的性能而是你本地机器的CPU识别速度。比如你用Tesseract在本地做OCR每个线程识别一次验证码可能要耗掉几百毫秒甚至几秒这会把整个压测的TPS曲线拉出一个巨大的假象服务器明明没到瓶颈但TPS就是上不去。如果你非要验证完整链路请确保OCR服务是独立的、不会成为压测瓶颈。5.2 BeanShell断言怎么判断验证码逻辑是否正确热词里有Jmeter Beanshell断言我得说两句。在处理验证码的脚本里断言的核心是“验证码错误”这类响应信息的捕捉。比如你提交验证码之后服务器返回了一段JSON{ code: 401, message: 验证码错误或已过期 }这时候用Beanshell断言去判断响应体是否包含“验证码错误”可以快速定位是识别问题还是会话问题。我一般这么写String response prev.getResponseDataAsString(); if (response.contains(验证码错误)) { // 置一个标记方便后续重试 vars.put(captchaFailed, true); } else { vars.put(captchaFailed, false); }外层再套一个While控制器判断条件是${captchaFailed} true。这样遇到识别失败就自动重新请求验证码、重新识别脚本容错率会高很多。如果你用的是JSR223 Groovy语法一样只是注意Groovy环境下直接用prev变量即可。5.3 多用户并发时验证码与账号怎么绑定最后一个高发雷区参数化登录时不同用户各自需要独立的验证码。很多JMeter脚本会配置一个CSV文件里面存了几十个测试账号然后用${username}和${password}参数化。但验证码接口如果被放在登录请求的上游只请求一次那所有线程拿到的就是同一个验证码图片。这种情况下OCR识别出的结果只有一个被N个线程同时拿去提交结果必然是大部分线程报“验证码错误”。正确的做法是把“获取验证码 - 保存图片 - OCR识别 - 提交登录”这四步全部放到线程组里让每个线程各自跑完整个闭环。这样每个线程拿到的验证码都是自己请求来的、独立有效的。如果只想复用一次获取验证码的结果也不是不行但必须同时把整个登录接口也串行化或者保证只有一个线程执行登录、其余线程复制这个线程的Cookie。这在JMeter里通常要借助临界控制器让所有线程等待第一个线程完成登录后再继续后面的请求。不过说实话这种做法只适合“登录态准备”场景真正要测登录接口的并发能力还是得回归到独立验证码方案。6. 常见问题排查实录我从现场踩过的坑6.1 正则提取图片数据时总是拿不到值这种问题十有八九是“响应数据格式跟预期不一致”。比如你以为验证码接口返回JSON里有个data.img字段存Base64结果实际返回的是result.imageBase64嵌套层级变了。排查方式很简单在JMeter里加一个“查看结果树”直接看验证码接口的真实响应体形态然后照着真实结构去写正则或JSONPath表达式。另一个容易被忽视的点是如果验证码接口设置在“仅一次控制器”里你跑第二遍迭代时这个Sampler不会重新执行变量自然取不到新值。确保它在线程组主流程里而不是被套进只执行一次的控制器里。6.2 OCR识别出的内容混入干扰字符OCR结果里多出一个空格、一个竖线或者一个引号是家常便饭。我在项目里吃过一次亏Tesseract把验证码“z3Df”识别成了“z3Df|”脚本没做清理直接传给登录接口结果接口返回“验证码错误”。查了半天才发现是多了个竖线字符肉眼看不出来但程序里它就是个实实在在的校验失败。处理办法是在提交之前对OCR结果做一次正则清洗只保留字母和数字String raw vars.get(ocrResult); String clean raw.replaceAll([^a-zA-Z0-9], ); vars.put(captchaText, clean);6.3 提交提示“验证码已过期”或“未登录请登录”这类报错的根源基本在会话管理上。验证码接口和业务接口没有走同一个Cookie管理器或者Cookie管理器作用域只覆盖了前半段请求。解决方案是把HTTP Cookie管理器放在线程组的顶层让它作用于线程组内所有HTTP请求如果系统用的是Token机制同样要确保验证码接口返回的captchaId被正确提取并传给登录请求。顺便提一嘴很多人遇到过类似{code:401,message:未登录,请登录!}的报错而且经常不是验证码问题是前面的登录请求压根没成功脚本还硬着头皮去请求后置接口。排查时要按顺序来先看登录接口返回再看Cookie有没有生效最后才怀疑验证码。6.4 并发场景所有线程报“验证码已被使用”这个跟前面说的“多用户并发”问题类似还有个变种一个验证码只能使用一次。就算你并发四个线程同时提交同一个验证码服务端处理第一个之后后三个都会报“已被使用”。遇到这种系统唯一的方案就是每个线程独立获取验证码或者干脆绕过验证码逻辑。注意还有个细节验证码重新获取后之前提取到的captchaId可能也变了。很多系统的验证码接口每次调用都会生成一个新的uuid你必须同步更新请求参数里的captchaId否则服务端会认为“提交的验证码与当前验证码不匹配”。6.5 现场踩坑经验速查表典型问题常见原因处理方式图片保存后打不开base64没解码或响应内容是文本包装先看响应体确认格式解码前清理换行和前缀OCR识别结果永远少一位验证码有干扰线或粘连字符调整--psm参数增加灰度/二值化预处理请求报“未登录”Cookie未作用于后续请求顶层放Cookie管理器确认用户名密码正确并发报“验证码错误”多线程共用一个验证码每个线程独立获取验证码或使用万能验证码TPS远低于预期OCR识别耗时占用线程压测时改用绕行方案OCR只用于功能链路7. 一点个人建议不同阶段怎么选方案我自己的经验是处理图片验证码这事儿没有银弹得分阶段选策略。功能调试阶段直接上人工看图输入最轻松脚本写得不复杂还能人工盯业务链路对不对接口回归阶段如果能申请到OCR服务就花点时间把全自动方案搭起来重试逻辑一定要做真正到了压测阶段别再纠结验证码识别直接找开发开万能验证码或做会话绕过这是工程效率最高的选择。另外多说一句图片验证码只是接口测试中“动态不可解析参数”的一个代表。你能把这套“获取动态数据 - 处理解析 - 关联到后续请求 - 异常重试”的思维学会后面遇到滑块验证、短信验证码、图形点选验证时思路也能顺利迁移过去。拦截器也好、函数也罢JMeter的核心从来不是某个组件而是你串联这些组件去解决实际问题的能力。