无数小时用于测试 Web 应用程序以确保其在本地开发环境内外都能正常工作。在 Selenium 之前，这项测试由大量手动测试人员负责，他们在所有基准测试浏览器上制定和重新制定数百个测试用例场景，标记出问题并试图查明问题的根源。
根据手动测试团队的规模，端到端系统测试可能需要几天到几周的时间才能完成。
今天的开发方法可以在两到四个星期的更短的时间内工作。在此期间发布新的、无错误的版本需要确定性、可重复的测试，以提供近乎即时的反馈。这就是为什么 Selenium 测试是当今开发不可或缺的一部分。
以下是对 Selenium 自动化测试的更深入了解，支持它的工具集是如何形成的，以及它在当今常见的快节奏开发管道中的使用情况。
什么是Selenium？
Selenium 是一个自动化 Web 浏览器的开源工具。它提供了一个单一界面，让您可以使用 Ruby、Java、NodeJS、PHP、Perl、Python 和 C# 等编程语言编写测试脚本。
注意：要开始使用 Selenium 最新版本（基于 WebDriver 的实现），您只需要一个 selenium jar 文件 (selenium-standalone-server-'{'version'}'.jar) 即可在本地和上运行测试远程设备。此 JAR 文件包含 W3C 标准 WebDriver API 和 Selenium Grid，以及 Selenium Server（适用于已弃用的 Selenium RC 实现的现有用户）。
免费开始自动化
以下是这些组件的工作原理：
Selenium 网络驱动程序
WebDriver也称为 Selenium 2.0，通过特定于浏览器的驱动程序执行测试脚本。它包括：
API
应用程序接口。通过绑定将您用 Ruby、Java、Python 或 C# 编写的测试脚本移植到 Selenese（Selenium 自己的脚本语言）。
图书馆
容纳 API 和特定于语言的绑定。尽管存在大量第三方绑定来支持不同的编程语言，但主项目支持的核心客户端绑定是：Selenium Java（作为 selenium jar 文件）、Selenium Ruby、Selenium dotnet（或 Selenium C#，可作为 .dll 获得）文件）、Selenium Python 和 Selenium JavaScript（节点）。
司机
打开浏览器实例并运行测试脚本的可执行模块。特定于浏览器——例如，谷歌为 Selenium 开发和维护 Chromedriver 以支持 Chromium/Chrome 上的自动化。
框架
支持与自然或编程语言测试框架集成的库，例如 Selenium 与 Cucumber 或 Selenium 与 TestNG。
这是Selenium Webdriver的详细教程。
工作原理： WebDriver 协议有一个本地端（“客户端”），它将命令（测试脚本）发送到特定于浏览器的驱动程序。驱动程序在其浏览器实例上执行这些命令。因此，如果测试脚本要求在 Chrome 和 Firefox 上执行，ChromeDriver 将在 Chrome 上执行测试；GeckoDriver 将在 Firefox 上执行相同的操作。
注意：测试脚本仅在 WebDriver 的客户端和浏览器/驱动程序连接时执行。他们不必在同一个设备上。要在多个远程驱动程序上启用测试执行，您需要 RemoteWebDriver 和 Grid。
Selenium网格
Grid 可以通过一次在任意数量的远程设备上执行多个测试脚本来最小化测试运行时间。这称为并行测试。
Selenium Grid 是一个智能服务器，可将测试命令路由到远程设备上的浏览器实例。为此需要的两个主要组件（来自客户端/测试器的测试脚本除外）是：
“集线器”（服务器）：
接受来自 WebDriver 客户端的访问请求。将 JSON 测试命令路由到已注册“节点”上的远程驱动程序。
“节点”（远程设备）：
包含本机操作系统、浏览器和 remoteWebDriver。
工作原理： WebDriver-client通过remoteWebDriver在远处的设备上执行测试。RemoteWebDriver 就像您的常规 WebDriver，除了它的两个组件是客户端（您的测试脚本）和服务器（实际在远程设备上执行测试的 Java servlet）。
在您的测试脚本中，您定义将执行测试的节点的“所需功能”（设备、平台、浏览器等）。Hub 接收到这个脚本，通过注册的节点运行以找到一个与所需功能匹配的节点，并将测试分配给它以执行。
注意：设置网格非常简单，但扩展、配置和维护其完整性可能会占用大量资源。请务必在仔细考虑后采用它。
Selenium IDE
Selenium IDE 是一个 Chrome 和 Firefox 插件，可以记录浏览器中的“自然”交互，并以 C#、Java、Python 和 Ruby 等编程语言以及 Selenese（Selenium 自己的脚本语言）生成代码。
测试人员可以在 IDE 中启用“录制”功能，并在浏览器上“播放”测试场景。然后，IDE 可以重放这些交互并以红色突出显示任何错误（重放期间）。
请记住，虽然插件快速且有用，但生成的代码通常过于混乱，无法用于自动化测试脚本。所以用它来进行快速原型设计，但是对于更严重的跨浏览器测试，我们推荐 Selenium WebDriver。
开始您的第一次Selenium测试
Selenium：一段历史
Selenium 从内部项目发展到浏览器自动化开源行业标准的主要事件时间表：
2004 年：在两部分中创造历史（从 Selenium A 到 B）
- ThoughtWorks 的 Jason Huggins 需要测试他的 Web 应用程序在不同浏览器中的前端行为。
- 他开发了一种通过在网页下方注入 JavaScript 来工作的工具，允许测试人员编写可以“自动化”前端用户交互的代码。这成为了 JavaScript TestRunner。
- 虽然 JS 注入方法不能自然地复制用户交互（通过击键/鼠标移动），但它是“同主机源策略”的一种解决方法，它禁止外部 JavaScript 代码访问域中的元素。最初驻留在其中。尽管如此，该工具仍受到内部开发人员和 ThoughtWorks 客户的一致好评。
- 由于大众需求，该工具是开源的。
- 为了消除对 JS 注入的需要，Huggins 和同事 Paul Hammant 讨论了“服务器”组件的可能性。该服务器将充当 HTTP 代理，并诱使浏览器实例相信测试脚本和被测 Web 应用程序来自同一来源。
- 他们用 Java 开发服务器组件，并将原始客户端驱动程序 (TestRunner) 移植到 Ruby。
- 这是原始的 Selenium。在进化时间线中称为驱动Selenium或Selenium B。
2005：Selenium RC（远程控制）
- 在其他地方（特别是在 Bea），Dan Fabulich 和 Nelson Sproul 开始研究驱动程序编码器。他们最终将其塑造成一个独立的服务器，将 MortBay 的 Jetty 捆绑为 HTTP 代理。
- 这将成为“Selenium RC（远程控制）”或 Selenium 1.0。在我们切入 2.0 之前，还有另一个重大的发展形式是……
2006 年：Selenium IDE
- Shinya Kasatani 将 Selenium 驱动程序代码包装在 Firefox 浏览器的 IDE 模块中。
- 当它工作时，他发现他可以在网站上运行功能性“实时测试”——与浏览器交互（就像用户那样）；根据需要记录/重播交互和调试。
- Kasatani 将此工具捐赠给 Selenium 项目，在那里它被称为 Selenium IDE。
2007：Selenium WebDriver (Selenium 2.0)
- 回到 ThoughtWorks，Simon Stewart 努力为每个流行的浏览器编写单独的“驱动程序”客户端，因此它们都支持具有本机浏览器功能的自动化。
- 它得到了回报。该项目以 WebDriver 闻名。
2008：乘以“n”：Selenium Grid
- 在 ThoughtWorks，Philippe Hanrigou 创建了一个服务器，允许测试人员访问并在任意数量的远程设备上的浏览器实例上运行测试。
- 这被称为网格。减少到…
2016：Selenium 3.0
Selenium RC 被弃用，WebDriver 成为标准实现——又名Selenium 3.0。
2019：W3C 协议
WebDriver 成为 W3C 标准协议。
2021 年：Selenium 4 发布
2021 年 10 月 13 日，Selenium 4.0 正式发布。
为什么我需要 Selenium 自动化测试？
想象一下手动测试人员有这样的场景：在 Windows 7 上的最新版本的 Chrome 和 Firefox 中检查 Web 应用的注册页面 (www.example.com/signup) 是否验证输入字符串并成功注册用户。
假设注册页面有这些输入字段——用户名、电子邮件地址和密码。测试人员将获得一个 Windows 7 桌面，并在最新版本的 Chrome 和 Firefox 上连续执行以下步骤：
- 在地址栏中输入 URL (www.example.com/signup)
- 在每个输入字段（电子邮件、用户名和密码）中输入无效字符串
- 检查输入字符串是否针对相应的正则表达式和数据库中的任何预先存在的值进行了验证
- 在每个输入字段中输入“有效”字符串；点击注册
- 检查“欢迎，'{'username'}'”页面是否出现
- 检查系统数据库是否为'{'username'}'创建了新的用户ID
- 如果测试成功，则将测试标记为“通过”，如果注册功能在测试期间的任何地方中断，则标记为“失败”。
这是一个非常基本的系统测试。在现实世界中，测试人员更有可能检查 www.example.com 上的所有用户工作流是否损坏，并根据需要检查尽可能多的操作系统浏览器组合，以满足基准兼容性标准。
根据手动测试人员的数量（以及测试用例的彻底性），可能需要数小时到数周的时间才能确保 Web 应用程序功能齐全。
现代开发人员和产品团队没有那种时间来分配测试，但他们也不能为了匆忙发布而搁置详尽的测试。这就是为什么他们通过由 Selenium 提供支持的自动化来增强他们的测试。
运行Selenium测试
Selenium 测试如何促进敏捷开发
什么是敏捷？
敏捷是一种开发方法。它从最简单的产品设计工作版本开始——一个可以不断改进的版本。
典型的敏捷工作流程如下所示：
- 利益相关者同意产品的“最简单的工作”设计。
- 设计分为更小的模块。
- 每个模块都分配给一个由开发人员、设计师和质量保证人员组成的跨职能团队。
- 团队在 sprint 中工作，以在时间框架（“迭代”）内创建他们的模块——一到四个星期的窗口。
- 在每次迭代结束时，将完成的模块放在一起。运行测试并向利益相关者展示功能性产品（具有最少的错误）。
- 利益相关者评估项目优先级，添加客户反馈并根据需要进行调整。
整个周期从下一次迭代和一组新模块重新开始。“市场就绪”的产品或新功能总是需要多次迭代。
测试自动化从何而来：
- QA 从早期阶段就参与进来，对模块进行一系列单元测试和验收测试。
- 每次迭代的集成测试确保单独编码的模块在放在一起时不会中断。
- 每个新的迭代都需要回归测试（因此它不会破坏之前的工作迭代）。
跟踪代码和测试用例非常重要，因此所有迭代都有很好的文档记录。当我们讨论这个主题时，您应该注意，这种循环测试是任何基于敏捷的快速迭代开发子类别的主题，例如 CI/CD。
Selenium 测试如何融入持续集成/交付 (CI/CD)
什么是 CI/CD？
持续集成/交付优先考虑频繁且快速地交付新版本的构建。已启动的项目对持续迭代（如敏捷）保持开放。
唯一的区别是：项目也随时准备好交付（而不是等待迭代运行它们的过程）。
CI/CD 管道如下所示：
- 开发人员有他们想要集成到项目中的代码
- 外部 CI 服务器执行“集成”测试——它获取源文件并尝试使用新代码进行构建。
- 如果构建成功完成，服务器会将更改与源文件打包在一起。如果没有，服务器会通知团队成员。
CI 引擎（如 Jenkins 或 Bamboo）有仪表板，显示当前和以前的构建、以前签入的日志及其状态（成功/失败）、发生了什么（以及何时）等。每个人都会随时了解代码的任何变化，基础设施或配置。这可确保及早发现（并修复）部署失败。
注意： “成功构建”和“高质量构建”之间存在差异。即使新的集成是成功的，在它通过 QA 工程师的一系列测试之前，它也不会被认为可以发布。这就是使用 Selenium 进行自动化测试的地方。
Selenium 自动执行频繁和重复的功能、性能和兼容性测试。这为开发人员提供了近乎即时的反馈，以加快调试速度，让他们有更多时间为新版本/功能编写业务逻辑。
现代 Web 开发需要 Selenium 测试，因为：
- 它自动重复测试大型（r）代码库的较小组件
- 它是敏捷开发和 CI/CD 不可或缺的一部分
- 它将资源从手动测试中解放出来
- 它始终可靠；捕获人类测试人员可能错过的错误
- 它可以提供广泛的测试覆盖率
- 很精确；可定制的错误报告是一个额外的加分项
- 它是可重复使用的；每次部署新功能时，您都可以重构和重用端到端测试脚本。
- 它是可扩展的；随着时间的推移，您可以为产品开发一个广泛的可重复测试用例库
Selenium 可以自动化哪些类型的测试？
通常使用 Selenium 自动化的测试类型有：
兼容性测试：
由 QA 专业人员/测试人员完成，以确保 Web 应用程序满足不同浏览器-操作系统组合的性能基准。例如，在不同的设备（移动设备和桌面设备）上进行测试，以确保前端适合规模（响应式）；在不同的浏览器上进行测试，以查看视频广告是否按应有的方式呈现在页面上。
性能测试：
由 QA 专业人员/测试人员进行的一系列测试，以确保项目符合利益相关者设定的性能基准。测试人员编写一个脚本，检查主页上的所有元素是否在 2 秒内在不同的浏览器/浏览器版本上加载。
集成测试：
由开发人员完成，以验证单独编码的单元/模块（独立工作），在组合在一起时也可以工作。例如，并行测试计算器具有单独的层。UI 接受输入，业务逻辑计算输出，然后将其发送回 UI 进行显示。测试人员可以验证他们是否能够在集成时中继数据/输出。
系统测试：
又名黑盒测试。由没有代码上下文或任何先前执行的测试的测试人员/QA 专业人员完成。通常以单个用户工作流程为中心。例如，产品网站上的结账流程包括：验证用户凭据、从购物车中获取产品、检查其可用性以及验证支付细节——然后再重定向到银行网站。测试人员可以编写一个脚本来验证整个系统是否正常工作。
端到端测试：
也由测试人员/质量保证专业人员完成，通常是从用户的角度来看。目的是验证网络应用程序上的所有接触点是否正常工作。从前面的示例中，测试人员可以编写一系列测试用例来检查注册、产品搜索、结帐、评论、书签和所有其他功能是否按预期运行（当在输入字段中输入无效值时会失败）。
回归测试：
进行了一系列测试，以确保新构建的功能可以与现有系统一起使用。在同一个例子中，假设产品网站推出了一项新功能（促销代码），该功能在结账前自动应用于符合条件的商品。测试人员可以编写案例来验证它不会破坏结帐功能的其余部分。
编写良好的测试套件还可以使用 Selenium 自动化 Smoke 和 Sanity 测试。
注意： Selenium 测试并不意味着取代手动测试。测试自动化，顾名思义，就是自动化那些不值得人类评估的东西。您无法自动测试新改进的 UI 以实现人类可用性。但对于其他一切，有 Selenium。
