高影响力、省力的跨浏览器测试

跨浏览器测试既费时又费力。 然而，开发者天生就是懒惰的：坚持 DRY 原则，编写脚本来自动化我们必须手动完成的事情，利用第三方库； 懒惰使我们成为优秀的开发人员。

“正确”进行跨浏览器测试的传统方法是在您的受众使用的所有主要浏览器中进行测试，然后逐渐转向旧的或更晦涩的浏览器，以便说您已经测试过它们。 或者，如果时间和资源很短，可以测试一小部分 ad hoc 浏览器，并希望没有错误可以让您对应用程序的完整性充满信心。 第一种方法体现了“良好”的发展，但效率低下，而第二种方法体现了懒惰但不可靠。

关于 SmashingMag 的进一步阅读：

• Noah 向移动可用性测试的过渡
• 应用程序、游戏和移动网络测试自动化的基础知识
• 如何创建自己的前端网站测试计划
• 世界上最好的开放设备实验室在哪里？

在接下来的 15 分钟内，我希望通过描述一种测试策略来节省您数小时的浪费精力，该策略不仅劳动强度小，而且更有效地捕捉错误。 我想记录一个现实的测试策略，而不是简单地“测试所有的东西！”，利用我作为 BBC 视觉新闻测试开发人员的经验。

语境

顺便说一句，值得指出的是，我们在团队中所做的不仅仅是手动测试。 跨浏览器测试不能替代单元测试（Jasmine/QUnit）、功能测试（Cucumber）以及在适当情况下的自动化视觉回归测试（Wraith）。 事实上，从长远来看，自动化测试更便宜，并且当您的应用程序达到一定大小时是必不可少的。

然而，一些错误只在某些浏览器中表现出来，测试自动化还没有可靠地进入跨浏览器测试的领域。 在 iPhone 4 上查看时，计算机如何知道您的自动滚动事件刚刚遮住了一半的标题？ 它怎么知道这是个问题？ 在人工智能发展到计算机能够理解你所构建的东西并欣赏你试图展示的叙述和艺术性之前，总是需要手动测试。 作为必须手动执行的事情，我们有责任让跨浏览器测试过程尽可能高效。

你的目标是什么？

在盲目地进行跨浏览器测试之前，先决定你希望从中得到什么。 跨浏览器测试可以概括为有两个主要目标：

1. 发现错误这需要尝试破坏您的应用程序以找到要修复的错误。
2. 健全性检查这涉及验证您的大多数观众是否获得了预期的体验。

我想让你从这篇文章中得到的第一件事是这两个目标是相互冲突的。

一方面，我知道我可以通过在 Chrome（桌面）、Chrome（Android）和 Safari（iOS 9）中进行测试来验证近 50% 的英国观众的体验。 另一方面，如果我的目标是找到错误，那么我会想把我的网络应用程序扔到我们必须积极支持的最有问题的浏览器上：在我们的例子中，IE8 和原生 Android 浏览器 2。

这两种浏览器的用户在我们的受众中所占的比例越来越小（目前约为 1.5%），如果我们的目标是进行完整性检查，那么在这些浏览器中进行测试会浪费我们的时间。 但是，如果您想看看设计精良的应用程序在丢给不起眼的渲染引擎时会变得多么糟糕，那么它们是可以测试的绝佳浏览器。

可以理解的是，传统的测试策略更加强调在流行的浏览器中进行测试。 然而，不成比例的错误只存在于比较模糊的浏览器中，在传统的测试模型下，这些错误直到测试结束才会被发现。 然后，您将面临两难境地……

当您在长尾测试阶段后期发现错误时，您会怎么做？

1. 忽略错误。
2. 修复错误并希望你没有破坏任何东西。
3. 修复错误并在所有以前测试过的浏览器中重新测试。

在理想情况下，最后一种选择是最好的选择，因为它是真正确信所有浏览器仍按预期工作的唯一方法。 但是，它的效率也非常低——而且您可能需要多次执行此操作。 它是类似于冒泡排序的手动测试。

因此，我们发现自己处于 Catch-22 的情况：为了获得最大效率，我们希望在开始跨浏览器测试之前修复所有错误，但在开始测试之前我们无法知道存在哪些错误。

答案是对我们如何测试要聪明：通过增量测试来实现我们的错误发现和健全性检查的目标，我喜欢称之为三阶段攻击。

三阶段攻击

想象你身处战区。 你知道坏人躲在城市另一边的总部。 在你的支配下，你有一名特工、一支由久经沙场的游击队组成的精锐团队和一大群轻武装的当地民兵。 您发起三阶段攻击以夺回城市：

