超越流程图：架构图与原型图的 AI 解析与非功能测试用例生成

摘要 测试用例不仅关乎“功能是否正确”，更关乎“系统是否健壮、体验是否流畅”。而这些非功能需求（NFR） 的关键线索，往往隐藏在系统架构图、UI 原型图甚至一张简单的截图中。本文将揭示如何利用 AI 视觉理解 + 领域知识 Prompt，从这些非结构化图表中自动提取性能压测模型、安全边界、兼容性清单等高价值测试资产，并给出 JMeter 脚本、A11Y 检查点等可落地的输出方案，真正实现“全维度”智能测试。

引言：被忽视的“非功能”测试金矿

在前两篇中，我们成功解决了功能性测试用例的自动化生成问题——从图文需求到流程路径，再到可执行脚本。

然而，一个高质量的软件系统，远不止“功能正确”这么简单。它还必须：

• 快：API 响应 < 500ms，页面加载 < 2s
• 稳：在 1000 并发下不崩溃
• 安全：用户 A 不能看到用户 B 的数据
• 兼容：在 iPhone SE 和 Galaxy S24 上体验一致
• 无障碍（A11Y）：视障用户也能操作

这些非功能需求（Non-Functional Requirements, NFR），恰恰是线上事故和用户差评的主要来源。而它们的设计依据，常常就藏在两张图里：

1. 系统架构图 → 性能、安全、可靠性
2. UI 原型图/截图 → 兼容性、无障碍、UI 一致性

问题是：AI 能否像资深测试架构师一样，从一张架构图中看出这里需要做熔断测试，或从一张 UI 图中发现这个按钮对比度不达标？

答案是：能，但需要我们教会它“看什么”和“怎么想”。

一、从系统架构图生成性能压测模型

场景：一份微服务架构图，展示了 User Service → Order Service → Payment Gateway 的调用链。

AI 的任务：

1. 识别所有对外 API 入口（如 /api/v1/orders）
2. 识别关键依赖链路（如创建订单会触发支付）
3. 为每个入口和链路，生成JMeter 压测场景

技术方案：

Step 1: 架构图 OCR + 组件识别

• 使用 PaddleOCR 提取所有服务名、API 路径、数据库图标。
• （进阶）用 YOLOv8 训练一个“微服务组件检测模型”，自动框出 Service、DB、API Gateway 等图标。

Step 2: 多模态 LLM Prompt 设计

text编辑

你是一名资深 SRE 工程师，请分析此系统架构图：

1. 列出所有**对外暴露的 RESTful API 入口**（格式: POST /api/v1/create_order）。
2. 识别**核心业务链路**（例如：下单 → 支付 → 发货）。
3. 为每个 API 入口和核心链路，生成 JMeter 压测建议：
   - 目标 TPS
   - 并发用户数
   - Ramp-up 时间
   - 持续时间
   - 关键监控指标（如 P99 延迟、错误率）

输出严格遵循以下 JSON Schema：
{
  "api_endpoints": [
    {"method": "POST", "path": "/api/v1/orders", "tps_target": 100}
  ],
  "business_flows": [
    {
      "name": "Create Order Flow",
      "steps": ["POST /orders", "POST /payment"],
      "concurrent_users": 500
    }
  ]
}

Step 3: 自动生成 JMeter 脚本草稿

利用上一步的 JSON，用 Python 模板引擎（如 Jinja2）生成 .jmx 文件：

xml编辑

<!-- 自动生成的 JMeter Test Plan 片段 -->
<ThreadGroup>
  <stringProp name="ThreadGroup.num_threads">500</stringProp>
  <stringProp name="ThreadGroup.ramp_time">60</stringProp>
  <hashTree>
    <HTTPSamplerProxy>
      <stringProp name="HTTPSampler.path">/api/v1/orders</stringProp>
      <stringProp name="HTTPSampler.method">POST</stringProp>
    </HTTPSamplerProxy>
  </hashTree>
</ThreadGroup>

✅ 落地价值： 将性能测试规划时间从 数天缩短至分钟级，且确保压测场景 100% 覆盖架构设计。

二、从 UI 原型图生成兼容性 & 无障碍（A11Y）

场景：一张 Figma 登录页原型图，包含输入框、按钮、Logo。

AI 的任务：

