Web 开发人员和应用程序开发人员面临的主要障碍之一是跨不同浏览器“测试他们的网站/应用程序”。测试机制也称为“跨浏览器测试”。有很多浏览器和浏览器版本(Google Chrome、Mozilla Firefox、Internet Explorer、Microsoft Edge、Opera、Yandex 等)，可以通过多种方式访问您的网站/应用程序(通过台式机、智能手机、平板电脑等)。 ) 和许多可能用于访问您的网站的操作系统(Windows、MacOS、Linux、Android、iOS 等)。

　　确保您网站的 UI/UX 及其功能在“浏览器 + 浏览器版本 + 操作系统 + 设备配置文件”的组合上没有任何缺陷，将涉及大量的开发、测试和维护工时。尽管测试可能包括自动跨浏览器测试，但您总是希望在最终发布之前进行一轮手动跨浏览器测试。

　　手动跨浏览器测试的主要痛点是测试人员可能需要花费大量时间测试不同的网页，跨浏览器在越来越多的“复杂”组合列表上跨不同断点测试 Web 应用程序。因此，建议在将更改推送到生产环境之前，在暂存环境中执行一轮手动跨浏览器测试。

　　由于开发分支将涉及来自多个开发人员的更改，您可以期待在这些更改让位于“产品/生产服务器”之前对这些更改进行另一轮跨浏览器测试。尽管您可能遵循“软件开发模型”，但有许多活动会变成计划外/临时性的，手动跨浏览器测试通常被认为是其中之一。解决错误的周转时间 (TAT)可能因团队之间的协同作用而异。如果团队沉迷于责备游戏，TAT 可能会增加，而这种行为可能会导致整体延迟。

　　您无法改变人类的倾向，但您绝对可以确保流程保持到位，以提高执行测试的速度，而不会影响周转时间。让我们看一下可以改进手动跨浏览器测试的一些机制/过程。

　　1. 代码检查器

　　无论使用哪种开发语言，使用静态分析工具检查源代码非常重要。您可能无法通过浏览代码来识别编码错误;因此，有必要针对静态代码分析器(也称为 Linters)执行源代码。Linter 有助于节省验证HTML、CSS和JavaScript的跨浏览器兼容性的手动工作，而且您可以灵活地使用在线工具或安装在本地计算机中的行。在使用在线 linting 工具之前，建议您与您的经理讨论，因为您将在服务器上上传代码(在线 linter 将静态分析源代码)。

　　CSS、JavaScript 和 HTML 的一些流行的 Linters 是

　　1）CSS – CSS Lint , Stylelint

　　2）JavaScript – JSHint , ESHint

　　3）HTML – W3C 标记验证服务、HTML Lint、HTML Tidy

　　除了在线选项，您还可以将这些 linter 的插件/附加组件安装到您的代码编辑器中。使用附加选项可确保在开发环境的前提下完成 linting。

　　2. 重大开发里程碑后的跨浏览器测试

　　假设情况——你有一个包含 50 多个 CSS、JavaScript 和 HTML 文件的模块。在此模块的浏览器兼容性测试期间，您遇到了一个问题。在这样的环境中发现问题与在您更改了 100+ LOC(代码行)的同一模块中发现问题不同吗?任何开发人员都会保证第二个选项，因为您知道更改(100+ LOC)已导致功能中断。添加代码更改后，您应该在“目标客户”可能正在使用的浏览器上测试这些更改。根据您的内部研究，您可以在最新的浏览器版本上进行测试，或者在目标客户群使用的版本上进行测试。

　　一旦你修复了很多错误，你应该进行一轮完整的跨浏览器测试。但是，这种方法在很大程度上取决于客户可交付成果的时间线和产品的性质;在产品开发的早期阶段进行跨浏览器测试可以在测试和开发的后期阶段获得丰厚的回报。

　　3. CSS 前缀

　　CSS 供应商前缀或 CSS 前缀是浏览器供应商在这些功能成为所有浏览器的主流之前添加新 CSS 功能的机制。如果您希望您的源代码在最新的浏览器和这些浏览器的旧版本上得到支持，您的 CSS 代码应该包含前缀代码和无前缀代码。使用 CSS Flexbox 之类的工具，您可以生成新的布局功能。您必须为CSS Flexbox提供所需的前缀和旧语法，以便您的代码在这些前缀是必需的浏览器版本上执行。

　　如果您手动添加所需的供应商前缀，则在此过程中很可能会引入手动错误。避免此类错误的最佳方法是使用可以自动添加 CSS 前缀的工具/库(在必要时)。一些流行的预处理器库或工具是：

