Selenium WebDriver 自动化

你在解决什么问题

Web UI 自动化最容易死在三个地方：定位器随 DOM 改版失效、等待混用导致超时不可预测、以及测试结束后 driver 未 quit 留下僵尸浏览器进程。团队还常常把断言和 findElement 散落在用例里，CI 一上规模就 flaky 成片。

技能如何组织工作流

技能把对话当成一次小型 QA 架构评审，按固定步骤推进：

1. 执行目标：先澄清要测的页面/流程，而不是直接堆脚本。
2. 语言检测：根据你提到的 Python/pytest、Node/Mocha、C#/.NET 等信号，选择对应工具链；默认走 Java + Maven + JUnit 5，其它语言会指向 reference/*-patterns.md。
3. 范围分流：

- 「为 X 写测试」→ 单文件、内联 setup；
- 「搭 Selenium 项目」→ POM、配置、基础类齐全；
- 「修/调试」→ reference/debugging-common-issues.md；
- 「上云跑」→ reference/cloud-integration.md。

Java 默认模式强调可维护写法：定位器优先 ID / 相对 CSS，禁止脆弱绝对 XPath；等待只用 显式 WebDriverWait，不写 Thread.sleep；清理在 teardown/@AfterEach 里 driver.quit()。页面对象模型把定位器收进 Page 类，断言留在 Test 类。云侧从环境变量读取 LTUSERNAME、LTACCESS_KEY（TestMu AI 集成）。更重的生产模式（DriverFactory、BasePage、并行、Allure、CI 矩阵等）在 reference/playbook.md 分章展开。

适用边界

这是 脚本与工程模式 向导，不是替代你本地浏览器驱动、Maven/npm 环境或云账号配置。非 Java 栈需要按 reference 补齐依赖与目录约定；不稳定用例仍要回到等待策略、定位器和 stale element 等调试清单逐项排查。