WPT是综合网络测试套件，旨在确保浏览器互操作性，起源于兼容性问题。它促进了浏览器厂商协作，成为网络标准和开发的关键，提升了网络平台的健壮性。
译自：How a Shared Test Suite Fixed the Web’s Biggest Problems
作者：Mary Branscombe
它在网络标准和浏览器开发中扮演着关键角色，从微不足道的开端发展而来，依赖于数量惊人的一小部分人，由主要的浏览器公司共同资助。尽管甚至政府都关心浏览器的竞争力以及它所支撑的兼容性，但它却不广为人知。
如今，Web Platform Tests（简称WPT）是针对网络平台的综合测试套件，有助于确保浏览器之间的互操作性；这正是你期望从一个由规范和多个竞争性实现驱动、每天有30亿人使用的平台所得到的。可以把WPT看作是网络互操作性的引擎。
Ecma主席Daniel Ehrenberg告诉The New Stack：“Web Platform Tests对于任何实现浏览器的人来说都至关重要，这样他们才能确保兼容性。”“有时人们阅读同一份规范可能会有不同的理解，Web Platform Tests确保了实际、具体地发布相同的行为。”
然而，事情并非总是如此……
“Web Platform Tests确保了实际、具体地发布相同的行为。”
——Daniel Ehrenberg，Ecma主席
Igalia的开发者倡导者Brian Kardell指出：“在网络标准存在的半个时间里，都没有测试。”各个浏览器运行自己的测试套件，但“从Tim Berners-Lee说‘这是我想要做的事情的论文’到现在，我们走到了历史的一半，Web Platform Tests才成为现实。”
网络的复杂性和规模意味着这成为了一个日益严重的问题。
前Boucoup首席执行官Boaz Sender告诉我们：“网络平台是世界上最大的软件平台；它的表面积如此之大，以至于尝试外部测试网络平台是行不通的。”
W3C技术战略副总裁Philippe Le Hégaret补充说：“WPT源于网络无法正常运行的挫败感，我们必须为此做些事情。”
在此过程中，WPT也改变了构建浏览器的文化——从思考他们正在编写的软件，转变为思考如何使开发者所依赖的网络平台具有互操作性，从而实现共赢。
“WPT源于网络无法正常运行的挫败感，我们必须为此做些事情。”
——Philippe Le Hégaret，W3C技术战略副总裁
微软Edge浏览器高级产品经理兼W3C WebDX社区组联合主席Patrick Brosset解释说：“WPT的目标过去是，现在仍然是，作为一个涵盖基于标准的网络平台及其所有实现的综合测试套件。”
“核心思想是将开放网络平台视为一个实体，一个组合的软件项目，网络开发者在此基础上构建他们的产品。正因为如此，我们需要平台健壮且具有互操作性，这需要彻底的测试。”
从浏览器特定测试到统一网络平台
网络是如何在没有通用测试的情况下走得这么远的呢？前HTML规范编辑Robin Berjon承认：“我们之所以能做到，是因为它常常带来糟糕的开发者体验。”
事实上，Berjon指出，早期的W3C并没有被参与其中的人视为一个标准组织；“它更像是‘嘿，让我们聚在一起，就我们想要的功能达成一致’，然后功能就实现了，因为人们只是在实现它们。”
由于W3C规范长期以来要求在批准之前有多个实现，任何没有实际构建浏览器的人可能都认为这总是包括测试。
Google网络平台团队总监Rick Byers指出：“如果你问日常工程功能的浏览器工程师，他们会说情况并非如此；通常这些事情发生在功能已经在浏览器中发布之后。”“而到了那时，说实话，已经太晚了。”
在WPT出现之前，Berjon和Le Hégaret都在处理HTML5规范，他们担心如果没有更好的测试，它将无法实现互操作性。Le Hégaret说：“网络并没有按照我们想要的方式运行。”“我感到沮丧的一部分是复杂性显著增加，我们甚至不知道如何测试这些东西。”2010年，他警告HTML5尚未准备就绪，因为它不具备互操作性。
“……电视行业找到我们说，‘我们需要弄清楚如何进行测试，因为这是我们为电视所做的事情——你们的网页测试在哪里？’”
——Le Hégaret
这阻碍了对采用HTML感兴趣但习惯于进行大量测试的手机和电视制造商。Le Hégaret说：“智能电视正在考虑部署HTML作为其平台，电视行业找到我们说，‘我们需要弄清楚如何进行测试，因为这是我们为电视所做的事情——你们的网页测试在哪里？’我们看着他们，就像他们来自另一个星球。”
并非没有人做任何测试；而是测试不全面或不一致。Google网络平台团队的软件工程师Philip Jägenstedt指出：“网络一直都有测试。”“实现功能的浏览器工程师会编写测试，有时他们可能会与其他浏览器引擎共享这些测试。”
以ECMAScript测试项目Test262为例（它有自己的维护者、基础设施以及与项目的集成）：它是JavaScript新功能开发的关键部分，提案必须等到有完整的测试套件才能推进（最近引入的ECMAScript 2.7阶段专门用于使编写测试成为一个更有效、更轻松的过程）。这大约始于2010年——当时Google和微软将其内部的ECMAScript测试贡献给了TC39。
Kardell同意：“每个引擎都有测试。”“但他们都只是做自己的事情，你不知道他们的测试是什么样的：它们是否足够好，是否与LFS上其他浏览器的测试测试相同的东西。”
Mozilla网络兼容性工程师James Graham解释说：“他们基本上专注于‘我们如何才能不再出现回归’的问题。”Graham曾在Opera公司从事自动化测试套件的工作。“而且这些测试非常特定于那个浏览器。”另一位在Opera测试套件工作过的Mozilla工程师Simon Pieters补充说，复制另一个浏览器的测试变成了“维护噩梦”。
在21世纪初，新的规范成为W3C推荐标准的过程开始要求提供一个测试套件，展示两个独立的实现；Berjon回忆说，这标志着网络的重要性。但如果流程要求没有伴随文化变革，它们很容易被视为烦人的官僚主义。Byers指出：“过去你会做所有规范工作，然后当你试图获得推荐印章时，你会做额外的工作来证明你有测试套件。”
“整个SVG大概只有200个测试，这太荒谬了！甚至不足以测试形状或颜色。”
——Robin Berjon，前HTML规范编辑
将其视为额外工作并不一定会带来全面的测试。W3C会议会留出一天时间专门用于测试工作，但Berjon回忆说，那天的“互操作日”可能只为一个包含数百页的规范产出少数几个测试。“整个SVG大概只有200个测试，这太荒谬了！甚至不足以测试形状或颜色。”
Berjon继续说道：“这些事情现在看来很疯狂。”“当时我们知道这并不完美——但也没有被认为是糟糕透顶。网络仍然成功，人们仍然发布东西。但问题在于它造成的问题累积起来了。”
同样，一些浏览器将其部分测试贡献给W3C工作组，为HTML、DOM和CSS构建测试套件——但这些套件包含的测试数量非常有限，存储在不同的测试仓库中，仅供W3C自身检查规范的初始实现是否符合要求，通常只运行一次——并且在规范批准后（即使后来发生变化）通常会被遗忘。
Le Hégaret告诉我们：“它们只是为了检查，是的，你可以实现一个规范。它们从来不是为了确保网络也能正常运行。”
当WHATWG带着将HTML作为不断演进的“活标准”的概念出现时，一些僵化的测试并不适合支持这一点。
Pieters指出：“如果另一个浏览器改变了API的行为，或者实现了一个新的API，或者规范发生了变化：当时，并没有针对规范变更提交浏览器bug的政策，也没有在你改变自己的实现时，向其他浏览器供应商提交bug的文化。”“一些其他浏览器改变了，或者规范改变了，其他浏览器也随之改变，但一个浏览器没有注意到。它们没有收到任何bug报告，只有当网站开始出现问题时，它们才会注意到，然后需要调查和逆向工程来弄清楚发生了什么。”
Graham指出，工作组的测试套件也没有自动化。CSS 2测试套件需要两天时间才能运行，因为“它需要像我这样的人坐着观察，并判断它们是通过还是失败。”它们是为内部规范目的设计的，对于互操作性来说效果不佳：“它们不会发现边缘情况，也不会发现那些让作者网站崩溃的问题。”
“我们有浏览器特定的测试，这些测试质量很高，但只针对特定的浏览器。”
——James Graham，Mozilla网络兼容性工程师
独立的ACID测试是尝试进行更全面测试的努力，但它也有自己的问题。加载包含多种功能以测试浏览器对标准实现的网页，导致浏览器过于专注于通过测试和修复降低分数的bug。但到了ACID 3，浏览器制造商开始质疑测试中包含哪些功能的选择，并且对ACID分数的强调意味着一些浏览器只是实现了足够的功能以通过测试，“但在你试图以任何其他方式使用它时，基本上都是坏的，”Graham说。
Graham继续说：“Web Platform Tests是对所有这些事情的回应。”“我们有浏览器特定的测试，这些测试质量很高，但特定于某个浏览器。我们有共享测试，它们难以运行且不够深入；我们有ACID测试，它们深入但变成了营销活动。WPT早期的目标是，让我们尝试构建一个真正以工程为重点的共享测试套件，我们将所有测试收集在一起，并使它们能够在浏览器供应商之间共享，这样工程师们就有动力说‘我的实现有一个bug，我应该修复它’——而不是为了营销或推进标准。”
WPT的独立起源和影响力
当Le Hégaret和Facebook当时的网页标准负责人Tobie Langel为开放网络平台测试项目起草了一个可能的预算，并向W3C成员寻求支持时，应者寥寥；只有几家组织提供了资金，而且更像是20万美元，而不是官方项目所需的700万美元中的一份。当时，Le Hégaret估计每个单独的测试将花费100美元来编写和验证。
他回忆说，自2009年以来，他一直致力于推动更好的测试方法，“我感觉自己像个坏掉的唱片。”
Adobe资助了Test the Web Forward活动，这些活动是旨在为多个浏览器引擎贡献测试的黑客马拉松。Berjon认为，它不一定产生了大量有用的测试，但确实有助于提高认识。“我认为它有助于扩大社区，因为它赋予了项目合法性。”
甚至工作组主席也不总是支持通用测试的想法，有时将其视为完成规范的干扰。尽管WPT始于W3C内部，但在2014年，WPT成为了一个独立项目（得到Facebook的一些资助）——一个只有少数人参与的非常草根的项目。
“当时其他浏览器供应商没有——在某种程度上，现在仍然没有——像Opera那样独立的测试团队。”
——Mike Smith，W3C
事实上，Berjon解释说，WPT测试集合的形成只是通过将现有测试收集到一个地方，并将之前HTML测试套件仓库重命名为Web Platform Tests。“我以最简单的方式开始转移内容。我列出了CVS、Mercurial、其他Git仓库以及人们通过电子邮件发送的ZIP文件中的所有测试的巨大清单，然后我开始导入所有内容，如果可能的话，包括历史记录，然后我对它们进行了最脏的搜索和替换，使它们与相同的测试工具一起工作——然后我们就有了东西。”
Le Hégaret说，这个测试工具是Graham在Opera自动化工作的一部分。“James Graham编写了一个简短的JavaScript库，以便更容易地编写测试，我们借用了它。”
W3C的Mike Smith补充说：“当时其他浏览器供应商没有——在某种程度上，现在仍然没有——像Opera那样独立的测试团队。”
他与Berjon一起完成了导入工作，Berjon将这些微不足道的开端描述为“固执”，但足以开始测试。“我们开始测试那个东西。它几乎使所有浏览器都崩溃了，因为浏览器不喜欢被如此严格地测试！从那时起，我们才真正有了一个项目。”他们的工作慢慢吸引了其他人贡献或审查测试。“我们开始获得动力。”
WPT的核心团队人数很少，并且积累测试数量需要时间。尽管CSS对网络很重要，但由于CSS测试的工作方式存在一些限制，与WPT方法冲突，因此最初并未包含在WPT中。
Pieters解释说：“我们希望将激励结构设计成面向互操作性，并尽可能降低贡献测试套件的门槛，这样浏览器工程师就会在WPT中编写测试，而不是做简单的事情，即继续编写内部测试。”“CSS测试套件对测试有很多要求，这使得浏览器工程师有意义地贡献到该测试套件的门槛太高了。”
将他们的测试纳入标准测试套件的开销超出了贡献它们的价值：WPT旨在让正确的事情变得更容易。
“WPT是标准中如此重要的一部分，以至于它是一个独立的实体。它以自己的工作模式、自己的流程和自己的成员资格独立运作。”
——Boaz Sender，Boucoup首席执行官
最终，CSS测试套件被集成到WPT主仓库中，尽管不同的工作组——例如CSS工作组——仍然有自己与WPT集成的流程。到2017年，WebKit和Edge也开始参与进来。
具有讽刺意味的是，未能筹集资金使WPT成为W3C的正式组成部分，可能因为它独立性而赋予了它更大的影响力（即使这种影响力在技术上是非正式的，更多地与共识而非任何明确的权力有关）。
Le Hégaret解释说：“我坚信权力平衡，所以我希望这个项目是独立的。”“我希望测试人员能够挑战任何W3C工作组。”
Le Hégaret说：“W3C为网络制定标准，这赋予了W3C对网络一定程度的权力，尽管我们的标准是自愿的。”“浏览器供应商本身也对网络拥有权力，因为他们实现了浏览器——如果你的浏览器没有实现某个东西，那它就不是网络的一部分。”
规范、实现和像MDN这样的文档都是基础性的。Le Hégaret补充说：“如果你没有面向开发者的文档，那么使用这项技术本身就不那么容易。我希望测试成为另一个支柱。”
Sender同意：“WPT是标准中如此重要的一部分，以至于它是一个独立的实体。”“它以自己的工作模式、自己的流程和自己的成员资格独立运作。”
他建议：“测试是一种同行评审。”或者，Fermyon联合创始人Matt Butcher（他在Bytecode Alliance从事Wasm标准工作）这样说：“标准用文字写出来很好，用文字和代码写出来更好。”
促进浏览器厂商间的协作文化
当Google（有点姗姗来迟地）在2016年将WPT作为Chrome工程流程的关键部分时，它源于同样的认识，即开发者对网络不一致的持续沮丧可以追溯到软件开发基础。“软件工程的第一步是你应该有一个连贯的测试套件，”Byers回忆道。“开发者所依赖的我们的主要产品甚至没有一个可靠的测试套件：我们作为工程师没有尽到我们的职责。”
Jägenstedt指出，测试已经存在多年：“问题在于我们不太关心它。”
决定Chromium未来的所有工作都需要附带所有浏览器都可以用于互操作性的符合性测试，这是为了改变Chromium项目的文化，就像它在工作组中开始改变一样，工作组最初曾反对共享测试的重要性。
“开发者所依赖的我们的主要产品甚至没有一个可靠的测试套件：我们作为工程师没有尽到我们的职责。”
——Rick Byers，Google网络平台团队总监
Jägenstedt指出：“这并不是从不关心测试到突然编写测试的转变；而是做了大量工作，真正让这些流程运作起来，让一个浏览器供应商可以编写测试，并让这些测试显示给另一个浏览器供应商，并拥有一个共享的仪表盘，我们可以在上面看到结果。”
这也为项目带来了Google的影响力（和资金）。Chrome团队资助Bocoup帮助Chromium工程师将他们编写的测试贡献给WPT，以便它们能够像那样显示出来。Apple和Mozilla在此基础上实现了自己的同步，微软也向他们支付了费用，在它转向Chromium时，将内部的Edge测试（包括用于测试Trident Edge的WPT分支）迁移过来。Google还与Bocoup合作，构建了基础设施，以便为每个新的浏览器版本自动运行WPT测试。这些结果就是你现在在WPT仪表盘上看到的。
在此过程中，Berjon告诉我们，WPT也帮助W3C和WHATWG（最初采取相当敌对的方法）学会更好地相互合作。
“所有这些人基本上都有相同的目标；他们正在处理一些不同的交付物，但重叠的部分远大于差异。我当时想，如果我们能让一群人致力于他们都关心的事情，我们就可以放心地说这是合作成果，那么我们就会有一些有助于修复社区的东西。”
这奏效了；事实上，WHATWG活标准现在不仅要求WPT测试，而且Smith指出，“你甚至无法合并拉取请求，直到你编写了测试并将它们提交到WPT。”
WPT结果如何推动互操作性倡议
WPT之所以如此不为人知的一个原因可能在于，尽管它在GitHub上，你也可以从你选择的浏览器中尝试这些测试（尤其对于像Ladybird这样的小项目很有用），但它主要在幕后使用。浏览器制造商将他们自己的WPT测试部署集成到他们自己的CI/CD系统中（导入测试副本并将结果导出回WPT，以及同步他们编写的新测试）。例如，在Chrome中发布新功能之前，相关的测试必须集成到WPT并通过——你可以在WPT仪表盘上查看最新公共测试分数的存档。
Smith建议，浏览器工程师可能会使用WPT结果，根据其他浏览器对功能的支持程度来优先考虑更具互操作性的功能。“如果你查看WPT结果，看到一片红色中有一列绿色，也许那不是我想要实现的功能。”
大多数不构建浏览器或服务器端运行时的人会明确接触WPT的地方是年度Interop倡议，该倡议提出了一系列优先事项，旨在改善WPT分数显示互操作性不尽如人意的领域中的浏览器兼容性。
WPT上各个浏览器的分数并不能完美地反映整个网络平台的状态，因为重要的不是这些单独分数有多高（因为它们衡量的是不同的测试和子测试组合），而是所有浏览器通过了多少测试，这样开发者才能依赖这些功能在每个浏览器中都能正常工作。
“如果你查看WPT结果，看到一片红色中有一列绿色，也许那不是我想要实现的功能。”
——Mike Smith，W3C
WPT仪表盘确实允许你探索，例如Chrome和Firefox是否比Safari通过了更多测试，Firefox中是否存在Chrome和Safari都未能通过测试的功能，或者Chrome是否通过了非Chromium浏览器都没有通过的测试（这可以让你了解Chrome是否可能发展过快，或者开发者对Safari互操作性问题的抱怨是否有原因）。
Meyer指出：“Google资金充足，能够对事物进行测试实现；当需要实现时，他们通常是第一个实施的。”
但原始的WPT数字可能包括仍在开发中的功能的测试，以及后来被弃用的提案，例如事实证明存在隐私问题的环境光传感器。某个特定浏览器失败的测试数量，或者某些测试甚至与所有浏览器都不相关的事实，不一定表明该浏览器在网络标准方面落后。在去年某个时候，Safari失败的测试最多，但Firefox失败的子测试最多——这使得使用分数进行比较的帮助性更低。
Graham指出，这与ACID测试始终是一个刻意的区别。“我们并没有假设准备就绪意味着每个测试都达到100%通过率。也许其中一些测试是关于你根本不发布的其他功能之间的交互。也许它们是极端的边缘情况。”
这些测试也不总是正确的。WPT是像Ladybird（Smith也为其做贡献）这样的新浏览器的资源：“在iPhone上获得许可的要求是你必须通过90%的WPT测试，”他指出——但他补充说有时WPT和规范并不一致。
“有些情况下，你会发现你无法严格按照规范所说的那样实现，同时也能通过WPT测试，因为有些WPT测试不是按照规范要求编写的，而是按照现有实现的行为编写的。”Ladybird的实现是为了与WPT匹配以实现互操作性，但也会提出规范问题——而该规范实际上可能是为了记录现有浏览器实现而编写，但没有更新。
Meyer同意：“功能的首次实现将包括工程师所考虑的测试，这些测试将成为规范的一部分，但后续实现可能会发现测试和规范不完全匹配的问题。”
“在WPT早期，我们不得不做一些巧妙的周旋，以安抚浏览器供应商，我们并不是要指责他们没有正确实现标准，而是要给他们一个工具来改进他们的实现。”
——Le Hégaret，W3C
WPT从来都不是为了对浏览器进行排名：它是为了帮助它们全部改进——这也是Interop的目的。Le Hégaret说：“在WPT的早期，我们不得不做一些巧妙的周旋，以安抚浏览器供应商，我们并不是要指责他们没有正确实现标准，而是要给他们一个工具来改进他们的实现。”
这就是为什么Sender提出的Interop分数来取代通过/失败率是一种更有用的比较。首先，它们涵盖了所有主要浏览器都认为足够重要以投入精力通过的WPT子集，因为这改善了功能的互操作性。它还剔除了可能对开发者有趣（例如用于连接设备的WebSerial和WebBluetooth）但尚未成为公认网络标准的实验性功能的测试。
Sender指出：“Interop分数是一个很好的解决方案，因为它每年都可以发展，而且它也不会让人们相互竞争；因为为了使其运作，公司需要合作。”“Safari和Chrome之间不具备互操作性的问题是基于技术、隐私或硬件集成方面的战略决策。存在竞争，但标准实现不是他们竞争的领域。”
Topal也同意：“显然，每个供应商都有自己的战略和思考，关于什么对他们及其客户和用户是重要的。”“但有一点也很清楚，那就是只有一个开发者受众，所以当他们遇到问题时，基本上这就是所有供应商的根本真相。”
Ehrenberg表示，Interop和WPT推动了所有人向前发展。“所有人一致认为，我们专注于遵守这套测试，确实有助于为网络用户建立一个稳定的基础，这样一旦完成，它将进入Newly Available Baseline，然后是完整的Baseline。这为网络开发者提供了一个非常好的管道，可以可靠地获得新功能，因为我们知道，如果功能只在某些浏览器中可用，或者虽然可用但在某些地方出现故障，那么人们就会避开它们。如果它们没有广泛实现并且没有正确实现，就不会得到那么多采用，也不会提供那么多价值。”
“……我们知道，如果功能只在某些浏览器中可用，或者虽然可用但在某些地方出现故障，那么人们就会避开它们。”
——Ehrenberg，Ecma
Google网络平台产品经理Kadir Topal表示，WPT是Interop的基础；“我们需要确保我们对功能有良好的测试覆盖，Interop仪表盘为我们提供了仪表盘上功能的良好状态视图。”Brosset补充说，这有助于开发者“了解浏览器中给定功能的实现水平”。
尽管Interop解决的领域来源于开发者在年度HTML、CSS和JavaScript状态调查（由Web DX社区组运行）中抱怨的问题或作为互操作性bug提交的问题，但它依赖并改进了WPT测试。
Interop仪表盘分数显示了每个浏览器在每个重点领域WPT测试中的表现如何，但解决一个重点领域的部分工作是检查WPT是否包含正确的测试，有时还会改进或扩展它们。没有测试的功能不能成为Interop的一部分，因为正如Meyer指出的，“如果我们没有测试或规范的清晰度来知道我们应该做什么，我们又如何评估互操作性呢？”
WPT测试结果反馈给Web Platform Status等工具，该工具显示了Web平台功能在不同浏览器上的状态——包括浏览器支持、基线状态和WPT结果。虽然WPT和Interop网站清晰地显示结果，但它们没有提供太多关于被测功能的信息；Web Status背后的想法是填补这一空白，Topal解释道。
“我们已将整个网络平台映射到诸如popover和promise.try等独立功能，总共有1000多个网络功能。我们现在正在将Web平台测试映射到这些功能，以便你像在Interop仪表盘上一样获得清晰的信息，但涵盖整个平台。”
Jägenstedt补充说：“我们希望这能帮助网络平台的维护者看到差距在哪里。”“如果你正在实现视图过渡并希望它稳固，你该怎么做？过去没有任何脚手架，现在情况很清楚：这是锚点定位的测试，你通过了92%。”
微软还在其根据自身经验和开发者反馈编写的顶级开发者需求列表中使用了WPT测试分数。WPT结果没有出现在其他网络功能仪表盘，如CanIWebView或MDN文档中，但WebDX Web Platform Features Explorer中的页面链接到每个功能的WPT结果，以及使用统计和原始规范等其他详细信息。
支撑WPT的技术基础设施
WPT在当前关于浏览器所有权、资金和竞争格局的辩论中尚未受到太多关注，但Kardell指出“支撑网络的资金主要来自Google搜索”，他将其描述为“一个承重型垄断企业”。这包括WPT的部分基础设施；它还使用Mozilla（本身大部分由Google资助）和微软捐赠的服务来运行测试，尽管苹果公司在内部（由于许可复杂性）在macOS上运行Safari测试。
WPT的核心人员也在浏览器制造商和W3C工作，W3C由会员组织资助。
“……支撑网络的资金主要来自Google搜索”[而且它是一个]“承重型垄断企业”。
——Brian Kardell，Igalia
这既是实用主义，也是利他主义。Smith指出：“WPT代表了价值数百万美元的工作和基础设施，通过提供共享测试框架，为浏览器供应商节省了大量资源。”“我们很幸运，Mozilla、Google和Apple随着时间的推移真正理解了为这项工作付费的重要性。”
测试本身是HTML、JavaScript和CSS。“最简单的测试是你创建一个在屏幕上绘制盒子的网页，然后创建另一个网页，用不同的功能集在屏幕上绘制一些盒子。它们匹配吗？”Kardell解释道。
测试使用WebDriver进行JavaScript无法完成的浏览器自动化：“拥有这种跨浏览器的方式来完成浏览器内部无法完成的事情非常重要，”Graham说，因为它也是摆脱内部浏览器测试的另一个动力。
WPT的核心测试工具是用Python编写的，最初用于本地运行测试，它使用Python内置的基本HTTP服务器。当浏览器制造商将其作为CI管道的一部分运行时，这在性能方面存在一些限制，尤其是随着WPT中测试数量的增长。
Jägenstedt指出：“这听起来可能不难，但要让它可靠地工作实际上相当困难。”
Smith指出：“[WPT]就像网络一样；它以这种方式成长、演变，现在要回去替换和重写所有内容将非常困难。”
Interop每年调查的领域通常是关于如何向WPT添加测试以覆盖更多领域，这可能像编写新测试（或改进现有测试，如果它们被证明不准确）一样简单，但通常涉及研究浏览器自动化可能实现的功能，这反过来可能意味着向WebDriver添加新选项。
“[WPT]就像网络一样；它以这种方式成长、演变，现在要回去替换和重写所有内容将非常困难。”
——Smith，W3C
Test262仍然独立于WPT。显然存在一些重叠——因为每个浏览器都有一个JavaScript引擎——但尽管WPT项目和Test262团队讨论过是否应该更紧密地整合它们，但也存在明显的差异：例如，Node.js、Deno和Bun等服务器端JavaScript运行时通常与浏览器的行为不同，因为它们做的事情不同。此外，JavaScript规范要求的行为与HTML规范要求的行为并非完全相同（这就是为什么导入JSON模块同时出现在Interop 2025和ECMAScript 2025中）。
Node.js技术指导委员会成员Joyee Cheung指出了其中的细微差别：“你希望能够与为其他环境编写的代码互操作，而测试是验证这一点的一种方式，但我们用于运行测试的工具实际上可能会在互操作性中产生不同的行为。”
此类JavaScript功能在Interop中很少见，目前尚不清楚这是因为TC39已经处理了这些问题，还是一个先有鸡还是先有蛋的问题。Interop分数只能针对WPT中的测试进行计算，到目前为止，这是通过将相关的Test262测试复制到WPT中完成的，但如果没有更多JavaScript功能的Interop分数，开发者可能不会将该项目视为解决JavaScript互操作性问题的天然场所。
即使在浏览器中，有些领域——尤其是在移动设备和屏幕阅读器中——也难以通过WPT进行测试，并且正在开发一种全新的双向WebDriver协议来处理服务工作者、窗口管理和其他非网页内容的测试。
平台差异意味着并非所有WPT甚至都与JavaScript服务器端运行时相关：WinterTC联合主席Andreu Botella指出，“大多数需要WebDriver集成的API都不是服务器端运行时支持的API。”
但作为定义开发者可以期望服务器端运行时支持的最小网络API子集的一部分，Botella表示，“WinterTC正在致力于识别WPT测试的一个子集，可以作为测试套件使用。”这甚至可能帮助习惯在浏览器中工作的开发者理解运行时有意不同的行为（通常是因为它们有不同的安全模型，但有时是为了与早期的Node.js决策兼容）。
“网络无处不在；网络在手表、洗衣机、冰箱和电视上。”
——Sender
Sender指出：“网络平台的边界，以及网络浏览器中包含的库，我认为从测试角度来看这是有意义的。”但WPT也在尝试尽可能超越这一点，因为平台范围广阔。“网络无处不在；网络在手表、洗衣机、冰箱和电视上。”
由于物流原因，Interop的一些调查领域进展缓慢（触控测试仍然排除移动设备，因为它们难以进行仪器化），但他还指出要处理竞争组织的权衡。
“WPT是由来自六七家公司的15-20人组成的小组，他们必须回到他们数千人的工程团队，并对让大家在共享状态产品路线图上保持一致负责；他们能做的就这么多。”
WPT的规模和社区参与
WPT中的测试覆盖率比早期显著提高：根据你计算不同子测试的方式，大约有200万个独立测试，分组为大约60,000个主要测试。
WPT可能永远无法完全覆盖网络平台中的所有内容，因为网络平台每年都在不断扩展——Kardell称其为“移动的目标”，Le Hégaret指出“我们通过WPT实现的正是我们想要的，但问题是我们一直在发展网络平台。”
Jägenstedt告诉我们，WPT对包含哪些测试相当中立。“只要它是一个规范，你就可以把你的测试放在WPT中，即使只有一个浏览器供应商认为这是个好主意。基本上，每个人都受欢迎，如果其他人以后想加入，那也很酷。”
“……我们通过WPT实现的正是我们想要的，但问题是我们一直在发展网络平台。”
——Le Hégaret
不过，WPT测试的编写方式有一个小小的悖论。理想情况下，它们测试的是浏览器实现规范的程度，而这应该衡量它们对网络开发者的有用程度；但正如Smith指出的，编写WPT测试的人大多是熟悉C和C++的浏览器工程师和系统开发者，而不是具有HTML、CSS和JavaScript专业知识的网络开发者。
这包括浏览器制造商和像Igalia这样的咨询公司。Meyer指出：“有时是个人贡献者，那些真正关心某项技术但没有得到其他人关注的人会贡献测试。”
Kardell同意：“如果你想让浏览器中的某个东西得到修复，有一个失败的网络平台测试是一个很好的开始，因为没有失败的网络平台测试，什么都不会被修复。”“如果你是Wix或Shopify，你在网上有业务，而bug会让你损失很多钱，如果你迫切需要这个功能因为它会为你省钱或省时间，那么贡献WPT是你投资平台同时获得回报的一种方式。因为这会使[一个功能]更有可能被实现或[一个bug]更有可能被解决。”
曾有尝试让更多网络开发者参与编写WPT测试，一直追溯到Test The Web Forward，许多人希望这将是“通往网络标准的快车道”，Sender指出。但这不总是产生高质量的测试，因为编写涵盖所有场景和上下文的好测试很难，而且熟悉WPT本身也需要时间。
“这是一个混乱、不完美且可改进的系统，但社区的参与和持续推动仍然是好事。”
——Berjon
Jägenstedt同意：“这有点学习曲线；你需要一个WPT伙伴来花时间指导你并审查你的测试。”
此外，网络开发者通常忙于构建网站和应用程序，而且时间尺度并不总是很好匹配，因为他们的客户可能需要多年才能使用通过他们贡献的测试的新浏览器。
Berjon说：“我喜欢这有潜在的公共问责制，尽管在实践中太具挑战性了。”“这是一个混乱、不完美且可改进的系统，但社区的参与和持续推动仍然是好事。”
WPT对Web开发的持久影响
Graham回忆道，WPT的目标是“网络平台应该有多个可比较的实现，而且它们都应该是高质量的，用户可以真正拥有真正的选择。我们不会陷入这样的境地：构建一个与真实网络兼容的浏览器实在太困难了。”
WPT帮助终结了十年前的CSS技巧和神秘的浏览器变通方法。即使是一个静态网站也需要进行大量的多浏览器测试，以确保其正确渲染。Sender回忆道：多亏了WPT，“完成这些基本工作的痛苦消失了，我们获得了所有这些新的网络功能”。
Pieters也同意：“它产生的积极影响比我项目开始时想象的要大得多。”“当时很难想象Interop。现在浏览器在何时实现哪些功能上达成一致，并在测试中获得99%的通过率：这简直是梦想！”
“如果别人的东西能与你的东西一起工作，因为网络平台运作良好，那么你的东西就会更有价值。”
——Sender
尽管一些浏览器制造商的动机可能包括“90年代的反垄断恐惧——[WPT]是独特的、非凡的，我认为它也是一种反垄断保护”，但根据Sender的说法，它也是一个双赢的局面。“如果别人的东西能与你的东西一起工作，因为网络平台运作良好，那么你的东西就会更有价值。如果你是Google，有更多人使用它，你就能卖出更多广告；如果你是Apple，有更多人使用它，你就能卖出更多手机；微软就能卖出更多Windows许可证。”
他建议，共享的公共测试是一种独特的、适合网络的方法。“许多其他平台没有这个，但许多其他平台也没有以同样的方式实现互操作，拥有如此不同的代码库，却做着如此相似的事情。”
它可以在其他地方发挥作用吗？“这非同寻常，也许可以作为我们如何做其他事情的范本。”这可能包括可访问性，或者设计系统UI库的扩散可以以WPT或Interop能够实现的方式进行集成。“我们可以为网络拥有一个标准的UI库。”
Smith指出，WPT方法“事后看来，这似乎是理所当然的，那是做事情的正确方式。”
“现在我们已经无法想象，如果没有这些共享测试，我们如何能够维护网络以及我们目前拥有的标准化速度。”
——Graham
Graham同意，现在很难想象没有它的现代网络。“现在我们已经无法想象，如果没有这些共享测试，我们如何能够维护网络以及我们目前拥有的标准化速度。”
“一旦功能发布，你就期望能够使用它。这绝对是我们作为一个平台应该有的期望，我认为没有WPT，这种期望将完全不切实际。”多亏了WPT，“平台做得更多，而且做得更好。”