1. 侦察将你的间谍派往敌方总部，了解坏人可能藏身的地方、有多少人以及战场的总体状况。
2. 突袭将您的精锐团队派往敌人的心脏地带，在一次猛烈的突袭中消灭大多数坏人。
3. 清关派遣当地民兵去挑选剩余的坏人并确保该地区的安全。

您可以将相同的军事策略和纪律带到您的跨浏览器测试中：

1. 侦察在开发机器上的流行浏览器中进行探索性测试。 了解错误可能隐藏的位置。 修复遇到的任何错误。
2. Raid在少数有问题的浏览器上手动测试可能会显示最多的错误。 修复遇到的任何错误。
3. Clearance Sanity 检查您的受众中最流行的浏览器是否已被清除以获得预期的体验。

无论您是在战场上还是在进行设备测试，这些阶段都以最少的时间开始，并随着操作变得更加稳定而增长。 你能做的侦察只有这么多——你应该能够在很短的时间内发现一些错误。 突袭更加激烈和耗时，但提供了非常有价值的结果并显着稳定了战场。 通关阶段是所有阶段中最费力的阶段，您仍然需要保持警惕，以防一个未发现的坏人不知从何而来并给您造成伤害 - 但这是能够自信地声称战场是必要的步骤现在安全了。

我们三阶段攻击的前两个步骤实现了我们的第一个目标：漏洞发现。 当您确信您的应用程序是健壮的时，您将希望进入攻击的第三阶段，在与大多数观众的浏览行为相匹配的最少数量的浏览器中进行测试，实现第二个目标：健全性检查。 然后，您可以以量化支持的信心说您的应用程序适用于 X% 的受众。

设置：了解你的敌人

不要轻易参战。 在开始测试之前，您需要了解用户如何访问您的内容。

找出您的受众统计数据（来自 Google Analytics 或您使用的任何工具）并以您可以阅读和理解的格式在电子表格中获取数据。 您将希望能够查看每种浏览器和操作系统组合以及占总市场份额的相关百分比。

浏览器使用统计数据只有在可以轻松使用时才有用：您不希望看到一长串令人生畏的浏览器/操作系统/设备组合列表来进行测试。 此外，测试每一种可能的组合都是徒劳的。 我们可以使用我们的 Web 开发人员知识来启发式地整合我们的统计数据。

简化您的浏览器使用统计

作为 Web 开发人员，我们并不特别关心桌面浏览器在哪个操作系统上运行——浏览器错误很少适用于一个操作系统而不适用于另一个操作系统——因此我们将桌面浏览器的统计数据合并到所有操作系统中。

我们也不特别关心有人使用的是 Firefox 40 还是 Firefox 39：版本之间的差异可以忽略不计，而且版本的更新是免费的，而且通常是自动的。 为了便于我们理解浏览器统计信息，我们合并了所有桌面浏览器的版本——IE 除外。 我们知道旧版本的 IE 既存在问题又普遍存在，因此我们需要跟踪它们的使用数据。

类似的论点适用于便携式操作系统浏览器。 我们并不特别关心移动版 Chrome 或 Firefox 的版本，因为它们会定期且容易地更新——所以我们合并了这些版本。 但同样，我们关心 IE 的不同版本，因此我们分别记录它们的版本。

如果我们谈论的是 Android，则设备的操作系统版本无关紧要。 重要的是使用的原生 Android 浏览器的版本，因为这是一个出了名的问题浏览器。 另一方面，设备运行的 iOS 版本非常相关，因为 Safari 版本本质上与操作系统相关联。 然后还有一整套用于其他设备的原生浏览器：这些浏览器在我们的整体受众中只占很小的比例，以至于它们的版本号也被合并了。

最后，我们迎来了迅速普及的新一波浏览器：应用内浏览器，主要在社交媒体平台上实现。 这对我们来说仍然是一个新领域，因此我们热衷于列出所有应用内浏览器平台及其各自的操作系统。

一旦我们使用我们的领域专家知识来合并相关统计数据，我们会通过删除所有占我们受众不到 0.05% 的浏览器来进一步缩小列表范围（请根据您自己的要求随意调整此阈值）。

桌面浏览器

便携式浏览器

应用内浏览器

完成后，您的电子表格应该看起来像这样（暂时忽略“优先级”列 - 我们稍后会谈到）：

因此，现在您已经获得了简化的电子表格，从 Web 开发人员的角度显示了主要浏览器，每个都与总市场份额百分比相关联。 请注意，您应该更新此电子表格； 每月更新一次就足够了。

