选型文章最容易写成两种：一种是「我家最好」，一种是拿别人的体感当自己的结论。这篇我努力避开这两条，尽量把四条路线的形状和代价摆出来，最后给五个问题 —— 你答完基本就知道该选哪个了。
先说清楚：这四条路线都能跑测试。「打开页面 → 点一下 → 断言文本」用哪个都写得出来。所以比较的重点从来不是「能不能」，而是代价谁承担。
就是直接用 Playwright 的库和 Test Runner 写脚本。
代价：codegen 只是起点，录出来的脚本仍要人维护；用例库、回归编排、失败证据（截图 / console / network）、报告、历史记录，这些都得自己搭 —— 而这恰恰是「跑一次」和「能天天跑」的差距。
适合：有工程能力、要细粒度控制、把 E2E 当代码直接写进 CI 的团队。
官方定位已经不只是跑测器，而是把端到端、组件测试、无障碍检查、覆盖率串成一个工作流（Cloud 是配套的商业产品线）。前端团队上手快，组件测试和调试体验是招牌，跨域场景官方给了 cy.origin 方案。
需要注意的是，官方自己在「Trade-offs」页明确列了架构带来的取舍：它跑在浏览器内部（这是调试体验好的原因，也是很多限制的来源），其中一条写的就是「不能同时打开多个浏览器」。这不是 bug，是架构选择的必然结果 —— 选它就得接受。
适合：以 web 前端行为为主、团队熟 JS、看重组件测试与调试体验。
可视化录制 + 云端（或托管）执行 + 团队报表与权限。
通常的卖点：零搭建、不写代码也能录、并行执行、团队可见。
通常的代价：执行环境和数据往往要出内网；按座位或跑量计费，长期成本随团队规模涨；复杂断言和自定义逻辑受产品边界限制，遇到平台不支持的只能等。
适合：要快速铺开、有预算、被测系统能上云、不打算自建基础设施的团队。
这一节我只描述「这一类产品的一般特征」，不点名对比具体厂商 —— 没有实测就拿营销词做对比，是选型文最容易翻车的地方。
形状：把「生成 / 录制 → 确认 → 存成脚本 → 确定性回放」做成一个本地桌面应用，底层还是 Playwright 在跑。
.testcase，含上传时连文件一起打包，能进 Git、也能让编程 agent 直接生成。代价：跑在自己机器上 —— 没有托管调度、并发队列和团队权限；多机器协作要靠文件和 Git；生成质量取决于你配的模型。
| 维度 | Playwright 裸写 | Cypress | 商业平台 | 本地工具 |
|---|---|---|---|---|
| 定位器从哪来 | 手写 / codegen | 手写 | 录制（平台私有格式） | 生成或录制，落为语义定位器 |
| 执行确定性 | 完全确定 | 完全确定 | 通常确定 | 完全确定 |
| AI 参与 | 无 | 无 | 平台内（黑盒） | 仅生成 + 自愈，可审查 |
| 断言能力 | 全部自己写 | web 断言 + 网络拦截 | 平台提供 | UI / 接口 / WebSocket 内置 |
| 复杂组件 | 自己处理 | 自己处理 | 看平台覆盖 | 语义动作插件 + 预设 |
| 资产形态 | 代码 | 代码 | 平台云端 |
.testcase 文件 |
| 数据位置 | 你的仓库 | 你的仓库（Cloud 可选） | 厂商云端 | 本地 SQLite |
| 成本结构 | 人力 | 人力 + 订阅 | 座位 / 跑量订阅 | 人力 + 模型调用（回放为 0） |
| 上手门槛 | 需工程能力 | 前端友好 | 最低 | 中等（要配网关） |
data-testid 也只能掉到末档。Playwright / Cypress 做贴近代码层的验证（组件、集成、边界逻辑）——离开发者最近；一句话：写测试 ≠ 管测试资产。前者的瓶颈是表达力，后者的瓶颈是维护成本和可信度。
你们团队最后选的是哪条路线？中间换过吗？我特别想听两类经历：
评论区聊聊，也给正在选型的同学一点真实参考。
参考链接：
