跨国深谈← 返回←浏览器自动化标准背后的故事：Selenium、WebDriver 与测试哲学

浏览器自动化标准背后的故事：Selenium、WebDriver 与测试哲学

关联

人物 Josh Goldberg · David Burns

公司 BrowserStack

概念 Selenium · WebDriver · WebDriver BiDi · W3C · 开源 · 无障碍性 · vibe coding · 可观测性 · OpenTelemetry

自动化浏览器测试是无数网页开发者天天依赖的基础技术——一份测试能以同样的方式驱动 Chrome、Firefox 和 Safari,背后是多年标准化工作的成果。

这一集的主角 David Burns 就是亲历者：他是 Selenium 和 WebDriver 的长期贡献者，在 Mozilla 待了十年，现在担任 BrowserStack 的开发者布道与开源负责人。

他从南非长大、学了计算机科学加工业心理学的奇怪组合讲起，2006 年左右在一家初创公司当第一个 QA 招聘，晚上因为妻子是音乐家不在家，就开始给刚起步的 Selenium 做开源贡献——就此一路做到了标准组织的深处。

WebDriver 标准是怎么来的

转折点发生在瑞士的一场 Google 测试自动化大会(GTAC)上：Opera 来了一个人，展示了他把 Selenium 移植进 Opera 浏览器的成果。

在场的人觉得这太棒了，每个有浏览器的公司都应该这么做，而那位 Opera 的人说，实现它的路径就是进入标准制定。

当时浏览器对自身的自动化测试大量依赖手工，又慢又容易出错——有个 Internet Explorer 的 QA 纠结于「完美还是够好」，盯着两张图片找半个像素的差异，浪费了海量时间。

于是 David 和 WebDriver 的创造者 Simon Stewart、后来加入团队的 Andreas Tolfsen 一起开始构建规范。

制定标准最难的不是「点击」「输入」这类简单操作，而是那些看起来无法定义的东西：你怎么知道一个元素真的在页面上？

要等多久？

David 说这归结为「在某种程度上标准化一个有意义的等待，而不试图解决停机问题」——停机问题是图灵提出的著名不可解问题，自动化不可能绕过它去判断「程序会不会永远跑下去」。

还有「可见」的定义：CSS 有 Z-index,但仅凭 DOM 布局方式，其他元素照样能覆盖在上面，不做逐像素检查就极难判定。

大量精力正是花在解决这些「用户不必自己解决」的难题上，并留出扩展机制——比如浏览器权限弹窗(摄像头、麦克风)这种难测的东西，现在可以通过规范内的 WebDriver API 扩展出去测试。

WebDriver 就是描述如何向浏览器发送和接收命令的标准(点击、这个元素可见吗)；Selenium、WebDriver.io、Playwright 等一票工具都建在它之上。

它们的共同福利是不用再操心「怎么跟浏览器对话」——当年跟 Firefox 说话要靠内置扩展，跟 Internet Explorer 说话要做 COM interop,从 Java、Python 到 Ruby 一路越做越糟。

而现在的工作重心在 WebDriver BiDi(BiDi 即双向，bi-directional),让脚本与浏览器之间的通信从单向请求变成双向事件流。

大公司为什么该回馈开源

有人问：怎么说服一个高管，雇人去维护连竞争对手都受益的开源？

David 的答案是从风险说起：「所有人都停止为这些项目做贡献的风险是什么？我觉得这是最大的风险」。他举了一个真实教训：

2020 年疫情期间，一个 node 包的作者失业了，向依赖他的社区请求资助，没人给钱，于是他给所有包下了毒、删光了代码。

而更深一层的理由是企业责任——你需要照好让你赚钱的东西，尤其 AI 时代供应链攻击会越来越普遍；

参与进去帮忙保障安全，送出去一些东西，换来的是业务尽可能无风险。

人脉也是回报：如果 BrowserStack 的产品在 Chrome 上出 bug,他可以直接找到 Chrome 的人请对方优先处理——互相反馈 bug,自己受益，其他人也受益。

测试哲学：每条关键路径一个扎实测试

David 的核心建议是：先写一个测试，从那里逐步扩展，理想情况下每条关键路径只有一个测试。

如果系统架构想清楚了，可观测性、遥测、日志这些保护层本来就在，一个「能登录并完成 X」的测试就足够覆盖关键路径。

反例是他见惯的「测试圣诞树/沙漏」：15 个大致做同样事情的测试，每个一分钟，平白等 15 分钟。要平衡的是三件事：速度、正确性、风险。

浏览器启动在算力上极其昂贵——如今浏览器本质上就是操作系统，「你每次都相当于在启动一台电脑，而且是一台电脑里再套一台电脑」——所以把端到端测试压缩到那 100 个真正重要的，是唯一划算的做法。

无障碍测试：别只盯着大棒

对无障碍测试，David 主张讲「胡萝卜」而不是「大棒」(诉讼合规是棒，好处是胡萝卜)。关键洞见：

很多无障碍功能本来就是生产力功能——IDE 里不碰鼠标完成所有操作、开车时手机读出短信并语音回复，这些都是围绕无障碍需求构建、然后惠及所有人的。

