什么是 WebDriver？

Scrapeless Agent Browser 通过为受支持的自动化客户端提供文档化接口来实现受管浏览器执行。

WebDriver 是一种用于网页浏览器的标准化远程控制接口。浏览器外部的程序使用 WebDriver 来请求导航、查找元素、执行交互操作以及检查浏览器状态。该协议与编程语言无关：不同的客户端库可以在依赖共享的通信与执行模型的前提下，表达浏览器操作。

WebDriver 通常是通过 Selenium 接触到的，但这两个术语指代的是不同的层。Selenium 提供浏览器自动化库和相关基础设施。WebDriver 定义了一个浏览器控制契约。特定浏览器的实现负责在被控制的浏览器环境中处理该契约的远程端。区分这些层可以让设置和诊断更加精确。

WebDriver 命令如何到达浏览器

WebDriver 客户端向控制浏览器的远程端发送命令。 WebDriver 远程控制规范 定义了命令模型、功能、会话和浏览器操作。

客户端可以在浏览器旁边运行，也可以通过远程基础设施进行连接。该部署选择会改变浏览器运行的位置，但不会改变对兼容命令契约这一基本需求。一个可访问的服务器不一定是 WebDriver 服务器，而用于控制浏览器的 URL 也不能与其他所有自动化端点互换。

命令的成功响应确立了该命令所定义的结果。导航操作并不一定表明客户端渲染的图表已完成。找到某个元素并不能确定它就是预期的实例，如果定位器匹配到多个相似的控件则更是如此。

应用断言提供缺失的含义。它们定义在某个操作之后必须出现的页面、记录或用户可见状态。协议负责驱动浏览器；测试或工作流则决定这种移动是否完成了任务。

WebDriver 会话是控制关系

WebDriver 会话标识客户端与浏览器环境之间的控制关系。会话创建会协商能力集，而后续命令则在生成的会话中执行。

功能用于表达需求并描述所选定的执行环境。它们有助于识别浏览器和受支持的行为，但并不能保证网站会返回预期的内容。同一浏览器会话可能会进入登录页面、空结果视图，或是一个内容完全填充的应用程序。

将 WebDriver 会话与网站身份验证分开。网站可以通过浏览器状态在服务器端维持登录。结束自动化会话并不一定会撤销该登录，而一个活动的自动化会话也不能保证网站登录仍然有效。

会话所有权应当是显式的。在开始需要会话的工作时创建会话，通过预期的工作流传递其控制权，并在该所有者完成时结束会话。在应用程序代码中丢失引用，与确认远程浏览器资源已被释放，是两回事。

定位器和元素引用具有不同的生命周期

定位器描述了如何查找一个元素，而元素引用标识的是在特定文档状态下找到的特定元素。这个区别解释了为什么引用会变得陈旧。

动态应用程序可能会在数据加载后替换某个控件。新控件可以具有相同的外观和选择器，但却是不同的节点。先前返回的引用不会自动变为对该替换控件的引用。

当页面发生变化时，请重新评估当前文档并再次定位目标元素。关键问题在于应用程序的状态是否仍然与即将执行的操作相匹配。导航前可用的定位器在导航后可能会匹配到其他内容，或者属于错误的页面。

优先选择与任务含义紧密相关的选择器。稳定的标识符、无障碍名称以及定义良好的应用属性通常比一长串穿过临时布局容器的路径更容易审查。无论你选择哪种定位器，都要确认它在工作流实际支持的页面变体中，确实能选中正确的控件。

等待意味着检查相关条件

在 WebDriver 中，等待是指在有限的时间内允许相关的应用程序条件变为真。 Selenium 等待策略 解释隐式等待和显式等待之间的区别，并警示在不了解它们的计时效果时不要将二者混合使用。

已完成的导航可以先于后续脚本活动发生。按钮可以在变为可用之前就已存在。表格可以在仍显示占位行的情况下可见。请选择描述下一个安全操作或最终有用结果的条件。

