Errore selenio: la richiesta HTTP al WebDriver remoto è scaduta dopo 60 secondi


85

Uso Selenium da diversi mesi, che stiamo utilizzando per automatizzare alcuni dei nostri processi di test interni. Le sceneggiature stanno passando bene. Di recente ho aggiornato al webdriver C # 2.40.0 utilizzando FF 27.01 e ora i nostri script non funzionano in modo casuale con il seguente errore.

[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)

L'ultimo errore che sono riuscito a rintracciare in una singola riga di codice:

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

La cosa fastidiosa è che cercare di risolvere il problema si sta rivelando difficile, come se eseguissi il test sulla mia macchina locale, in debug passa. Inoltre, se lo eseguo tramite il runner NUNIT sulla macchina di build su cui sto eseguendo il test, anche esso passa. Sembra fallire solo come parte del nostro processo di build automatizzato quando si utilizza Teamcity. Come ho detto, questo funziona bene da mesi e l'unica cosa che è cambiata è il kit del webdriver al selenio.

Ho riscontrato questo problema in passato, durante il debug, e quando è Click()stata chiamata una riga di codice, Firefox sembrava bloccarsi e solo l'arresto del test avrebbe permesso a Firefox di continuare. Ci sono una serie di suggerimenti qui inclusa la modifica della fonte del webdriver? Mi piacerebbe non seguire quella strada se possibile se qualcun altro può offrire qualche suggerimento.


Abbiamo riscontrato esattamente lo stesso problema in diversi progetti indipendenti che utilizzavano questa configurazione e non abbiamo ancora soluzioni alternative per questo. La nostra scommessa migliore era eseguire il downgrade alle versioni precedenti degli assembly WebDriver e Firefox. Inoltre non sappiamo se questo comportamento sia causato da WebDriver o Firefox.
Dio F

Risposte:


23

Ho avuto un problema simile utilizzando il driver Chrome (v2.23) / eseguendo i test tramite TeamCity. Sono stato in grado di risolvere il problema aggiungendo il flag "no-sandbox" alle opzioni di Chrome:

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

Non sono sicuro che esista un'opzione simile per il driver FF. Da quello che ho capito, il problema ha qualcosa a che fare con TeamCity che esegue Selenium con l'account SYSTEM.


questo risolve anche il mio problema. Non sono stato più in grado di eseguire i test di Chrome dopo mesi in cui non li ho provati. Grazie combatc2
Etienne

1
Il mio codice funzionava correttamente in un ambiente ospitato da IIS e si è interrotto improvvisamente, ma ha funzionato ancora nei miei unit test. L'aggiunta di questa riga lo ha fatto funzionare di nuovo in IIS env. Grazie!
Leggende

1
L'ho considerato come var options = new ChromeOptions(); options.AddArgument("--no-sandbox");Funzionante ora nella versione C # Webdriver 3.14.
moto_geek

20
new FirefoxDriver(new FirefoxBinary(),new FirefoxProfile(),TimeSpan.FromSeconds(180));

Avvia il browser utilizzando le righe di codice sopra. Ha funzionato per me.


Risolto anche per noi. Quando si esegue uno script di base che ha appena creato un driver FF e nient'altro, un timeout di 60 secondi ha funzionato il 100% delle volte. Quando si esegue il nostro script ricco di risorse, che apre le connessioni ai database / legge / scrive / fa molto di più immediatamente prima di aprire FF, un timeout di 60 causerebbe errori ~ 50% delle volte. L'aumento del timeout a 3 minuti ha risolto il problema. Sembra che Webdriver abbia solo bisogno di un po 'più di tempo per riscaldare il motore.
KayakinKoder

13

Ho riscontrato questo problema per la prima volta mesi fa (anche su click()comando) e da allora è stato un problema per me. Sembra esserci una sorta di problema con le associazioni .NET Selenium. Questo post sul blog del ragazzo che lavora sul driver IE è utile per spiegare cosa sta succedendo:

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

