通过Selenium和C#最小化浏览器时如何滚动查看

时间:2019-03-10 14:19:06

标签: c# selenium selenium-webdriver webdriver scrollview

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

当前我有以下代码:

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

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

1 个答案:

答案 0 :(得分:0)

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

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

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

  • 尤其是当您的@Tests基于 Selenium 时,出于以下原因,应以最大化的Viewport进行测试执行

    • 在最低级别上,actions class 的行为旨在尽可能接近地模仿具有实际输入设备的远端的行为,并且实现策略可能涉及例如将综合事件注入浏览器事件循环。因此,分派行动的步骤将不可避免地终止于特定于实现的领域。但是,某些内容可观察到的效果必须在实现之间保持一致。为了适应这一点,该规范要求远端执行特定于实现的动作分派步骤,以及事件及其属性的列表。此列表并不全面;特别是,输入源的默认操作可能会导致其他事件,具体取决于浏览器的实现方式和状态(例如,与焦点位于可编辑元素上时的键操作有关的输入事件,滚动事件等)。
  • 此外,

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

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

  • 此外,

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

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

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

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

    • 第二,我们不想让浏览器窗口自动聚焦。这意味着仅将浏览器窗口强制为前台是次优的。

结论

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