对于报告工作流，条件可能是预期的报告标题和已完成的结果区域已出现。对于表单，则可能是正确的控件已启用且没有覆盖层将其阻挡。固定延迟描述的是经过的时间，而不是应用程序是否已就绪。

失败的等待应保留足够的上下文来解释缺少了什么。捕捉预期条件、当前页面标识以及有限的诊断性观察。这能区分已更改的定位器、不同的页面或未完成的应用程序状态。

框架和窗口定义命令的作用范围

WebDriver 命令在选定的浏览器上下文中运行，因此定位正确的窗口或框架是正确性的组成部分。嵌入文档中的元素不是父文档 DOM 的普通后代。

《 HTML 浏览上下文模型 》描述了文档、窗口和嵌套内容之间的关系。在选择某个操作所属的文档时，工作流必须遵循这些关系。

假设某个应用嵌入了一个运费估算器。父文档里的定位器可以找到 iframe 元素，但无法找到估算器内部的表单控件。请选择目标框架，确认其文档已就绪，然后在该文档中查找控件。

弹出窗口提出了类似的问题。原始窗口可以保持打开状态，而所需输出在别处出现。应根据与任务相关的证据识别新窗口，而不是假定 API 返回的最后一个句柄总是正确的那个。在那里完成工作后，返回预期的父上下文。

Cookie 和应用会话构成网站状态

Cookie 可以将浏览器请求与网站状态关联起来，但它们与 WebDriver 会话并不相同。《 HTTP 状态管理机制 》定义了 Cookie 在其作用域内的存储和发送方式。

经过身份验证的测试应使用经批准的账号和刻意设定的起始状态。重用浏览器数据有助于满足连续性需求，但也可能掩盖依赖关系。测试之所以通过，可能只是因为前一个任务已经接受了某项同意选择或选定了一个位置。

将需要干净状态的测试与有意保留状态的任务区分开来。记录状态来源，但不要记录 Cookie 或凭据。如果登录在工作流过程中过期，应报告该结果，而不是把缺失的应用数据当作成功的空结果。

WebDriver 与其他浏览器接口的比较

WebDriver 是多种浏览器控制接口中的一种，合适的接口取决于所需的浏览器覆盖范围和操作类型。经典 WebDriver、WebDriver BiDi 和 CDP 具有不同的命令和观测模型。

不要仅凭库的名称来做选择。某个库可能暴露不止一种底层协议，或具有特定环境的限制。请确认精确的连接方式和操作，而不是凭类比在不同协议之间翻译连接示例。

规划 WebDriver 工作流

一个有用的 WebDriver 工作流会明确其起始状态、上下文切换、就绪检查、结果与清理。这些细节使其在开发者机器或远程基础设施上运行时都具有可维护性。

从一个具有代表性的应用路径开始。确定初始 URL、账号状态、视口和预期文档。对每次交互，都定义允许该交互的页面条件以及之后应有的状态。这样就能将一串点击转换为明确的行为契约。

在结束会话之前，验证生成的数据或可见状态。即便测试到达了最终 URL，如果应用显示了错误，也可能是不完整的。请在作业结果中区分协议错误、资源不可用和业务断言失败。

决策中 Scrapeless 所处的位置

Scrapeless Agent Browser 属于浏览器执行层。其 托管浏览器环境 和 Agent Browser 功能 应通过文档化的客户端接口进行评估，而不是假定存在任意的 WebDriver 端点。

关于 浏览器控制台和回放诊断 的讨论，为观测远程页面行为提供了相关背景。考虑托管执行时，请查阅 Scrapeless 定价 。本定义中并未宣称存在任何 WebDriver 与 Scrapeless 的集成或基准。

结论

WebDriver 为浏览器自动化提供了标准化的控制模型。可靠的工作流仍然依赖于特定应用的定位器、上下文选择、等待和断言。请将这些条件与会话生命周期一并定义，以便区分命令成功与任务成功。