需求文档里有截图、流程图和代码,别再只用 OCR 硬啃了

很多团队做 AI 测试落地，第一步就卡在需求文档。

文档是有的，但格式很复杂：PDF、Word、PPT、图片扫描件混在一起；里面有流程图、审批截图、接口示例、伪代码、表格规则；有些内容在正文里，有些藏在截图里，还有一些关键条件写在页眉页脚、批注或附件里。

于是大家很自然想到一个办法：OCR。

但做过测试的人都知道，只拿 OCR 文本去生成用例，很容易翻车。

比如订单状态流转图被识别成一堆散句，异常分支丢了；接口字段表被读成普通段落，必填、类型、默认值混在一起；代码示例缩进没了，判断条件被改写；产品截图里的按钮和页面状态没有和前后文关联起来。

最后 AI 看似生成了很多测试用例，实际却是“数量很漂亮，质量很危险”。

这篇文章想聊一个更适合测试团队的方案：用 Docling 做文档结构化解析底座，再叠加图像理解、规则校验和测试质量门禁，把复杂需求文档变成可用于需求评审、用例设计、接口测试、自动化生成和 RAG 检索的测试资产。

一、先说结论：不要把需求文档解析等同于 OCR

OCR 解决的是“图里的字是什么”。

测试需要解决的是“这些内容在需求里代表什么”。

这两件事差得很远。

一份复杂需求文档，至少有五类信息需要被保留下来：

如果这些结构被打散，后面的 AI 再强，也只能在碎片上猜。

所以更合理的做法是：先把文档解析成“结构化资产”，再让 AI 做需求理解、风险识别、用例生成，而不是直接把整篇 OCR 文本塞给大模型。

二、为什么 Docling 适合做这个底座？

Docling 是一个开源文档转换与解析工具，官方定位是把复杂文档转换成适合生成式 AI 使用的结构化数据。

它比较适合测试团队关注的原因，不是因为它“能转 Markdown”，而是因为它的思路更接近测试需要的文档理解链路。

第一，它支持多种输入格式。

官方文档列出的输入包括 PDF、DOCX、PPTX、XLSX、HTML、图片、Markdown、CSV、LaTeX、音视频转写等。测试过程中的需求文档、接口说明、评审材料、截图说明、验收清单，往往并不是单一格式，统一入口很重要。

第二，它不是只输出纯文本。

Docling 可以导出 Markdown、HTML、JSON、DocTags 等格式，其中 JSON 可以保留更完整的文档结构。对测试系统来说，这比一段纯文本更有价值，因为我们后续要做字段提取、章节定位、用例追溯、差异比对和质量评分。

第三，它的文档模型里有结构概念。

DoclingDocument 会把内容组织为 texts、tables、pictures、key_value_items、body、groups 等对象，并保留阅读顺序、层级、版面和来源信息。换句话说，它能帮助我们知道：这是表格，那是图片，这段属于哪个章节，这个元素来自哪一页。

第四，它提供了一些增强能力。

比如代码理解、公式理解、图片分类、图片描述、图表抽取等增强能力。官方也提醒，这些能力会增加处理时间，所以在企业落地时不能全量无脑打开，而应该按文档类型、页数和业务价值分层使用。

三、推荐方案：Docling 做结构，AI 做语义，测试做门禁

我建议把需求文档解析拆成三层，而不是压成一个“上传文档，生成用例”的黑盒。

第一层，Docling 负责结构化解析。

它把 PDF、Word、PPT、图片等输入转换为统一的文档对象和可消费的 Markdown / JSON，尽量保留标题、段落、表格、图片、代码块、页码、层级和阅读顺序。

第二层，AI 负责语义补全。

AI 不直接替代解析器，而是在结构化结果之上做业务理解：识别需求点、提取规则、解释流程图、补充图片说明、推断测试风险、生成问题清单和用例草稿。

第三层，测试平台负责质量门禁。

