自动化测试中“看图识对象”的坑，是自动化测试崩溃的起点

自动化测试中“看图识对象”的坑是自动化测试崩溃的起点——从“图像猜测”到“模型驱动识别”的工程重构在自动化测试领域图形识别Image Recognition一直被视为“万能方案”。但在真实项目中尤其是金融行业很多案例验证了一件事图形识别不是能力的上限而是工程体系的下限。一、为什么很多团队会走向图形识别在 UI 自动化中传统定位方式XPath / Name / Id在以下场景确实会失效非标准控件国产表格、定制组件图形化界面K线图、地图、画板跨进程 / 信创环境控件信息缺失于是很多团队会自然走向“既然拿不到结构那就直接看图。” 这正是问题的起点你放弃了结构放弃了测试要求的准确而选择了猜测真行二、图形识别的“三大工程死穴”1️⃣ 环境敏感系统一变全部失效图形识别依赖像素或特征匹配一旦分辨率变化字体变化主题变化浅色 / 深色 匹配度瞬间崩塌真实案例某银行系统仅仅因为按钮增加 1px 阴影 300 用例全部失败 排查耗时2人 × 1周 本质问题图像是表现层不是稳定层。2️⃣ 无法理解结构只能看到“块”看不到“语义”典型问题DataGrid你想定位第3行第5列状态“待复核”的那一格图形识别只能找“类似区域”或 OCR 出一段模糊文本但无法回答这一列是什么这一行属于哪个业务状态数值是否正确 本质问题图形识别没有业务语义。3️⃣ 金融场景下不可用在金融系统中场景图形识别问题K线图定位像素偏移导致交易日错误金额识别字体抗锯齿导致误判行情刷新每帧变化导致匹配失败信创环境渲染差异导致不可复用 实际结果某券商平台图形识别误报率超过 40%最终全部你懂得三、我们的核心思路回到“结构与语义”我们MARS 体系解决这个问题的核心原则是优先结构化识别其次图像兜底最终统一模型治理四、MARS 对策一对象模型Object Model优先核心原则只要能拿到结构就绝不看图而拿结构代表了平台的系统能力。MARS 的多引擎对象识别能力场景技术WindowsUIA / MSAA / MARS引擎WebCDPJavaJAB / MARS java 引擎信创Accessibility 自研适配层 MARS 引擎 能获取控件类型名称状态值层级结构DataGrid 场景关键能力MARS 不是“找图片”而是表格 → 行 → 单元格 → 属性支持按列名定位按数据值筛选按业务状态过滤 这意味着测试不再依赖坐标而是依赖业务语义五、MARS 对策二图形识别降级为“能力兜底”MARS 并没有完全放弃图形识别而是严格限制其使用边界使用策略✔ 动态阈值 多尺度匹配按场景调整精度适应 DPI 变化✔ OCR 二次校验图像匹配 文本验证双重确认✔ 相对定位布局驱动不用绝对坐标基于窗口/区域偏移 核心原则图像只用于定位不用于判断六、MARS 对策三混合模型Model AI Vision针对极端场景如 3270、老系统1️⃣ AI 视觉识别非像素匹配YOLO 目标检测语义分割基于形状和布局 关键区别传统图像MARS AI识别像素匹配语义识别易失效可泛化2️⃣ 布局模型缓存首次运行→ 建立界面结构关系后续运行→ 动态推导位置 本质从“识别图片”升级为“理解界面”七、金融级加固MARS关键能力✔ 数据验证分离金额 / 利率 → 接口或数据库验证UI只验证展示✔ 多图形稳定判断多图成功才通过✔ 信创适配层麒麟 核心目标确保测试结果可用于发布决策八、效果指标图形识别MARS体系维护成本高↓ 80%跨环境稳定性63%失败7%表格误报率41% 1%信创适配3个月2周九、总结图形识别的正确位置图形识别不是主力能力而是“最后防线”。MARS 原则总结1️⃣ 优先结构化对象识别2️⃣ 次选图像 OCR 校验3️⃣ 兜底AI视觉识别4️⃣ 禁止用图像判断业务数据一句话结论建议加粗自动化测试的本质不是“看见界面”而是“理解系统”。