　　1）萨斯 - http://bourbon.io/

　　2）少 - http://lessprefixer.com/

　　3）PostCSS – http://postcss.org/

　　4）自动前缀 - https://github.com/postcss/autoprefixer

　　开始您的免费实用波旁威士忌测试。

　　4. 并行测试

　　不管测试策略是否涉及自动化测试，众所周知，与串行开发/串行测试相比，并行模块开发/并行测试总是更快。

　　您可以通过开发测试脚本来实现并行测试，该脚本允许跨不同浏览器、操作系统和设备对源代码进行跨浏览器测试。您可以使用Selenium WebDriver开发可以模仿人类方法的有效测试脚本。我们将在后面的要点中介绍它。

　　5. CSS 分析

　　我们之前讨论了 CSS Linting 以及为什么应该使用 Linting 工具。尽管 Linting 可以帮助您识别 CSS 代码中的错误，但您还应该使用执行 CSS Profiling 的工具。作为开发人员，您可能正在向具有大量遗留代码的 CSS 模块添加代码。代码量越大，识别遗留代码的必要性就越困难。处理此问题的理想方法是使用!important CSS 属性，该属性可确保应用规则而不管文档中规则的位置。

　　有许多工具可用于分析 CSS 代码，但 CSS Parker 是使用最广泛的工具，因为它提供了有关 CSS 代码的大量统计信息。

　　6. 在云端执行跨浏览器测试

　　建立一个可以适应设备、浏览器和操作系统组合的测试基础设施可能是一件昂贵的事情，而且它也可能不具备可扩展性。例如，如果您必须在不同风格的 Android 上测试网站功能——奥利奥、派、牛轧糖等;您将需要具有这些 Android 版本的设备，并且您还需要投资从不同的智能手机供应商处采购设备。因此，这种方法非常不可行且不可扩展。一种理想的方法是在LambdaTest

　　等云测试服务上测试功能，这样您就可以专注于测试而不用担心基础设施。您还可以通过下载相应的 WebDriver for Selenium 来使用 Selenium 编写自动化测试脚本。

　　7. 测试，测试和测试在每个阶段

　　定期测试可确保在开发周期的后期遇到错误。作为开发人员，您应该针对不同的组合测试您的功能。即使你不习惯测试你的模块，你也应该改变思维方式，并将测试作为你日常工作的一部分。

　　如果您正在处理一个复杂的功能，您可以将您的测试计划划分为不同的阶段，这样就没有依赖关系。您还可以使用CodePen之类的工具——一个面向前端开发人员的社交开发平台。它可用于对测试用例进行原型设计。

　　8.制定详细的测试计划

　　您将针对各种设备、操作系统、浏览器类型、屏幕尺寸等组合跨浏览器测试您的源代码。因此，您在浏览器类型的一个版本(例如 Chrome 59)上遇到的问题性质可能与您在相同浏览器类型的不同版本(例如 Chrome 60)上遇到的那些。当您在不同的操作系统和设备上使用相同的浏览器类型时，事情会变得复杂。因此，在这种情况下，临时的测试方法可能是不够的。

　　您应该制定详细的测试计划，以便在不同组合上测试代码的重要功能。您可以根据每个设备组制定测试计划，以便您可以轻松隔离在每个设备上遇到的问题。

　　9. 单元测试

　　单元测试这个术语不需要介绍，它正在测试开发人员在“单元级别”所做的更改。无论使用哪种编程语言，单元测试都用于在单元级别验证代码更改。为了带来“彻底测试”的文化，重点应该放在测试驱动开发(TDD)上。通过结合 TDD 方法，开发人员和设计人员可以设计出精美的代码。它还涉及思维方式的改变。JavaScript 有一套详尽的库可以帮助单元测试，下面列出了流行的库：

　　1）摩卡 - https://mochajs.org/

　　2）茉莉花——http: //jasmine.github.io/

　　3）据说开发和测试应该齐头并进，以便在产品开发的早期阶段发现错误。

　　10. 测试脚本

　　单元测试是在“单元级别”执行的，而回归测试是在牢记产品的端到端功能的情况下执行的。理想情况下进行回归测试以确保新代码更改对现有功能没有副作用。

　　在某些情况下，功能中可能包含视觉元素，例如使用 JavaScript 的按钮单击;而在某些情况下，界面上可能没有更新，例如单击按钮后数据库中某些字段的更新。因此，建议及时开发和维护测试脚本，并按优先级对测试脚本进行分组。

　　11. 使用网络分析找出最喜欢的浏览器

