Selenium 核心机制

• 八种定位方式
• 优先级与稳定性
• CSS/测试 ID vs 绝对 XPath

Selenium 八种定位方式：id、name、className、tagName、linkText/partialLinkText、xpath、cssSelector。优先级与稳定性权衡：id 最稳定（唯一且语义清晰）优先；name、className 次之（可能有重复）；cssSelector 表达力强、性能好、稳定（相对路径、语义类名）；xpath 功能最全但绝对 XPath 脆弱；linkText 用于链接。推荐 CSS/测试 ID 的原因：data-testid/id 是"稳定锚点"，不受布局/样式/文本变动影响；CSS 选择器稳健、可读、性能好（浏览器原生支持）、支持相对定位与层级；而绝对 XPath（/html/body/div[2]/div[3]/form/...）依赖 DOM 层级与顺序，任何布局调整、元素增减都会使其失效，且可读性差、维护难。结论：优先用测试 ID/id 定位关键元素，功能/结构用语义 CSS，仅在"无稳定属性、需复杂逻辑"时用相对 XPath，避免绝对 XPath。

定位的稳定性 = "锚点稳定性 + 路径稳定性"。测试 ID/id 是语义锚点，CSS 是稳定路径，绝对 XPath 是脆弱的"位置路径"，故优先推荐前者、慎用后者。

• 三种等待的区别
• 混用问题
• 超时叠加与错误掩盖的机制

三种等待的区别：强制等待（Thread.sleep/time.sleep）——固定时长无条件等待，无论元素是否已就绪，最简单但浪费、不稳定、易 flaky；隐式等待（implicitly_wait）——设置全局默认超时，每次查找元素时若无立即找到则轮询等待，直到超时，作用于所有 "find" 操作；显式等待（WebDriverWait + ExpectedConditions）——针对特定条件（元素可见、可点击、出现文本）轮询等待，直到条件满足或超时，最精确可控。混用显式与隐式等待的问题：两者叠加导致超时时间相乘（隐式 10s + 显式 10s = 最坏 20s），且显式等待的底层查找也受隐式等待影响，导致等待时间不可预期、用例变慢、超时误判；隐式等待还能掩盖"元素不存在"的错误（变成等待超时而非立即失败）。正确做法：只用一种等待策略——推荐显式等待为主（精确、可控），隐式等待只作兜底且不混用；Playwright 用 auto-wait 统一替代，避免此类问题。

三种等待的本质区别是"等待的对象"：强制等时间、隐式等任意查找、显式等特定条件。混用会叠加超时、掩盖错误，破坏等待的可预期性，故应统一策略。

• 异常产生机理
• 规避策略
• re-find 模式与公共层收敛处理

StaleElementReferenceException（元素失效异常）的产生机理：Selenium 找到元素后，DOM 被重新渲染/替换（Ajax 刷新、页面导航、SPA 路由切换、列表更新），原先持有的元素引用指向"已脱离 DOM 的旧节点"，再操作该引用时就抛 StaleElement。规避策略：一是避免保存元素引用——每次操作前重新查找（Playwright 的每次 locator 操作都重新解析；Selenium 则在操作前重新 find），不做"找一次存起来反复用"；二是等待稳定——在异步更新后先等待元素重新就绪（显式等待可见/可交互）再操作；三是用"重试-重新查找"——捕获 Stale 后重新查找元素再操作（有限次重试）；四是封装为稳定的"re-find"模式——把"查找+操作"封装成会重试的方法，避免用例层写裸引用；五是优先用 Playwright 的 auto-wait/重新解析（天然规避 Stale）。系统化：用"元素不缓存 + 操作前重新解析 + 异常重试"三层策略，把 Stale 处理收敛到公共层。

Stale 的根源是"引用了脱离 DOM 的旧节点"。规避核心是"不缓存元素引用、操作前重新解析、异步后等待稳定"，并封装为可重试的 re-find 模式。

• iframe 切换
• 多窗口切换
• 原生弹窗处理

