浏览器测试现状 — Software Engineering Daily

综合解读

1. 01

   浏览器自动化标准化是多方协作的结果

   WebDriver 标准源于开源项目（如 Selenium）、浏览器厂商（如 Opera、Mozilla）和标准组织（如 W3C）之间的协作努力，其推动力来自现实世界的互操作性需求——例如 Opera 实现 Selenium——并受到手动浏览器测试低效且易出错这一问题的驱动。

   支持这项说法 1

   他说：“嗯，实现这一点的办法就是参与标准制定。”我说：“我们完全不知道那是什么意思。”

   David Burns · 11:26

   浏览器测试现状 — Software Engineering Daily · 2026年10月1日

   原始摘录

   And he was like, "Well, the way to do that is to get into standards." And I was like, "We have no idea what that means."

   上下文

   所以当我加入 Mozilla 时——我想那时我已经在 Selenium 上工作了大约四年，直到我们开始讨论标准。当时有一场很有意思的讨论。我在瑞士参加一个会议。对于年长一些的听众来说，以前有一个非常棒的会议叫 Google Test Automation Conference，即 GTAC。它曾在世界各地举办。 有一年，一位来自 Opera 的人来了。他说：“看看我做了什么。”他把 Selenium 做进了 Opera。我们当时觉得：“太棒了。我们认为每家拥有浏览器的公司都应该这么做。” 显然，我一直在做一些事情，我会阅读规范，看看它们与我的工作有什么关联。因为有时会出现“哦，我们要添加这个新功能”的情况，而这些功能通常来自某项规范，以便在不同浏览器之间实现互操作。我可能会帮别人围绕这些功能创建测试框架，以确保他们能够进行测试。但从来没有出现过类似“这里有一个标准，可以把测试框架构建进——”不是测试框架，而是把自动化框架构建进浏览器里的东西。于是我们开始做这件事。 那个人叫 Andreas Tolf Tolson，几个月后他加入了我的团队，我们开始编写规范以及所有相关内容。我与创建了 WebDriver 的 Simon Stewart 密切合作，推动这项标准的落地。当我们真正把它做起来的时候，他在 Facebook 工作。是的，我们最终意识到了它有多重要。因为当涉及到“how standar”……

   原始上下文

   So when I joined Mozilla - and I've been working on Selenium, I think, for about four years, by the time it became - we started talking about standards. And there was an interesting discussion. I was at a conference in Switzerland. So for the older listeners of this, there used to be a really cool conference called the Google Test Automation Conference, GTAC. And it used to be around the world. And one year, someone from Opera arrived. And he's like, "Look what I've built." And he had built Selenium into Opera. And we were like, "This is amazing. We think every company should be doing it that has a browser." Obviously, I've been doing a few things and I would read like specs and see how that related to my work. Because there'd be times where it's like, "Oh, we're adding this new feature," which normally came from a specification so that we could have interoperability between browsers. And I might help people create testing frameworks around that to make sure that they could test it. But there was never something that was like, "Here's a standard to build a testing framework into -" it was not a testing framework, an automation framework into the browser. And we started doing that. And it was a chap called Andreas Tolf Tolson, who then, about months after that, joined my team and we started building out the specification, everything like that. And I was working very closely with Simon Stewart, who created WebDriver, to get the standard going. He was at Facebook at the time once we got it really going. And yeah, we finally realized how important it was. Because when it came to how standar

   回到原文语境 →

   继续探索

   标准制定 →