只要把「用户多快能到达他要去的地方」做好，无障碍就顺带解决了。

而且残障人群的消费能力和你我一样，放弃无障碍就是放弃那块市场——和他反驳「只测 Chrome 就行」是同一个逻辑。

规范层面，正在构建中的 Accessibility Test Driver(AT Driver)与 AxeCore 这类「读 DOM 推断问题」的工具不同：

它试图驱动屏幕阅读器、再由屏幕阅读器驱动浏览器，目标是让 Linux、Mac、Windows 上千差万别的屏幕阅读器有统一的标准方式，从而提升 Chrome、Firefox、Safari 之间的互操作性。

标准慢，反而是对的

被问到规范制定太慢的挫败感，David 的回答反直觉：「但这种慢反而让它变得正确。

因为如果你把事情做得太快，就会引发其他问题」。他举例：

浏览器间通信的一个规范已到第三个迭代，前两版快但错得多——Firefox 打不到 Chrome，连同浏览器之间都打不通；

第三版慢了很多，但更正确了。

而 Selenium 的竞争者 Playwright、Cypress 从未深度参与规范制定，这正是 WebDriver 试图弥补的方向：给浏览器加新功能，自动就能获得对应的 WebDriver 测试。

【背景】这里说的浏览器间通信规范，通常指 WebRTC（网页实时通信）。

AI 时代的测试会更重要

David 今年做过一个关于 vibe coding(只写提示词、凭感觉拿到代码)和 vibe testing 的演讲，他的警告很直接：

人们会「凭感觉把生产数据库搞垮」——Replit 出过事故后加了护栏，用户转用 Claude 又不给护栏，数据库照样被删。

他认为 AI 越普及化，糟糕的情况会越严重，因为大量安全知识是「你我从构建软件中获得的经验」：

C/C++ 里别在变量交给垃圾回收器后还去访问它、要检查身份验证、别把 API 密钥硬编码……

从没写过软件的人没有这些被反复灌输的直觉。所以他的建议是：初级工程师应该少用 AI,把它更多当作审查备份；

每个人都该有机会做原型，但原型进生产前必须重写或至少过安全检查。另一个铁律：「AI 会产生幻觉。

那不是可能会产生幻觉，它就是会产生幻觉」——只有回头审查过，你才分辨得出真假。

他自己在推进的方向是把可观测性接进测试：

OpenTelemetry(跨应用创建调用追踪的标准)已经存在八九年，但几乎没人把它放进测试里——如果一个测试从「访问网站」一路追踪穿过整个应用，失败时你就有完整的状态和入口数据，可以精确复现「那个人是怎么操作的」，而不是对着日志干瞪眼。

他强调不需要改任何规范，一切能力都是现成的，只是没人讲清楚怎么上手。

本集带走

• 测试从一/start:先写一个测试，然后每条关键路径只保留一个扎实测试；靠架构里的可观测性、遥测、日志兜住其余，而不是堆 15 个重复测试。
• 别造 DSL 式的流式 API:David 早年给自己公司构建了一个流式(fluent)DSL,调试时发现「到处都是点」，每层都要单步穿过去才能找到真问题——好看但难用，别犯。
• 用风险说服高管回馈开源：最大的风险是维护者断供后项目被「下毒」(2020 年 node 包作者删码事件)；企业责任之外，供应链安全在 AI 时代只会更重要。
• 把无障碍当生产力讲：Tab 键可达、语音交互这些无障碍功能同时就是效率功能，讲收益比讲合规诉讼有效得多。
• 慢的规范才正确：浏览器间通信规范前三版快而错、第三版慢而对；别指望标准化跟上工具的速度。
• AI 时代测试是护栏：AI 一定会幻觉，生产数据库被 vibe coding 删掉的事故会越来越多；初级工程师应少用 AI 以积累安全直觉，原型上线前必须重写或过安全检查。
• 把追踪接进测试：用 OpenTelemetry 的追踪键贯穿端到端测试，失败时能精确复现入口数据，不用再「不知道从哪开始查」。

问题就来了，人们会凭感觉把他们的生产数据库搞垮，然后就直接被扔掉了。
The problem then comes is that people will vibe their production database into the ground and like it just gets thrown away.
—— David Burns · [41:12]

我虽然喜欢 AI,但我觉得初级工程师应该少用它，把它更多当作一个备份来审查他们的东西，问一句，嘿，你有没有考虑过这个那个问题，对吧？
And I think while I like AI, I kind of feel like junior engineers should be using it a lot less, more of a backup to review their stuff and go, hey, did you think about this problem, that problem, right?
—— David Burns · [43:44]

那不是可能会产生幻觉，它就是会产生幻觉。
That’s not a maybe hallucinate, it will hallucinate.
—— David Burns · [45:21]

我就想，哇，流式 API 简直是最糟糕的，对吧？因为到处都是点。
And I was like, wow, Fluent APIs are literally the worst, right? Because everything’s a dot.
—— David Burns · [07:03]