三种跨边界场景的处理：iframe——需先切换到 iframe 上下文才能操作其内部元素：Selenium 用 driver.switchTo().frame(identifier/index)，操作后 switchTo().defaultContent() 返回；Playwright 用 frameLocator() 直接定位 iframe 内元素，无需显式切换。多窗口——新窗口/新标签页：Selenium 先 getWindowHandles() 拿到句柄再用 switchTo().window(handle) 切换，Playwright 用 page.expect_popup() 捕获新页；等待窗口就绪、用完关闭或切回。原生弹窗（alert/confirm/prompt）——JS 弹窗阻塞页面，需先处理：Selenium 用 switchTo().alert().accept()/dismiss()/getText()/sendKeys()；Playwright 用 page.on('dialog') 预注册监听并 accept/dismiss；未处理会阻塞后续操作。要点：切换后要恢复上下文（切回主 frame/默认窗口），弹窗要预注册监听或提前处理，避免"找不到元素/上下文错误"。

三种场景的共同点是"跨越了页面默认上下文"。显式切换/预注册监听并恢复上下文，是把交互正确指向目标对象的关键，避免"上下文混淆"类错误。

• W3C WebDriver 协议
• 相对定位器
• BiDi 能力

Selenium 4 相比 Selenium 3 的关键变化：一是 W3C WebDriver 协议——Selenium 4 完全基于 W3C WebDriver 标准（取代旧的非标准 JSON Wire Protocol），客户端与浏览器驱动统一用标准协议通信，跨浏览器兼容性更好、无需再为不同浏览器做协议适配；二是相对定位器（Relative Locators）——用 withTagName、above、below、toLeftOf、toRightOf、near 基于"与另一元素的位置关系"定位元素，极大简化需要位置关系的定位（如"位于按钮上方的标签"），替代复杂 XPath；三是 BiDi 能力——Selenium 4 引入 WebDriver BiDi 协议（双向通信，浏览器主动推送事件），支持日志、网络、性能等更丰富的能力（仍在演进），比单向指令更强大。此外改进：元素交互、窗口管理、getShadowRoot 等。这些变化让 Selenium 更标准、易用、能力更强。

Selenium 4 的三大变化契合"标准化 + 易用 + 能力增强"：W3C 协议统一交互、相对定位器简化定位、BiDi 开启双向通信与更丰富浏览器能力。

• 无头上传
• 无头下载
• 以 API/事件方式替代系统对话框

无头（headless）浏览器中文件上传/下载无法通过系统对话框，需用 API 方式。上传：优先用 input 元素直接 sendKeys(filePath)（Selenium）或 setInputFiles(path)（Playwright），绕过系统文件选择框，无头下同样生效；仅当不能用 input 时（如自定义拖拽上传）才需特殊处理（如直接设置文件输入或 JS 注入）。下载：需配置浏览器下载行为——headless 下禁用"另存为"弹窗，设置下载目录（Chrome prefs 的 download.default_directory、download.prompt_for_download: false），Selenium 配置 ChromeOptions，Playwright 用 page.waitForEvent('download') 捕获下载并 saveAs() 到指定目录；无头下要确保下载目录真实存在且可写。要点：无头下"弹窗/对话框"不适用，统一用"API 方式"（input 传路径、事件捕获下载）替代，并配置浏览器下载策略；下载完成以"完成事件/文件存在"为信号而非固定等待。

无头下没有系统 UI，因此"经外部对话框"的路径不可用。上传用 input 送路径、下载用事件捕获+目录配置，以 API/事件方式替代，是无头文件交互的标准做法。

• WebDriver 架构
• 通信协议
• 与浏览器自动化协议关系

Selenium WebDriver 架构是"客户端-服务器"模式：测试代码（Client，如 Java/Python 库）通过 HTTP 协议与"浏览器驱动（Browser Driver，如 chromedriver、geckodriver）"通信，驱动再把命令翻译成浏览器原生支持的自动化协议来驱动浏览器。通信协议：Client 与 Driver 之间用 WebDriver Wire Protocol（Selenium 3 时代非标准 JSON Wire Protocol）演进到 Selenium 4 的 W3C WebDriver 标准（JSON over HTTP 的 REST 风格命令），驱动与浏览器之间则用浏览器厂商的自动化协议——Chrome 用 CDP（Chrome DevTools Protocol）、Firefox 用 Marionette、Safari 用 WebDriver 原生协议。也就是说：WebDriver 协议是"客户端↔驱动"的国际标准，解决了"一个 API 驱动所有浏览器"的问题；驱动内部把标准命令翻译为各浏览器专有协议。理解架构有助于排查（驱动版本不匹配、端口、协议差异）与选型（不同浏览器驱动）。

