Software Quality Assurance & Testing Asked by Ivan B on January 25, 2021
The case – I can get access to my AUT only from my company’s virtual machine, connecing to it by RDP.
I’m using jmeter’s jsr223 samples to create the load by means of a chromedriver (interacting with it by org.openqa.selenium methods, sending the instructions by http requests to localhost).
If i don’t add chromedriver.addOptions("--headless")
so that chromedriver actually opens a GUI chrome window, everything works fine. However, with –headless options something goes wrong – I start the chromedriver, get.url("http://AUT/login/page")
, fill usernamepassword fields, logging in succesfully, clicking the which opens a new window, switch to this window (I log every action, so I’m pretty sure, that until this moment everything works fine), but in this new window I’m trying to perform element.sendKeys
(which works ok in 99.9% cases in GUI mode) but, get a timeout exception (actually using wait.until(ExpectedConditions.ElementToBeClickable(By.xpath('//bla-bla/bla'))).sendKeys("zzzz");
) and always get a timeout exception.
When I log the hole document’s innerHTML, I can clearly see that //input i’m trying to access is present in the document.
Also tried to launch the –headless variant from my colleagues local machine (which also has access to AUT hosts) – everything works fine. However I’ll have to generate the load from hosts, accessed by RDP, and if the headless mode won’t work on it, I’ll be fired&killed (:. So can anyone please tell me, which group policies in Win7 can affect the headless chromedriver work?
Also I had to add ChromeOptions.setExpirementalOption("useAutomationExtension",false)
because without it, (even in non-headless mode) I get a warning box "Can't load extension from .... Loading of unpacked extensions is disabled by the administrator"
However, after clicking OK in this warning, the test continues without any problem.
It seems, that I’ll have to require some special Windows group policy modifications from my companies SysAdmins && security service for the success.
Updating chrome to v66 and chromedriver to v2.38 in combination with setting the following options:
ChromeOptions options = new ChromeOptions();
options.addArguments("--window-size=1920,1080");
options.addArguments("--disable-gpu");
options.addArguments("--disable-extensions");
options.setExperimentalOption("useAutomationExtension", false);
options.addArguments("--proxy-server='direct://'");
options.addArguments("--proxy-bypass-list=*");
options.addArguments("--start-maximized");
options.addArguments("--headless");
Solved the problem
Correct answer by Ivan B on January 25, 2021
After making following changes to my code -It started working like a charm :
options.addArguments("--window-size=1920,1080"); options.addArguments("--disable-gpu"); options.addArguments("--disable-extensions"); options.setExperimentalOption("useAutomationExtension", false); options.addArguments("--proxy-server='direct://'"); options.addArguments("--proxy-bypass-list=*"); options.addArguments("--start-maximized"); options.addArguments("--headless");
Answered by lakshmi sharada on January 25, 2021
I've been stuck trying to get a JMeter test to work running a headless Selenium (standalone) chromedriver script on a Docker instance, from my corporate Win machine. Ran fine on my personal Linux machine, but on the corporate network kept on being blocked by the proxy (ERR_NO_SUPPORTED_PROXIES network error). The proxy 'direct' trick worked. I know it's different issue to the OP's problem, but just documenting in case someone else finds this post. So the option that worked for me was just:
options.addArguments("--proxy-server=direct://")
Answered by metalRules on January 25, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP