先交代背景。 2023 年我在一个 SaaS 后台项目里接手了 260 条 UI 自动化用例。 当时用 Selenium 4 + pytest，跑一次全量 47 分钟，平均每天 3 条 flaky。 最烦的不是慢，是没人敢信红灯：开发说测试问题，测试说环境问题，最后 bug 从缝里溜过去。 后来我把 UI 砍到 38 条，接口补到 410 条，夜间全量 12 分钟，flake 从每天 3 条降到每周 1 条左右。 我的观点可能不讨喜：自动化测试不是越多越好，它是维护预算问题。
先对比三个我真正用过的框架，版本分别是 Playwright 1.40 + pytest-playwright 0.5、Selenium 4.16、Cypress 12.x。 启动速度：我 M1 Mac 上 Chromium 冷启动，Playwright 约 1.8 秒，Selenium 4 约 2.8 秒，Cypress Electron 约 2.2 秒；CI 的 ubuntu-22.04 2 vCPU 上都会再慢 1-2 秒。 等待机制：Playwright 的自动等待最省心，locator.click() 会等 actionable；Selenium 必须自己写 WebDriverWait，写不好就是 flaky；Cypress 自带重试但同源 iframe 和跨域会让人头大。 并行：Playwright 用 pytest-xdist 或 --workers=4，Cypress 需要 Cypress Cloud 或 sorry-cypress，Selenium 一般上 Grid。 调试：Playwright trace viewer 最舒服，失败保留 trace.zip；Selenium 靠截图和日志；Cypress 时间旅行很好，但 CI 上视频很占空间。 跨浏览器：Playwright 自带 chromium/firefox/webkit；Selenium 最广但驱动和版本要管；Cypress 主要是 Chromium 系，Firefox/WebKit 支持有限。
再说大家最常搜的问题：自动化测试 flaky 怎么办。 我用的步骤土但有效。 第一步，先隔离，给用例打 @flaky，CI 里不阻塞合并，但每天统计。 第二步，收集 2 周数据，按错误分类。我这边 selector 占 40%，测试数据冲突 25%，等待 20%，环境 15%。 第三步，selector 全换成 getByRole/getByTestId，禁用一长串 CSS 路径；数据按 worker 分 tenant_id，每个 worker 独立租户，用完 API 删除；等待用 expect(locator).to_be_visible(timeout=5000)，不用 sleep。 第四步，CI 只允许重试 1 次，pytest --reruns=1，超时 30 秒，suite 总超时 20 分钟。 第五步，每周清理 3 条最慢或最 flaky 的用例。 结果：flake 率从 15% 降到 3%，夜间构建从 47 分钟降到 12 分钟。
如果你要从零落地，我会按这个顺序抄。 第 1 天：画核心流程，只选 5 条冒烟：登录、下单、支付、退款、后台改价。 第 2 周：接口优先，pytest + requests + jsonschema + allure，410 条接口用例平均 120ms，全套 50 秒左右。 第 3 周：UI 只覆盖 38 条，Playwright + Python 3.11，页面对象轻封装，别搞五层继承。 CI 配置：GitHub Actions，runs-on ubuntu-22.04，timeout-minutes: 20，PR 跑 smoke 约 3 分钟，main 每晚 2 点跑全量约 12 分钟。 命令我是这么写的：pytest -m smoke --workers=4 --reruns=1 --timeout=30 --alluredir=allure-results。 环境用 Docker Compose 起 MySQL 8、Redis 7，每次 CI 新 namespace，跑完销毁。
选型结论我不按 star 数排。 新项目、Python/TS、跨浏览器、要 trace，我选 Playwright。 老系统、Java/C#、多团队、要 Grid，我留 Selenium。 前端团队、JS 栈、组件测试多，Cypress 更顺手。 但我更想说：UI 自动化是奢侈品，接口自动化是日用品，单元测试是自来水。 覆盖率 70% 的接口 + 关键路径 UI，比 100% UI 有用得多。 自动化测试的 KPI 不是用例数，是发现真 bug 数除以维护分钟数。
最后放几个我踩过的坑。 不要用 sleep(10)，除非你在本地调试。 不要多个测试共享同一个账号，并行会互相锁数据。 不要拿生产数据跑测试，脱敏也尽量别碰。 不要把断言写进 page object，page object 只负责页面动作。 不要追 100% 覆盖率，那通常是给领导看的数字。 每周看一次 flaky 排名，失败先看 trace，再本地复现，最后才改代码。 留一点手工探索测试时间，自动化只能证明旧 bug 没回来，不能发现新交互问题。
