背景：测试用例编写的痛点？

测试用例编写是软件测试中最"体力活"的环节。据统计，一个中等复杂度的需求，测试工程师平均需要花费：

环节	耗时占比	痛点
理解需求文档	30%	文档格式混乱，PRD、原型图、流程图分散
提取测试点	40%	需要人工识别边界条件、异常场景
编写用例格式	20%	重复劳动，复制粘贴到用例管理工具
评审与修正	10%	遗漏场景、描述不清

传统AI方案的局限：

早期的"AI生成用例"大多基于纯文本输入，比如把需求文档的Word/PDF文字提取出来喂给ChatGPT、DeepSeek。但现实中，大量关键信息藏在图片里——产品原型图、流程图、手绘草图、甚至Excel截图。

我们曾遇到过一个案例：某金融系统的"转账限额规则"只存在于一张复杂的Excel配置表截图中，文字提取工具完全失效，测试工程师只能肉眼识别37个单元格，手动编写142条用例，耗时2天。

这就是OCR+LLM方案的出发点：让AI不仅能"读文字"，还能"看懂图"。

利用OCR与LLM的结合：

除此之外，随着产品迭代速度加快，每次需求变更都需要重新修改、补充用例，传统手写方式无法适配敏捷开发的节奏，而自动生成方案可快速响应需求变更，大幅提升测试效率，让测试工程师将精力聚焦在核心场景优化、缺陷排查上，而非重复的用例编写工作。

二、解决什么问题？

这个方案设计初衷主要为了解决三类场景：

场景1：原型图/设计稿 → 功能用例

产品经理给的是Axure/墨刀导出的PNG，包含页面元素、交互说明、业务规则。传统方式需要测试工程师对着图一条条写，现在让AI直接看图生成。

场景2：流程图/时序图 → 流程用例

复杂的业务状态流转（如订单从"待支付"到"已完成"的7个状态），流程图里画得很清楚，但文字提取会丢失箭头逻辑。OCR需要识别节点和连接关系。

场景3：配置表/规则表 → 组合用例

权限矩阵、费率表、风控规则等，往往以Excel截图或表格图片形式存在。需要识别行列关系，并应用组合测试/正交试验法生成用例。

核心目标：

三、技术方案架构

整体架构分为感知层→认知层→生成层，模拟人类测试工程师"看→懂→写"的过程：

┌─────────────────────────────────────────────────────────┐
│                      输入层                              │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐  │
│  │  PDF    │  │ 图片    │  │ Word    │  │ 原型链接 │  │
│  │ 文档    │  │ (PNG/JPG)│  │ 文档    │  │ (可选)   │  │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘  │
└───────┼────────────┼────────────┼────────────┼────────┘
        │            │            │            │
        └────────────┴────────────┘            │
                     │                         │
                     ▼                         │
┌──────────────────────────────────────────────┴─────────┐
│                   感知层 (OCR Engine)                  │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐  │
│  │  通用OCR    │  │  表格OCR    │  │   版面分析       │  │
│  │ (PaddleOCR/ │  │ (TableMaster│  │ (LayoutParser   │  │
│  │  Azure AI)  │  │ /Structurize)│  │ /DocLayout-YOLO)│  │
│  └─────────────┘  └─────────────┘  └─────────────────┘  │
│                        │                               │
│                        ▼                               │
│  ┌─────────────────────────────────────────────────────┐ │
│  │              结构化文本 + 坐标信息                   │ │
│  │  {text: "用户名", bbox: [x1,y1,x2,y2], type: "input"}│ │
│  └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│                   认知层 (LLM Engine)                   │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐  │
│  │   多模态    │  │   提示工程   │  │   知识注入       │  │
│  │ 理解 (GPT-4V│  │  (Few-shot   │  │ (RAG检索业务    │  │
│  │ /Claude/Qwen│  │  CoT)        │  │  术语库)        │  │
│  │  -VL)       │  │              │  │                 │  │
│  └─────────────┘  └─────────────┘  └─────────────────┘  │
│                        │                               │
│                        ▼                               │
│  ┌─────────────────────────────────────────────────────┐ │
│  │  测试实体识别：页面元素、业务规则、状态流转、边界值   │ │
│  │  关系抽取：点击关系、依赖关系、前置条件、后置结果    │ │
│  └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│                   生成层 (Case Builder)                 │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐  │
│  │  用例模板    │  │  组合策略    │  │   格式导出       │  │
│  │  引擎        │  │ (Pairwise/   │  │ (Excel/XMind/   │  │
│  │              │  │  正交/全排列) │  │  TestRail API) │  │
│  └─────────────┘  └─────────────┘  └─────────────────┘  │
│                        │                               │
│                        ▼                               │
│  ┌─────────────────────────────────────────────────────┐ │
│  │  标准测试用例：ID、标题、前置条件、步骤、预期结果、    │ │
│  │  优先级、类型（功能/异常/边界）、关联需求            │ │
│  └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘

但从交互角度来说，可细分为五层: 输入层 → 预处理层 → OCR识别层 → LLM推理层 → 输出层

1. 输入层：接收原始设计文件

支持多种输入格式，覆盖日常工作中常见的设计文件类型，无需转换格式，降低使用门槛：

2. 预处理层：优化识别效果

原始设计文件可能存在模糊、倾斜、水印、多页面等问题，影响OCR识别准确率，预处理层主要做3件事：

3. OCR识别层：提取页面核心元素

这一层是“读懂设计稿”的核心，采用成熟的OCR模型（如PaddleOCR、Tesseract，可根据需求选择），重点提取3类信息，为LLM生成用例提供基础：

