摘要 (Executive Summary)

在我们的 UI 自动化测试平台中，我们引入了一套革命性的AI视觉验证智能体（AI Visual Checker）。该机制通过**“执行-验证”分离的双智能体模型**，彻底改变了传统UI测试断言的脆弱性和局限性。它不再依赖于不稳定的元素定位符或简单的存在性检查，而是通过视觉分析，模拟人类测试者的判断力，直接验证操作执行后的业务结果是否符合预期，从而构建出更健壮、更智能、更能发现深层问题的自动化测试。

一、传统UI测试的痛点：为何需要Checker？

传统的UI自动化测试严重依赖于代码层面的断言，例如：

• assertElementExists("#user-welcome-message")

• assertElementTextEquals("#username", "张三")

这种方式存在三大根本性缺陷：

1. 脆弱性 (Brittleness): 任何前端代码的微小重构（如修改一个ID或类名）都会导致测试失败，即使功能本身完全正常。

2. 验证深度不足 (Lack of Depth): 它只能验证“某个元素是否存在”或“文本是否匹配”，却无法回答更关键的业务问题，比如：“登录成功后，页面整体布局是否正确？”、“提交表单后，列表中的数据状态是否真的更新了？”、“弹出的成功提示框样式是否符合UI规范？”

3. 高维护成本 (High Maintenance): 测试人员需要花费大量时间编写和维护这些精确但脆弱的定位符和断言。

为了解决这些问题，我们设计了 AI Checker，其核心思想是——让AI像真人一样，“看”懂结果。

二、核心架构：执行者-验证者 (Executor-Checker) 模型

我们系统的核心是双智能体分离架构：

1. 执行者智能体 (Executor Agent):

   • 角色: 专注的“操作手”。

   • 任务: 它的唯一任务是理解人类下达的自然语言指令（如“点击登录按钮”），分析当前截图，并生成在屏幕上执行该动作所需的原子操作（如 click、type）。它不关心操作的后果，只负责精准执行。

2. 验证者智能体 (Checker Agent):

   • 角色: 严谨的“质检员”。

   • 任务: 它在“执行者”完成一系列操作后介入。接收执行后的最终截图、原始的步骤目标和预期结果描述，然后做出一个全局性的、基于业务的判断。

这种分离设计带来了巨大的好处：职责单一。执行者只管“做”，验证者只管“看”，使得整个系统逻辑清晰，扩展性强。

三、Checker 的工作流详解 (The Verification Workflow)

当一个测试步骤被触发时，Checker 的工作流如下：

1. 动作执行 (Action Execution): 执行者 Agent 首先完成它的任务，比如在输入框输入文字，然后点击一个按钮。

2. 捕获“结果快照” (Capture 'After' Snapshot): 在执行者完成动作后，系统会等待UI渲染稳定，然后立即截取一张高清的屏幕快照。这张快照就是本次操作的“证据”。

3. 构建“验证上下文” (Construct Verification Context): 系统将三份关键信息打包成一个请求，发送给 Checker Agent：

   • 视觉证据 (Visual Proof): 刚刚截取的结果快照（Base64编码）。

   • 操作意图 (The Goal): 原始的测试步骤描述，告诉Checker“我们刚才想做什么”，例如：“点击‘保存’按钮”。

   • 成功标准 (The Criteria): 对应的预期结果描述，告诉Checker“我们期望看到什么”，例如：“系统应提示‘保存成功’，并且列表页中出现一条新记录”。

4. AI的视觉分析与判断 (AI's Analysis & Verdict): 这是最核心的一步。Checker Agent（背后是配置了特定指令的大语言模型）接收到上述上下文后，会：

   • 图像理解: 分析快照中的所有UI元素、文本、颜色和布局。

   • 逻辑推理: 将图像内容与“操作意图”和“成功标准”进行比对和逻辑推理。它会回答这样的问题：“图片中是否真的有一个‘保存成功’的绿色提示框？”、“图片下方的列表中，真的比操作前多了一条数据吗？”

   • 输出原子化裁决 (Atomic Verdict): 基于推理，Checker 必须从几个预定义的、极其简单的结果中选择一个进行输出：

     • True: 视觉证据完全符合预期结果。

     • False: 视觉证据不符合预期结果。

     • execution error: 从视觉上看，上一步的操作似乎根本没被执行（例如，点击按钮后页面毫无变化）。

     • UI_ERROR: 截图模糊或存在无法识别的UI元素。

5. 系统的响应 (System Response): 自动化框架接收到Checker的裁决后，执行相应操作：

   • 收到 True: 测试步骤标记为成功，继续执行下一步。

   • 收到 False: 测试步骤标记为失败，终止测试并报告错误。

   • 收到 execution error: 触发**“自愈”机制**，例如执行浏览器后退 (go_back)，然后重试该步骤。这是构建韧性测试的关键。

四、Checker 的“灵魂”：高度结构化的Prompt

Checker能够做出精准判断的秘密，在于我们为其设计的高度结构化和强制性的Prompt。这个Prompt就像是AI的“法律”或“操作手册”，它严格规定了AI的角色、任务、分析流程和输出格式，将其创造力约束在测试验证这一特定领域，确保了结果的稳定性和可靠性。

五、动画的呈现：让验证过程“可视化”

为了让用户直观地感受到 Checker 的工作过程，我们在脚本回放页面设计了一个验证动画：

1. 执行后: 当一个步骤的截图显示后，一个半透明的覆盖层会出现在截图上。

2. 扫描动画: 一条明亮的“扫描线”会从上到下扫过整个截图，生动地模拟了AI正在“审视”和“分析”这张图片的过程。

3. 结果呈现: AI返回裁决后，扫描线消失，一个巨大、清晰的成功（✅）或失败（❌）图标会出现在屏幕中央，并伴有短暂的放大动画，给予用户即时、明确的反馈。

这个动画不仅提升了界面的美观度，更重要的是建立了用户对后台AI工作过程的信任感。

结论

我们的AI Checker机制，通过模拟人类的视觉认知和逻辑判断，成功地将UI自动化测试从脆弱的“代码检查”提升到了稳健的“业务验证”层面。它不仅大幅提高了测试的可靠性和深度，还通过“自愈”机制增强了测试的韧性，最终赋能团队以更高的效率和信心交付高质量的软件产品。