业务链路驱动的 Web UI Agent 测试Web UI 测试的重点可以从“按脚本点完页面”转向“在真实页面状态下完成并验证业务目标”。为此Agent 需要把需求拆成可验收的链路在每一步重新观察页面、限制操作边界并用证据说明结论。动作成功、页面变化、步骤达成和任务完成是四个不同的判断层级。从脚本自动化转向业务链路传统 UI 自动化常沿着测试范围、测试点、环境与数据、脚本编写、调试、执行、缺陷回归、页面变更后的维护逐步推进。主要成本集中在前期建脚本、动态页面下的误报以及 UI 变化后的反复维护。业务链路驱动把更稳定的业务目标和验收条件放在中心由 Agent 根据页面观察推进执行人仍负责质量判断与高风险决策。维度传统脚本自动化业务链路驱动驱动对象页面控件和预写步骤业务目标与链路节点执行方式固定路径随页面与业务状态调整成功判定操作结束、脚本无报错关键状态和业务结果满足验收条件异常定位读日志、人工排查区分失败环节、缺陷、访问阻断和环境异常变更影响页面结构变化牵动脚本尽量保留业务意图重新定位页面目标这一路线能否落地取决于四件事把自然语言需求变成可执行链路、在动态页面找准元素、让流程持续感知并纠偏以及用多维证据验证结果。业务语义相对稳定并不意味着页面变更完全免维护候选采集、规则和验收条件仍需持续更新。五层架构与执行闭环系统按职责分为任务接入、任务调度、Agent 编排、浏览器执行、数据与结果五层。接入层解析参数、注入上下文并约定调用边界调度层管理队列、资源和并发编排层负责意图、目标、规划、验证与恢复浏览器层感知页面、收集候选并执行交互结果层记录轨迹、沉淀知识、归因并产出报告。一次任务遵循“任务输入 → 规划 → 执行 → 验证 → 完成”的生命周期。执行中的小循环更重要从 DOM、截图、可访问性树与控制台日志观察当前状态制定下一步计划执行浏览器动作再检查是否产生预期变化未通过时反思并更新计划失败或越界时终止并上报。日志、关键截图或视频、耗时与成功率等可观测信息贯穿全链路。运行时护栏先于自主恢复Agent 可以提议操作但高风险写操作必须经过确认。只读白名单可直接执行提交、删除、支付、批量操作等要按结构化风险规则拦截或待确认。动作只能在当前页面采集到的候选中选择页面变化后强制重采单批步骤、总步数、上下文、资源、并发和超时都设上限。敏感数据应脱敏令牌和密码不持久化。异常先分诊再选有界恢复、同策略重试或重新规划恢复次数和失败预算耗尽就熔断。登录、验证码、403、网络异常等访问状态应单独识别不能一概算成产品缺陷。每一步保留前后状态、截图、页面事实、计划版本和恢复记录使高风险拦截与最终结论可离线复核也允许依据证据修正结论。难点一把需求变成可验收链路自然语言需求常省略入口、导航路径、操作对象、前置条件和验收标准后续页面状态又只能在进入页面后观察。同一句话可能对应多条业务路径因此一次性制定长计划容易建立在错误假设上。点击完成也不能替代业务验收。解决方法是先拆成独立的链路单元补齐前置条件与判定规则再结合需求文档、业务知识、页面或接口信息、历史数据形成结构化短计划。每个短计划至少写明原子动作、语义目标、直接预期、风险等级和异常断言。执行时采用“动作前观察 → 执行 → 动作后观察 → 步骤裁决”在关键状态变化、短计划结束或步骤失败时重新观察并规划下一段无需每点一次就重做整套计划。最终按整条链路验收全部链路通过才完成可恢复缺口带新证据进入下一轮不可恢复或证据不足则给出失败或不确定的结论。计划结构校验、页面变化后重采候选、有限恢复和全程留痕使这一过程可控、可复核。难点二找对元素并确认它仍有效元素定位有三种常见失败目标不唯一例如普通页面和“新增车辆”弹窗都有“车牌号”输入框目标没进入候选集例如真正的“查看订单”入口未被枚举目标已经变化例如识别后页面重新渲染原引用在点击时失效。仅凭相似文字或屏幕坐标都无法保证操作到正确的业务对象。先将自然语言目标转成目标文字、控件类型、区域、预期结果等结构化条件再用 DOM 与 ARIA 收集候选按区域、类型、文字和上下文逐步缩小范围。候选唯一且置信度高时仍做本地复核存在歧义时可给候选编号提供 SOM带编号标记的截图让视觉模型只在现有编号中选择或回答无匹配不能自由猜坐标。执行后重新观察并验证变化不通过就回到候选采集。难点三及时发现流程跑偏页面加载、跳转、弹窗和滚动会不断改变执行环境。早期的小偏差若没有被发现可能从定位错位、筛选条件不符逐渐放大为整条链路失败。必须分清动作执行成功 ≠ 页面效果生效 ≠ 步骤目标达成 ≠ 任务完成。每一步先核对 URL、标题、可见文本、表单值、弹窗和可操作元素执行后再看加载、跳转、列表、表单等变化并确认动作作用于预期对象。步骤裁决可为通过、未通过、证据不足关键节点还要回查原始需求是否被完整覆盖。失败处理有顺序高风险或不可自主处理的场景先拦截并保留现场有明确低风险恢复条件时做有限 Recovery重新验收原步骤确定性恢复无效后Reflector 才基于最新状态重规划重复无效、计划循环或预算耗尽则熔断输出可解释结论。这样将恢复约束在可观察、可追溯的范围内。难点四让测试结果有证据支撑操作日志、点击记录、输入、截图和页面切换能说明“做了什么”却不能单独证明业务达成。单帧截图可能遗漏后续变化“保存”与“保存草稿”容易混淆局部步骤成功可能掩盖关键目标未完成页面错误也可能被误归因。因此“流程跑完”不能作为通过条件。可信结果分三层构建。执行证据层保存步骤目标、动作对象、直接预期、Before/After、截图、DOM、表单真实值和恢复过程分层裁决层分别核对动作效果、步骤验收和任务目标并按业务目标、规则、事实一致性验证报告审计层给出总体结论、需求覆盖、步骤时间线、证据引用、缺陷与异常、访问阻断和下一步建议。从原始需求列出验收点再用步骤级前后对照和确定性页面事实做任务级 Goal Verify最后反向核对证据引用。URL、标题、页面文本和表单真实值是可核验事实视觉推测只能辅助。最终结论应允许通过、失败、不确定三态漏审、证据不可读、事实冲突或关键确认异常时降级为“不确定”而非强行判通过。报告中的“不确定”还应写明置信度、可能的替代解释、依赖与假设以及下一步验证建议。规模化运行与持续改进成熟度取决于“短计划、短闭环、预算止损”形成的工程闭环而不只是模型能力。衡量效果时单步定位成功率只能解释局部能力更关键的是以任务为单位的链路通过率同时关注覆盖、误失败、执行步数、成本和运行稳定性。后续演进有三个方向统一跨团队和跨业务的需求接入、运行配置、证据与报告标准并按任务优先级和风险弹性调度把需求、页面事实、计划、动作、前后证据和裁决结论归档为可反馈重放的评测样本比较新旧策略是否改善覆盖、误通过、误失败和成本结合需求变更、历史缺陷与执行证据识别高风险功能及测试覆盖缺口让输出从单次结论升级为质量决策依据。实践中最重要的检查顺序是先明确业务目标与验收点再限制动作和恢复预算最后用可复核证据判断整条链路。这样即使出现阻断或证据不足也能给出可定位、可解释的结果。