【问题标题】:How to ScrollIntoView when the browser is minimized through Selenium and C#通过Selenium和C#最小化浏览器时如何ScrollIntoView
【发布时间】:2019-03-10 14:19:05
【问题描述】:

如何在浏览器最小化的情况下滚动到元素?

目前我有这个代码:

IWebElement scrollnextpage = driver.FindElement(By.XPath("//a[" + x + "][contains(@class, 'paged-nav-item')]"));
                                    js.ExecuteScript("arguments[0].scrollIntoView({behavior: 'smooth', block: 'center'});", scrollnextpage);

这工作正常,但是当我最小化我的浏览器时它停止工作。 有什么解决办法吗?

【问题讨论】:

  • 尝试使用动作类var element = driver.FindElement(By.id("element-id")); Actions actions = new Actions(driver); actions.MoveToElement(element); actions.Perform();
  • 我试图使用它,但这完全不起作用。我发现一些信息表明该类不再受支持。
  • 好的,是否需要最小化浏览器?您可以切换到其他窗口并重新激活上述浏览器并继续测试。只是一个想法。
  • 嗯,alt+tab 可以正常工作,但我不想告诉每个用户在测试期间他不能最小化浏览器。像 js.executeScript("window.scrollBy(0,1000)"); 这样的简单方法最小化时工作,但我不能在我的程序中使用它,它必须滚动到视图中
  • 在这种情况下使用无头浏览器选项

标签: c# selenium selenium-webdriver webdriver scrollview


【解决方案1】:

直接回答,当您启动测试执行时,浏览器客户端不应保持最小化。当你使用 Selenium 来执行你的程序/脚本时,Selenium 需要 Browser Client 上的 focus 来呈现HTML DOM.

为什么不应该最小化浏览器?

软件测试自动化是一门艺术。 测试执行必须在受控环境中执行以优化性能。

  • 特别是当您的@Tests 是基于Selenium 时,测试执行应该在Viewport 最大化的情况下进行,原因如下:

    • 在最低级别,actionsclass 的行为旨在尽可能接近地模拟远程端与实际输入设备的行为,实施策略可能涉及例如将合成事件注入浏览器事件循环。因此,发送动作的步骤将不可避免地在特定于实现的领域中结束。但是,某些内容可观察到的效果必须在实现之间保持一致。为了适应这一点,规范要求远程端执行特定于实现的动作分派步骤,以及事件列表及其属性。这个列表并不全面;特别是输入源的默认操作可能会导致根据浏览器的实现和状态生成其他事件(例如,当焦点位于可编辑元素上时,与键操作相关的输入事件、滚动事件等)。
  • 此外,

    • 由 WebDriver API 用户生成的激活触发器必须与由与浏览器交互的真实用户生成的触发器没有区别。特别是,调度的事件将 isTrusted 属性设置为 true。调度这些事件的最可靠方法是在浏览器实现本身中创建它们。将特定于操作系统的输入消息发送到浏览器窗口的缺点是,正在自动化的浏览器可能无法与用户意外修改输入源状态正确隔离。使用操作系统级别的可访问性 API 的缺点是浏览器的窗口必须聚焦,因此多个 WebDriver 实例无法并行运行。

    • 操作系统级别的可访问性 API 的一个优点是它可以保证输入正确反映用户输入,并在必要时允许与主机操作系统进行交互。但是,从机器利用率的角度来看,这可能会降低性能。

  • 另外,

    • Robot Class 用于生成本地系统输入事件,用于测试自动化、自运行演示和其他需要控制鼠标和键盘的应用程序。 Robot 的主要目的是促进 Java 平台实现的自动化测试。使用类生成输入事件与将事件发布到 AWT 事件队列或 AWT 组件的不同之处在于,事件是在平台的本机输入队列中生成的。例如,Robot.mouseMove 将实际移动鼠标光标,而不仅仅是生成鼠标移动事件。
  • 最后,按照Internet Explorer and Native Events

    • 由于 InternetExplorerDriver 仅适用于 Windows,它会尝试使用所谓的“本机”或操作系统级别的事件在浏览器中执行鼠标和键盘操作。这与使用模拟的 JavaScript 事件进行相同的操作形成对比。使用本机事件的优点是它不依赖于 JavaScript 沙箱,并且可以确保在浏览器中正确地传播 JavaScript 事件。但是,当 IE 浏览器窗口没有焦点以及尝试将鼠标悬停在元素上时,当前存在一些鼠标事件问题。
  • 浏览器焦点:

    • 挑战在于,如果窗口没有焦点,IE 本身似乎不完全尊重我们发送给 IE 浏览器窗口(WM_MOUSEDOWN 和 WM_MOUSEUP)的 Windows 消息。具体来说,被点击的元素会收到一个围绕它的焦点窗口,但点击不会被该元素处理。可以说,我们根本不应该发送消息。相反,我们应该使用 SendInput() API,但该 API 明确要求窗口具有焦点。我们与 WebDriver 项目有两个相互冲突的目标。

    • 首先,我们努力尽可能地模拟用户。这意味着使用原生事件而不是使用 JavaScript 模拟事件。

    • 其次,我们不希望自动聚焦浏览器窗口。这意味着仅将浏览器窗口强制置于前台是次优的。

结论

在开始测试执行时始终保持浏览器 最大化

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-07-27
    • 2016-10-14
    • 2018-10-06
    • 1970-01-01
    • 1970-01-01
    • 2019-03-01
    • 2019-03-13
    相关资源
    最近更新 更多