前两周团队内部在排新一轮需求评审我扫了一眼需求文档40多页光截图就占了一半里面还有两三张关键业务规则的Excel截图、原型图和一堆手填的审核补充说明。这种图文混合的需求文档过去我得逐页翻、逐条抄、逐条翻译成测试用例一个中等模块下来光是梳理用例就要搭进去一整天。这也就是我为什么要做这套“自动生成case”方案的原因让OCR先把图片里的文字读出来再由LLM理解这些散落的规则片段最终自动生成一份结构化的测试用例初稿。方案本身并不复杂但它解决的是测试团队每天都会遇到、却很少被认真对待的效率问题。如果你也在处理大量带截图、带表格、带扫描件的需求文档或者正在做质量效能方向的工具建设这篇可以给你一条直接能落地的路径。1. 为什么需要OCRLLM这套组合1.1 图文混合需求的真实痛点先说一个很多团队都在硬扛的现状需求文档的形态越来越“杂”。原型截图、业务规则表截图、流程图、邮件转发、PDF扫描件甚至聊天记录里随手拍的白板照片都能成为“需求”的一部分。传统做法是测试人员人工浏览这些材料把文字描述、图片中的提示语、表格中的规则全部搬进用例管理工具。这个过程有四个明显问题。第一耗时。一个中等规模的需求模块涉及页面截图可能在二十张以上每张截图里的弹窗提示、校验文案、按钮状态都要一条条整理成可验证的预期结果。第二容易漏。人眼在长篇幅图文混排内容里跳跃很容易漏掉某个角落里的规则尤其当规则藏在表格单元格里时。第三口径不一致。同一个字段叫“金额”还是“报销金额”一张图一个叫法拆出来的用例在不同版本里难以对应。第四变更成本高。需求改一版截图可能只改了几处但测试人员往往要重新逐张核对因为根本不知道哪里变了。所以我最初的目标很明确不是让AI完全替代测试人员而是把“从文档到用例初稿”的时间从小时级压到分钟级。自动生成case真正的价值是让初稿达到60到70分的可用度再由测试人员把精力集中在用例评审、补边界、查遗漏上。这个定位决定了整套方案的设计走向也决定了后面技术选型的尺度——所有环节都必须优先保证稳定和可修正而不是追求一次到位。1.2 整体方案与流程设计这套方案的核心链路其实只有五步文档收集、图像预处理、OCR识别、LLM结构化解析、用例生成与校验。输入一张截图、一个扫描件或者一份混合文档输出一份带标记的测试用例JSON。很多人第一反应是“这不就是OCR加一个对话模型吗”实际落地时没那么简单。OCR识别出来的是无序文本直接丢给LLM它会生成看起来很通顺但根本对不上的用例。问题出在图文混合需求里除了连续的文字段落还有大量表格和版式信息。表格一旦被打平成纯文本行列关系就丢了LLM只能猜。所以我在中间加了一层“结构化解析”先把OCR文本还原成带表格结构、带字段名的需求描述再交给LLM做语义理解。这一步是整个方案的灵魂后面我会详细展开。这里还要解释一下为什么不用多模态大模型一把梭。多模态模型确实能直接读图但在真实项目里会遇到几个麻烦复杂表格的结构容易被忽略、印章和水印会干扰识别、长截图在缩放后细节模糊、大面积图片换算成token的成本也不低。更关键的是很多团队根本不想把原始需求图直接传到接口OCR在本地执行LLM只吃文本数据的暴露面小得多。而且OCR结果是中间产物识别错了可以直接改文本再重跑出错边界清晰成本低一个量级。2. 技术选型OCR引擎与LLM的取舍2.1 OCR引擎怎么选OCR引擎的选型直接决定整个方案的下限。我对比过几套常见方案这里直接说结论。PaddleOCR现在建议直接用PaddleX里的PP-OCRv4是国内中文场景下综合效果最好的开源方案之一印刷体识别准确率很高而且自带表格结构识别能力也就是PP-StructureV2。缺点是环境依赖比较重装Paddle全家桶的时候容易踩版本坑。RapidOCR是纯ONNX Runtime推理的轻量方案模型和PaddleOCR同源部署非常简单支持CPU适合内网离线环境。Tesseract是老牌方案可定制、可训练但默认模型对中文支持一般要达到生产可用需要自己准备训练数据成本偏高。UMI-OCR这类本地桌面工具适合团队内部快速验证想法但不太适合做集成。如果团队对中文识别率要求高并且已经具备Python环境直接选PaddleX的pipeline更省事检测、识别、表格还原一条龙。如果只有一台普通服务器想快速跑通PoC我建议先用RapidOCR把链路搭起来等确认流程没问题再换强模型避免一开始就被环境问题劝退。这里顺便说一个和“固定模板票据”相关的选型经验如果需求文档里的表格、票据、合同都是固定版式比如固定位置的“姓名”“金额”“日期”不要一上来就全文OCR。先做模板定位框出关键区域再在局部做识别准确率和效率都远高于全文识别后再找字段。只有当版式不固定比如各种截图混在一起才需要走“全文OCRLLM语义解析”的路线。这个边界要在方案设计阶段就想清楚。方案部署方式中文效果表格识别适合场景PaddleOCR/PaddleXPythonGPU/CPU优秀支持PP-StructureV2生产级复杂文档RapidOCRONNXCPU良好需二次处理内网轻量部署Tesseract可训练重一般弱特定定制场景UMI-OCR桌面应用良好较弱人工辅助验证2.2 LLM怎么选LLM的选型要从三个维度看上下文长度、结构化输出能力、部署方式。需求文档经过OCR后文本量经常到几千甚至上万字表格转成HTML结构后还会膨胀。所以模型至少要有32K以上的上下文128K会更从容否则长文档会被截断尾部规则直接丢失。结构化输出能力是硬指标。生成用例必须落成JSON普通对话模型容易在JSON里夹带注释和多余说明解析很痛苦。建议选支持JSON Mode或者Function Calling的模型让输出严格走schema。部署方式上如果数据敏感度不高直接用商用API最省事国内主流的模型都可以长上下文和JSON支持都很成熟。如果要求数据不出内网就选开源模型做私有化部署比如Qwen系列或者GLM系列。7B量化模型在16G显存的机器上可以跑速度尚可14B级别建议至少24G以上显存不然推理延迟会明显拉高。没有GPU也不是不能用CPU能跑但并发一大就扛不住这种情况我建议直接把OCR和LLM拆开OCR走本地服务LLM走API或独立推理节点。选型的另一个参考点是模型榜单但不要迷信榜单核心还是拿自己团队的实际需求文本去测。我的做法是准备二十段“带表格的OCR文本”让候选模型分别抽字段、生成用例人工打分对比。效果比任何公开benchmark都直接。2.3 为什么不是“用多模态模型一把梭”这个决策值得单独说明因为几乎每个听到方案的人都会问。多模态模型可以直接输入图片理论上省掉了OCR环节。但在图文混合需求场景下实际不够用。第一表格还原能力不足。多模态模型对整张图片中的表格常常只能读出单元格里的文字很难稳定还原行列的对应关系。而需求文档里最值钱的恰恰是“哪一行配哪一列”的规则。第二长截图质量不稳定。页面长截图经过模型缩放后小字和弹窗提示会糊成一团。第三成本不可控。大量图片直接传给多模态接口token消耗比纯文本高很多对需要反复调试的团队来说不划算。第四数据合规压力。原始需求图往往包含业务敏感信息走OCR本地识别只传文本比把整张图丢出去更让人放心。所以我始终坚持OCRLLM这套组合OCR负责“读”LLM负责“懂”。每读错一个字我都能在文本中间产物里看到、改掉而不是让模型在图像里瞎猜。3. 核心流程实现从图片到结构化需求3.1 图像预处理很多团队把OCR效果不好归咎于模型其实一半以上的问题出在预处理。拍照截图、扫描件、翻拍件多少都有倾斜、暗光、模糊和阴影。我处理顺序一般是这样的先做角度检测如果检测到文档倾斜超过三度就用透视变换矫正不矫正的话表格线条断开的概率会大幅上升。然后转灰度并做自适应二值化拍照件容易出现局部偏暗全局阈值不好使自适应阈值会稳很多。分辨率太低的图先放大1.5倍到2倍再做识别PaddleOCR内部虽然也有缩放逻辑但预处理先放大能有效减少小字号字段的漏识别。预处理这步花的时间不多但对指标的影响能到5到10个百分点。比如一个表格里的小字说明直接识别可能乱码放大加二值化之后基本能完整读出来。而且预处理还承担一个额外作用把非关键信息减掉。比如截图里的背景色块、装饰性边框通过二值化之后会被过滤成干净的黑白内容LLM拿到的是文本而不是一堆无关字符。3.2 OCR识别与表格结构还原预处理完成之后进入OCR识别环节。我用的是PaddleX的pipeline方式因为它在同一套流程里把文字检测、文字识别、表格结构还原都串起来了。代码大体是这样的from paddleocr import PPStructure engine PPStructure(show_logFalse, langch) result engine(image_path) for item in result: print(item[type]) # text、table、figure等 print(item[res])PP-StructureV2的输出里表格会被还原成HTML结构这一项对后续LLM理解至关重要。“单笔报销金额不超过2000元自动审批”这类规则如果OCR只输出一串文字LLM不知道它属于“金额”列还是“审批方式”列。但转成HTML后行列关系一目了然LLM读起来和看原表几乎没有区别。如果环境限制必须用RapidOCR也没有问题可以只拿检测和识别结果然后配合规则做表格重建。轻量场景下我的经验是先按文本块坐标聚类把同行文字拼成一条记录再用分隔符拼出CSV结构。这个方案对简单表格够用复杂表格建议还是上PP-StructureV2。OCR结果一定要分批保存到本地比如每张图对应一个纯文本文件和一个HTML文件。这不是多此一举后面LLM生成结果不满意时可以直接改OCR文本重跑不用重新识别图片。整个链路里OCR是相对稳定的一环LLM是多变的一环把两者的中间产物固化下来调试效率会高很多。3.3 需求字段提取与归一化OCR跑完后手里是散乱的文本和表格。直接拿去生成case还不行我在这里加了一层“需求结构化”让LLM把OCR内容翻译成统一的数据结构。这一步的核心是减少生成用例时的重复解析也方便后续做规则校验。我给LLM定义的目标结构包含模块名称、操作对象、业务规则列表、权限约束、数据约束、关联流程、特殊情况说明。业务规则最好是显式的“if-then”形态比如“如果金额大于2000则转部门负责人审批”这比原文“超过两千需要领导签字”规范得多生成用例时也能直接映射成步骤和预期结果。输出格式用JSON举一个简化的片段{ module: 费用报销, business_rules: [ { rule: 单笔报销金额2000元系统自动审批, condition: 报销金额2000, action: 触发自动审批 }, { rule: 报销金额2000元转部门负责人审批, condition: 报销金额2000, action: 审批人变更为部门负责人 } ] }这一步有个小技巧在提示词里明确告诉模型“不要新增需求文档中不存在的规则不确定的内容标记为需确认”。很多幻觉就是在这个环节发生的因为模型会把常识当成需求补进去。加了约束之后输出的业务规则基本都能追溯到原文方便评审时对照。4. 让LLM生成可用的case4.1 提示词设计先回答三个问题LLM生成case的质量很大程度取决于提示词设计而提示词设计的核心我总结成三个词Key、Query、Value。用我们自己的话讲就是“我是谁、我在找什么、我能提供什么”。Key是角色定义。生成case前先让模型明白自己是资深测试工程师熟悉功能测试用例设计而不是一个通用问答助手。Query是任务目标要明确告诉模型“从结构化需求中提取可测业务规则生成功能测试用例清单”。Value是输出约定必须严格指定字段、格式、数量约束和预期结果风格。实际用下来的System Prompt大概是这样的你是一名资深测试工程师熟悉Web和App端功能测试用例设计。 任务从用户提供的结构化需求中提取可测业务规则生成功能测试用例清单。 要求 1. 每组业务规则至少生成2条用例正常流程一条异常或边界场景一条。 2. 用例字段必须包含id、title、precondition、steps、expected、data、priority。 3. 只依据需求内容生成禁止编造原文不存在的规则。 4. 不确定的业务规则在title后加“(待确认)”标记。 5. 输出严格为JSON数组不要输出任何解释文字。这里还有一个容易踩的坑不要拿OCR原文直接生成case。OCR文本里有识别误差、重复片段、图表噪声模型容易被带偏。必须先经过3.3节那一层字段提取和归一把干净的规则列表喂进去。我早期图省事直接跳过了结构化那步结果生成的用例里到处都是同一句话的变体回头加了一层解析之后质量立刻稳定了。4.2 借助模板与示例提升生成质量提示词里只给描述还不够我更建议在提示词里注入一个参考用例模板。模型见过一次你想要的格式之后输出的稳定性能提升很多。比如对“自动审批”这条规则参考用例可以这样写{ id: CASE-REIMBURSE-001, title: 单笔报销金额不超过2000元时自动审批通过, precondition: 已登录系统并拥有报销申请权限, steps: [ 进入费用报销页面, 填写报销金额1800元, 提交报销申请 ], expected: 系统自动审批通过状态变为已通过无需人工介入, data: 报销金额1800, priority: P1 }有了这个示例LLM再生成“金额超过2000转人工审批”的用例时字段、风格甚至步骤表达都会自动对齐。我还会在提示词末尾加一句“涉及金额、日期、数量等字段时必须补充边界值用例”比如恰好等于2000元、1999.99元、2000.01元这三条。这一步对测试用例价值提升非常明显因为人工梳理时最容易漏的就是边界。生成策略上我给每个业务规则设了一个强制组合至少一条正向用例、一条反向用例涉及数值的加一条边界用例涉及权限的加一条越权用例。这些策略可以做成配置项不同项目按需开关。之前我们在“报销”模块里用这套组合从6条业务规则一口气生成了24条用例去掉重复和待确认项后有效初稿比例接近八成。4.3 结果校验与兜底措施生成完用例不等于方案结束生产级链路必须有校验和兜底。LLM再强也会偶尔输出不完整的JSON或者把字段写串。我加了一个规则校验器对所有生成结果做三层检查。第一层是格式检查看JSON能否正常解析必填字段是否齐全steps和expected是否非空。第二层是内容检查expected里是否包含可验证的结果词比如“成功”“失败”“提示”“跳转”如果是空泛的描述直接打回重生成。第三层是去重检查按“用例标题前置条件”做hash重复的直接丢弃。这层能挡住不少“同一规则换了个说法生成两条”的情况。再往下兜底LLM调用失败或者返回乱码时设置一次自动重试。连续两次失败就降级为把结构化规则文本输出给人工至少保证原始需求没有丢。实际跑下来正常网络和模型状态下重试率很低但必须有这个机制否则一个超时就会让整批需求停摆。我一直跟团队讲这套方案的定位是“测试人员的加速器不是替代者”。P0级别的核心用例必须人工过一遍P2、P3级别的回归用例可以批量抽查。完全甩手给AI不现实但让AI先干完80%的体力活效果已经很可观了。5. 常见问题与排查技巧实录5.1 常见问题速查表以下是我在落地过程中碰到过的高频问题整理成一张速查表方便直接对照处理。现象可能原因排查与解决中文识别率低、漏字严重原图分辨率不足或倾斜预处理先放大1.5倍并做透视矫正识别出大量乱码二值化阈值不当改用自适应二值化表格行列错乱表格结构未走专项识别用PP-StructureV2还原HTML中文正常但韩文/日文识别不了语言模型未切换PaddleOCR设置对应lang参数或加载多语言模型LLM输出的JSON无法解析模型夹带注释或Markdown开启JSON Mode并要求压缩输出生成的用例大量重复提示词缺少去重要求增加“删除title类似的用例”并做hash去重调云OCR接口报文件格式错误文件格式伪装或参数传错检查实际二进制格式与接口要求是否一致内网部署无法调用外部API缺少外网访问全部改走本地OCR加私有化LLM部署这里想展开两个比较有代表性的案例。一个是在使用PaddleX时默认的langch模型只能识别中英文如果需求文档里混了韩文字段就会出现那类“识别不了韩文”的报错和输出为空。解决方式是换用多语言识别模型或者检测到目标语言后动态指定lang参数。另一个是云OCR接口的“file format error”多半不是扩展名问题而是文件实际编码格式不对比如把PDF伪装成PNG上传。排查时先看文件头几个字节的魔数再对照接口支持的格式基本一击命中。5.2 三板斧定位问题整个链路跑起来之后最怕出现问题却不知道出在哪一环。我的经验是先看图、再看文本、最后看输出按这个顺序排查大多数问题都能快速定位。第一步确认预处理后的图片是否清清晰晰表格线是否完整。如果图片已经糊了后面全白搭。第二步打开OCR中间产物搜索几个关键业务词是否存在如果OCR文本里就缺了那就是识别问题别去折腾LLM。第三步再检查结构化解析后的规则列表看看业务规则有没有被理解歪。如果规则列表正常但用例不对问题出在生成阶段的提示词如果规则列表就不对问题出在结构化阶段的输入多半是OCR噪声干扰了模型判断。这个三板斧方法帮我省了大量时间。早期我总是一出错就去调提示词后来发现十次里有六次是OCR文本本身缺字或表格结构丢失。记住一个原则每一层都要有可验证的中间产物不要让错误穿透到最后一层才暴露。5.3 内网部署与轻量实践很多团队对数据管控有要求OCR尽量内网私有化部署LLM则要视条件选择。我的建议是OCR直接用RapidOCR的ONNX模型起一个HTTP服务输入图片返回文本和表格HTML。这个服务在普通CPU服务器上就能跑并发控制在几个线程以内完全够用。LLM如果实在没有GPU先用云API跑通流程等验证价值之后再采购推理资源。不需要一上来就上高端配置。曾经有人问我远程怎么弄OCR识别我觉得内网起服务的方案才是团队场景里最稳的前端上传图片到服务端服务端调用本地OCR模型中间不经过任何第三方接口。数据不到外网响应也可控。6. 落地效果与个人体会6.1 一组真实对比数据方案成型之后我用一个真实项目做了效果验证这里列一组对比数据供参考。项目是“费用报销审批流”需求文档40多页其中包含16张页面截图和3张业务规则表格旧流程由一名测试手工整理用例大约需要4到6个小时。使用这套方案后从上传文档到拿到60多条用例初稿耗时大约5到8分钟主要时间花在OCR识别和LLM生成上。人工修正和补边界后最终入库用时约1小时。整体效率提升了四到五倍。用例质量上初稿里约有三到四成需要修改主要修改点集中在步骤表达不够精确和预期结果描述偏泛但骨架和覆盖方向基本都能用人工主要是在润色而不是从零起草。这个结果不算完美但已经具有实用价值。如果再算上需求变更场景方案优势更明显文档重新上传后几分钟就能得到新版用例再核对哪些case有变化比人工逐页比对截图要快太多。6.2 后续扩展方向与几句大实话这套方案目前能覆盖的形态是印刷体为主的图文需求。手写文字、涂改严重的图片、复杂嵌套表格识别质量还是会有波动需要人工兜底。想再往前一步可以考虑两个方向一个是把历史用例库接进检索增强生成流程生成时自动调取相似模块的历史用例做参考让风格更贴近团队习惯另一个是沉淀“固定版式模板识别”把高频出现的票据、合同模板做成配置化字段抽取在进入LLM之前就完成一半结构化工作。踩过几次坑之后我最深的体会是这类自动生成case的方案重点从来不在模型本身有多强而在流程里每一层是否留有可验证、可修正的中间产物。OCR错了就改OCR文本LLM错了就调提示词把出错边界隔离开整条链路才能真正稳定地跑起来。最后再分享一个小技巧OCR文本和结构化结果一定要落盘留痕版本记录下来。有人问你这个case是怎么生成的时候你能拿出中间的每一步产物证明逻辑比拍胸脯说“AI生成的就是好”有说服力得多。