
摘要 需求文档里最关键的业务逻辑,往往藏在一张流程图、一张原型截图或一个复杂表格中。当测试工程师面对这类“非结构化”信息时,AI 能否像人类一样“看懂”并自动生成覆盖全面的测试用例?本文将手把手拆解一套可落地、低成本、高精度的技术方案,涵盖从 PDF 图片提取、OCR 识别优化,到多模态 LLM 理解与结构化输出的全链路实现,并附关键代码片段与 Prompt 模板,助你打造真正的“AI 测试之眼”。
在智能座舱、ADAS 或车联网等复杂系统的需求文档中,纯文字描述早已无法满足表达需要。产品经理和系统工程师更倾向于使用:
这些图文混合内容,恰恰是测试用例设计的核心依据。然而,当前主流的 AI 测试方案(如基于 LLM 解析 Word 文档)对此束手无策——因为大模型“看不见”图片。
结果就是:测试工程师仍需人肉盯图,手动梳理分支、记录规则、再一行行编写用例。效率低、易遗漏,且难以规模化。
有没有可能,让 AI 不仅能读,还能看?
答案是肯定的。本文将带你构建一套完整的 “图文需求 → 结构化测试路径” 自动化 pipeline。
我们的目标很明确:输入一份含图的需求文档,输出一份 JSON 格式的、可直接用于生成测试用例的结构化路径描述。
为此,我们设计了如下四阶段 Pipeline:
原始需求文档 -> 图片提取 -> OCR 文字识别 -> 多模态 LLM 理解] -> 结构化 JSON 输出
表格
阶段 | 推荐工具 | 选择理由 |
|---|---|---|
文档解析 | pdf2image + python-docx | 轻量、稳定,完美提取内嵌图片 |
OCR 引擎 | PaddleOCR | 百度开源,中文场景 SOTA,支持检测+识别+方向分类 |
多模态 LLM | Qwen-VL / LLaVA-1.6 | 开源可私有化部署,支持图像+文本联合推理 |
后处理 | OpenCV + networkx | 图像预处理 & 后续路径分析 |
💡 为什么不用 GPT-4V? 虽然 GPT-4V 视觉能力强大,但企业级需求文档通常涉密,无法上传至公有云。因此,私有化部署的开源多模态模型是更务实的选择。
PDF 中的矢量图在转为图片时极易模糊。我们使用 pdf2image 并设置高 DPI:
python编辑
from pdf2image import convert_from_path
# 以 300 DPI 提取,保证文字清晰
images = convert_from_path("requirement.pdf", dpi=300)
for i, img in enumerate(images):
img.save(f"page_{i}.png", "PNG")
对于 Word 文档,使用 python-docx 提取内嵌图片:
python编辑
from docx import Document
doc = Document("requirement.docx")
for rel in doc.part.rels.values():
if "image" in rel.target_ref:
with open(f"image_{rel.rId}.png", "wb") as f:
f.write(rel.target_part.blob)
流程图中的文字常带有旋转、弯曲或低对比度。直接调用 OCR 会导致大量识别错误。
解决方案:OpenCV 预处理 + PaddleOCR 精调
python编辑
import cv2
import numpy as np
def preprocess_image(image_path):
img = cv2.imread(image_path)
# 1. 灰度化
gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
# 2. 二值化(增强对比度)
_, thresh = cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY + cv2.THRESH_OTSU)
# 3. 去噪
denoised = cv2.fastNlMeansDenoising(thresh, None, 10, 7, 21)
return denoised
# 使用 PaddleOCR
from paddleocr import PaddleOCR
ocr = PaddleOCR(use_angle_cls=True, lang="ch") # 启用方向分类
processed_img = preprocess_image("flowchart.png")
result = ocr.ocr(processed_img, cls=True)
✅ 效果对比:
这是最核心、也最容易被忽视的一环。不能只丢一张图给 LLM,而要给出明确的指令和输出格式。
“请描述这张图。”
→ LLM 可能输出一段散文,无法用于自动化。
text编辑
你是一名资深汽车软件测试专家,请严格按以下步骤分析此业务流程图:
1. **识别节点**:列出所有操作节点(如“输入手机号”、“验证邮箱”),忽略装饰性元素。
2. **识别决策点**:找出所有菱形判断框,并明确其“是/否”分支指向的下一个节点。
3. **提取业务规则**:从图中文字提取关键校验规则(如“手机号必须为11位”)。
4. **输出格式**:严格返回以下 JSON Schema:
{
"nodes": [{"id": "node_1", "label": "输入手机号"}],
"edges": [{"from": "node_1", "to": "node_2", "condition": "手机号有效?"}],
"rules": ["手机号长度必须为11位", "不能包含字母"]
}
流程图中的箭头常被 OCR 误识别为“→”、“—”等符号,干扰 LLM 理解。
应对:
在预处理阶段,使用 形态学操作(Morphological Operations)擦除细线: python编辑
kernel = np.ones((2,2), np.uint8)
cleaned = cv2.morphologyEx(thresh, cv2.MORPH_CLOSE, kernel)
在 Prompt 中明确告知:“忽略所有箭头和连接线符号,只关注文本节点。”
多模态模型可能因 OCR 错误或自身不确定性,虚构出图中没有的路径。
应对:
对于跨泳道、多层嵌套的流程图,单纯 OCR 无法还原空间关系。
进阶方案(可选):
detectron2)先对图像做区域分割,识别“标题区”、“流程区”、“注释区”。完成上述 pipeline 后,我们将获得一份机器可读的 JSON,它可以直接驱动测试用例生成。
输入(流程图 OCR + LLM 输出):
json编辑
{
"nodes": [
{"id": "n1", "label": "输入手机号"},
{"id": "n2", "label": "发送验证码"},
{"id": "n3", "label": "输入验证码"}
],
"edges": [
{"from": "n1", "to": "n2", "condition": "手机号有效?"},
{"from": "n2", "to": "n3", "condition": "always"},
{"from": "n1", "to": "n1", "condition": "手机号无效?"}
]
}
输出(自动生成的测试用例草稿):
python编辑
def test_register_with_invalid_phone():
"""路径: 输入无效手机号 -> 提示错误 -> 停留在本页"""
page.input_phone("123")
assert page.get_error() == "手机号格式错误"
assert page.current_step == "input_phone"
def test_register_happy_path():
"""路径: 输入有效号 -> 发验证码 -> 输入正确码 -> 成功"""
page.input_phone("13800138000")
page.click_send_code()
page.input_code("123456")
assert page.is_on_success_page()
📊 效率提升:
让 AI 理解图文混合需求,不再是遥不可及的概念。通过 OCR + 多模态 LLM + 精心设计的 Prompt,我们已经能够构建出稳定、安全、高效的“视觉理解”能力。
这不仅是提效工具,更是一次测试左移(Shift-Left) 的实践——在需求阶段就完成测试路径的全覆盖规划。
下一步,我们将基于本篇输出的结构化 JSON,深入探讨 **“如何用图论算法自动拆解所有测试路径”**。敬请期待系列第二篇:《从流程图到测试路径:基于图论的自动化分支拆解》。