1. 识别所有交互元素（按钮、输入框）
2. 分析其位置、尺寸、颜色
3. 生成多端兼容性检查点 和 WCAG 2.1 A11Y 合规报告

技术方案：

Step 1: UI 元素检测 —— 不只是 OCR

OCR 只能识别文字，但我们需要知道“这是一个按钮，宽 200px，位于屏幕底部”。

解决方案：

• 方法 A（推荐） 如果有 Figma/Sketch 设计源文件，直接通过 Figma API 获取元素属性（位置、尺寸、颜色值）。
• 方法 B（通用） 对 PNG 截图使用 OpenCV 模板匹配 或 预训练的 UI 检测模型（如 ScreenAI）。

python编辑

# 伪代码：使用 OpenCV 检测按钮区域
button_template = cv2.imread("button_template.png")
result = cv2.matchTemplate(screen_img, button_template, cv2.TM_CCOEFF_NORMED)
locations = np.where(result >= 0.8)  # 置信度 > 0.8

Step 2: 多模态 LLM 分析 Prompt

text编辑

你是一名 UI/UX 测试专家，请分析此登录页原型图：

1. 列出所有交互元素及其属性：
   - 元素类型（按钮/输入框）
   - 在屏幕中的相对位置（上/中/下，左/中/右）
   - 尺寸（宽/高，单位 px）
   - 文字颜色和背景色（HEX 值）

2. 针对每个元素，生成：
   a) **兼容性检查点**：在 iPhone SE (375x667), Pixel 5 (393x851), iPad (768x1024) 上是否布局错乱？
   b) **A11Y 检查点**：文字与背景的对比度是否 ≥ 4.5:1 (WCAG AA 标准)？

输出 JSON 格式：
{
  "elements": [
    {
      "type": "button",
      "position": "bottom-center",
      "size": {"width": 200, "height": 44},
      "color": {"text": "#FFFFFF", "bg": "#007AFF"},
      "compatibility_checks": ["iPhone SE: 按钮不应被键盘遮挡"],
      "a11y_checks": ["对比度 4.3:1 < 4.5，不合规"]
    }
  ]
}

Step 3: 输出可执行的检查清单

将 JSON 转换为团队可用的测试清单：

表格

✅ 落地价值：

• 提前拦截 80%+ 的 UI 兼容性问题，避免上线后紧急 hotfix。
• 自动化 A11Y 审计，满足金融、政务等强监管行业的合规要求。

三、构建统一的“AI 测试洞察中心”

上述能力不应是孤岛。我们可以将其整合为一个内部平台：

平台架构：

上传需求文档 
图文解析引擎--> UI 原型解析引擎
Figma链接 --> 架构图PNG --> 系统架构解析引擎 --> 统一测试知识库 --> 自动生成
功能用例 --> 性能模型 --> 兼容性清单

用户工作流：

1. 测试工程师上传一份包含流程图、架构图、原型图的 PRD。
2. 平台自动分发给不同解析引擎。
3. 10 分钟后，收到一份 **“全维度测试包”**：
   • functional_tests.py
   • performance_plan.jmx
   • compatibility_checklist.xlsx
   • a11y_report.html

四、为什么这代表了测试的未来？

1. 测试左移的终极形态

非功能测试不再等到开发完成才开始，而是在需求评审阶段就已规划完毕。

2. 释放 QA 专家的核心价值

工程师无需再花费数小时研究 WCAG 标准或 JMeter 配置，而是聚焦于：

• 审核 AI 生成的测试资产
• 设计更复杂的混沌工程场景
• 优化用户体验

3. 构建组织级测试知识库

每一次对图表的解析，都在沉淀团队的领域知识。久而久之，AI 会越来越懂你的业务、你的系统、你的质量标准。

结语：从“功能验证者”到“质量架构师”

当 AI 能够从一张架构图中预见性能瓶颈，从一张 UI 图中发现无障碍缺陷，测试工程师的角色便完成了又一次跃迁。

我们不再是那个在功能完成后才介入的“验证者”，而是**在需求诞生之初就参与塑造质量的“架构师”**。

这三篇文章，从“看见图文”到“拆解路径”，再到“洞察全维质量”，共同描绘了一幅 AI Native 测试 的蓝图。它并非遥不可及，而是由一个个可落地的工程模块组成。

现在，轮到你动手了。选择一个痛点，从今天开始，构建属于你和你团队的“AI 测试之眼”。