2. 02

   WebDriver 有意不解决等待机制中的停机问题

   WebDriver 的规范刻意避免为等待元素定义通用解决方案——因为判断元素何时“就绪”可能会面临不可判定的停机问题——而是专注于对实用且可观察的行为（如可见性、可交互性）进行标准化，而不依赖像素级或布局相关的检查。

   支持这项说法 1

   有趣的问题随之而来，比如：你怎么知道某个元素确实在页面上？或者你需要等待多久？那里的问题归根结底是如何在不试图解决停机问题的前提下，对一种有意义的等待进行一定程度的标准化。

   David Burns · 14:19

   浏览器测试现状 — Software Engineering Daily · 2026年10月1日

   原始摘录

   The interesting problems came as like, when do you know that an element is actually on the page? Or how long do you have to wait? And the problem there comes down to somewhat standardizing a meaningful wait without trying to solve the halting problem.

   上下文

   所以一旦你有了制定规范的想法，我们所做的很多工作就是试图决定哪些可以标准化、哪些不能。对于 Selenium 或 WebDriver 来说，简单的事情是“我想输入文字”，或者“我想点击、想移动鼠标、想拖放”。这些看起来相对容易。 停机问题是著名的图灵问题，它是无法解决的，对吧？而自动化要弄清楚这一点极其困难。所以你并不是在试图解决那个问题。 另一个问题是，当你想要操作某个东西时，它是否可见？因为 WebDriver 刚起步时，Simon 就说：“当有人点击某个东西时，它必须是可见的。”但“可见”是什么意思呢？而且不能逐像素检查，因为可能会有覆盖层之类的东西，CSS 有 Z 轴索引，但它并不真的是 Z 轴索引，因为你可以通过 DOM 和 CSS 的布局方式让其他东西覆盖在上面，等等。这变得非常困难。 大量的精力就花在了这些地方，试图解决那些人们未必需要解决的稍难一些的问题。然后再创造一种方式，让人们能够通过其他标准、其他规范来扩展 WebDriver。这样无论他们在构建什么，都会说：“Oh, w”……

   原始上下文

   So once you've got the idea for a specification, a lot of the work that we did was trying to decide what we could standardize and what we couldn't. For Selenium, the easy things were, "I want to type," or WebDriver. I want to type, I want to click, I want to move the mouse, I want to drag, drop. Those seemed relatively easy. The halting problem, famous Turing problem, and it's impossible to solve, right? And automation becomes so hard to figure that out. And so you're not trying to solve that one. The other one was, is something visible when you want to do it? Because when WebDriver started, Simon was like, "When someone clicks on something, it needs to be visible." What does visible mean, right? And without doing pixel by pixel checks, because you can have overlays and things like that and CSS, has a Z index, but it's not really a Z index because you can have other things that can overlay just by the way you lay out the DOM and the CSS and things like that. And it becomes very hard. And that's where a lot of the effort went into, was trying to solve these slightly harder problems that people didn't need to necessarily solve. And then create a way that people could extend out WebDriver through other standards, through other specifications. So that whenever they were building something, they go, "Oh, w

   回到原文语境 →

   继续探索

   测试自动化设计 →