Sfortunatamente, non sembra esserci una vera soluzione a questo problema. Ogni volta che questo problema è stato sollevato dagli sviluppatori Selenium ( vedi qui ), questa è una risposta tipica :

Abbiamo bisogno di uno scenario riproducibile, che deve includere una pagina di esempio o un collegamento alla pagina di un sito pubblico in cui il problema può essere riprodotto.

Se sei in grado di inviare un test case riproducibile in modo coerente, potrebbe essere molto utile per porre fine a questo bug per sempre.

Detto questo, forse nel frattempo puoi provare questa soluzione alternativa. Se il pulsante HTML che stai provando click()ha un onclickattributo che contiene Javascript, considera l'utilizzo di un JavascriptExecutor per eseguire quel codice direttamente, piuttosto che chiamare il click()comando. Ho scoperto che l'esecuzione onclickdiretta di Javascript consente il superamento di alcuni dei miei test.


9

Ha avuto lo stesso problema con Firefox. Sono passato a Chrome con le opzioni e da allora è andato tutto bene.

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));

Probabilmente mi sbaglio qui, ma sembra che l'ultima riga non avrà alcun effetto. PageLoad è esso stesso un TimeSpan e .Add on TimeSpan è una funzione pura, che non modifica PageLoad ma restituisce semplicemente un nuovo TimeSpan che viene scartato.
Jason Ritchie

3

Nel mio caso, il tipo del mio pulsante submitnon è buttone cambio il Clickper Sumbitpoi ogni lavoro buono. Qualcosa come sotto,

a partire dal driver.FindElement(By.Id("btnLogin")).Click();

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

BTW, ho provato tutte le risposte in questo post ma non funzionano per me.


3

Ho riscontrato un problema simile. Prova a impostare più tempo nel costruttore del driver - aggiungi ad es.

var timespan = TimeSpan.FromMinutes(3);

var driver = new FirefoxDriver(binary, profile, timeSpan);

Ciao bewu, sarebbe nel formato come il seguente? driver.Manage (). Timeouts (). ImplicitlyWait (TimeSpan.FromSeconds (5));
Nathan

4
No, non questa attesa ImplicitlyWait è collegata alla ricerca di elementi. È necessario modificare il timeout del driver predefinito (60sec), quando attende che la richiesta venga eseguita (se non sbaglio). Ad ogni modo devi trovare una riga in cui impostare il costruttore del driver FF e aggiungervi altri attributi o modificare il timeout. Qualcosa del tipo:driver = new FirefoxDriver(new FirefoxBinary(), new FirefoxProfile(path to your profile), TimeSpan.FromMinutes(3));
Bart Wojtala

2
per ChromeDriver sembrerebbedriver = new ChromeDriver(service, chromeDriverOptions, TimeSpan.FromMinutes(3));
redwards510

2

Penso che questo problema si verifichi quando si tenta di accedere all'oggetto del driver Web dopo

1) una finestra si è chiusa e non sei ancora passato al genitore

2) sei passato a una finestra che non era ancora pronta ed è stata aggiornata da quando sei passato

aspettare windowhandles.countche sia quello che ti aspetti non tiene conto del contenuto della pagina né document.ready. Sto ancora cercando una soluzione a questo problema


2

Nel mio caso, è perché ho eliminato la cartella degli aggiornamenti di Chrome. Dopo la reinstallazione di Chrome, funziona correttamente.


1

Il problema è che la valutazione dei Click()timeout sull'ambiente di compilazione .. potresti voler approfondire cosa succede Click().

Inoltre, prova ad aggiungere Retrys per il Click()perché occasionalmente le valutazioni richiedono più tempo a seconda delle velocità di rete, ecc


Salve, l'opzione Riprova non funzionerà poiché il browser si blocca. Solo l'arresto del test consente al browser di continuare.
Nathan

1

Nel mio caso ho riscontrato che questo errore si verificava nel server di build dei nostri team. I test hanno funzionato sulle nostre macchine di sviluppo locali.

Il problema era che il sito Web di destinazione non era configurato correttamente sul server di compilazione, quindi non poteva aprire correttamente il browser.

