答案。

问题的背景：

现代单页应用程序（SPA）基于 React、Angular、Vue 的出现导致了 UI 测试自动化的新问题：数据的异步加载、复杂的动态用户界面元素、客户端路由。经典的方法（例如，通过选择器或静态渲染的 DOM）已不再适用于这些应用程序。

问题：

由于加载延迟、动画和元素的异步变化，测试经常“失败”。
选择器的不稳定性（动态 ID、类、DOM 结构的变化）。
在前端更改后维护测试的复杂性。

解决方案：

使用显式等待 (explicit waits) 来等待元素的出现或变化：

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 20)
my_element = wait.until(EC.visibility_of_element_located((By.ID, 'dynamic_id')))

使用更具稳定性的标识符（data-testid、唯一属性）。
组织测试基础设施：模拟 API 响应，使用特殊的测试助手。
在前端包含特殊的钩子或稳定的测试 ID。

关键特点：

强调稳定的标识符和显式等待
通过 API 或服务事件验证 UI 状态
“分层”自动化：单元 + 集成 + E2E

有误导性的问题。

在 SPA 测试中是否可以只依赖 XPATH 或 CSS 选择器？

不可以。XPATH/CSS 等选择器在任何 DOM 更改时都容易失效。最好使用专门嵌入元素中的稳定 data-* 属性或测试 ID。

Selenium/WebDriverWait 解决所有异步问题吗？

不。WebDriverWait 有助于避免由于延迟而导致的失败，但不保证复杂 UI 的正确加载和状态。需要额外的检查、模拟 API 以及 UI 状态的工作。

仅检查页面上可见元素是否足以确认 UI 的正确加载吗？

不可以。如果元素显示但不包含预期的数据或状态，可能错误地接受“空”的加载为成功。需要验证内容和字段值。

常见错误和反模式

使用动态或不稳定的选择器
隐式等待（使用 sleep 而不是显式等待）
仅检查元素的存在，而不检查其值/内容
缺乏 API 响应/服务的模拟

生活中的例子

消极案例

自动测试按计划运行，使用 XPath 选择器和 sleep 延迟。更新 UI 后，一半的测试因缺少元素或其随着新 ID/class 的移动而失败。

优点：

自动测试的快速创建
结构简单

缺点：

不稳定性（不可靠的测试）
每个版本的维护复杂性

积极案例

在 UI 中嵌入 data-testid，测试使用显式等待和特殊的测试钩子。所有网络响应都被模拟，测试验证的不仅是存在性，还有元素的内容。