先说结论：自动化测试的瓶颈不是写脚本，而是失败解释成本
2023年11月，我接手一个跨境SaaS后台的E2E流水线。仓库里躺着312条Selenium用例，Python 3.11 + pytest 7.4 + selenium 4.15，CI跑在GitHub Actions的ubuntu-latest上，2核7G内存，单次全量回归18分42秒。最要命的不是慢，是flake率6.8%：10次跑挂7次？不，是100次里有6.8次失败，其中一半重跑就过。
我当时做了个很反直觉的决定：先不迁移，先删。把最近30天失败记录拉出来，312条里只有97条在主干合并前真正拦截过bug，占比31.1%。剩下203条里，114条是点按钮看文案、68条是重复校验接口返回、21条是环境初始化失败。删完再迁Playwright 1.40，保留198条，CI降到7分15秒，flake率0.9%，每周维护时间从12小时掉到3.5小时。
所以我的独立观点是：自动化测试的ROI不是用例数乘以覆盖率，而是（回归节省时间 × 失败可信度）减去（维护时间 + 诊断时间 + 等待时间）。当失败可信度低于0.7，这条流水线就是负资产。工具选型只能影响后三项，救不了前一项。
工具对比：Selenium、Playwright、Cypress、Appium、Robot Framework
我把常用工具按2024年中的稳定版本拉了个表，维度只留能影响你加班时间的：自动等待、网络拦截、多标签/多上下文、移动原生、并行隔离、调试体验、CI资源占用。
| 维度 | Selenium 4.18 | Playwright 1.42 | Cypress 13 | Appium 2.5 | Robot Framework 7.0 |
|---|---|---|---|---|---|
| 语言 | Java/Python/C#/JS/Ruby | JS/TS/Python/Java/C# | JS/TS | Java/Python/JS/C#/Ruby | Python/Java/JS/.NET |
| 自动等待 | 无，需显式等待 | 内置auto-wait | 内置重试 | 需配合等待策略 | 关键字封装 |
| 网络拦截 | CDP/BiDi，较绕 | route，一行搞定 | cy.intercept，强但同源限制 | 靠代理或驱动 | 需自写库 |
| 多标签/窗口 | 支持但API碎 | BrowserContext隔离 | 多标签弱，跨域麻烦 | 原生App上下文 | 支持有限 |
| 移动原生 | 不适用 | Android实验，iOS不行 | 不适用 | 事实标准 | 通过AppiumLibrary |
| 并行 | Grid/Selenoid | workers+shard | Cypress Cloud收费 | Selenium Grid/Appium | pabot |
| 调试 | 截图+日志 | Trace Viewer | 时间旅行 | Inspector | 日志+报告 |
| 适合 | 老系统、多语言 | 现代Web、高频回归 | 前端组件、本地开发 | 移动端真机 | 验收/关键字驱动 |
具体说几个坑。Selenium 4.18虽然有了Selenium Manager，浏览器驱动不用手动下，但等待还是要自己写，WebDriverWait 写多了会出现等待时间叠加，一条用例多等3秒，200条就是10分钟。Playwright的auto-wait不是万能，它只保证元素可操作，不保证业务数据到位；我遇到过一次库存扣减用例，按钮可点了，但后端异步队列还没消费，最后还是得加 expect.poll 轮询接口。
Cypress 13的DX确实好，cy.intercept 改响应体很方便，但它跑在浏览器里，遇到 window.open 新标签、跨域支付回跳、文件下载，就要绕。Appium 2.5把驱动拆成插件后灵活了，但启动一个Android模拟器+UiAutomator2，冷启动经常40秒起，CI里跑100条移动用例，光启动就吃掉一小时。Robot Framework 7.0适合业务验收，关键字表看起来清楚，但一旦有复杂条件分支，你会写出嵌套5层的 Run Keyword If，维护的人想哭。
迁移不是重写：我按这5步做了一周评估
如果你现在用Selenium跑得好，别因为Playwright火就全量迁。先花一周做评估，步骤很土但有用。
-
导出最近30天CI失败记录。字段至少要有：用例ID、模块、失败时间、是否重跑通过、失败原因分类。算两个数：flake率 = 重跑通过次数 / 总失败次数；有效拦截率 = 失败且最终确认是bug的次数 / 总失败次数。
-
给每条用例打标签：核心路径、数据构造、断言类型、平均执行时间、平均诊断时间。诊断时间从Slack里翻，谁在群里问“这条为什么挂”就算一次，超过10分钟的标红。
-
选30条高频失败且核心的用例，用目标工具重写。别选最简单的登录，要选带异步、文件上传、支付回跳、多角色权限的。记录三个数：开发耗时、运行耗时、失败后定位到原因的时间。
-
在GitHub Actions里开一个独立workflow，用Playwright的
--shard=1/3分3片，workers=4，失败重试1次，开启trace为on-first-retry。跑两周，和旧流水线对比。如果30条里flake从5%以上降到1%以下，诊断时间从8分钟降到2分钟，再谈分批迁移。 -
迁移顺序：先迁API/集成测试，再迁UI核心路径。UI只留15%-20%的用例，其他下沉到接口或组件测试。我们最后UI只留了198条里的76条，剩下122条全转成pytest+httpx的接口测试，CI里跑完只要2分10秒。
数据隔离和并行：80%的flake不是工具问题
很多人把flake归罪于Selenium慢、Playwright不稳，其实大部分是测试数据打架。我们当时有3个用例同时给用户 test001@example.com 充值，并行一开，余额断言就随机挂。后来改成每个worker独立租户：worker 0用 tenant_0，worker 1用 tenant_1，数据库用Testcontainers 1.19.7每次起一个MySQL 8.0.36容器，Redis 7.2.4用独立db index。CI时间反而降了，因为不用排队等固定测试环境。
具体参数给你抄：pytest-xdist用 -n 4，Playwright用 workers: 4，GitHub Actions矩阵 shard: [1,2,3]，每个shard一个runner，总并行12个浏览器上下文。2核7G的runner跑4个Chromium headless已经是上限，再多就OOM。如果跑Firefox或WebKit，workers降到2。Docker Compose里给MySQL加 --innodb-buffer-pool-size=512M，否则容器容易在并发写入时抖。
还有一个反直觉的点：不要追求100%并行。把用例按“可并行”和“必须串行”分开，支付、库存扣减、优惠券领取这类有状态用例串行跑，其他并行。我们最后只对61%的用例开了并行，整体时间从18分42秒降到7分15秒，如果强行100%并行，flake率会从0.9%涨到4.3%，得不偿失。
报告和KPI：别再看用例数了
我见过团队周报写“自动化用例突破2000条”，结果主干合并前没人看，因为跑一次要45分钟，失败30条，大家直接点重跑。自动化测试的KPI应该只有三个：主干流水线反馈时间、失败可信度、每周维护人时。我们的目标是：反馈时间小于10分钟，失败可信度大于95%，维护人时小于4小时/周。达不到就删用例，而不是加机器。
报告用Allure 2.27，但别把Allure当装饰。每条失败必须带三样东西：trace文件、失败时刻截图、后端request-id。Playwright的Trace Viewer能直接看DOM快照、网络请求、console日志，定位时间从平均8分钟降到2分钟。接口测试用httpx的 event_hooks 记录请求响应，失败时把request-id打到日志，后端同学能直接查链路。
最后说选型。如果你团队是Java老系统，Selenium 4.18 + JUnit 5 + Allure没毛病，别折腾。如果是新Web项目，TypeScript栈，Playwright 1.42优先。如果是前端组件库，Cypress 13写开发期测试很爽。移动原生绕不开Appium 2.5，但一定要配真机农场和独立设备池。Robot Framework 7.0留给业务验收，别拿它写复杂E2E。工具没有银弹，先算失败解释成本，再决定迁不迁。