三层架构里，WebDriver 协议是"统一命令层"，各浏览器自动化协议是"厂商实现层"。驱动是翻译器，把标准命令映射到浏览器原生机，从而多浏览器统一 API。

• 定位优先级
• 性能差异
• 动态元素定位

定位优先级：id 优先（唯一、快、语义清晰）→ name/class（次之，可能有重复）→ css（表达力强、可控）→ tagName/linkText → xpath（能力最全但相对慢）。性能差异：id 最快（浏览器按 ID 索引查），css 次之（原生选择器引擎，性能好），xpath 相对慢（尤其绝对/复杂 XPath，需遍历 DOM），name/class 适中。动态元素定位：id/class 带随机数或索引变化时，用稳定语义属性（data-testid）、相对定位（text、层级关系、nth）、或"包含/开头匹配"（CSS [class^="btn"]、XPath contains）定位；避免依赖硬编码索引与绝对路径；配合显式等待等待元素就绪。要点：优先稳定锚点（id/testid），用语义 CSS 兼顾性能与可读，动态元素用"相对 + 属性匹配 + 等待"而非"绝对 + 索引"。

定位的优先级是"唯一性 + 性能 + 稳定性"的权衡。id/testid 唯一且快，css 快且可读，xpath 全面但慢；动态元素用稳定的语义锚点 + 相对匹配解决。

• 无头 vs 有头差异
• 截图/下载/媒体/资源
• 取舍

无头（headless）与有头（headed）版本差异：有头有真实窗口、可见渲染，适合调试观察；无头无窗口、后台渲染，适合 CI/批量。差异与取舍：截图——两者都能截图，但无头需注意"视口/渲染时机"（某些动画/懒加载可能未完成，需等待）；有头截图更直观。下载——无头需配置下载目录，有头可依赖系统行为但弹窗难自动化；无头更可控。媒体播放——无头对媒体/视频渲染支持有限（部分浏览器无头默认禁用 GPU/硬件加速），需显示配置；有头更接近真实。资源开销——无头内存/CPU 占用低、启动快、适合大批量并行，是 CI 首选；有头开销大、需显示环境（如 xvfb）。取舍：CI 与批量用无头（省资源、快、可控），本地调试/需验证真实渲染时用有头；用"无头为主、有头按需"策略，并在无头下针对性处理截图时机、下载配置、媒体/GPU 配置。

取舍核心是"资源效率 vs 真实度"。无头省资源适合 CI，有头真实适合调试；无头下需针对性处理截图时机、下载目录、媒体/GPU 配置，才能接近有头效果。

• 容器内 xvfb/无头
• 驱动版本匹配
• 资源限制

Selenium 在 CI 容器中执行需处理三方面。xvfb/无头：容器无显示环境，用无头模式（headless）最简；若需有头或截图绘图，用 xvfb（虚拟帧缓冲）提供虚拟显示（xvfb-run），让浏览器以为有显示。驱动版本匹配：浏览器与驱动版本必须匹配（chromedriver 对应 Chrome 版本），用 WebDriverManager（Java）自动下载匹配版本，或手动确保; CI 容器用固定浏览器+驱动版本并缓存，避免漂移；版本不匹配会报"SessionNotCreated/Driver version"错误。资源限制：容器用 --memory/--cpus 限制，浏览器是资源大户，需预留内存（多 worker 并发时按 worker 数分配）；并发数匹配容器资源，防 OOM；设置浏览器启动参数（--no-sandbox、--disable-dev-shm-usage 在容器 root 下常用）。综合：无头/虚拟显示 + 驱动版本自动匹配 + 资源受限并发匹配，保证 CI 容器内稳定执行。

