关注 霍格沃兹测试学院公众号，回复「资料」, 领取人工智能测试开发技术合集

当多模态大模型开始具备“看图理解界面”的能力之后，很多人就在想：

如果模型已经能理解页面结构，它能否参与测试用例的生成？

过去，测试用例通常来自：

• PRD 文档

• 原型图

• 页面实现

• 流程图

• 接口文档

而现在，输入可能变成：

页面截图 + 业务上下文 + 测试目标

输出则是：

结构化 JSON 测试用例

问题不在于“能不能生成”。 真正值得讨论的是：

• 这套系统如何设计？

• 多模态输入如何进入工程链路？

• 代码如何分层？

• 它在哪些场景可用，在哪些场景不可用？

---

目录

1. 为什么视觉模型可以进入测试场景

2. 系统整体架构设计

3. 图片到测试用例的工程链路

4. 后端代码分层与接口设计

5. 多模态能力的边界

6. 单模型方案为何不稳定

7. 视觉驱动测试的工程价值

---

一、为什么视觉模型可以进入测试场景

UI 测试本质上依赖“页面理解”。

一个登录页，测试工程师会自然识别：

• 用户名输入框

• 密码输入框

• 登录按钮

• 第三方登录入口

多模态模型已经具备：

• OCR 文本识别

• 组件识别

• 页面结构推断

• 基础交互逻辑理解

因此从技术能力上，它确实可以参与 UI 测试设计。

但能力 ≠ 工程可用。

---

二、系统整体架构设计

合理架构不应该是：

图片 → 大模型 → 文本用例

而应该是分层结构：

核心思想：

• 视觉理解与用例生成分离

• 输出必须结构化

• 与现有系统通过 API 集成

---

三、图片到测试用例的工程链路

生成用例至少需要三类输入：

1. 页面截图

2. 业务说明（例如：这是会员登录页）

3. 测试目标（例如：覆盖登录路径）

如果只上传截图而无上下文，模型只能推断“表单结构”，无法推断业务规则。

---

多模态解析流程

模型首先会：

• 识别页面文本

• 识别按钮与输入区域

• 推断页面结构

• 分析潜在业务流程

例如登录页面，可能推断：

• 正常登录流程

• 空输入校验

• 错误密码提示

• 第三方登录跳转

然后进入用例生成阶段。

---

输出必须结构化

如果输出是自然语言描述，无法自动入库。

推荐强制 JSON：

{
  "title": "",
  "precondition": "",
  "steps": [],
  "expected_result": ""
}

这样可以：

• 存入数据库

• 导出为 Excel

• 对接禅道或其他管理系统

结构化输出，是工程可用的前提。

---

四、后端代码分层设计

典型前后端分离结构：

project/
 ├── backend/
 │   ├── routes/
 │   ├── services/
 │   ├── models/
 │   ├── utils/
 │   └── ai_service.py
 └── frontend/

---

核心接口设计

后端应提供：

1. 生成测试用例接口

2. 导出 Excel 接口

3. 文件下载接口

时序逻辑如下：

---

AI Service 的职责

AI service 不只是调用模型。

它应负责：

• Prompt 构造

• 输出格式约束

• 错误重试机制

• 日志记录

• 流式响应控制

否则系统难以调试。

---

Excel 导出模块

建议独立封装：

避免把导出逻辑写进模型调用层。

---

五、多模态模型的能力边界

必须清醒认识：

视觉模型适合：

• 标准 UI 表单

• 简单业务流

• 原型阶段页面

• 基础功能验证

不适合：

• 复杂权限体系

• 高并发场景

• 数据一致性校验

• 风险控制逻辑

它能生成 60% 的基础用例。 剩余 40% 仍需测试工程师设计。

---

六、为什么单模型方案不稳定

很多 Demo 直接：

截图 → 一个 Prompt → 输出全部用例

这在小规模测试中可行，但生产中会不稳定。

更合理的结构：

多智能体分工可以：

• 提高稳定性

• 提高可控性

• 降低 hallucination 风险

---

七、视觉驱动测试的真正价值

它的意义不在于“自动生成所有用例”。

而在于：

• 快速构建基础用例池

• 降低重复劳动

• 辅助需求评审

• 加速原型阶段测试

当 60% 的标准用例可自动生成时，

测试工程师的角色开始转向：

• 测试策略设计

• 边界条件建模

• 自动化框架搭建

• AI 输出质量控制

---

写在最后

视觉模型进入测试领域，不是概念展示，而是系统工程问题。

真正决定系统能否落地的因素包括：

• 是否分层设计

• 是否结构化输出

• 是否具备日志与可追溯机制

• 是否可与现有系统集成

模型能力只是起点。 架构设计才是关键。

当多模态能力进入测试链路后， “写用例”本身不再是核心竞争力， “设计 AI 流程”才是。

推荐学习

开源AI助理 OpenClaw（龙虾）公开课，手把手带你打造24小时不休的AI打工人。

扫码进群，报名学习。

关于我们

霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。