解析结果必须经过可度量的检查，比如章节是否完整、表格列是否对齐、图片是否有说明、流程是否能还原成节点和边、字段规则是否能追溯到来源页码。

可以把它理解成下面这条链路：

需求文档进入系统后，先经过 Docling 解析成结构化文档；再根据元素类型进入不同处理器：正文进入规则抽取，表格进入字段校验，图片和流程图进入视觉理解，代码块进入接口/逻辑识别；最后统一进入测试资产库，生成需求点、风险点、问题单和用例草稿。

四、落地时，Docling 解析结果要怎么存？

很多团队第一版会只保存 Markdown。

这适合人工阅读，但不够支撑测试自动化。

企业落地更建议同时保存三份结果：

如果需求文档包含大量截图和流程图，图片导出模式建议优先使用 referenced，即把图片作为独立文件导出并在文档中引用。这样后续可以把图片单独送入视觉模型，也可以在测试报告里回链到原图。

一个最小化的 Python 入口大概是这样：

from docling.document_converter import DocumentConverter  converter = DocumentConverter() result = converter.convert("需求文档.pdf") doc = result.document  markdown = doc.export_to_markdown() json_data = doc.export_to_dict()

这段代码不是完整生产实现，但它说明了一个方向：不要只拿字符串，要拿文档对象。

如果是服务化场景，可以把解析结果存成如下目录结构：

requirement-assets/   RQ-20260715-001/     source/原始需求文档.pdf     parsed/document.md     parsed/document.json     images/page-003-picture-001.png     quality/parse-report.json     testing/requirement-points.json     testing/test-risk-list.json     testing/testcase-draft.json

这样做的好处是，后续每一个测试用例都可以追溯：它来自哪个需求文档、哪一页、哪个表格、哪张图、哪段代码。

五、图片和流程图，不要只“看见文字”

需求文档里的图片通常有三类。

第一类是界面截图。

测试要关心按钮、输入框、提示文案、状态展示、权限入口，而不是只识别截图里有哪些字。

第二类是流程图。

测试要关心节点、连线、判断条件、异常分支、结束状态。流程图识别不好，最容易漏测。

第三类是图表或架构图。

测试要关心数据来源、依赖系统、异步链路、失败补偿和边界条件。

Docling 可以把图片作为 PictureItem 保留下来，并支持图片分类、图片描述、图表抽取等增强能力。企业落地时，我建议对图片采用“分级处理”：

这里要特别注意：流程图不能只让 AI 写一段描述。

更好的输出是结构化结果，例如：

{   "nodes": ["提交订单", "库存校验", "支付", "出库", "取消订单"],   "edges": [     {"from": "提交订单", "to": "库存校验", "condition": "订单创建成功"},     {"from": "库存校验", "to": "取消订单", "condition": "库存不足"}   ],   "test_focus": ["库存不足分支", "支付超时", "重复提交", "取消后库存回滚"] }

六、表格解析，是需求解析质量的第一道硬门槛

在测试需求里，表格往往比正文更关键。

字段规则、状态枚举、错误码、权限矩阵、兼容性范围、计费规则，经常都写在表格里。

所以表格解析不能只看“有没有内容”，而要看结构是否可信。

建议给表格解析结果增加四类检查：

比如一个接口字段表，如果解析后“是否必填”这一列丢了，AI 仍然可能生成用例，但测试质量会明显下降，因为正向、反向、空值、缺省值用例都会受影响。

因此，企业级方案里要设置质量门禁：关键表格解析置信度不足时，不允许自动生成用例，只允许进入人工复核队列。

七、代码和接口示例，要进入测试设计而不是被当成附件

很多需求文档里会出现代码片段、SQL 示例、接口 JSON、错误码示例。

这些内容对测试非常有价值。

Docling 的增强能力里包含代码理解，可以对文档中的代码块做进一步解析，并识别代码语言等信息。对测试团队来说，重点不是“代码识别得多漂亮”，而是能不能转化成测试检查点。

比如接口示例可以转成：

如果文档里有下面这种规则：