补充：OCR识别后，会生成一份“元素清单”，包含所有提取的信息，便于后续LLM调用，同时支持人工手动修正识别错误，提升准确率。

4. LLM推理层：生成标准化测试用例

这一层是“生成用例”的核心，也是方案的灵魂。我们选用适配中文场景、推理速度快的LLM模型（如Claude、通义千问、讯飞星火，可根据团队成本、隐私需求选择），核心工作流程如下：

5. 输出层：输出可落地的测试用例

支持多种输出格式，适配不同团队的使用习惯，同时支持人工优化：

四、关键环节设计

1、OCR层：通用OCR vs 专用模型，怎么选？

OCR识别准确率直接影响LLM生成用例的质量，若识别错误（如把“验证码输入框”识别成“密码输入框”），会导致用例生成偏差。

建议采用组合策略：

内容类型	推荐方案	理由
纯文字段落	PaddleOCR / EasyOCR	开源、可私有化部署、中文效果好
复杂表格	TableMaster / Structurize	能识别单元格合并、行列关系
流程图/架构图	Azure Document Intelligence	对线条、箭头、框图识别准确
手写草图	暂不处理，提示用户转电子稿	识别率低，人工兜底

另外，还可以通过3个优化手段，将识别准确率提升至95%以上：

2、LLM层：多模态理解还是OCR+文本LLM？

这是架构设计的核心抉择。我们对比了两种路线：

路线A：端到端多模态（GPT-4V/Claude 3/Qwen-VL）

路线B：OCR提取结构化文本 + 文本LLM（GPT-4/Claude 3.5/Qwen-Max）

建议的混合策略：

if 内容以文字/表格为主:
    使用路线B（OCR+文本LLM），成本低且准确
elif 内容包含复杂交互/视觉状态（如原型图）:
    使用路线A（多模态），保留视觉上下文
else:
    双路并行，投票机制决定最终输出

3、认知层：如何让LLM"像测试工程师一样思考"？

LLM生成用例的质量，完全依赖Prompt的设计。我们设计的Prompt包含3个核心部分，确保用例覆盖全面、格式标准：

• • OCR负责“读懂”设计稿/原型图中的视觉元素（按钮、输入框、弹窗等），
  • LLM负责“理解”产品逻辑、补齐测试场景、生成标准化用例。两者协同，实现“输入设计稿，输出可评审用例”的闭环。
  • 输入：任意格式的需求载体（PDF、图片、Word混排）
  • 处理：结构化提取业务规则、页面元素、流程节点
  • 输出：符合团队规范的测试用例（Excel/XMind/TestRail格式）
  • 原型图：Axure、Figma导出的图片（PNG/JPG）、PDF文件；
  • UI设计稿：PS、Sketch导出的图片、切图文件；
  • 需求文档：包含页面截图的Word、PDF需求稿。
  • 图像优化：去水印、去噪点、调整亮度对比度，确保元素清晰；
  • 倾斜校正：自动校正倾斜的设计图，避免文字、元素识别偏差；
  • 分页拆分：对多页面PDF、长图进行拆分，逐页识别，避免遗漏页面元素。
  • 元素信息：识别页面中的输入框、按钮、下拉框、弹窗、文本标签等，标注元素名称（如“手机号输入框”“登录按钮”）；
  • 元素属性：提取输入框的长度限制、默认提示文本，按钮的状态（可点击/不可点击），下拉框的选项等；
  • 页面结构：识别页面的模块划分（如“登录模块”“注册模块”）、元素的位置关系，梳理页面交互逻辑。
  1. Prompt工程：将OCR提取的“元素清单”，结合测试用例生成规则（如覆盖正常/异常/边界场景、统一输出格式），组装成Prompt，传递给LLM；
  2. 逻辑推理：LLM结合Prompt，理解页面交互逻辑，自动补齐各类测试场景，比如输入框的格式校验（手机号、邮箱）、按钮的重复点击、验证码的过期校验等；
  3. 格式标准化：按照“模块 | 用例标题 | 前置条件 | 操作步骤 | 预期结果”的格式，生成标准化用例，确保可直接用于评审、执行。
  • 文档格式：Word、Excel、PDF，可直接用于评审；
  • 测试工具格式：导出为JIRA、TestRail等测试管理工具可导入的格式，直接落地执行；
  • 编辑界面：提供简单的在线编辑界面，可手动修改、补充用例，优化场景覆盖。
  • 模型选型：优先选用中文识别效果好的模型，比如PaddleOCR（开源免费，中文识别准确率高），针对设计稿场景，可微调模型参数，提升元素识别精度；
  • 人工校正：OCR识别后，提供简单的校正界面，测试工程师可快速修正识别错误的元素名称、属性，耗时不超过1-2分钟；
  • 关键词匹配：预设常用测试元素关键词（如“验证码”“登录”“注册”“提交”），当OCR识别到相关关键词时，自动关联对应元素属性，减少识别偏差。
  • 优点：直接输入图片，省去OCR环节，理解更整体
  • 缺点：成本高（GPT-4V约$0.00765/图），对表格细节容易
  • 优点：成本低（文本模型便宜一个数量级），表格数据准确
  • 缺点：丢失视觉信息（如红色警告框、禁用状态样式）

  • 角色定义：明确LLM的身份——“资深测试工程师，擅长生成可评审、可落地的功能测试用例，熟悉各类场景的测试要点”；

  • 需求约束：明确用例覆盖范围（正常场景、异常场景、边界场景、格式校验、验证码、第三方登录、重复提交等），以及输出格式；