企业官网建设流程全解析

“今早一来，群里自动化任务的失败告警刷了二十多条，点进去一看，又是登录按钮的id变了。上一次修好是在两周前，这一次打包号一换，整个页面结构跟着动了一遍。”这种场景对于维护 Web UI 自动化脚本的人来说，绝对不陌生。动态定位器大概是脚本维护里最让人头大的问题之一，而“AI驱动的自动化脚本维护”这个方向，正是想把这个长期耗时、机械重复、又不得不做的事，变成一条半自动化的流水线。

这篇文章不会讲太玄的东西，而是围绕“动态定位器修复”这个具体问题展开：它为什么会发生、AI 在中间到底扮演什么角色、实际落地时怎么搭一套能用的修复机制。适合正在维护 Selenium、Playwright 或其他浏览器自动化脚本的测试开发工程师，也包括想了解“AI辅助测试”到底能干什么、又不能干什么的测试团队负责人。

1. 动态定位器为什么这么难修

1.1 所谓“动态”，往往不是完全随机

大多数人第一次遇到定位器失效，第一反应是“这个网站的开发者怎么这么不靠谱，id 怎么能乱变”。真正做了很久的自动化维护之后，你会发现大多数“动态”背后都有自己的规律，只是这些规律经常超出我们预先写死的预期。

我见过比较典型的几类：

• 带时间戳或随机数的属性：比如id="card-1699999999"，数字是按当前时间生成的。这种一眼就能看出来，但你没法每次运行时都重新计算。
• 部署生成的变更 ID：系统每次发版会把元素属性重新生成一遍，比如>driver.find_element(By.ID, "username_input")

  页面改版之后变成：

  <div class="login-form"> <label>邮箱</label> <input>driver.find_element(By.CSS_SELECTOR, "input[data-field='user-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 整体架构：失败 → 快照 → 分析 → 验证 → 回填

  我搭过的一个比较朴素的修复管线，按下面五个环节跑：

  1. 采集：监控测试执行结果，拦截所有因元素定位失败抛出的异常。
  2. 快照：在异常发生点抓取页面源码、截图、当前 URL、失败定位器信息。
  3. 裁剪：对 HTML 快照做裁剪，只保留和目标元素相关的内容（例如向上找几级父节点，再包含一部分兄弟节点），避免把整个页面一次性丢给模型。
  4. 生成：调用 AI 接口，输入“目标元素语义描述 + 裁剪后的 DOM 片段 + 旧定位器”，要求返回多个候选定位器及置信度。
  5. 验证：在测试环境重新打开 URL，逐个尝试候选定位器，确认唯一匹配且能完成预定义的前置操作；验证通过后自动生成补丁，提交到待审分支。

  流程本身不复杂，但每步都有很多细节。

  3.2 失败发生时怎么留存上下文

  这一步是整个管线的地基。很多团队说 AI 修复不准，仔细一看，是失败的时候根本没存东西。

  我建议至少从五个维度采集信息：

  • 异常类型和异常消息。例如NoSuchElementException: Cannot locate an element with the xpath: //*[@id="btn_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_page=True), "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 class="order-list"> <div>from playwright.sync_api import sync_playwright def verify_candidates(url, candidates, action="click"): 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(timeout=3000) 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-* 属性提取成结构化文本，再丢给模型。这样不仅速度快，结果的稳定性也高很多。这套流程跑顺之后，我最大的感受就是：自动化测试脚本终于回到了测试本身，而不是天天在给垃圾元素属性擦屁股。