3. 03

   规范制定缓慢有助于保证正确性

   Web 规范开发进展缓慢是一种有意为之的权衡，目的是确保正确性。例如，某浏览器消息传递规范的第三次迭代推进得更慢，但互操作性问题（如 Firefox 与 Chrome 之间的通话失败）比早期版本更少，这印证了这一点。

   支持这项说法 1

   第三次迭代的进展要慢得多，但更加正确。因为前两次迭代引发了太多不同的问题，比如“哦，你没法发起通话，比如说从 Firefox 到 Firefox，或者从 Chrome 到 Chrome，但你永远无法从 Firefox 打到 Chrome”。

   David Burns · 35:45

   浏览器测试现状 — Software Engineering Daily · 2026年10月1日

   原始摘录

   And the third iteration is going a lot slower, but it's being more correct. Because the first two iterations, it just caused so many different problems between like, "Oh, you couldn't make a call from like, say, Firefox to Firefox or Chrome to Chrome, but you can never do Firefox to Chrome."

   上下文

   “tration”……我想很多听众都会遇到这种情况：每当某样东西要走规范流程时，实际完成规范化实在太慢了，对吧？我刚入行时，JavaScript 在不同浏览器之间简直是一团糟。你需要做各种各样的处理，要在回调地狱里摸索着熬过去。 后来 ECMAScript 的很多标准化工作出现了。大家觉得：“哦，这真酷。”我们开始着手这方面的工作，然后他们开始创建可以全面运行的测试套件。但这种缓慢让它变得正确。因为如果你做得太快，就会引发其他问题。我们在规范领域已经看到了这一点。 有一项规范，我现在一时想不起名字了，是用来让人们在浏览器之间发送消息的。所以如果你想通过浏览器打电话之类的事情，就要用它。它现在已经是第三次迭代了。 而这引发了一些问题。因此把事情做对就变得非常重要。 WebDriver 规范也是一样的，对吧？市面上有一些与 Selenium 竞争的工具，比如 Playwright 或 Cypress，它们从未真正深入参与过规范部分。但我们在做这些事情时，努力让它做到“哦，你总是可以扩展它”，然后当你说“哦，我们要给浏览器加这个功能”时，就会自动获得一项 WebDriver 测试。这样你就能知道从不同浏览器得到的是什么，这在移动端领域变得更加重要，因为像 Android 上的 Chrome、iOS 上的 Safari，你需要考虑这些东西在此过程中如何相互交互，尽可能让人们从中获益。

   原始上下文

   tration that I think a lot of your listeners will have is that whenever something's going through a specification, it's so slow to actually get specified, right? When I started work, JavaScript was just a mess across the board between different browsers. And you needed to do all these different things, and you would figure it out through callback hell, and you would go through it. And then a lot of the ECMAScript standardization came in. It was like, "Oh, this is really cool." We started working on this, and then they started creating test suites that you could run through everything. But the slowness made it correct. Because if you make things fast, you cause other problems. And we've seen that in the spec world. There was a specification, I can't think of the name of it at the moment, which is used for people to send messages between browsers. So if you want to make a phone call or things like that through a browser, you would do it through this. And it's on its third iteration. And that caused problems. And so that's where it becomes really important to get that correct. It's the same with the web driver specification, right? There are competing tools out there to Selenium, like Playwright or Cypress, and they were never really - that involved in the specification part. But when we've been working on things, we're trying to make it that, "Oh, you can always extend it out," and then go, "Oh, we're going to add this feature to the browser," automatically gets a web driver test. And so you can know that whatever you get from different browsers, and it becomes really important in the mobile space a lot more, because like Chrome on Android, Safari on iOS, you need to think about how those things interact with each other along the way and get the best out for people.

   回到原文语境 →

   继续探索

   Web 标准制定 →
4. 04

   AI 的快速普及可能带来安全问题

   David Burns 表示自己喜欢 AI，但担心 AI 开放得太快，安全问题往往会随之出现。他澄清说，自己并不是主张不让人们使用 AI。

   支持这项说法 1

   我确实很喜欢 AI。我只是觉得它向所有人普及得太快了。并不是说大家不该拥有它，而是往往会冒出很多安全问题。

   David Burns · 38:09

   浏览器测试现状 — Software Engineering Daily · 2026年10月1日

   原始摘录

   I really do like AI. I just think it's being democratized too quickly to everyone. And not that they shouldn't have it, but it's like there's a lot of security problems that then tend to kind of crop up.

   上下文

   “wn away.”……我们看到了无数报道，而且我觉得情况并没有真正好转。去年我们看到了关于 Replit 之类的报道，他们随后在其中加入了防护和安全措施。然后人们就说：“哦，我不再需要 Replit 了。我就用 Claude。”接着有人输入了某些内容，没有给它设置防护栏。结果就是：“哦，我的生产数据库现在被删了。真好。” 所以我认为 AI 领域是有帮助的。但同时我认为，我们仍然需要懂得 AI 在生成什么的人，来为它设置防护栏、修正它、解决这些问题。因为在你我交谈时，有很多背景信息是我们的生活经验会附加到我所说的话里的。而 AI 不一定具备这种东西。但它在做快速原型或转换方面也非常出色，这些都很重要。比如把数据从一个地方移到另一个地方，你可以说：“哦，就这么做。真酷。” 而且……

   原始上下文

   wn away. We've seen numerous stories and it's not actually getting any better, I think. We saw stories about like Replit and things like that last year, who then have putting guards and saves things into that. And then people were like, "Oh, I don't need Replit anymore. I'll just use Claude." And then someone put in something, didn't give it guardrails. And it's like, "Oh, my production database is now deleted. Great." And so I think the AI space is helpful. But I think at the same time, we still need people who understand what AI is generating to be able to give it the guardrails, fix it, solve those problems. Because there's a lot of context that when you and I are talking, that our lived experience will be adding to whatever I'm saying. And AI doesn't necessarily have that kind of thing. But it's also really good at doing quick prototypes or transformations that are really important. So moving data from one place to another, you can go, "Oh, just do this. It's really cool." And

   回到原文语境 →

   继续探索

   软件开发中的 AI →