　　根据最初的市场研究和客户市场细分，您的管理层以及开发团队将获得有关预期用户细分的信息。他们还将获得有关应该在其上执行更多测试的浏览器的信息(因为使用您的产品的大多数用户群可能正在使用该浏览器)。您还可以使用网络分析工具来查明对您的大部分流量负责的浏览器。

　　作为开发人员，您希望您的代码能够在所有浏览器中无缝运行;但是您不能将相同的时间用于每个浏览器(在开发和测试期间)。因此，您制定了一个详细计划，说明如何在您的客户群使用的浏览器上测试功能。

　　12. 创建跨浏览器兼容性矩阵

　　完成对负责为您的网站带来流量的浏览器的分析之后，就可以通过对它们进行分类来确定这些浏览器的优先级，如下所述：

　　1）完全支持和最受欢迎的浏览器。

　　2）完全支持但不太喜欢的浏览器

　　3）部分支持但喜爱的浏览器。

　　4）部分支持，不是最喜欢的浏览器。

　　5）不受支持但最喜欢的浏览器。

　　6）不受支持和不喜欢的浏览器。

　　跨浏览器兼容性矩阵将帮助您了解在执行跨浏览器测试时不应错过的浏览器。它还可以帮助您减少测试工作，让您清楚地了解没有提供结果的浏览器，正如您所期望的那样。使用跨浏览器兼容性矩阵，您可以规划更有效的跨浏览器测试策略。

　　13.专注于产出更多的任务

　　浏览器也是一种软件，与任何其他软件一样，它们也有错误。浏览器公司会定期修复错误，并通过更新将它们推送给用户。修复的错误可能不是很严重/更改可能对您正在实施的功能没有任何影响。

　　由于有许多操作系统，您应该有意识地决定是否应该在不同操作系统的同一浏览器上进行测试。如果跨这些操作系统的浏览器更改微不足道，您可以跳过测试。

　　因此，在执行手动跨浏览器测试时，您应该专注于产生更好输出的任务，而不是专注于本质上重复的任务。

　　14. 重用组件

　　软件革命已经走过了漫长的道路，尤其是开源软件，因为开发人员可以使用开源模块，从而加快产品开发速度。从项目开始，您应该跟踪用于开发和测试的工具和组件，以免重复。

　　您还可以使用工具来创建项目正在使用的元素的共享存储库。

　　15. 使用“人道方法”进行测试

　　除了单元测试和回归测试之外，您还需要执行从最终用户的角度或多或少模仿测试的功能测试。为了充分利用这些测试，您应该提出一种自动化的测试方法。

　　Selenium 是一种流行的 Web 应用程序软件测试框架，并且得到了广泛的支持。WebDriver和NightWatch是围绕Selenium Webdriver的流行 JavaScript 包装器。我们将在我们的博客上讨论/已经讨论过使用 Selenium 进行自动化 Web 测试。您还可以参考我们的Nightwatch JS教程，了解如何使用 Nightwatch JS 运行自动化测试脚本

　　通过使用 Selenium 编写测试用例，您可以自动化按钮单击、滚动、填充文本字段等。这些是 Web 开发周期中将发生的一些实时场景。执行这些测试的另一个优点是与团队成员的“交互”。这些测试不是在孤岛中完成的，因此，作为开发人员，您有机会与团队中的其他测试人员和开发人员进行互动和讨论问题。

　　16. 寻找专业测试人员

　　白盒测试，即功能测试是一项专业技能，您需要适应开发人员的立场来测试产品功能。尽管开发人员可以对他们的模块进行单元测试，但他们永远不应该执行端到端测试，因为他们的思维方式可能会产生偏见，并且他们不会完全清楚地了解测试规范。因此，手动跨浏览器测试应该由专业或合格的测试人员完成，因为他们可以发现产品中的错误。

　　如果您无法聘请测试人员，您可以确定开发人员(具有测试天赋)并培训他们了解测试的特征。这些资源可以兼作开发人员和测试人员，这在当今时代是一种罕见的组合。

　　17. 众包测试

　　如果您无法在内部找到测试资源，您可以使用众包测试服务。对于众包测试网站，您可以选择符合您标准的测试人员。根据产品的性质，您可以获得由测试人员签署的 NDA(保密协议)，从而保护有关产品的机密信息。

　　越来越多的公司(不同规模的)正在使用众包测试，因为它具有良好的成本效益。

　　18. 用户的后备机制