您现在已准备好开始三阶段攻击。

1. 侦察：查找与浏览器无关的错误

早在你考虑拿出一个设备进行测试之前，做你能做的最简单的事情：在你最喜欢的浏览器中打开你的网络应用程序。 除非你是一个彻头彻尾的受虐狂，否则这很可能是 Chrome 或 Firefox，它们都很稳定并且支持现代功能。 第一阶段的目的是找到与浏览器无关的错误。

与浏览器无关的错误是与用于访问您的应用程序的浏览器或硬件无关的实现错误。 例如，假设您的网页上线，您开始收到一些模糊的错误报告，人们抱怨您的网页在 HTC One 横向模式下看起来很垃圾。 你浪费了很多时间来确定使用的是哪个版本的浏览器，使用 Android 的 USB 调试模式并搜索 StackOverflow 寻求帮助，想知道你将如何解决这个问题。 您不知道，这个错误与设备无关：相反，您的页面在某个视口宽度上看起来有问题，而这恰好是相关设备的屏幕宽度。

这是一个与浏览器无关的错误的示例，它错误地将自己表现为特定于浏览器或特定于设备的错误。 你被引导了一条漫长而浪费的道路，错误报告充当噪音，混淆了问题的根本原因。 帮自己一个忙，从一开始就抓住这种错误，用更少的努力和更多的远见。

通过在我们甚至开始跨浏览器测试之前修复与浏览器无关的错误，我们应该面临更少的错误。 我喜欢称之为融化的冰山效应。 我们正在融化隐藏在地表下的虫子，使我们免于在海洋中坠毁和溺水——我们甚至没有意识到我们正在这样做。

以下是您可以在开发浏览器中执行以发现与浏览器无关的错误的简短列表：

• 尝试调整大小以查看响应性。 任何地方都有一个时髦的断点吗？
• 放大和缩小。 您的图像精灵的背景位置是否被歪斜了？
• 查看应用程序在关闭 JavaScript 时的行为。 你还得到核心内容吗？
• 查看关闭 CSS 后应用程序的外观。 标记的语义仍然有意义吗？
• 尝试同时关闭 JavaScript 和 CSS。 您是否获得了可接受的体验？
• 尝试仅使用键盘与应用程序交互。 是否可以导航并查看所有内容？
• 尝试限制您的连接并查看应用程序的加载速度。 页面加载量有多大？

在进入第 2 阶段之前，您需要修复遇到的错误。 如果我们不修复与浏览器无关的错误，我们只会在以后报告大量错误的浏览器特定错误。

偷懒。 修复与浏览器无关的错误。 然后我们可以进入攻击的第二阶段。

2. Raid：首先在高风险浏览器中测试

当我们修复错误时，我们必须小心我们的修复不会引入更多错误。 调整我们的 CSS 以修复 Safari 中的填充可能会破坏 Firefox 中的填充。 优化那部分 JavaScript 以在 Chrome 中更流畅地运行可能会在 IE 中完全破坏它。 我们所做的每一次改变都会带来风险。

为了真正确信新更改没有破坏我们已经测试过的任何浏览器的体验，我们必须返回并再次在相同的浏览器中进行测试。 因此，为了最大程度地减少重复工作，我们需要明智地了解我们的测试方式。

漏洞分布统计分析

考虑下表，其中十字图标表示浏览器存在错误。

假设我们要按风险升序测试我们的内容：低风险浏览器、中风险浏览器、高风险浏览器。 如果它可以帮助您将其可视化，这些浏览器可能会分别映射到 Google Chrome、IE 9 和 IE 6。

首先测试低风险浏览器 (Chrome)，我们会发现并修复错误 #2。 当我们转移到中等风险浏览器时，错误 #2 已经修复，但我们发现了一个新错误：#4。 我们更改代码以修复错误——但我们如何确定我们现在没有破坏低风险浏览器中的某些内容？ 我们不能完全确定，所以我们必须返回并再次在该浏览器中进行测试，以验证一切仍然按预期工作。

现在我们转到高风险浏览器并发现错误 #1、#3 和 #5，需要大量返工才能修复。 一旦这些都解决了，我们该怎么办？ 返回并再次测试中低风险浏览器。 这是很多重复的工作。 我们必须总共测试我们的三个浏览器六次。

现在让我们考虑如果我们按风险降序测试我们的内容会发生什么。