5. 05

   在浏览器测试中加入可观测性追踪

   将基于 OpenTelemetry 的可观测性追踪集成到端到端浏览器测试中，从测试启动一直追踪到应用执行，能让故障调试更深入：工程师可以回放并分析完整的请求路径，而不必只依赖日志或孤立的错误信号。

   支持这项说法 1

   如果你能把它加到组件测试或浏览器测试中呢，对吧？或者加到移动端测试中，然后一路贯穿下去。这会创造出一些非常有意思的构建方式。

   David Burns · 44:15

   浏览器测试现状 — Software Engineering Daily · 2026年10月1日

   原始摘录

   What if you could add it to a component test or a browser test, right? Or a mobile test and you go all the way through. And then that creates some really interesting ways of creating.

   上下文

   是的，正是如此。因为可观测性让你能够创建追踪，对吧？所以如果你说：“这是我的追踪键，我希望你全程使用它”，其中一些东西就会在你的开发和传递过程中被捕获。今年年底我有一系列演讲即将发布，会在其中展示我正在做的一些工作。我认为这里面有一些非常重要的东西。因为多年来，很多人只专注于看日志。而你必须知道它对应的是哪个连接，对吧？但当 OpenTelemetry 出现、人们开始构建它之后，你总可以说：“哦，我能看到它经过了这里。”但你从来不知道它究竟是怎么开始的。你只是看到数据进入系统。 因为这样一来，如果你看到一个失败，你会说：“哦，我有这些数据。让我看看能不能复现它，看看它是怎么进来的。”如果你用同样的数据填写表单，而那一次成功了，你就会说：“哦，好吧，也许有人是用另一种方式操作的。”现在你就可以试着弄清楚那个人是怎么做的，而不是说：“我不知道该怎么开始。让我研究一下。”然后白白花时间。所以关键在于尝试把其中一些信息前置到你的测试中，然后一路跟踪到底。

   原始上下文

   Yes, exactly that. Because observability allows you to create traces, right? And so if you go, "Here's my trace key, and I want you to use it all the way through," some of those things get picked up in how you develop and pass things through. So I've got a whole bunch of talks coming out towards the end of this year where I'm showcasing some of the work that I'm doing. And I think it's got some really important things. Because for years, a lot of people would just focus on reading logs. And you have to know what connection that has, right? But you could always then - when OpenTelemetry came out and people were building it, you could go, "Oh, I could see it go through here." But you never knew exactly how it started. You just saw the data coming into the system. Because then if you see a failure and you go, "Oh, I have this data. Let's see if I can replicate it, how it came in." And if you fill in the form with the same data and it worked that time, you go, "Oh, okay, maybe someone's doing it in a different way." And now you can try to figure out how that person was doing it rather than going, "I don't know how to start this. Let me figure it out." And then kind of spending time. So it's about trying to front load some of that information into your test and then following it all the way through.

   回到原文语境 →

   继续探索

   测试可观测性 →