　　作为开发人员，您可能会使用所有最新技术进行更新，但仍有相当多的人仍然依赖旧技术(或浏览器)。根据产品市场研究和预期目标受众，您的产品应该为旧浏览器不支持的功能包含一个后备机制。例如，在您的网络浏览器不支持 Flash 的情况下，有一个视频播放的后备机制。

　　19. 在相关位置使用断点

　　断点的定义取决于是从开发人员的角度还是从设计人员的角度来看待它。对于开发人员/代码，断点是媒体查询;而对于设计师来说，断点是内容呈现发生变化的点。建议您在设计、开发、内容等方面遵循移动优先的方法。断点的全部目的是让网页的内容适应查看页面的设备的屏幕分辨率。这通常通过在媒体查询声明中添加浏览器宽度来实现。

　　什么时候应该添加断点?当您的内容难以阅读时，您应该添加一个断点，例如当屏幕较宽时，内容看起来很糟糕，您可以在此处添加断点。没有理想数量的断点，但您应该明智地使用它以遵守响应式网页设计原则。

　　20. 使用测试工具

　　在“重用组件”这一点中，我们讨论了跟踪用于开发和测试的工具和资源的重要性。您可以使用该信息来创建测试工具设置。测试工具是一种自动化测试框架，用于针对各种测试数据测试软件/代码。测试是在不同的条件下执行的，例如可变 CPU 负载等。捕获测试结果并比较测试的失败或成功。

　　测试工具应该以模块化的方式设计，以便组件松散耦合，并且可以在不同的团队(和项目)中重复使用。JUnit是一种流行的单元测试框架，可用于创建测试工具设置。

　　21. 研究目标市场的浏览器格局

　　我们之前讨论了在真正重要的浏览器上进行测试的重要性，即在您可以获得最大受众的地方更流行的浏览器。因此，在您开始设计和编码您的网站/Web 应用程序之前，请务必查看CanIUse等资源，其中概述了不同浏览器支持的功能。例如，您可以检查CSS Grid Layout是否适用于 Safari?了解您的目标受众并开发功能以牢记目标受众是一个很好的起点。

　　您需要致电支持的浏览器(及其各自的版本)，并根据这些发现确定功能开发和测试的优先级。

　　22.利用模拟器和仿真器

　　您的源代码在作为“独立模块”进行测试时可以完美执行，但在作为最终产品和在各种条件下(例如最新的浏览器、不受支持的浏览器等)进行测试时会发生彻底的测试。拥有一个可以容纳所有可以进行测试的产品的实验室需要大量投资;因此，这是一个不可行的选择。

　　这就是像 LambdaTest这样的跨浏览器测试可以帮助您的地方。LambdaTest 提供了一个基于云的测试基础设施，该基础设施具有可扩展性，可以最大限度地降低与测试相关的成本。在 LambdaTest，您可以在一个测试会话中跨来自不同供应商的40 多台设备对您的网站进行响应式测试!或者，您还可以选择使用可以安装特定浏览器版本的 VM(虚拟机)。从可扩展性和可靠性的角度来看，基于云的测试是一个更可取的选择。这将帮助您了解如何从众多设备访问您的网站。

　　23. 部署持续集成模型

　　持续集成是一个开发过程，一旦开发人员推送代码，就会触发构建。您还可以在持续集成过程中集成测试，在这种情况下，一旦构建成功，也会触发模块测试和全功能测试。这样的过程可确保您的代码在不同场景中按照预期的功能工作。

　　许多大型组织使用Jenkins，它是领先的开源自动化服务器，并提供大量用于构建、部署和自动化的插件。

　　24. 根据规范进行测试

　　如果您可以在提出布局规范后立即跨不同浏览器自动执行布局测试会怎样?这可以通过使用像Galen Framework这样的框架来实现，您可以通过该框架验证布局中元素的相对定位。

　　当您希望您的网站/Web 应用程序遵循响应式设计原则时，Galen 框架是一种重要的资源。通过使用这样的框架，您可以在产品开发的早期阶段发现设计问题。

　　25. 与测试人员携手合作

　　在我们之前的观点之一中，我们讨论了在开发人员和测试人员社区之间进行“适当沟通”的重要性。开发人员还应该积极参与端到端测试阶段，并向他们的测试人员推荐测试用例(以防他们可能错过了一些测试用例)。

　　与结对编程的概念类似，开发人员可以与测试人员(负责测试他们的功能)结对，并创建一个更有利于学习的环境。

　　26. 让交互尽可能简单

　　作为最终用户，您希望正在开发的产品对用户友好且易于使用。在网页中添加过多的组件以将美化元素添加到设计中会导致设计混乱，因此您应该添加不会增加产品复杂性的设计功能。因此，您应该进行不会混淆最终用户的用户交互并保持这些交互简单。

