跨浏览器测试简介
本文概述了跨浏览器测试：什么是跨浏览器测试，一些常见问题，以及一些调试/故障排除方法。
| 预备知识 | 熟悉核心 HTML、CSS 和 JavaScript 语言。 |
|---|---|
| 目标 | 了解跨浏览器测试中涉及的高级概念。 |
什么是跨浏览器测试？
跨浏览器测试是确保网站在各种浏览器和设备上都能正常运行的做法。Web 开发者应该考虑：
- 不同的浏览器，包括一些不支持所有最新 JS/CSS 功能的稍旧的浏览器。
- 从台式机和笔记本电脑到平板电脑和智能手机，再到智能电视的各种设备，它们具有不同的硬件功能。
- 残疾人，他们可能依赖屏幕阅读器等辅助技术，或者只使用键盘。
请记住，你不是你的用户 — 仅仅因为你的网站在你的 MacBook Pro 或高端 Galaxy Nexus 上运行良好，并不意味着它对所有用户都适用！
注意：让所有人都用上 Web 讨论了不同的浏览器、它们的市场份额以及相关的跨浏览器兼容性问题。
网站应该能在不同的浏览器和设备上以及残疾人（例如，屏幕阅读器友好）中访问。网站不必在所有浏览器和设备上提供完全相同的体验，只要核心功能能够以某种方式访问即可。例如，现代浏览器可能拥有一些动画、3D 和闪亮的东西，而旧浏览器可能只显示具有相同信息的平面图形。
此外，网站不可能在所有浏览器和设备上都运行，因此 Web 开发者应该与网站所有者就代码将运行的浏览器和设备范围达成一致。
为什么会出现跨浏览器问题？
跨浏览器问题发生的原因有很多，请注意，这里我们讨论的是在不同浏览器/设备/浏览偏好下行为不同的问题。在解决跨浏览器问题之前，您应该已经修复了代码中的 bug（如有需要，请参阅之前主题中的调试 HTML、调试 CSS 和出了什么问题？JavaScript 故障排除，以重新回顾）。
跨浏览器问题通常是因为：
- 有时浏览器有 bug，或者实现功能的方式不同。这种情况比以前好多了；在 20 世纪 90 年代，当 IE4 和 Netscape 4 争夺主导地位时，浏览器公司故意以不同于其他公司的方式实现事物，试图获得竞争优势，这让开发者的生活变得一团糟。现在浏览器在遵循标准方面做得好多了，但差异和 bug 有时仍然会出现。
- 某些浏览器对技术功能的支持程度可能与其他浏览器不同。当你处理浏览器刚刚开始实现的前沿功能时，或者当你必须支持不再开发的非常旧的浏览器时，这是不可避免的，这些浏览器可能在新功能发明很久之前就已经被冻结（即不再进行新的工作）。例如，如果你想在你的网站中使用尖端 JavaScript 功能，它们可能无法在旧浏览器中运行。如果你需要支持旧浏览器，你可能不得不不使用这些功能，或者在需要时使用某种交叉编译器将你的代码转换为旧式语法。
- 某些设备可能存在限制，导致网站运行缓慢或显示不良。例如，如果一个网站被设计成在台式 PC 上看起来很好看，那么它在移动设备上可能会显得很小且难以阅读。如果你的网站包含大量大型动画，它可能在高端平板电脑上运行良好，但在低端设备上可能会迟钝或卡顿。
……还有更多原因。
在后续文章中，我们将探讨常见的跨浏览器问题，并寻找解决方案。
跨浏览器测试工作流程
所有这些跨浏览器测试业务听起来可能既耗时又可怕，但事实并非如此——你只需要仔细规划，并确保在正确的地方进行足够的测试，以确保你不会遇到意想不到的问题。如果你正在处理一个大型项目，你应该定期测试它，以确保新功能对你的目标受众有效，并且代码的新增内容不会破坏以前正常工作的老功能。
如果你把所有测试都留到项目结束，那么你发现的任何 bug 都会比你边做边发现和修复的 bug 更昂贵、更耗时。
一个项目的测试和 bug 修复工作流程大致可分为以下四个阶段（这只是非常粗略的划分——不同的人可能会以非常不同的方式完成）：
初步规划 > 开发 > 测试/发现 > 修复/迭代
步骤 2-4 将根据需要重复多次，以完成所有实现。我们将在后续文章中更详细地介绍测试过程的不同部分，但现在，我们只总结每个步骤中可能发生的情况。
初步规划
在初步规划阶段，你可能会与网站所有者/客户（可能是你的老板，或你正在为其构建网站的外部公司的某人）举行几次规划会议，在会议中，你将确切地确定网站应该是什么样子——它应该拥有什么内容和功能，它应该看起来如何等等。此时，你还需要知道你有多少时间来开发网站——他们的截止日期是什么，他们会为你的工作支付多少费用？我们不会对此进行太多详细讨论，但跨浏览器问题可能会对此类规划产生严重影响。
一旦你对所需的功能集和可能用于构建这些功能的技术有了概念，就应该开始探索目标受众——此网站的目标受众将使用哪些浏览器、设备等？客户可能已经从他们之前进行的研究中获得了这方面的数据，例如，从他们拥有的其他网站，或从你现在正在处理的网站的先前版本。如果没有，你可以通过查看其他来源（例如竞争对手的使用统计数据或网站将服务的国家/地区）来获得一个很好的概念。你也可以凭直觉来判断。
例如，你可能正在构建一个服务于北美客户的电子商务网站。该网站应该完全兼容最流行的桌面和移动浏览器的最新几个版本——这应该包括 Chrome（以及基于 Chrome 相同渲染引擎的 Edge、Opera）、Firefox 和 Safari。它还应该符合 WCAG AA 级无障碍标准。
现在你知道你的目标测试平台了，你应该回去审查所需的功能集和你将要使用的技术。例如，如果电子商务网站所有者希望在产品页面中嵌入一个由 WebGL 驱动的产品 3D 导览，他们将需要接受这在所有旧版浏览器中都无法工作。
你应该列出潜在的问题区域。
注意：你可以在 MDN（你当前所在的网站）上查找不同的功能来找到技术的浏览器支持信息！你还应该查阅 caniuse.com，以获取一些其他有用的详细信息。
一旦你同意了这些细节，你就可以继续开发网站了。
开发
现在开始网站的开发。你应该将开发的各个部分拆分成模块，例如，你可以将不同的网站区域拆分开来——主页、产品页面、购物车、支付流程等。然后你还可以进一步细分这些——实现通用的网站页眉和页脚，实现产品页面详细视图，实现持久购物车小部件等。
跨浏览器开发有多种通用策略，例如：
- 让所有功能在所有目标浏览器中尽可能接近地工作。这可能涉及编写不同的代码路径，以不同的方式重现针对不同浏览器的功能，或者使用 Polyfill 来使用 JavaScript 或其他技术模拟任何缺失的支持，或者使用一个允许你编写一段代码，然后根据浏览器支持情况在后台执行不同操作的库。
- 接受有些东西在所有浏览器上都无法以相同的方式工作，并在不支持完整功能的浏览器中提供不同的（可接受的）解决方案。有时这是由于设备限制不可避免的——电影宽屏不会提供与 4 英寸手机屏幕相同的视觉体验，无论你如何编程你的网站。
- 接受你的网站在某些旧浏览器中无法正常工作，然后继续前进。如果你的客户/用户群对此没有意见，那就可以了。
通常你的开发会涉及上述三种方法的组合。最重要的是，在提交每个小部分之前进行测试——不要把所有测试都留到最后！
测试/发现
在每个实现阶段之后，你需要测试新功能。首先，你应该确保你的代码没有普遍性问题，阻碍了你的功能正常工作。
- 在你的系统上用几个稳定的浏览器进行测试，例如 Firefox、Safari、Chrome 或 Edge。
- 进行一些低保真辅助功能测试，例如尝试仅使用键盘浏览你的网站，或通过屏幕阅读器使用你的网站以查看其是否可导航。
- 在移动平台（例如 Android 或 iOS）上进行测试。
此时，修复你在新代码中发现的任何问题。
接下来，你应该尝试将你的测试浏览器列表扩展到目标受众浏览器的完整列表，并开始专注于排除跨浏览器问题（有关确定目标浏览器的更多信息，请参见下一篇文章）。例如：
- 尝试在所有你能接触到的现代桌面浏览器上测试最新的更改——包括桌面版 Firefox、Chrome、Opera、Edge 和 Safari（理想情况下，在 Mac、Windows 和 Linux 上）。
- 在常见的手机和平板电脑浏览器中进行测试（例如，iPhone/iPad 上的 iOS Safari，iPhone/iPad/Android 上的 Chrome 和 Firefox），
- 还要在你目标列表中包含的任何其他浏览器中进行测试。
最简陋的选择是自己尽可能地进行所有测试（如果你在团队中工作，可以拉队友帮忙）。在可能的情况下，你应该尝试在真实的物理设备上进行测试。
如果你没有条件在物理硬件上测试所有这些不同的浏览器、操作系统和设备组合，你也可以利用模拟器（在你的台式计算机上使用软件模拟设备）和虚拟机（允许你在你的台式计算机上模拟多个操作系统/软件组合的软件）。这是一个非常流行的选择，尤其是在某些情况下——例如，Windows 不允许你在同一台机器上同时安装多个版本的 Windows，因此使用多个虚拟机通常是唯一的选择。
另一种选择是用户组——使用开发团队之外的一群人来测试您的网站。这可能是一群朋友或家人，一群其他员工，当地大学的一个班级，或者一个专业的用户测试设置，人们在那里获得报酬来测试您的网站并提供结果。
最后，您可以使用审计或自动化工具更智能地进行测试；随着项目规模的扩大，这是一个明智的选择，因为手动进行所有这些测试可能会花费很长时间。您可以设置自己的测试自动化系统（Selenium 是流行的选择），例如，它可以在多个不同的浏览器中加载您的网站，并且：
- 查看按钮点击是否成功触发了某些操作（例如，显示地图），并在测试完成后显示结果。
- 为每个浏览器截图，让您可以看到布局在不同浏览器之间是否一致。
如果您希望在测试上投入资金，还有商业工具可以为您自动化大部分设置和测试（例如 Sauce Labs 和 Browser Stack）。这些工具通常支持持续集成工作流，其中代码更改在被允许提交到您的代码仓库之前会自动进行测试。
在预发布浏览器上测试
通常在浏览器的预发布版本上进行测试是个好主意；请参阅以下链接：
如果您在网站中使用非常新的技术，并且希望针对最新实现进行测试，或者如果您在浏览器的最新发布版本中遇到了错误，并且希望查看浏览器开发者是否已在较新版本中修复了该错误，则此功能尤为重要。
修复/迭代
一旦你发现了 bug，就需要尝试修复它。
首先要做的是尽可能缩小 bug 发生的范围。从报告 bug 的人那里获取尽可能多的信息——平台、设备、浏览器版本等。在相似的配置上进行尝试（例如，在不同的桌面平台上的相同浏览器版本，或在相同平台上的同一浏览器的几个不同版本），以了解 bug 的普遍程度。
这可能不是你的错——如果一个 bug 存在于某个浏览器中，那么希望厂商会迅速修复它。它可能已经修复了——例如，如果 Firefox 49 版本中存在一个 bug，但 Firefox Nightly（版本 52）中已经没有了，那么他们已经修复了它。如果还没有修复，那么你可能需要提交一个 bug（请参阅下面的报告 bug）。
如果是你的错，你需要修复它！找出 bug 的原因涉及与任何 Web 开发 bug 相同的策略（再次请参阅调试 HTML、调试 CSS 和出了什么问题？JavaScript 故障排除）。一旦你发现是什么导致了你的 bug，你需要决定如何在导致问题的特定浏览器中解决它——你不能直接修改问题代码，因为这可能会破坏其他浏览器中的代码。通常的方法是以某种方式分支代码，例如使用 JavaScript 特性检测代码来检测问题特性不起作用的情况，并在这些情况下运行一些不同的、可行的代码。
完成修复后，您需要重复测试过程，以确保修复正常工作，并且没有导致网站在其他地方或其他浏览器中出现问题。
报告 bug
重申一下上面所说的，如果你在浏览器中发现了 bug，你应该报告它们：
总结
本文应该已经为您提供了关于跨浏览器测试所需了解的最重要概念的高级理解。掌握了这些知识，您现在就可以继续学习跨浏览器测试策略了。