Error de selenio: la solicitud HTTP al WebDriver remoto agotó el tiempo de espera después de 60 segundos

85

He estado usando Selenium durante varios meses, que estamos usando para automatizar algunos de nuestros procesos de prueba internos. Los guiones han ido bien. Recientemente actualicé a C # 2.40.0 webdriver usando FF 27.01 y nuestros scripts ahora fallan en lugares aleatorios con el siguiente error.

[Portal.SmokeTest.SmokeRunTest.Booking] TearDown method failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/element timed out after 60 seconds.
  ----> System.Net.WebException : The operation has timed out
TearDown : OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/window timed out after 60 seconds.
  ----> System.Net.WebException : The operation has timed out
[09:01:20]
[Portal.SmokeTest.SmokeRunTest.Booking] TearDown method failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/element timed out after 60 seconds.
  ----> System.Net.WebException : The operation has timed out
TearDown : OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/window timed out after 60 seconds.
  ----> System.Net.WebException : The operation has timed out
   at OpenQA.Selenium.Support.UI.DefaultWait`1.PropagateExceptionIfNotIgnored(Exception e)
   at OpenQA.Selenium.Support.UI.DefaultWait`1.Until[TResult](Func`2 condition)
   at Portal.Test.Helpers.Process_Bookings.OpenBookings.SelectBooking(String bookingnumber)
   at Portal.SmokeTest.SmokeRunTest.Booking() in d:\TeamCityAgent\work\dac1dcea7f2e80df\SmokeTests\SmokeRunTest.cs:line 68
--WebException
   at System.Net.HttpWebRequest.GetResponse()
   at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
--TearDown
   at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
   at OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
   at OpenQA.Selenium.Firefox.Internal.ExtensionConnection.Execute(Command commandToExecute)
   at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
   at OpenQA.Selenium.Remote.RemoteWebDriver.Close()
   at Portal.Test.Helpers.Setup.CloseWebdriver()
   at Portal.SmokeTest.SmokeRunTest.TearDown() in d:\TeamCityAgent\work\dac1dcea7f2e80df\SmokeTests\SmokeRunTest.cs:line 162
--WebException
   at System.Net.HttpWebRequest.GetResponse()
   at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)

El último error que logré rastrear en una sola línea de código:

_setup.driver.FindElement(By.XPath("//button[@class='buttonSmall lockBookingButton']")).Click();

Lo molesto es que tratar de solucionar el problema está resultando difícil, como si ejecutara la prueba en mi máquina local, en la depuración pasa. Además, si lo ejecuto a través del corredor NUNIT en la máquina de compilación en la que estoy ejecutando la prueba, también pasa. Solo parece fallar como parte de nuestro proceso de ejecución de compilación automatizado cuando se usa Teamcity. Como dije, esto ha estado funcionando bien durante meses antes, y lo único que ha cambiado es el kit de controlador web de selenio.

He experimentado este problema antes, mientras estaba en depuración, y cuando Click()se llamaba a una línea de código, Firefox parecía bloquearse y solo detener la prueba permitiría que Firefox continuara. Hay una serie de sugerencias aquí, incluida la modificación de la fuente del controlador web. Me gustaría no seguir ese camino si es posible si alguien más puede ofrecer alguna sugerencia.

Nathan
fuente
Tuvimos exactamente el mismo problema en varios proyectos independientes que usaban esta configuración y todavía no tenemos una solución para esto. Nuestra mejor apuesta fue cambiar a versiones anteriores de los ensamblajes WebDriver y Firefox. Tampoco sabemos si este comportamiento es causado por WebDriver o Firefox.
Dio F

Respuestas:

23

Tuve un problema similar al usar el controlador de Chrome (v2.23) / ejecutar las pruebas a través de TeamCity. Pude solucionar el problema agregando la marca "no-sandbox" a las opciones de Chrome:

var options = new ChromeOptions();
options.AddArgument("no-sandbox");

No estoy seguro de si existe una opción similar para el controlador FF. Por lo que entiendo, el problema tiene algo que ver con TeamCity ejecutando Selenium en la cuenta SYSTEM.

combatc2
fuente
esto también resuelve mi problema. Ya no pude ejecutar pruebas de Chrome después de meses sin probarlas. Gracias combatc2
Etienne
1
Mi código funcionaba bien en un entorno alojado en IIS y se detuvo repentinamente, pero aún funcionaba en mis pruebas unitarias. Agregar esta línea hizo que funcionara nuevamente en IIS env. ¡Gracias!
Legends
1
Lo eliminé como var options = new ChromeOptions(); options.AddArgument("--no-sandbox");Trabajando ahora en la versión C # Webdriver 3.14.
moto_geek
20
new FirefoxDriver(new FirefoxBinary(),new FirefoxProfile(),TimeSpan.FromSeconds(180));

Inicie su navegador usando las líneas de código anteriores. Funcionó para mí.

usuario2298124
fuente
Arreglado para nosotros también. Al ejecutar un script básico que acaba de crear un controlador FF y nada más, un tiempo de espera de 60 segundos funcionó el 100% del tiempo. Al ejecutar nuestro script con muchos recursos, que abre conexiones a bases de datos / lecturas / escrituras / hace mucho más inmediatamente antes de abrir FF, un tiempo de espera de 60 causaría fallas ~ 50% del tiempo. Aumentar el tiempo de espera a 3 minutos solucionó el problema. Parece que Webdriver solo necesita un poco más de tiempo para calentar el motor.
KayakinKoder
13

Encontré este problema por primera vez hace meses (también en el click()comando), y ha sido un problema para mí desde entonces. Parece haber algún tipo de problema con los enlaces de .NET Selenium. Esta publicación de blog del tipo que trabaja en el controlador de IE es útil para explicar lo que está sucediendo:

http://jimevansmusic.blogspot.com/2012/11/net-bindings-whaddaymean-no-response.html

Desafortunadamente, no parece haber una solución real a este problema. Siempre que se haya planteado este problema a los desarrolladores de Selenium ( ver aquí ), esta es una respuesta típica :

Necesitamos un escenario reproducible, que debe incluir una página de muestra o un enlace a la página de un sitio público donde se pueda reproducir el problema.

Si puede enviar un caso de prueba que se pueda reproducir de forma coherente, podría ser muy útil para acabar con este error para siempre.

Dicho esto, tal vez puedas probar esta solución mientras tanto. Si el botón HTML que está intentando click()tiene un onclickatributo que contiene Javascript, considere usar un JavascriptExecutor para ejecutar ese código directamente, en lugar de llamar al click()comando. Descubrí que ejecutar onclickJavascript directamente permite aprobar algunas de mis pruebas.

Daniel Charles
fuente
9

Tuve el mismo problema con Firefox. Cambié a Chrome con opciones y todo ha ido bien desde entonces.

ChromeOptions options = new ChromeOptions();
 options.AddArgument("no-sandbox");

 ChromeDriver driver = new ChromeDriver(ChromeDriverService.CreateDefaultService(), options, TimeSpan.FromMinutes(3));
 driver.Manage().Timeouts().PageLoad.Add(System.TimeSpan.FromSeconds(30));
Lawal
fuente
Probablemente me equivoque aquí, pero parece que la última línea no tendrá ningún efecto. PageLoad es un TimeSpan en sí mismo, y .Add on TimeSpan es una función pura, que no modifica PageLoad, simplemente devuelve un nuevo TimeSpan que se está descartando.
Jason Ritchie
3

En mi caso, el tipo de mi botón submitno lo es buttony lo cambio Clicka Sumbitentonces todo funciona bien. Algo como abajo

desde driver.FindElement(By.Id("btnLogin")).Click();

a driver.FindElement(By.Id("btnLogin")).Submit();

Por cierto, he probado todas las respuestas en esta publicación pero no me funcionan.

MichaelMao
fuente
3

Tengo un problema similar. Intente establecer más tiempo en el constructor del controlador; agregue, por ejemplo.

var timespan = TimeSpan.FromMinutes(3);

var driver = new FirefoxDriver(binary, profile, timeSpan);
Bart Wojtala
fuente
Hola bewu, ¿estaría en el formato que se muestra a continuación? driver.Manage (). Timeouts (). ImplicitlyWait (TimeSpan.FromSeconds (5));
Nathan
4
No, no esta espera ImplicitlyWait está relacionada con la búsqueda de elementos. Debe cambiar el tiempo de espera del controlador predeterminado (60 segundos), cuando espera a que se procese la solicitud (si no me equivoco). De todos modos, debe encontrar una línea en la que establezca el constructor del controlador FF y agregar allí más atributos o cambiar el tiempo de espera. Algo como:driver = new FirefoxDriver(new FirefoxBinary(), new FirefoxProfile(path to your profile), TimeSpan.FromMinutes(3));
Bart Wojtala
2
para ChromeDriver se vería asídriver = new ChromeDriver(service, chromeDriverOptions, TimeSpan.FromMinutes(3));
redwards510
2

Creo que este problema ocurre cuando intenta acceder a su objeto de controlador web después

1) una ventana se ha cerrado y aún no ha cambiado al padre

2) cambió a una ventana que no estaba lista y se actualizó desde que cambió

esperar a windowhandles.countque sea lo que esperas no tiene en cuenta el contenido de la página ni document.ready. Sigo buscando una solución a este problema

ribbo
fuente
2

En mi caso, es porque eliminé la carpeta de actualización de Chrome. Después de reinstalar Chrome, funciona bien.

gary.zhang
fuente
1

El problema es que la evaluación de los Click()tiempos de espera en su entorno de compilación ... es posible que desee profundizar en lo que sucede Click().

Además, intente agregar Retrys para el Click()porque ocasionalmente las evaluaciones toman más tiempo dependiendo de la velocidad de la red, etc.

poco
fuente
Hola, La opción de reintento no funcionará ya que el navegador simplemente se bloquea. Solo detener la prueba permite que el navegador continúe.
Nathan
1

En mi caso, encontré este error en el servidor de compilación de nuestros equipos. Las pruebas funcionaron en nuestras máquinas de desarrollo locales.

El problema era que el sitio web de destino no estaba configurado correctamente en el servidor de compilación, por lo que no podía abrir el navegador correctamente.

Estábamos usando el controlador de Chrome, pero no estoy seguro de que eso marque la diferencia.

Sean Tomlins
fuente
1

En mi caso, el problema fue con SendKeys () y Escritorio remoto . Publicando la solución alternativa que tengo hasta ahora:

Tuve una prueba de selenio que fallaba cuando se ejecutaba como parte de un trabajo de Jenkins en un nodo alojado en vSphere y administrado a través de RDP. Después de solucionar algunos problemas, resultó que tiene éxito si el Escritorio remoto está conectado y enfocado, pero falla con la excepción de si el Escritorio remoto está desconectado o incluso minimizado.

Como solución alternativa, inicié sesión a través de vSphere Console en lugar de RDP y luego, incluso después de cerrar vSphere, la prueba ya no fallaba. Esta es una solución alternativa, pero tendría que tener cuidado de no iniciar sesión nunca a través de RDP y siempre administrar solo a través de vSphere Console.

sashoalm
fuente
0

cambiar el Selenium.WebDriver.ChromeDriver de 2.40.0 a 2.27.0 está bien para mí

john liao
fuente
0

los new FirefoxDriver(binary, profile, timeSpan) ha sido obsoleto.

Ahora puedes usar new FirefoxDriver(FirefoxDriverService.CreateDefaultService(), FirefoxOptions options, TimeSpan commandTimeout) en lugar.

También hay un new FirefoxDriver(string geckoDriverDirectory, FirefoxOptions options, TimeSpan commandTimeout)y funciona. Pero no está documentado y debe especificar manualmentegeckoDriverDirectory aunque ya esté en formato Path.

imba-tjd
fuente
0

Tuvimos el mismo problema. En nuestro caso, el navegador fue bloqueado por una ventana emergente de inicio de sesión (autenticación de Windows), por lo que no regresó después de 60 segundos. La adición de los derechos de acceso correctos a la cuenta de Windows que Chrome se estaba ejecutando resolvió el problema.

Rogier van het Schip
fuente
0

Arrrgh! Enfrenté esto en macOS hoy y el problema fue tan simple como: la ventana emergente que sugería instalar la nueva versión de Appium se mostraba en el servidor de compilación de CI remoto.

Simplemente VNC'ing y haciendo clic en " Instalar más tarde " lo solucionó.

RAM237
fuente
0

En mi caso, ninguna de las respuestas anteriores resolvió mi problema por completo. Terminé usando el no-sandboxmodo ( ), la conexión con un período de tiempo de espera extendido ( driver = new RemoteWebDriver(new Uri("http://localhost:4444/wd/hub"), capability, TimeSpan.FromMinutes(3));) y el tiempo de espera de carga de la página ( driver.Manage().Timeouts().PageLoad.Add(System.TimeSpan.FromSeconds(30));), así que ahora mi código se ve así:

    public IWebDriver GetRemoteChromeDriver(string downloadPath)
    {
        ChromeOptions chromeOptions = new ChromeOptions();
        chromeOptions.AddArguments(
            "start-maximized",
            "enable-automation",
            "--headless",
            "--no-sandbox", //this is the relevant other arguments came from solving other issues
            "--disable-infobars",
            "--disable-dev-shm-usage",
            "--disable-browser-side-navigation",
            "--disable-gpu",
            "--ignore-certificate-errors");
        capability = chromeOptions.ToCapabilities();

        SetRemoteWebDriver();
        SetImplicitlyWait();
        Thread.Sleep(TimeSpan.FromSeconds(2));
        return driver;
    }
    
    private void SetImplicitlyWait()
    {
        driver.Manage().Timeouts().PageLoad.Add(TimeSpan.FromSeconds(30));
    }


    private void SetRemoteWebDriver()
    {
        driver = new RemoteWebDriver(new Uri("http://localhost:4444/wd/hub"), capability, TimeSpan.FromMinutes(3));
    }

Pero como mencioné, ninguno de los métodos anteriores resolvió mi problema, recibía continuamente el error y varios procesos chromedriver.exe y chrome.exe estaban activos (~ 10 del chromedriver y ~ 50 del chrome).

Entonces, en algún lugar leí que después de desechar el controlador debería esperar unos segundos antes de comenzar la siguiente prueba, así que agregué la siguiente línea para desechar el método:

    driver?.Quit();
    driver?.Dispose();
    Thread.Sleep(3000);

Con esta modificación de suspensión, ya no obtengo el error de tiempo de espera y no hay procesos chromedriver.exe y chrome.exe abiertos innecesariamente.

Espero haber ayudado a alguien que lucha con este problema durante tanto tiempo como lo hice.

turanszkik
fuente
0

Tuve la misma excepción al intentar ejecutar un ChromeDriver sin cabeza con una tarea programada en un servidor de Windows (desatendido). Lo que me solucionó es ejecutar la tarea como el usuario " Administradores " (observe la S al final). Lo que también hice (no sé si es relevante) es seleccionar "Cualquier conexión" de la pestaña "Condiciones" de la tarea.

SubconsultaCrunch
fuente
-1

Para ChromDriver, lo siguiente funcionó para mí:

string chromeDriverDirectory = "C:\\temp\\2.37";
 var options = new ChromeOptions();
 options.AddArgument("-no-sandbox");
 driver = new ChromeDriver(chromeDriverDirectory, options, 
 TimeSpan.FromMinutes(2));

Selenium versión 3.11, ChromeDriver 2.37

R2D2
fuente