当前位置：首页 > news >正文

GLM-OCR驱动软件测试自动化：从UI文本到文档的智能验证实践

news 2026/7/2 23:06:57

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( model="glm-4v", # 指定视觉模型 messages=[ { "role": "user", "content": [ {"type": "text", "text": question}, {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_base64}"}} ] } ], temperature=0.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(f"API调用失败: {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.8+，CUDA/cuDNN（与你的GPU驱动匹配），以及torch。

模型下载与加载：从Hugging Face或ModelScope等平台下载GLM-4V的模型权重。使用transformers库加载。

pip install transformers accelerate

from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_path = "/本地路径/glm-4v-9b" # 替换为你的模型路径 tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained(model_path, torch_dtype=torch.float16, device_map="auto", trust_remote_code=True) model.eval()

注意事项：trust_remote_code=True是必须的，因为GLM模型有自定义代码。torch_dtype=torch.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_url="http://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, format="PNG") 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, files=files, data=data, timeout=30) 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(scope="session") 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(state="visible") screenshot_bytes = order_card.screenshot(type="png") # 将字节数据转为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_page=1, last_page=1) 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正确理解需求的“问题”和“指令”，这本身就是一个充满挑战和乐趣的新领域。

查看全文

http://www.jsqmd.com/news/1111734/