容器内执行的三大坑是"无显示、驱动漂移、资源不足"。无头/xvfb 解决显示，WebDriverManager 解决版本，资源限制与并发匹配解决稳定性。

• 常用 ExpectedConditions
• 自定义等待条件
• 轮询与超时控制

Selenium ExpectedConditions 常用条件：visibilityOfElementLocated、elementToBeClickable、presenceOfElementLocated、textToBePresentInElement、elementToBeSelected、stalenessOf、invisibilityOfElementLocated、numberOfElementsToBe、urlContains 等。自定义等待条件：用 ExpectedCondition<T> 接口，apply 方法返回"期望值或 null/false"，实现业务化等待（如等待某文本出现、某接口数据渲染、某元素具备特定属性），WebDriverWait.until(condition) 执行。避免轮询过频：WebDriverWait 可设 pollingEvery（如 500ms）控制轮询频率，避免高频空转 CPU；对快速变化的页面用合理频率。避免超时误判：设置合理超时（Duration.ofSeconds）匹配真实等待时间，避免太短误杀（页面慢）或太长掩盖问题；结合"等待条件准确"（等待业务条件而非固定元素），超时时间用失败日志提示"等待了什么"。要点：用语义化条件、合理轮询/超时，让等待"精确、可控、可诊断"。

显式等待的价值在"条件驱动"。常用条件覆盖常见就绪状态，自定义条件支撑业务化等待；轮询频率与超时是"性能与准确性"的平衡，需合理设置。

• open/closed shadow root
• piercing 定位
• JS 句柄

Shadow DOM 用于封装自定义元素内部结构，分 open 与 closed 两类。open shadow root：可通过 element.shadowRoot 从外部访问，可被穿透定位；closed shadow root：shadowRoot 返回 null，外部无法直接访问，只能靠 JS 或浏览器内部手段。定位方法：piercing——Playwright 的 CSS 选择器能自动穿透 open shadow root（locator('x-button').locator('.inner')），Selenium 需用 getShadowRoot() 逐层进入（shadowRoot.findElement(...)）；JS 句柄——用 execute_script 执行 document.querySelector 逐层穿透（element.shadowRoot.querySelector('.inner')），对 closed shadow 可用返回的 JS 句柄操作（但需浏览器内部能力，受限）。稳定性：优先给自定义元素加稳定属性（data-testid）作锚点；用自动 pierce 减少手工穿透；把穿透逻辑封装在 Page 内。对 closed shadow，尽量通过公开属性/API 验证，避免依赖内部结构。

定位 Shadow DOM 的关键是"能否穿透"。open 可穿透到 JS/外部，closed 拒绝外部访问；用自动 pierce/JS 句柄 + 稳定锚点，把穿透细节封装在 Page 层。

• CDP 增强
• 网络拦截
• 性能指标与弱网

Selenium 4 可通过 CDP（Chrome DevTools Protocol）增强浏览器能力，Selenium 提供 DevTools 接口（driver.getDevTools()）实现高级能力。网络请求拦截：用 CDP 的 Network.* 域监听/拦截请求——Network.enable、Network.requestWillBeSent/Network.responseReceived 获取请求响应，或 Fetch.enable 拦截并修改请求（mock 响应、阻断请求）；Selenium 封装 DevTools 的 createSession/addListener 实现。性能指标采集：用 CDP 的 Performance.*/Runtime.evaluate 采集 performance.getEntriesByType('paint') 得到 LCP、CLS、FCP 等 Core Web Vitals，或 Performance.enable 后获取指标。模拟弱网：用 CDP 的 Network.emulateNetworkConditions 设置带宽/延迟/丢包（latency、downloadThroughput、uploadThroughput、offline），模拟弱网/离线测试。综合：CDP 让 Selenium 从"命令式自动化"扩展为"可观测、可拦截、可模拟"的浏览器控制，支撑性能、网络与弱网测试。

CDP 是 Selenium 能力增强的窗口。通过 DevTools 接口可拦截网络、采集性能指标、模拟弱网，弥补 Selenium 原生能力不足，实现更接近浏览器底层的测试。

