打开Selenium浏览器的方法,而不是覆盖我的当前浏览器

开始 软件测试自动化 是一门艺术。你的 试验台 应该是:

• 配置了所有必需的 软件 , 图书馆 和 二进制文件 .
• 测试执行 必须在受控环境中执行才能优化性能。
• 当你 @Tests 正在执行,应该没有 人工干预 .

• 尤其是当你 @测试 是 硒 基于,而 测试执行 是 正在进行中 这个 测试环境 不应干预,因为:

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

• 此外,

  • WebDriverAPI用户生成的激活触发器需要与实际用户与浏览器交互生成的激活触发器不可区分。尤其是,已调度的事件的istrusted属性将设置为true。调度这些事件的最可靠的方法是在浏览器实现本身中创建它们。将特定于操作系统的输入消息发送到浏览器窗口有一个缺点,即被自动处理的浏览器可能无法与用户意外修改输入源状态的情况正确隔离。使用操作系统级的可访问性API有一个缺点,即浏览器窗口必须集中,因此,多个WebDriver实例不能并行运行。

  • 操作系统级可访问性API的一个优点是,它确保输入正确镜像用户输入,并允许在必要时与主机操作系统进行交互。然而,从机器使用的角度来看,这可能会对性能造成影响。

• 此外,

  • Robot Class 用于生成本机系统输入事件,以实现测试自动化、自运行演示和其他需要控制鼠标和键盘的应用程序。机器人的主要目的是促进对Java平台实现的自动化测试。使用类生成输入事件不同于将事件发布到awt事件队列或awt组件,因为这些事件是在平台的本机输入队列中生成的。例如,robot.mouse move将实际移动鼠标光标,而不只是生成鼠标移动事件。

• 最后,按照 Internet Explorer and Native Events :

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

• 浏览器焦点:

  • 挑战在于,如果窗口没有焦点,IE本身似乎没有完全尊重我们发送给IE浏览器窗口(wm_mousedown和wm_mouseup)的Windows消息。具体来说,被单击的元素将在其周围接收一个焦点窗口,但元素不会处理单击。可以说,我们根本不应该发送消息;相反,我们应该使用sendinput()API,但该API显式要求窗口具有焦点。我们有两个与WebDriver项目冲突的目标。

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

  • 第二,我们不希望浏览器窗口的焦点被自动化。这意味着仅仅强迫浏览器窗口进入前台是次优的。

结论

始终保持 测试环境 分开 开发环境 绝对没有 人工干预 .

浏览器是显示在当前浏览器上,还是显示在后台,取决于驱动程序的实现以及从浏览器到浏览器的变化——它不依赖于硒元素或宁静。不过,我通常在chrome模式下以headless模式运行测试,这完全消除了问题。