PDF 组件选型：转换、解析和批注该怎么测试？

给业务系统选择 PDF 组件时，需要把“支持哪些功能”变成具体的检查任务：转成 Word 后能否继续编辑，表格解析后是否漏行，新增批注保存后能否重新打开。

先按实际需求确定要测试的功能，再选择包含双栏、扫描页、表格或已有批注的业务文件。转换、解析与编辑的预期结果不同，应分别验收；测试文件能打开，还不足以说明这些操作都符合要求。

下面给出按文件类型组织的验收清单，以及记录结果、小范围运行和失败回退的方法。首次接入时可以检查候选方案，更换组件时则对照现有结果，逐项决定后续使用范围。

先写出用户真正需要的结果

“支持 PDF 转 Word”需要继续拆成：能否编辑段落、表格能否增行、保存后内容是否保留。“支持批注”也需要明确：新增和删除能否保存，重新打开后是否仍在。

挑选获准用于测试的业务文件，并写出预期结果。第一轮可以先覆盖下表中的相关类型；具体数量随文件差异和业务风险增加，不把固定样本量当成可靠性保证。

表中的标准要由实际用途决定。若 Word 文件需要继续编辑，像原稿的页面外观还不够；若输出用于固定版式归档，则要另行检查字体、分页和打印效果。

相同文件、明确参数，才有比较意义

每次运行记录输入文件内容哈希、组件版本、部署方式、参数和输出位置。现有组件与候选组件使用同一批文件，允许必要的产品参数差异，但要记录差异的原因。

以 ComPDF 的PDF 转 Word 接口为例，文档列出了 OCR 开关、识别语言、布局模式、图片及批注保留等参数。扫描页与普通文本页应分别检查，参数名称存在并不表示所有输入都会得到相同结果。

同时核对运行形态：Cloud API 的输出检查，不能证明本地 Server SDK 已经适配目标系统；一个转换接口通过，也不能证明 Web Viewer 的预览和编辑流程通过。目标部署使用哪种组件，就单独检查它的版本、系统架构、许可和关键操作。

如果业务有数据存储区域或本地部署要求，应先判断候选方案能否满足，再决定是否上传文件测试。不能用云端演示的结果替代部署条件确认。

验收表要能指向失败文件

可以直接复制下面的 CSV 表头到表格中。一行记录一个文件的一项任务，避免“部分通过”掩盖关键失败。

样本编号,输入哈希,任务,组件及版本,参数记录,输出位置,检查动作,预期结果,实际结果,结论,复核人

结论使用“通过、未通过、待验证”。没有执行的项目保留为待验证；输出文件能打开时，继续完成对应的编辑、保存或字段检查再给结论。

例如，一份双栏 PDF 转成 DOCX 后外观接近原件，但复制文字时左右栏交错。如果下游要顺序提取正文，该任务应记为未通过。如果只是用于查看，还要按查看需求另行判断。这个例子说明如何判定，不代表某个产品的实际输出。

若需要比较耗时，固定运行环境及计时范围，区分上传、排队、处理和下载，重复运行并保留异常。单次演示的耗时不适合直接写成生产性能或厂商排名。

先让候选流程单独产出，再考虑切换

第一轮让候选流程输出到独立位置，正式业务仍沿用原组件的结果。对同一任务保留输入、两份输出和检查记录，暂不让候选产物覆盖正式文件。

至少分开记录四个状态：请求已受理、处理已结束、产物可读取、业务验收通过。异步接口返回任务编号时，仍需等待处理结束；下载得到文件后，也仍需检查内容。

对未通过的文件先分类：是输入本身有问题、参数不适用、部署或许可异常，还是结果不符合业务标准。分类后才能判断应该调整调用、修正应用，还是继续保留旧组件。

回退方法也要走一遍

切换前先在测试环境检查超时、失败重试、重复提交以及权限限制。确认重试不会产生重复业务记录，失败时能找到原任务和输入文件。

再验证回退路径：哪些文件继续交给旧组件，怎样识别新旧版本产物，回退后谁处理未完成任务。已经由用户编辑过的新文件，应先保存和确认格式兼容性，不能直接被旧结果覆盖。

最终按任务和文件类型决定切换范围。普通正文转换通过，可以进入小范围验证；扫描件或批注保存还未通过，就保留相应旧流程。这样的验收表既能支持选型，也能向产品和开发说明：已经解决什么，剩下的风险在哪里。