　　在源代码中可能会遇到竞争条件，即输出在很大程度上取决于事件时间的异步操作。竞态条件或死锁情况在 Web 开发环境中很常见，其中正在处理大量请求而代码中没有处理并发性。为了避免这种竞争条件，您可以使用 JavaScript 的Async 实用程序模块，该模块有助于在您的网站/Web 应用程序中协调异步请求。

　　27. 使用测试框架(尽可能)

　　作为 Web 开发人员，您应该了解使用 CSS 框架(如Bootstrap )的优缺点。一旦您详细了解了该框架，您应该决定使用该框架是否可以加快跨浏览器测试过程。

　　建议您咨询使用过 Bootstrap 或其他 CSS 框架的其他团队，以便您可以将这些知识融入您的项目中。

　　28. 设计简单

　　在我们之前的观点之一——保持交互尽可能简单，我们谈到了保持交互简单和遵守响应式设计原则的重要性。同样的经验法则也适用于您的产品开发。您应该保持“设计”简单而有效，并确保设计不会混淆最终用户。您应该始终在设计时牢记最终用户的观点。

　　您应该做出有意识的决定——功能是否重要/设计是否重要/功能和设计都很重要。作为设计师/开发人员，您永远不应该在设计上妥协功能。

　　29. 内容的一致性

　　您会遇到很多情况，网页上的特定内容在纵向模式下看起来很完美，但在横向模式下看起来很混乱(反之亦然)。这被称为内容变化，对于保持测试内容的一致性至关重要。

　　您可以使用JavaScript 库来伪造数据，这样您就不必经历为测试功能而提出(一致的)内容的痛苦。

　　30. 使用自动化捕获屏幕截图

　　“屏幕抓取”功能可用于验证渲染输出，这是图像回归测试的重要部分。整个方法非常简单——在执行特定功能的过程中进行屏幕抓取，并使用图像差异算法来验证屏幕抓取质量与预期输出之间的差异。

　　LambdaTest提供自动化屏幕截图测试，允许您捕获批量屏幕截图以快速跟踪您的跨浏览器测试工作。您可以在一个测试会话中从各种浏览器、浏览器版本、操作系统和设备捕获多达 25 个屏幕截图。

　　31. 将屏幕截图与自动化进行比较

　　现在您已经捕获了各种配置的批量屏幕截图，是时候比较和注意 UI 偏差了。然而，通过滚动到页面底部的大量页面将锚图像与其他图像进行比较可能是一个非常耗时且错误的过程。感谢 LambdaTest 之类的跨浏览器测试工具，他们让任务变得更加轻松和快捷。在 LambdaTest，您可以执行智能视觉 UI 测试，自动将多个图像与基线图像进行比较，并突出显示所有 UI 偏差，例如填充、图标、文本对齐等。

　　32. 内部测试

　　在前面的众包测试和寻找专业测试人员的部分中，我们谈到了拥有能够发现错误的高效且经验丰富的测试人员的重要性。在许多情况下，如果参与产品开发和产品测试的不同团队之间缺乏沟通，报告错误所涉及的周转时间可能会增加。这也可能导致项目延误。

　　因此，许多组织(无论规模大小)现在都在寻找内部测试团队，以便严格控制沟通并减少周转时间。

　　33.专注于可访问性测试

　　如果您的产品还吸引残疾人，例如色盲、听力障碍等，建议测试规范也涵盖满足“可访问性测试”的测试用例。从“可访问性角度”测试产品的测试人员应该对测试用例有清楚的了解，这样即使是角落的测试用例也可以得到验证。

　　34. 早期关注与本地化和用户体验相关的功能

　　手动测试适用于验证与用户体验紧密耦合的功能。早期的重点应该放在用户体验测试上，并且应该在产品测试的不同阶段继续进行。尽管自动化测试可以节省时间和精力，但它永远不能被视为手动测试的替代品。

　　如果您的产品具有本地化功能，例如网站内容以中文为中国客户显示，那么一旦产品达到某个成熟阶段，就必须对这些功能进行测试。如果这些问题后来被发现，这将成为产品和开发团队的负担。

        卓码软件测评是一家[ 具备CMA、CNAS双重资质 ]的专业做软件测试的第三方软件测试服务机构, 可根据您的需求提供各类软件测试服务，并出具合格有效的软件测试报告。点击→→可了解测试报价

        部分文字、图片来自网络，如涉及侵权，请及时与我们联系，我们会在第一时间删除或处理侵权内容。负责人：曾菲       电话：4006070568