• 可见但不可交互
• 点击失败原因
• 等待可点击封装

元素"可见但不可交互"指元素在 DOM 中可见（能找到、占位），但无法真正接收点击。常见原因：覆盖遮挡——其他元素（弹窗、遮罩、loading）盖在目标上，点击被遮挡元素接收；disabled——元素 disabled 属性，不可交互；视口外——元素在可视区域外（需滚动），或不可见（display:none/零尺寸）；动画/未就绪——元素尚未完全可交互。为何点击会失败：Selenium 点击会"点击元素中心"，若中心被遮挡（点击到遮罩）、元素 disabled（无响应）、视口外（坐标命中不了/需滚动），均失败或抛异常。统一封装"等待可点击"：用 elementToBeClickable（等待可见且可交互）或 Playwright 的 auto-wait（自动等待"可接收点击"）；封装时先判"是否遮挡"（elementFromPoint 检查点击点元素）、"是否 disabled"、"是否视口内"（滚动进入），再点击；对遮挡可先关闭遮罩/点击遮挡前的元素。统一封装成"等待可点击再点击"的方法，避免散落条件判断。

点击失败的本质是"可见 ≠ 可交互"。统一封装"等待可点击"（可见 + 未被遮挡 + 未 disabled + 在视口内），把常见交互条件收敛到公共方法，减少 flaky。

• 典型使用场景
• 滥用风险
• 非侵入式用法与真实交互验证

execute_script 直接执行 JS 用于 Selenium 不易实现的场景。典型场景：滚动（滚动到元素/指定位置，scrollIntoView / window.scrollTo）；修改属性（修改 css、value、disabled、移除元素属性）；点击被遮挡元素（绕开遮挡直接 element.click() 或触发事件）；获取复杂状态（document.querySelector 取值、读取 hidden 元素）；注入数据（设置富文本/输入框值）；处理 shadow DOM 穿透。滥用风险：绕过浏览器原生交互（直接改 DOM/触发事件）可能"测试通过但真实用户操作失败"（如绕过校验、点击未真正完成）；破坏真实交互语义（跳过了事件、验证、动画）；修改页面状态造成假绿；代码脆、难维护、失去自动化"模拟真实用户"的价值。正确用法：仅在"原生方式无法实现"时用 JS（如阴影、滚动、读取隐藏值），且尽量用"非侵入"方式（滚动、读取），避免用 JS 伪造交互绕过真实逻辑；用 JS 修改后需验证真实行为。

JS 是"绕过原生交互的捷径"，也是"伪造交互的陷阱"。典型场景用 JS 是合理补充，但滥用会失去"模拟真实用户操作"的意义，导致假绿，故应限制在原生无法实现的场景。

• Hub/Node 架构
• 跨浏览器/跨机器
• 分布式执行

Selenium Grid 用于跨浏览器、跨机器的分布式自动执行。架构：Hub（中心节点）与 Node（工作节点）。Hub 是"调度中心"，接收测试请求、管理节点注册与能力匹配、把任务路由到合适节点；Node 是"执行节点"，注册到 Hub，承载具体浏览器（可配置不同浏览器/版本/平台）。执行流程：测试客户端向 Hub 发送请求（含能力要求，如 Chrome、Firefox），Hub 根据能力匹配到符合的 Node，Node 启动对应的浏览器驱动执行用例，结果回传。跨浏览器：每个 Node 可配置不同浏览器（Chrome/Firefox/Edge/Safari），或同一浏览器多节点，实现跨浏览器矩阵测试。跨机器：Node 可部署在不同机器（不同 OS/平台），实现跨平台、跨机器并行。分布式执行：多个 Node 并发执行，测试用例按能力分发到各节点，实现并行加速（如回归在多个节点分片跑）。Selenium 4 的 Grid 更轻量、支持动态节点、容器化（Docker 一键起 Grid）。

Grid 的本质是"一个 Hub 调度多个 Node"。Hub 负责"能力匹配 + 任务路由"，Node 负责"实际执行"，从而支撑跨浏览器、跨机器、分布式的并行测试。