马上，我们就会在高风险浏览器中发现错误 #1、#3、#4 和 #5。 在修复了这些错误之后，我们将直接进入中等风险浏览器并发现错误 #2。 和以前一样，此修复可能间接破坏了某些内容，因此有必要返回高风险浏览器并重新测试。 最后，我们在低风险浏览器中进行测试，没有发现新的错误。 在这种情况下，我们总共在四个不同的场合测试了我们的三个浏览器，这大大减少了有效发现和修复相同数量的错误并验证相同数量浏览器的行为所需的时间.

开发人员可能会面临首先在最流行的浏览器中进行测试的压力，然后在我们的测试结束时一直使用不太广泛使用的浏览器。 但是，流行的浏览器很可能是低风险浏览器。

你知道你必须支持给定的高风险浏览器，所以从一开始就让那个浏览器不碍事。 不要浪费精力测试不太可能产生错误的浏览器，因为当您切换到产生更多错误的浏览器时，您只需返回并再次查看那些低风险浏览器。

修复不良浏览器中的错误使您的代码在良好浏览器中更具弹性

通常，您会发现这些有问题的浏览器中出现的错误是您的不良代码的意外结果。 您可能笨拙地将 div 设置为看起来像一个按钮，或者在触发某些任意行为之前侵入了 setTimeout； 这两个问题都存在更好的解决方案。 通过修复作为不良代码症状的错误，您很可能在看到其他浏览器中的错误之前就已经修复了它们。 再次出现融化的冰山效应。

通过检查功能支持，而不是假设浏览器支持某些东西，您正在修复 IE8 中的那个痛苦的错误，但您也使您的代码对其他恶劣环境更加健壮。 通过为 Opera Mini 提供该图像后备，您鼓励使用渐进增强，并且作为副产品，您正在改进您的产品，即使对于那些减少芥末的浏览器用户也是如此。 例如，移动设备可能会失去其 3G 连接，而仅下载了一半的应用程序资产：用户现在获得了他们以前无法获得的有意义的体验。

但请注意：如果您不小心，修复晦涩的浏览器中的错误可能会使您的代码变得更糟。 例如，抵制嗅探用户代理字符串以有条件地向特定浏览器提供内容的诱惑。 这可能会修复错误，但这是一种完全不可持续的做法。 不要为了支持笨拙的浏览器而牺牲好代码的完整性。

识别有问题的浏览器

那么什么是高危浏览器呢？ 答案有点模糊，取决于您的应用程序使用的浏览器功能。 如果您的 JavaScript 使用indexOf ，它可能会在 IE 8 中中断。如果您的应用程序使用position: fixed ，您需要在 iOS 7 上的 Safari 中检查它。

我可以使用是一种宝贵的资源，也是一个很好的起点，但这是再次来自经验和开发人员直觉的领域之一。 如果您定期推出 Web 应用程序，您将知道哪些浏览器会一次又一次地标记问题，并且您可以改进您的测试策略以适应这种情况。

您在有问题的浏览器中发现的错误的有用之处在于它们经常会传播。 如果 IE9 中存在错误，则该错误很可能也存在于 IE8 中。 如果某些东西在 iOS 7 上的 Safari 上看起来很时髦，那么它在 iOS 6 上可能看起来更加明显。注意到这里的模式了吗？ 较旧的浏览器往往是有问题的浏览器。 这应该可以帮助您列出一个很好的有问题的浏览器列表。

话虽如此，请使用使用统计信息来备份这些内容。 例如，IE 6 是一个非常有问题的浏览器，但我们不会费心对其进行测试，因为它的总市场份额太低。 花费在修复 IE6 特定 bug 上的时间对于少数需要改善体验的用户来说是不值得的。

在 raid 阶段，您并不总是想要测试旧版浏览器。 例如，如果您有一个带有图像回退的实验性 3D WebGL 画布项目，那么旧的浏览器只会获得回退图像，因此我们不太可能发现很多错误。 我们想要做的是根据手头的应用程序改变我们对有问题的浏览器的选择。 在这种情况下，IE9 可能是一个很好的测试浏览器，因为它是第一个支持画布的 IE 版本。

如果您的应用程序使用 CSS3 功能（例如渐变或边框半径），现代代理浏览器（例如 Opera Mini）也可能是一个不错的 raid 测试选择。 一个常见的错误是在不受支持的渐变上呈现白色文本，从而导致无法辨认的白底白字文本。

在选择有问题的浏览器时，请使用您的直觉并尝试抢先发现错误可能隐藏的位置。

使有问题的浏览器多样化

浏览器和浏览器版本只是等式的一部分：硬件也是一个重要的考虑因素。 您需要在各种屏幕尺寸和不同像素密度上测试您的应用程序，并尝试在纵向和横向模式之间切换。

