1. 项目概述当GLM-OCR遇见软件测试最近在做一个软件测试项目遇到了一个挺典型的痛点UI界面上的文本和生成的文档内容验证起来太费劲了。比如一个保险保费计算器前端页面显示“总保费¥12,345.67”后台生成的PDF保单里也有一行“应缴总保费人民币壹万贰仟叁佰肆拾伍元陆角柒分”。传统测试要么靠人眼一个个对要么写一堆脆弱的正则表达式去匹配效率低还容易漏。正好在调研大模型应用时注意到了GLM系列模型特别是其OCR能力灵光一现能不能用GLM-OCR来驱动这部分验证工作的自动化这个想法不是空穴来风。GLM-OCR作为智谱AI开源的多模态大模型GLM-4-Vision的一个重要能力它不仅仅是“认出图片上的字”。相比传统OCR如Tesseract或某些云OCR API它的核心优势在于强大的上下文理解和信息结构化能力。简单说传统OCR给你的是“文本行坐标文字”你需要自己写规则去理解“¥12,345.67”是金额“总保费”是标签。而GLM-OCR你可以用自然语言问它“图片中‘总保费’后面的数字是多少”或者“请提取图中所有金额数字并汇总”它可以直接给你答案。这对于测试验证来说简直是降维打击。那么GLM-OCR如何具体“助力”软件测试呢核心场景就是自动化验证UI文本与文档内容。这涵盖了从GUI自动化测试如Selenium, Playwright中的屏幕截图文本校验到对系统生成的报告、合同、票据等各类文档PDF、图片格式的内容准确性验证。目标用户很明确软件测试工程师、质量保障QA工程师、以及任何需要频繁进行内容正确性校验的开发者。通过引入GLM-OCR我们可以将那些依赖人工目视检查或复杂脚本解析的重复性、高精度要求的工作转化为稳定、智能的自动化检查点从而提升测试覆盖率、效率和可靠性。2. 核心思路与方案设计构建智能验证管道把GLM-OCR应用到软件测试中不是一个简单的“调个API替换现有OCR”的动作而需要一套完整的方案设计。核心思路是构建一个“智能验证管道”将传统的“截图/文档 - OCR识别 - 规则匹配 - 断言”流程升级为“截图/文档 - 大模型理解与提取 - 智能断言”的流程。2.1 传统OCR验证流程的瓶颈在深入新方案前先看看老办法为什么吃力。假设我们要验证一个网页表格里“状态”列是否为“已支付”。截图/获取元素通过自动化工具如Selenium定位表格并截图或直接获取元素文本。OCR识别如果需要如果元素文本无法直接获取比如Canvas渲染的图表则对截图使用Tesseract进行OCR得到一堆文本块和坐标。文本处理与定位写代码解析OCR结果可能需要根据“状态”表头的大致坐标去附近区域寻找“已支付”这三个字。坐标稍有变动如UI微调、分辨率不同脚本就可能失效。规则断言用字符串匹配或正则表达式判断是否包含“已支付”。这个流程的瓶颈在于脆弱性和低智能。UI布局变化、字体渲染差异、背景干扰都会影响OCR精度和后续的文本定位逻辑。对于更复杂的需求如“验证摘要段落第三行的金额与数据库查询结果一致”传统方法几乎需要为每个用例定制复杂的解析器维护成本极高。2.2 GLM-OCR驱动的智能验证管道设计我们的新方案围绕GLM-OCR的核心能力——视觉问答VQA和指令跟随——进行设计。整个管道分为四个层次数据采集层负责获取待验证的“视觉材料”。这包括UI截图通过自动化测试框架Selenium, Playwright, Appium在测试执行过程中截取全屏、区域或特定元素的图片。文档转换将待验证的PDF、Word等文档通过工具如pdf2image库转换为图片格式。因为GLM-OCR的输入是图像。智能解析层这是核心由GLM-OCR模型担任。我们不再满足于获取原始文本而是向模型提出具体的“验证问题”。例如直接提取“请提取图片中‘用户名’右侧输入框内的文本。”问答验证“图片中的‘订单总额’是否等于‘¥1,299.00’”逻辑判断“根据表格内容状态为‘已完成’的订单总金额是多少”文档理解“在PDF第一页的‘乙方签字’处是否有签名痕迹” 我们将测试用例的“预期结果”转化为给模型的“指令”Prompt模型返回结构化的答案JSON格式最佳。断言与集成层接收模型返回的答案并与测试用例的预期值进行比对。这里需要处理模型答案的不确定性。GLM-OCR虽然强大但并非100%准确。我们的断言逻辑需要有一定的容错性或者引入置信度评分。例如模型返回{value: ¥1,299.00, confidence: 0.98}我们可以设定当confidence 0.95且value与预期值匹配时断言通过。这一层需要与现有的测试框架如pytest, unittest, JUnit无缝集成。测试管理层管理和组织这些“智能验证点”。可以将针对某个UI组件或文档的验证指令和预期结果封装成可复用的测试函数或类纳入测试套件中统一调度。方案选型考量为什么是GLM-OCR而不是其他除了其强大的理解能力开源和可本地部署是关键。对于涉及敏感数据的测试如金融、医疗软件将截图或文档上传至公有云OCR服务存在安全合规风险。GLM系列模型支持私有化部署满足了企业级测试对数据安全的要求。此外其API设计友好支持通过curl或SDK简单调用易于集成到自动化测试流水线中。3. 环境搭建与模型部署实战理论说得再好不如动手搭起来。要让GLM-OCR在测试项目中跑起来第一步就是搞定环境。这里提供两种主流路径使用官方API快速上手和本地部署生产级推荐。3.1 路径一使用智谱AI开放平台API适合原型验证如果你只是想快速验证想法或者测试数据不敏感使用官方云API是最快的方式。注册与获取API Key访问智谱AI开放平台完成注册在控制台创建应用即可获得唯一的API Key和Secret Key。这是调用服务的凭证。安装SDK智谱提供了Python SDK安装非常简单。pip install zhipuai编写一个最简单的测试脚本我们来创建一个函数用于验证一张图片中的文本。import zhipuai import base64 from pathlib import Path def verify_text_with_glm_ocr(api_key, image_path, question, expected_answer): 使用GLM-OCR API验证图片内容 :param api_key: 智谱API Key :param image_path: 待验证图片路径 :param question: 向模型提出的问题如“图片中的标题是什么” :param expected_answer: 期望的答案 :return: (bool, str) 是否通过模型返回的实际答案 # 初始化客户端 zhipuai.api_key api_key # 读取图片并编码为base64 with open(image_path, rb) as image_file: image_base64 base64.b64encode(image_file.read()).decode(utf-8) # 构建请求消息。GLM-4-Vision模型支持多轮对话这里我们使用单轮。 response zhipuai.model_api.invoke( modelglm-4v, # 指定视觉模型 messages[ { role: user, content: [ {type: text, text: question}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{image_base64}}} ] } ], temperature0.1, # 低温度值使输出更确定适合测试验证场景 ) # 解析响应 if response[code] 200: actual_answer response[data][choices][0][message][content].strip() # 简单进行字符串包含判断实际可根据需求更精细比较 is_passed expected_answer in actual_answer return is_passed, actual_answer else: raise Exception(fAPI调用失败: {response[msg]}) # 使用示例 API_KEY 你的API Key result, answer verify_text_with_glm_ocr(API_KEY, screenshot_login.png, 登录按钮上的文字是什么, 登录) print(f验证结果: {result}, 模型回答: {answer})实操心得初次调用API最容易出错的是图片编码格式和消息结构。务必确保image_url的格式正确且messages是一个列表其中user的content是一个包含文本和图片的列表。将temperature设为较低值如0.1可以减少模型回答的随机性让验证结果更稳定。3.2 路径二本地部署GLM模型适合企业级应用对于需要处理敏感数据或希望控制成本、延迟的团队本地部署是必选项。GLM系列模型提供了多种规模的版本平衡精度与资源消耗。硬件与软件准备GPU推荐至少拥有16GB显存的GPU如NVIDIA RTX 4090, A10。GLM-4-9B等较小模型可在消费级显卡上运行但视觉模型GLM-4V对显存要求较高。环境安装Python 3.8CUDA/cuDNN与你的GPU驱动匹配以及torch。模型下载与加载从Hugging Face或ModelScope等平台下载GLM-4V的模型权重。使用transformers库加载。pip install transformers acceleratefrom transformers import AutoModelForCausalLM, AutoTokenizer import torch model_path /本地路径/glm-4v-9b # 替换为你的模型路径 tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(model_path, torch_dtypetorch.float16, device_mapauto, trust_remote_codeTrue) model.eval()注意事项trust_remote_codeTrue是必须的因为GLM模型有自定义代码。torch_dtypetorch.float16可以显著减少显存占用并加速推理对精度影响很小。构建本地推理服务直接在每个测试脚本中加载大模型不现实太重了。最佳实践是将模型部署为一个独立的HTTP服务测试脚本通过REST API调用它。可以使用FastAPI快速搭建。# server.py (简化示例) from fastapi import FastAPI, File, UploadFile from PIL import Image import io # ... 上面加载model和tokenizer的代码 ... app FastAPI() app.post(/ocr_qa) async def ocr_question_answer(image: UploadFile File(...), question: str ): # 读取上传的图片 image_data await image.read() pil_image Image.open(io.BytesIO(image_data)) # 使用模型进行视觉问答 with torch.no_grad(): response, _ model.chat(tokenizer, [pil_image], question, history[]) return {answer: response} # 运行服务: uvicorn server:app --host 0.0.0.0 --port 8000这样你的自动化测试脚本只需要像调用普通API一样向http://localhost:8000/ocr_qa发送图片和问题即可实现了与测试框架的解耦。4. 集成到自动化测试框架以Playwright Pytest为例环境搭好了接下来就是如何把它“编织”到我们日常的自动化测试流程中。这里以目前流行的Playwright用于UI自动化和Pytest测试框架组合为例展示一个完整的集成案例。4.1 场景定义验证电商订单确认页假设我们测试一个电商网站需要验证用户下单后订单确认页面上显示的信息订单号、金额、商品名称是否正确。传统方法痛点订单号是动态生成的商品名称可能带有特殊符号或换行金额格式需要精确匹配。用Playwright的text_content()或inner_text()获取元素文本后需要编写复杂的字符串处理和正则表达式来提取和比对。GLM-OCR智能方法我们直接对订单确认页的关键区域进行截图然后向GLM-OCR提问让它直接提取出我们需要的信息。4.2 代码实现创建智能验证夹具Fixture首先我们创建一个Pytest夹具用于封装与GLM-OCR服务的交互。这里假设我们使用本地部署的API服务路径二。# conftest.py 或某个公共模块 import pytest import requests import base64 from io import BytesIO from PIL import Image class GLMOCRValidator: def __init__(self, api_base_urlhttp://localhost:8000): self.api_url f{api_base_url}/ocr_qa def ask_image(self, image: Image.Image, question: str) - str: 向GLM-OCR服务发送图片和问题返回答案文本 # 将PIL Image转换为base64 buffered BytesIO() image.save(buffered, formatPNG) img_str base64.b64encode(buffered.getvalue()).decode() # 这里为了简化假设服务端接收base64。实际更常用multipart/form-data上传文件。 # 使用文件上传方式更佳 files {image: (screenshot.png, buffered.getvalue(), image/png)} data {question: question} try: response requests.post(self.api_url, filesfiles, datadata, timeout30) response.raise_for_status() result response.json() return result.get(answer, ).strip() except requests.exceptions.RequestException as e: pytest.fail(f调用GLM-OCR服务失败: {e}) pytest.fixture(scopesession) def ocr_validator(): 提供一个全局的OCR验证器实例 return GLMOCRValidator()4.3 编写具体的测试用例接下来在测试用例中使用这个夹具和Playwright。# test_order_confirmation.py import re def test_order_confirmation_page(ocr_validator, page): 验证订单确认页面关键信息。 前置条件已登录并完成下单流程进入订单确认页。 # 1. 导航到订单确认页 (假设已有相关操作) # page.goto(/order/confirm/123456) # 2. 对包含订单信息的整个卡片区域截图 order_card page.locator(.order-summary-card) # 确保元素可见 order_card.wait_for(statevisible) screenshot_bytes order_card.screenshot(typepng) # 将字节数据转为PIL Image from PIL import Image import io image Image.open(io.BytesIO(screenshot_bytes)) # 3. 定义验证问题并调用GLM-OCR # 问题需要尽可能清晰、无歧义引导模型给出精确答案。 questions_expected [ (请提取页面中的订单编号通常是一串数字或字母数字组合。, r^[A-Z0-9\-]$), # 用正则做格式校验 (商品名称列表中第一个商品的完整名称是什么, iPhone 15 Pro Max 256GB 深空黑色), # 精确匹配 (订单总计金额含税和运费是多少格式请统一为‘¥xxxx.xx’。, ¥10,299.00), ] for question, expected in questions_expected: answer ocr_validator.ask_image(image, question) print(f问题: {question}) print(f模型回答: {answer}) print(f预期: {expected}) # 4. 执行断言 if expected.startswith(^): # 如果是正则表达式 assert re.match(expected, answer) is not None, f订单编号格式不符。得到: {answer} else: # 对于金额可能模型返回‘人民币10299元’或‘¥10299’需要灵活处理 # 这里简化处理进行标准化后比较 normalized_answer answer.replace(人民币, ).replace(元, ).replace(,, ).strip() normalized_expected expected.replace(¥, ).replace(,, ).strip() # 更健壮的做法是提取数字部分进行比较 import re answer_number re.search(r[\d\.], normalized_answer) expected_number re.search(r[\d\.], normalized_expected) if answer_number and expected_number: assert float(answer_number.group()) float(expected_number.group()), f金额不匹配。得到: {answer} else: assert expected in answer, f答案不包含预期内容。得到: {answer} print(所有订单信息验证通过)核心技巧精准截图不要截全屏而是定位到包含待验证信息的特定元素如.order-summary-card进行截图。这能减少无关信息干扰提高模型识别精度和速度。设计好的Prompt问题Prompt的质量直接决定答案的准确性。问题要具体、无歧义。例如“订单金额是多少”不如“订单总计金额含税和运费是多少格式请统一为‘¥xxxx.xx’。”后者给出了上下文和输出格式的指引。灵活的断言逻辑模型返回的文本可能包含额外的描述或格式略有不同如“总计¥10299” vs “¥10,299.00”。断言逻辑不能是僵硬的字符串完全相等而应该进行标准化处理如移除货币符号、千位分隔符或提取核心数字/文本后再比较。这是智能验证管道稳定性的关键。5. 高级应用与场景扩展基础的UI文本验证只是开始。GLM-OCR在软件测试中的潜力远不止于此尤其是在文档内容验证和复杂逻辑校验方面。5.1 自动化验证生成文档PDF/报告许多系统会生成PDF报告、Word合同、Excel对账单等。手动核对这些文档内容是一项噩梦级任务。技术实现使用pdf2image用于PDF或python-docx/openpyxl结合截图将文档转换为图片然后提交给GLM-OCR。from pdf2image import convert_from_path def validate_pdf_invoice(pdf_path, ocr_validator): 验证PDF发票内容 # 将PDF第一页转为图片 images convert_from_path(pdf_path, first_page1, last_page1) invoice_image images[0] validation_checks [ (发票抬头购买方名称是什么, XX科技有限公司), (发票号码是多少, r^NO\.\d{10}$), (不含税金额总计是多少元, 8,849.56), (销售方盖章处是否有红色印章, 是), # 甚至可以进行简单的视觉判断 ] for question, expected in validation_checks: answer ocr_validator.ask_image(invoice_image, question) # ... 断言逻辑 ...场景价值自动化回归测试中每次构建后自动生成报告并与基线报告对比合同管理系统中验证关键条款和金额是否正确填充。5.2 复杂逻辑与上下文关联验证这是GLM-OCR相比传统OCR的杀手级优势——理解上下文和关联信息。场景一表格数据汇总校验。验证一个数据仪表盘中“本月总收入”的数字是否等于下方明细表格中所有“收入”列的和。Prompt设计“请识别图片中表格的所有行提取‘金额’列的数字并计算它们的总和。只返回最终的数字结果。”实现模型会先理解表格结构然后执行计算。测试脚本只需比较模型返回的总和与UI上显示的“总收入”是否一致。场景二状态一致性验证。在一个工单系统中验证当工单状态变为“已解决”时“解决人”和“解决时间”字段是否自动填充且不为空。Prompt设计“请检查图片中‘状态’字段是否为‘已解决’。如果是请检查‘解决人’和‘解决时间’字段是否有内容并返回格式为‘解决人[内容]解决时间[内容]’如果不是返回‘状态未改变’。”场景三多步骤流程验证。在一个多页表单流程中验证第二步页面显示的信息如“您输入的电话号码是138****1234”与第一步输入的信息是否一致。实现分别在第一步输入后和第二步页面对关键信息区域截图。测试脚本保存第一步输入的数据然后在第二步截图后向模型提问“图片中显示的电话号码后四位是什么”并与保存的数据进行比对。经验之谈在涉及复杂逻辑的Prompt设计时遵循“角色定义 - 任务分解 - 输出格式化”的步骤。例如给模型的指令可以是“你现在是一个软件测试助手。请按步骤执行1. 定位图片中的表格。2. 提取第三列标题为‘价格’的所有数字。3. 计算这些数字的平均值。4. 只返回平均值保留两位小数。” 这种结构化的指令能极大提高模型响应的准确性和一致性。6. 避坑指南与效能优化在实际项目中大规模应用GLM-OCR进行测试会遇到不少坑。这里分享一些实战中积累的经验和优化技巧。6.1 常见问题与解决方案识别精度波动现象同一张图片相同问题偶尔返回不同结果或置信度不高。排查图片质量确保截图清晰、无模糊、无遮挡。对比度低、文字过小、背景复杂都会影响识别。可以通过PIL库进行简单的图像预处理如转换为灰度图、二值化、调整对比度。from PIL import Image, ImageEnhance image Image.open(...).convert(L) # 转灰度 enhancer ImageEnhance.Contrast(image) image enhancer.enhance(2.0) # 增加对比度Prompt模糊检查问题是否足够明确。尝试更具体的描述或添加示例。模型版本关注官方模型更新新版本通常在精度和指令跟随上有提升。解决引入重试机制和多数表决。对于关键断言可以连续询问模型3次如果2次以上答案一致则采用该答案。处理速度慢现象本地部署模型推理一张图片需要数秒甚至更久影响测试套件执行速度。优化图片尺寸在保证关键信息清晰的前提下尽可能缩小截图区域。800x600的图片推理速度远快于1920x1080的全屏截图。模型量化使用bitsandbytes库进行4-bit或8-bit量化能大幅降低显存占用和提升推理速度对精度损失很小。批量推理如果有多张图片需要验证可以尝试将问题合并如果逻辑允许或者改造后端服务支持批量图片处理减少HTTP请求开销。缓存对于在同一个测试会话中不变的内容如静态页面的标题可以将模型回答缓存起来避免重复查询。成本与资源控制使用云API时问题频繁调用API会产生费用。策略非关键路径不用只在核心业务流程、金额、关键标识等必须验证的地方使用GLM-OCR。简单的静态文本依然用Playwright原生的文本获取方法。Mock服务在开发或调试测试用例时可以搭建一个Mock服务器模拟GLM-OCR的返回避免消耗API额度。监控与告警设置API调用量的监控避免意外超支。6.2 提升测试稳定性的设计模式封装验证操作不要在每个测试用例里都写一遍截图、调用API、解析答案的代码。将其封装成通用的Page Object方法或自定义的expect断言。# 在Page Object类中 class OrderPage: def __init__(self, page): self.page page self.ocr GLMOCRValidator() def expect_order_total_equal(self, expected_amount): 断言订单总计金额正确 locator self.page.locator(.total-amount-section) screenshot locator.screenshot() answer self.ocr.ask_image(screenshot, f此区域显示的总金额是多少请只返回数字例如‘10299’) # ... 解析和断言逻辑 ... assert extracted_amount expected_amount, f金额不符预期{expected_amount}得到{extracted_amount}分离测试数据与验证逻辑将测试用例的预期结果和对应的Prompt模板化、数据驱动化。可以用YAML或JSON文件来管理。# validation_cases.yaml - case_name: 验证登录成功提示 element_locator: .alert-success prompt_template: 图片中的成功提示信息是什么 expected_answer: 登录成功 assertion_type: contains - case_name: 验证余额显示 element_locator: .balance-text prompt_template: 图片中显示的账户余额数字是多少忽略货币符号 expected_answer: {{ dynamic_balance }} assertion_type: equals这样测试脚本只需要读取这个配置文件就能执行一系列验证维护性大大增强。建立基线对比机制对于文档验证可以首次手动确认一份正确的文档作为“黄金基线”Golden Baseline。后续自动化测试时不仅验证关键字段还可以让模型比较新生成的文档与基线文档在指定区域的视觉差异或文本差异用更智能的方式做“视觉回归测试”。将GLM-OCR引入软件测试本质上是在测试断言层引入了一个强大的“语义理解引擎”。它不能替代所有测试但在处理非结构化文本、复杂文档和需要上下文理解的验证场景时能极大解放人力并覆盖以往难以自动化的检查点。开始可以从一两个核心场景试点积累Prompt设计和断言处理的经验再逐步推广。这个过程中测试工程师的角色也在悄然进化从编写硬编码的检查规则转变为设计能够引导AI正确理解需求的“问题”和“指令”这本身就是一个充满挑战和乐趣的新领域。