Stavamo usando il driver cromato ma non sono sicuro che faccia la differenza.


1

Nel mio caso il problema riguardava SendKeys () e Remote Desktop . Pubblicando la soluzione alternativa che ho finora:

Ho eseguito un test sul selenio che falliva se eseguito come parte di un lavoro Jenkins su un nodo ospitato in vSphere e amministrato tramite RDP. Dopo un po 'di risoluzione dei problemi si è scoperto che riesce se Remote Desktop è connesso e focalizzato, ma non riesce con l'eccezione se Remote Desktop è disconnesso o addirittura ridotto a icona.

Come soluzione alternativa, ho effettuato l'accesso tramite vSphere Console anziché RDP e quindi, anche dopo aver chiuso vSphere, il test non ha avuto esito positivo. Questa è una soluzione alternativa, ma dovrei stare attento a non accedere mai tramite RDP e ad amministrare sempre solo tramite vSphere Console.


0

cambiare Selenium.WebDriver.ChromeDriver da 2.40.0 a 2.27.0 va bene per me


0

Il new FirefoxDriver(binary, profile, timeSpan)è stato obsoleto.

Ora puoi usare new FirefoxDriver(FirefoxDriverService.CreateDefaultService(), FirefoxOptions options, TimeSpan commandTimeout)invece.

C'è anche un new FirefoxDriver(string geckoDriverDirectory, FirefoxOptions options, TimeSpan commandTimeout)e funziona. Ma non è documentato e devi specificarlo manualmente geckoDriverDirectoryanche se è già in Path.


0

Abbiamo avuto lo stesso problema. Nel nostro caso, il browser è stato bloccato da un popup di accesso (autenticazione di Windows), quindi non è tornato dopo 60 secondi. L'aggiunta dei diritti di accesso corretti all'account Windows in cui era in esecuzione Chrome ha risolto il problema.


0

Arrrgh! Ho affrontato questo problema su macOS oggi e il problema era semplice come: la finestra pop-up che suggerisce di installare la nuova versione di Appium veniva visualizzata sul server di build CI remoto.

Basta eseguire VNC su di esso e fare clic su " Installa in seguito " per risolverlo .


0

Nel mio caso nessuna delle risposte sopra ha risolto completamente il mio problema. Ho finito per usare la no-sandboxmodalità ( ), la connessione con periodo di timeout esteso ( driver = new RemoteWebDriver(new Uri("http://localhost:4444/wd/hub"), capability, TimeSpan.FromMinutes(3));) e il timeout di caricamento della pagina ( driver.Manage().Timeouts().PageLoad.Add(System.TimeSpan.FromSeconds(30));), quindi ora il mio codice ha questo aspetto:

    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));
    }

Ma come ho già detto, nessuno dei metodi sopra ha risolto il mio problema, ho ricevuto continuamente l'errore e più processi chromedriver.exe e chrome.exe erano attivi (~ 10 del chromedriver e ~ 50 del chrome).

Quindi da qualche parte ho letto che dopo aver eliminato il driver avrei dovuto aspettare alcuni secondi prima di iniziare il prossimo test, quindi ho aggiunto la seguente riga per smaltire il metodo:

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

Con questa modifica del sonno non ho più l'errore di timeout e non ci sono processi chromedriver.exe e chrome.exe aperti inutilmente.

Spero di aver aiutato qualcuno che lotta con questo problema per tutto il tempo che ho fatto.


0

Ho avuto la stessa eccezione quando ho provato a eseguire un ChromeDriver headless con un'attività pianificata su un server Windows (incustodito). Ciò che ha risolto per me è stato eseguire l'attività come utente " Amministratori " (notare la S alla fine). Quello che ho fatto anche io (non so se è rilevante) è stato selezionato "Qualsiasi connessione" dalla scheda "Condizioni" dell'attività.


-1

Per ChromeDriver il seguente ha funzionato per me:

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

Selenium versione 3.11, ChromeDriver 2.37

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.