• ActionChains 稳定性
• HTML5 与老页面差异
• 替代方案

ActionChains 用于拖拽、悬浮、组合键等复杂交互，但稳定性堪忧。拖拽：HTML5 原生拖拽（dragstart/dragover/drop 事件）与老页面"mousedown + mousemove + mouseup"模拟拖拽不同，dragAndDrop 在 HTML5 上常失效（需本地事件序列模拟）；替代方案是自定义 clickAndHold + moveTo + release 或 execute_script 手工触发事件。悬浮（hover）：需 moveToElement 触发 CSS :hover 效果，但需元素可见且移动到位，动画/子菜单可能不稳定；替代用 moveToElement + 等待子菜单。组合键：keyDown/keyUp/sendKeys 组合（如 Ctrl+C），在跨平台/不同浏览器修饰键差异（Mac 用 Command）需按平台区分；替代直接 sendKeys(Keys.chord) 组合。稳定性问题：ActionChains 依赖真实鼠标事件流，受动画、遮挡、元素位置、焦点影响，容易 flaky。应对：优先用原生交互（Selenium 4 的 W3C 交互更稳）、等待可交互、用 JS 替代难实现的拖拽、封装为稳定的动作方法。

ActionChains 的稳定性源于"模拟真实鼠标事件流的脆弱性"。HTML5 与老页面拖拽机制不同、悬浮受动画影响、组合键有平台差异，需按场景用 native 交互或 JS 替代并封装。

• 失败诊断证据
• 自动归档方案
• 证据携带元数据（用例/环境/提交）并关联到报告

Selenium 测试失败诊断需自动归档多类证据。截图：失败时 getScreenshotAs 抓取页面截图（File 类型）；页面源码：getPageSource 抓取当前 DOM；控制台日志：通过 capability 开启 LogType.BROWSER 读取 manage().logs().get(LogType.BROWSER)，含浏览器 console 错误；网络日志：启用 LogType.PERFORMANCE 抓取请求/响应信息；视频录制：用外部工具（如 ffmpeg 录制屏幕，或 Selenium + 录屏库）录制全程，或用浏览器自带录制能力。自动归档方案：在失败钩子（如 JUnit @After 判断失败、pytest pytest_runtest_makereport）中捕获上述证据，命名规范（用例名-时间），保存到指定目录并上传为 CI artifact 或报告附件（Allure/Selenium 报告），关联到失败用例。设计：把"失败时捕获+归档"做成统一机制（失败即触发，避免正常用例也抓取），证据带元数据（用例/环境/提交），支持一键查看。综合截图看视觉、源码看结构、日志看 console、网络看请求、视频看时序，快速定位。

失败诊断的本质是"把失败现场固化"。失败时自动捕获截图/源码/日志/网络/视频并归档到报告，配合元数据，让失败可定位、可复现。

• SPA 等待设计
• 组合条件等待
• 避免固定 sleep

SPA（单页应用）路由切换不刷新页面，等待新页面就绪需用组合条件而非固定 sleep。等待条件：URL 变化——用 waitForURL/urlContains 等待路由跳转完成；关键元素——等待新页面的标志性元素出现（visibilityOfElementLocated 指定元素）；网络空闲——等待网络请求完成（Playwright 的 waitForLoadState('networkidle') 或等待特定接口响应）；交互就绪——等待可点击/可交互状态。组合策略：用"URL + 关键元素 + 网络空闲"的组合条件，而非单一条件——先等 URL 变化（路由已切换），再等关键元素（内容已渲染），必要时等网络空闲（数据已加载）；避免固定 sleep（无论多长都不确定、慢且 flaky）。Playwright 的 auto-wait 与 Web-first 断言内置"等待就绪"，Selenium 用 WebDriverWait + 组合 ExpectedConditions（如 and 组合）。要点：等待"业务终态"（新页面内容就绪、数据渲染完成），用可观测条件组合，把等待封装为语义化方法。

SPA 等待的核心是"等业务终态而非时间"。用 URL、关键元素、网络空闲的组合条件表征"新页面就绪"，避免固定 sleep，是 SPA 自动化稳定的关键。