将相关的浏览器组合在一起可能很诱人，因为可以感觉到工作成本的折扣。 如果您已经打开 VirtualBox 来测试 IE8，那么现在似乎也是在 IE9、IE10 和 IE11 中进行测试的好时机。 但是，如果您正处于测试 Web 应用程序的早期阶段，您会想要与这种诱惑作斗争，而是选择三到四个彼此明显不同的浏览器-硬件组合，以获得尽可能多的覆盖率尽可能多的错误空间。

尽管这些可能因项目而异，但以下是我目前选择的有问题的浏览器：

• Windows XP VM 上的 IE 8；
• 中端 Android 平板电脑上的原生 Android Browser 2；
• 运行 iOS 6 的 iPhone 4 上的 Safari；
• Opera mini（只有在没有 JavaScript 的情况下才真正值得测试的内容，例如 datapics）。

偷懒。 通过将您的应用程序扔到最有问题的受支持浏览器和设备上，尽可能多地发现错误。 修复这些错误后，您就可以进入攻击的最后阶段。

3. 清关：健全性检查

您现在已经在您必须支持的最严苛的浏览器中测试了您的应用程序，希望能够捕捉到大多数错误。 但是您的应用程序还没有完全没有错误。 我经常惊讶于即使是最新版本的 Chrome 和 Firefox 在呈现相同内容时也会有多么不同。 你还需要做更多的测试。

这是旧的 80:20 规则。 形象地说，在测试了 20% 的浏览器之后，您已经修复了 80% 的错误。 现在你要做的是通过测试不同的 20% 的浏览器来验证 80% 的观众的体验。

优先考虑浏览器

现在简单而明显的方法是切换回“传统的”跨浏览器测试，按市场份额的降序处理每个浏览器。 如果 Chrome 桌面恰好是您的受众浏览器份额的最高比例，其次是 iOS 8 上的 Safari，其次是 IE11，那么按此顺序进行测试是有意义的，对吧？

这是一个基本公平的系统，如果您的资源已经捉襟见肘，我不想让这一步过于复杂。 然而，事实是，并非所有浏览器都是平等的。 在我的团队中，我们根据决策树对浏览器进行分组，该决策树考虑了浏览器的使用、升级的难易程度以及浏览器是否为操作系统默认设置。

到目前为止，您的电子表格应该有一个浏览器列和一个市场份额列； 您现在需要第三列，指定浏览器属于哪个优先级。 说实话，这个优先级工作应该在发动三阶段攻击之前完成，但为了本文的目的，在这里描述它更有意义，因为直到清除阶段才真正需要优先级。

这是我们的决策树：

我们设计了决策树，以便 P1 浏览器覆盖大约 70% 的受众。 P1 和 P2 浏览器加起来覆盖了大约 90% 的受众。 最后，P1、P2 和 P3 浏览器为我们提供了几乎完整的受众覆盖。 我们的目标是在所有 P1 浏览器中进行测试，然后是 P2，然后是 P3，按市场份额的降序排列。

正如您在本文前面的电子表格中所见，我们只有少数 P1 浏览器。 事实上，我们可以如此快速地验证超过 70% 的观众的体验，这意味着如果代码库发生变化，我们没有理由不在这些浏览器中重新测试。 随着我们向下移动到 P2 和 P3 浏览器，我们必须花费越来越多的精力来验证不断减少的受众规模的体验，因此我们必须为较低优先级的浏览器设置更现实的测试理想。 作为指导：

• P1 。 在签署应用程序之前，我们必须对这些浏览器进行完整性检查。 如果我们对代码进行小的更改，那么我们应该再次在这些浏览器中进行完整性检查。
• P2 。 在签署应用程序之前，我们应该对这些浏览器进行完整性检查。 如果我们对代码进行较大的更改，那么我们应该再次在这些浏览器中进行完整性检查。
• P3 。 我们应该对这些浏览器进行一次完整性检查，但前提是我们有时间。

不要忘记使您的硬件多样化的必要性。 如果您能够在遵循此列表的同时在多种不同的屏幕尺寸和具有不同硬件功能的设备上进行测试，那么请这样做。

总结：三相攻击

一旦你努力了解你的敌人（简化你的观众统计数据并将浏览器分组为优先级），你就可以分三个步骤进行攻击：

1. 侦察：在您最喜欢的浏览器上进行探索性测试，以发现与浏览器无关的错误。
2. Raid ：在各种硬件上测试您最有问题的受支持浏览器，以发现大多数错误。
3. 许可：验证您的应用程序在最广泛使用和具有战略意义的浏览器上的体验，以量化支持您的应用程序工作的信心说。