“今早一来群里自动化任务的失败告警刷了二十多条点进去一看又是登录按钮的id变了。上一次修好是在两周前这一次打包号一换整个页面结构跟着动了一遍。”这种场景对于维护 Web UI 自动化脚本的人来说绝对不陌生。动态定位器大概是脚本维护里最让人头大的问题之一而“AI驱动的自动化脚本维护”这个方向正是想把这个长期耗时、机械重复、又不得不做的事变成一条半自动化的流水线。这篇文章不会讲太玄的东西而是围绕“动态定位器修复”这个具体问题展开它为什么会发生、AI 在中间到底扮演什么角色、实际落地时怎么搭一套能用的修复机制。适合正在维护 Selenium、Playwright 或其他浏览器自动化脚本的测试开发工程师也包括想了解“AI辅助测试”到底能干什么、又不能干什么的测试团队负责人。1. 动态定位器为什么这么难修1.1 所谓“动态”往往不是完全随机大多数人第一次遇到定位器失效第一反应是“这个网站的开发者怎么这么不靠谱id 怎么能乱变”。真正做了很久的自动化维护之后你会发现大多数“动态”背后都有自己的规律只是这些规律经常超出我们预先写死的预期。我见过比较典型的几类带时间戳或随机数的属性比如idcard-1699999999数字是按当前时间生成的。这种一眼就能看出来但你没法每次运行时都重新计算。部署生成的变更 ID系统每次发版会把元素属性重新生成一遍比如>driver.find_element(By.ID, username_input)页面改版之后变成div classlogin-form label邮箱/label input>driver.find_element(By.CSS_SELECTOR, input[data-fielduser-email])或者更稳妥一点driver.find_element(By.XPATH, //div[contains(class,login-form)]//input[contains(placeholder,邮箱)])2.2 三类典型的 AI 修复策略分享几个我实际用过并验证过的策略方向不一定每次都用大模型但整体思路可以复用策略一结构重写如果失败信息里直接带了旧定位器和失败时的 HTML 片段AI 可以先解析旧定位器依赖了哪些属性再到新 HTML 里找继承语义的候选节点。比如旧定位器用 id新页面里没这个 id但同样位置的节点有固定的 class 组合。这个时候生成CSS 选择器比 XPath 更合适因为可以减少对层级的依赖。策略二语义锚点匹配适合目标元素附近的文本内容变化不大、但结构属性全变的情况。模型分析出一组“附近稳定的语义描述”比如按钮文字、label 文案、相邻输入框的占位文本等再组合成新的定位条件。这种方式对改造后的页面特别有效也是纯规则化脚本很难做到的部分。策略三多候选回放验证不管多聪明的模型生成出来的定位器都存在一定的误判概率。所以我一直强调任何一个 AI 生成的定位器都不能直接改到主分支上。正确做法是让模型一次性生成多个候选放在真实环境里用浏览器自动执行一次看能不能成功操作到目标元素甚至继续完成后续一个断言动作。谁能通过运行验证谁才有资格进入提交列表。2.3 AI 的边界在哪里我对 AI 在测试领域作用的看法一直比较克制。它最适合处理的场景是“有明确失败信号、有页面快照、有清晰的验证方式”的定位器失效问题。它不适合做什么呢不适合在没有失败日志的情况下“预防性”重写所有定位器。不适合在页面本身功能已经破坏时强行修复定位器掩盖真实 bug。不适合在没有任何验证逻辑时直接信任生成的候选。话说到底AI 在这个场景里的定位是“快速生成候选人 辅助判断”而真正保证质量的一定是后面的验证闭环。没有这个闭环AI 只是高级一点的正则替换工具。3. 实操搭一套动态定位器自动修复管线3.1 整体架构失败 → 快照 → 分析 → 验证 → 回填我搭过的一个比较朴素的修复管线按下面五个环节跑采集监控测试执行结果拦截所有因元素定位失败抛出的异常。快照在异常发生点抓取页面源码、截图、当前 URL、失败定位器信息。裁剪对 HTML 快照做裁剪只保留和目标元素相关的内容例如向上找几级父节点再包含一部分兄弟节点避免把整个页面一次性丢给模型。生成调用 AI 接口输入“目标元素语义描述 裁剪后的 DOM 片段 旧定位器”要求返回多个候选定位器及置信度。验证在测试环境重新打开 URL逐个尝试候选定位器确认唯一匹配且能完成预定义的前置操作验证通过后自动生成补丁提交到待审分支。流程本身不复杂但每步都有很多细节。3.2 失败发生时怎么留存上下文这一步是整个管线的地基。很多团队说 AI 修复不准仔细一看是失败的时候根本没存东西。我建议至少从五个维度采集信息异常类型和异常消息。例如NoSuchElementException: Cannot locate an element with the xpath: //*[idbtn_12345]。当前页面 DOM。不要只存折叠后的标签要保留属性和文本。爬虫抓到的动态内容尤其重要。页面截图。方便后来人快速确认页面长什么样也可以交给视觉模型辅助定位。附近节点摘要。只存目标节点向上两层的父节点、父节点的兄弟节点、以及目标节点前后三五个同级节点这样模型不容易被无关噪声干扰。访问路径和前置操作步骤。这一步是从哪里跳转过来的用户点击了什么。比如“从商品列表页点进详情页然后点加入购物车”这个信息有助于理解目标元素的状态。拿 Playwright 举例异常捕获时的核心逻辑类似from playwright.sync_api import sync_playwright def on_error(page, ex): context { url: page.url, source: page.content(), screenshot: page.screenshot(full_pageTrue), message: str(ex), } return context注意不要用page.content()抓完直接丢给模型。一个大型页面全量 HTML 可能几百 KB而真正定位目标元素用不到 2KB。上下文裁剪做得好不好直接影响模型返回结果的质量和调用成本。3.3 AI 分析模块的关键设计这一段我直接说操作细节。如果你打算用大模型 API 来实现prompt 的结构建议固定成这样一是明确角色把你界定为“资深自动化测试工程师擅长修复动态页面元素的定位器”。二是给出快照把裁剪后的 DOM 片段贴进来。注意是 HTML 文本不只是文字内容。因为某些属性即使没有显示文本也可能是定位关键。三是标记目标元素在 HTML 片段中用!-- TARGET_START --和!-- TARGET_END --把目标元素包起来让模型知道真正要定位什么。四是输出格式要求强制返回 JSON 数组每个元素包含strategy、selector、confidence、reason。不要输出大段解释。一个简化版的 prompt 示例你是一名资深自动化测试工程师。以下是被测页面的部分 HTML 片段目标元素已被标记。旧定位器已不可用请分析目标元素在当前 DOM 中的唯一特征并给出 3 个候选定位器。 输出 JSON 数组格式如下 [ {strategy: css_selector, selector: ..., confidence: 0.9, reason: ...} ] HTML: div classorder-list div>from playwright.sync_api import sync_playwright def verify_candidates(url, candidates, actionclick): with sync_playwright() as p: browser p.chromium.launch() page browser.new_page() page.goto(url) results [] try: for cand in candidates: try: locator page.locator(cand[selector]) if locator.count() 1: locator.click(timeout3000) page.wait_for_timeout(1000) # 自定义断言判断页面是否发生了预期变化 results.append({candidate: cand, status: pass}) else: results.append({candidate: cand, status: count_error}) except Exception as e: results.append({candidate: cand, status: exec_error, reason: str(e)}) finally: browser.close() return results一个很重要的小点验证时的网络请求状态、登录态、接口返回数据要尽量和失败时保持一致。否则候选定位器即使在你本地跑通了进 CI 环境可能还是失败。我在一个项目里吃过这个亏手动验证全通过一上流水线就挂最后发现是验证用的测试账号没挂 cookie 导致的。4. 工具选型自建修复引擎还是使用现有自愈框架4.1 常见浏览器自动化框架的适配性先把主流框架在“接 AI 修复”这件事上的差异列一下。并不是越新的框架越合适要看团队底子。框架社区活跃度定位器机制接入 AI 修复的难度Selenium WebDriver高基于 WebDriver API元素定位方式固定中需要自行包装异常不过生态成熟Playwright高自带自动等待和 locator API定位更稳健低locator 结构清晰DOM 快照获取方便Cypress中内置重试机制定位器失败率相对低中但其封闭架构导致接入自定义修复逻辑不那么灵活Appium中移动端元素定位依赖 UiAutomator 等偏高移动端 dynamic 元素还涉及 native view 层级我的个人倾向是如果现在团队还在用 Selenium没必要为了“AI 修复”全面迁移到 Playwright。可以在原先框架上包装一个SmartElementFinder拦截异常后走修复管线。如果是从零开始搭新项目Playwright 的 locator API 确实在设计上对“动态场景”更友好比如它天然支持locator(button).filter(has_text去支付)定位器表达力更强。4.2 开源自愈方案Healenium如果你不想从零写一套 AI 修复管线可以了解下 Healenium 这类开源项目。它做的事情就是“定位器自愈”测试在原有定位器失败时自动尝试用模型和启发式规则生成新的定位器并把修复后的结果存下来下次运行直接用新的。Healenium 的优点是很务实不侵入原有测试代码加一个依赖、改一行配置就能接入。自带 Web 界面可以看到哪些定位器发生过自愈修改的历史是怎样的。支持本地部署不依赖外部商业服务。但它也不是全能的。它的默认分析逻辑偏规则化对复杂语义、彻底改版后的页面效果有限。另外当页面本身出现 bug 时Healenium 可能会“自愈”到一个错误元素隐蔽地掩盖真实问题。这也是所有自愈工具的通病。我在一个中大型电商项目的经验是可以直接用 Healenium 做基础自愈覆盖同时把它的失败快照接到大模型分析服务作为第二道保险。两者结合之后原来每周花在维护定位器上的时间至少减少了一半以上。4.3 自建 vs 商业平台怎么选商业平台有几家在主推 AI self-healing比如 Applitools、Mabl、Katalon 等。它们的好处是开箱即用界面完善团队不用自己维护一套模型服务。适合对合规要求没那么高、预算充足、测试平台能与它们集成的团队。自建方案更适合这几种情况公司对数据出域有要求不允许把业务页面 HTML 直接发给第三方。已有自定义测试平台希望嵌入这个能力但不想引入绑定型产品。有一套私有化大模型或者可以调用公司内网的大模型 API。团队想长期积累“页面结构变化”的数据资产而不是分散在外部平台里。成本上自建的前期投入比想象中大。你需要维护失败信息采集 SDK、上下文裁剪模块、AI 模型调用与结果解析、验证回放服务、补丁合并流程。不要以为“接一个大模型 API 就完事”了真正的工作量分布在各个环节。写完第一版可能只要一周但稳定运行并真正节省人力我花了差不多一个半月。5. 常见问题与踩坑实录5.1 动态定位器修复中我踩过的几个坑第一个坑只取“当前失败位置的局部 HTML”忽略了页面状态。比如目标元素在一个弹窗里弹窗可能是点击后才加载的。直接拿page.content()去分析弹窗 DOM 根本不存在再强的模型也找不出来。后来我把“页面操作路径”也一起作为模型输入模型才可以根据上下文判断“这个按钮应该在点击某个 menu 后出现”。第二个坑候选定位器在目标页面里有多个匹配。类似contains(text(), 支付)这种写法非常容易同时命中“去支付”、“支付方式”、“支付成功”等多个节点。我在验证环节加了“唯一性检查”之后大量误修复被拦截下来修复准确率明显提升。第三个坑AI 生成的 XPath 里带了太深的结构依赖。比如//div[3]/div[2]/button[1]就算当前能跑下次前端加一层容器又挂了。后来我在 prompt 里强制要求“优先使用语义属性文本、name、data-*其次再使用兄弟节点或容器 class禁止使用纯数字索引路径”很多低质量候选一下就少了。第四个坑修好了定位器但核心断言没跟着调。定位器修复只代表“能找到元素”不等于“测试能通过”。有些时候页面字段本身改了断言逻辑也要改。AI 修复定位器之后最好把执行结果再带回到原始测试上下文里看最终断言是否通过否则治标不治本。5.2 排查思路速查表现象可能原因建议处理定位器失败但页面截图里元素可见属性动态变化或元素在 iframe 内检查 iframe 上下文再让 AI 基于 iframe 内 DOM 生成新定位器定位器在本地通过CI 失败环境差异数据、登录态、网络延迟统一测试前执行环境确保快照采集来自失败环境本身候选定位器唯一匹配但点击无效元素可能是隐藏节点或被遮挡验证回放时增加点击后的状态断言选择器偶发匹配多个节点页面列表数据异步加载加入:visible/first()限定或等待数据加载完成页面彻底改版目标和旧版本毫无关联语义层级变化过大结合视觉截图描述目标位置让模型基于布局推理5.3 落地时给团队的几点建议我个人在实际落地中获得的最大体会是不要把“AI 修复定位器”当成一个技术玩具而应该当做一个工程能力来建设。首先要让失败采集标准化script 里所有的元素查找入口都要走同一个封装不然散落在各处的find_element调用根本没法统一接管。其次不要一上来就做全自动合并前两周保持“AI 生成候选之后由人确认”的状态积累置信度数据对团队没有坏处。最后记得给修复动作留审计日志哪怕只是存一条 JSON 记录将来复盘线上问题时能少很多争议。另外一个小技巧是验证回放时不要只用“点击成功”作为标准最好给每个核心元素定义一步“最小关键断言”。比如对登录按钮的验证不是满足于能点击而是点击后 URL 是否跳转或是否出现错误提示。有了这一层AI 修复的整个链路才算真正闭环。最后再分享一个我在使用大模型时的小经验复杂页面的 HTML 片段不要一股脑全塞进去先在本地做一个轻量级的“相关元素列表”抽取把表单、按钮、链接的 text、name、placeholder、data-* 属性提取成结构化文本再丢给模型。这样不仅速度快结果的稳定性也高很多。这套流程跑顺之后我最大的感受就是自动化测试脚本终于回到了测试本身而不是天天在给垃圾元素属性擦屁股。