if user_level == "VIP" and order_amount > 500:     discount = 0.9 else:     discount = 1.0

测试系统就不应该只保存这段代码，而应该生成至少三类风险点：VIP 且金额大于 500、VIP 但金额等于 500、非 VIP 但金额大于 500。

这就是结构化解析与测试设计结合的价值。

八、可落地的方案长什么样？

假设一家电商团队要做“需求文档到测试用例”的 AI 辅助平台。

他们的需求文档通常来自产品 Word、流程图 PDF、接口说明 Markdown、页面截图 PNG。过去测试同学需要先手工阅读文档，再整理需求点、画测试点、写用例。AI 接入后，第一版直接把文档丢给大模型，结果生成速度快了，但经常出现三类问题：漏掉流程图分支、表格字段错位、截图里的页面状态没有覆盖。

更稳妥的改造方式是这样的：

第一步，建立文档接入规范。

上传文档时必须绑定需求编号、版本号、业务线、关联迭代、文档来源。解析不是一次性文本处理，而是需求资产入库。

第二步，使用 Docling 做统一解析。

所有文档先转换为 DoclingDocument，再导出 Markdown 和 JSON。Markdown 给人看，JSON 给系统用，图片作为独立资产保存。

第三步，按元素类型分发处理。

正文段落交给需求点抽取模型；表格交给字段规则校验器；图片交给视觉描述和流程图结构化处理；代码块交给接口测试或逻辑分支识别模块。

第四步，建立解析质量报告。

每次解析都输出 parse-report.json，记录页数、章节数、表格数、图片数、代码块数、失败项、低置信度项、人工复核项。

第五步，测试人员只审核高风险内容。

低风险段落可以直接进入用例草稿；关键流程图、关键字段表、涉及资损或权限的规则必须人工确认。

这套方案的价值不是“让 AI 替测试写完全部用例”，而是把测试人员从重复整理中解放出来，把精力放到风险判断和质量把关上。

九、解析服务本身，也要被测试

如果你准备把 Docling 接入测试平台，不要忘了：文档解析服务本身也是一个需要测试的系统。

至少要准备一套回归样本库。

验收指标可以先不用复杂，但要足够工程化。

例如：关键章节召回率、关键表格可用率、图片引用完整率、解析耗时、失败重试率、人工复核占比、从需求点到用例的可追溯率。

官方文档也提醒，开启 OCR、表格结构、公式等能力会显著增加处理时间；生产系统建议设置超时保护，并且根据场景选择必要能力。这一点对测试平台非常关键：不要为了“全功能解析”拖垮整个需求评审流程。

十、落地建议：从三类文档开始，不要一上来全量接入

如果团队第一次做，我不建议直接覆盖所有历史需求文档。

更推荐从三类高价值文档开始：

第一类，接口需求文档。

它的表格、JSON、错误码最容易转成接口测试资产，收益最快。

第二类，核心业务流程文档。

比如下单、支付、退款、审批、开户、授信。这类文档通常包含流程图和状态机，最容易通过结构化解析发现漏测分支。

第三类，页面验收文档。

它包含大量截图、文案、控件和状态展示，适合验证“图片理解 + 测试点生成”的能力边界。

先把这三类做透，再扩展到制度文档、用户手册、历史缺陷、客服知识库，成功率会高很多。

最后：高质量解析，不是为了让 AI 多写，而是为了让测试少猜

很多 AI 测试方案失败，不是因为模型不够强，而是因为输入太乱。

需求文档一旦被解析成一段失去结构的文本，AI 只能靠猜；测试人员也只能靠复核一堆不可靠的输出。

Docling 这类工具真正有价值的地方，是把复杂文档先变成有结构、有来源、有类型、有层级的资产。

在这个基础上，AI 才能更稳定地做需求理解，测试才能更放心地做质量门禁。

所以我的建议很简单：

不要从“让 AI 生成多少用例”开始。

先从“需求文档能不能被高质量解析”开始。

可直接复用的落地清单