使用Python将Selenium Chrome实例发送到后台

问题描述

我正在尝试使用Python和Selenium打开一个简单的Chrome实例.请在下面找到我的代码:

I am trying to open a simple chrome instance using Python and selenium.Please find my code below:

import time, datetime, sys, os
start_time = time.time()
from datetime import datetime
os.system("cls")
from selenium import webdriver
from selenium.webdriver.common.keys import Keys
from selenium.common.exceptions import TimeoutException
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.options import Options

CHROME_PATH = 'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe'
CHROMEDRIVER_PATH = 'C:\\Users\\'+userID+'\\'+filename+'\\chromedriver.exe'
WINDOW_SIZE = "1920,1080"

chrome_options = Options()
chrome_options.add_argument("--window-size=%s" % WINDOW_SIZE)
chrome_options.add_argument("disable-gpu")
chrome_options.add_argument("disable-infobars")
chrome_options.add_argument("--disable-notifications")
chrome_options.binary_location = CHROME_PATH

browser = webdriver.Chrome(executable_path=CHROMEDRIVER_PATH,chrome_options=chrome_options)
time.sleep(1)
browser.get("https://www.google.com")
os.system("cls")
time.sleep(2)

我希望在后台打开它，即当我键入其他内容时，一旦打开此自动chrome实例，鼠标/光标焦点就不应随机进入.

I would like this to open in the background ie when I am typing something else the mouse/cursor focus should not randomly go to this automated chrome instance once it opens.

限制:请注意以下限制:

Limitations: Please note the below limitations:

1. 我不能使用"--headless"
2. 我不能使用phantomJS
3. 我无法使用PyVirtualDisplay，因为最终将为最终用户在Windows机器上部署代码(exe文件).

是否还有其他方法可以将此chrome实例推送到背景?谢谢

Would there be any other way to push this chrome instance to the background?Thanks

推荐答案

在 Browser Client 中，没有没有编程方式可以打开背景或 背景流程 .

There is no programatic way to open in the Browser Client at the background or as a Background Process.

粗略的替代方法是使用 Headless浏览器，您可以在.

Of coarse the alternative way is to use a Headless Browser and you can find a detailed discussion in Which drivers support "no-browser"/"headless" testing?.

软件测试自动化是一门艺术.您的 Test Framework 应该是:

Software Test Automation is an art. Your Test Framework should be:

• 配置了所有必需的软件，库和 binaries .
• 测试执行必须在受控环境中执行，以优化性能.
• 您的@Tests在执行时，应该没有人工干预.

• 尤其是当您的@Tests是基于硒的，而测试执行是 InProgress 测试环境时em>不应出于以下原因进行干预:

• Configured with all the required softwares, libraries and binaries.
• Test Execution must be performed in a controled environment for optimized performance.
• While your @Tests are executing, it should be free from Manual Intervention.

• Particularly when your @Tests are Selenium based, while test execution is InProgress the Test Environment shouldn't be intervened because of the following reasons:

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

• At the lowest level, the behavior of actions class is intended to mimic the remote end's behavior with an actual input device as closely as possible, and the implementation strategy may involve e.g. injecting synthesized events into a browser event loop. Therefore the steps to dispatch an action will inevitably end up in implementation-specific territory. However there are certain content observable effects that must be consistent across implementations. To accommodate this, the specification requires that remote ends perform implementation-specific action dispatch steps, along with a list of events and their properties. This list is not comprehensive; in particular the default action of the input source may cause additional events to be generated depending on the implementation and the state of the browser (e.g. input events relating to key actions when the focus is on an editable element, scroll events, etc.).

此外，

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

• An activation trigger generated by the WebDriver API user needs to be indistinguishable from those generated by a real user interacting with the browser. In particular, the dispatched events will have the isTrusted attribute set to true. The most robust way to dispatch these events is by creating them in the browser implementation itself. Sending OS-specific input messages to the browser's window has the disadvantage that the browser being automated may not be properly isolated from a user accidentally modifying input source state. Use of an OS-level accessibility API has the disadvantage that the browser's window must be focused, and as a result, multiple WebDriver instances cannot run in parallel.

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

An advantage of an OS-level accessibility API is that it guarantees that inputs correctly mirror user input, and allows interaction with the host OS if necessary. This might, however, have performance penalties from a machine utilisation perspective.

此外，

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

最后，按照 Internet Explorer和本地事件:

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

浏览器焦点:

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

• The challenge is that IE itself appears to not fully respect the Windows messages we send the IE browser window (WM_MOUSEDOWN and WM_MOUSEUP) if the window doesn't have the focus. Specifically, the element being clicked on will receive a focus window around it, but the click will not be processed by the element. Arguably, we shouldn't be sending messages at all; rather, we should be using the SendInput() API, but that API explicitly requires the window to have the focus. We have two conflicting goals with the WebDriver project.

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

First, we strive to emulate the user as closely as possible. This means using native events rather than simulating the events using JavaScript.

第二，我们不希望将浏览器窗口的焦点自动化.这意味着仅将浏览器窗口强制为前台是次优的.

Second, we want to not require focus of the browser window being automated. This means that just forcing the browser window to the foreground is suboptimal.

始终将测试环境与开发环境分开，并且完全摆脱人工干预.

Always keep the Test Environment seperate from Development Environment and absolutely free from Manual Intervention.

这篇关于使用Python将Selenium Chrome实例发送到后台的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！