Selenium WebDriver lancia sporadicamente le eccezioni Timeout

Usando il selenium per i test degli ui sul nostro progetto. Stiamo eseguendo la versione più recente 2.30.0. Usiamo Firefox WebDriver e stiamo eseguendo Firefox 19.0.

In generale, il test dell’interfaccia utente funziona localmente e anche sul lato server quando eseguo il test dell’interfaccia utente in Visual Studio. I nostri test dell’interfaccia utente vengono eseguiti nettamente sul nostro server di build. Utilizza la stessa distribuzione sullo stesso server che collaudo manualmente tramite Visual Studio.

Ma sporadicamente ci imbattiamo nel seguente problema quando il test dell’interfaccia utente viene eseguito su buildserver:

Test(s) failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL http://localhost:7056/hub/session/bed1d0e7-efdc-46b6-ba07-34903519c44d/element/%7B8717bb19-96c7-44d3-b0ee-d4b989ae652d%7D/click timed out after 60 seconds. ----> System.Net.WebException : The operation has timed out at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request) at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters) --WebException at System.Net.HttpWebRequest.GetResponse() at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request) 

In sostanza, il test fa clic su un pulsante di caricamento in cui il campo di input è stato precedentemente compilato con un file. Poiché il file è molto piccolo, questo viene eseguito in pochi secondi. Tuttavia a volte il limite di 60 secondi viene raggiunto.

Qualche idea su come isolare il problema sottostante? O eseguire qualcuno prima nello stesso problema? Ogni suggerimento è apprezzato. Grazie.

Ho ottenuto lo stesso errore: .NET WebDriver: 2.37, FF: 25.0.1. Ho notato che Firefox si bloccava fino all’uscita dalla mia applicazione di test, quindi ho creato la versione di debug di Firefox e ho scoperto che il blocco si verificava quando scriveva su stderr. Questo mi ha dato l’indizio di cambiare il codice del webdriver in modo che non reindirizzasse più lo standard e l’errore e questo risolvesse il mio problema. Sembra che WebDriver stia bloccando l’errore std in qualche modo. Da MSDN:

Le operazioni di lettura sincrone introducono una dipendenza tra la lettura del chiamante dallo stream StandardError e il processo figlio che scrive su quel stream. Queste dipendenze possono causare condizioni di deadlock …

Maggiori informazioni qui .

Per chiunque voglia fare lo stesso tweak che ho fatto: –

  1. Ottieni la fonte del selenium. Quindi controlla lo stesso ramo di codice che stai utilizzando.

  2. In FireFoxBinary.cs:

    io. Laddove trovi RedirectStandardError = true , passa a RedirectStandardError = false .

    ii. Laddove trovi RedirectStandardOutput = true , passa a RedirectStandardOutput = false . (per non Windows, ce n’è anche uno in Executable.cs)

    iii. In ConsoleOut, cambia “restituisci this.stream.ReadToEnd ()”, “restituisci” “”

  3. Crea e sostituisci WebDriver.dll con il tuo.

Disclaimer: questo ha funzionato per me, ma il problema potrebbe essere diverso. Inoltre, per quanto posso dire, questo non ha effetti negativi se non disabilitare l’output della console, ma potrebbero esserci altri effetti collaterali di cui non sono a conoscenza.

Sarei interessato a sapere se qualcun altro trova lo stesso.

Da quando ho risolto il mio problema, non scaverò più a fondo. Se qualcuno un membro del gruppo Selenium desidera maggiori informazioni / log / tweaks sarei felice di farlo.

Spero che questo verrà risolto presto.

Aggiornare

Sembra che Firefox v25 non sia attualmente supportato. Vedi questo commento .

Aggiornamento 25 febbraio 2014

Vedi questo aggiornamento :

Va bene, questo problema in generale non si manifesta in IE, o così sembra dai commenti. Mi piacerebbe che le persone provassero con Firefox e Chrome, e le associazioni .NET 2.40.0 (sarà la prossima versione al momento della stesura di questo documento) o successive, e vedremo se questo sta ancora accadendo.

Ho visto un minor numero di segnalazioni di ciò che accade in Chrome dal 2.35.0, quindi ho bisogno di sapere se questo è ancora un problema con i binding .NET e un recente chromedriver.exe.

2.40.0 potrebbe avere una soluzione per almeno uno dei problemi che potrebbero causare questo in Firefox.

Questo ha risolto il problema per me. Guardando il registro delle modifiche, c’è un commit dal 1/31/2014 per rimuovere il reindirizzamento della registrazione della console:

 "No longer redirecting console output for Firefox in .NET bindings." 

Qual è la soluzione che ho usato qui. Quindi, tutto ha un senso.

Mi è successo in quattro diversi scenari:

  1. La causa era che l’handle della finestra che stavo interrogando era già chiuso o in fase di chiusura. Se questo è il caso, è meglio controllare che la finestra esista ancora prima di interrogarla. Se si desidera evitare il lungo periodo di timeout di 60 secondi, è necessario modificare il modo in cui si crea l’istanza di Firefox per ridurre il ritardo di 60 secondi:

    nuovo FirefoxDriver (“FfBinaryPath”, FfProfileInstance, TimeSpan.FromSeconds (5));

  2. La causa era il plugin Flash ‘Modalità protetta’. Questo scenario mi è successo solo sotto Windows 7 e 8 quando hanno funzionato sotto il lavoro di Jenkins, il timeout non è accaduto sporadicamente. Per risolvere il problema, ho eseguito l’istanza di selenium Firefox con la modalità di protezione flash disabilitata:

    FfProfile.SetPreference (“dom.ipc.plugins.flash.disable-protected-mode”, true);

  3. Un’altra causa, anche non sporadica, in Jenkins e correlata a Flash, si è verificata durante l’utilizzo della versione 45 di Firefox. Per risolvere questo problema è stato necessario eseguire il downgrade alla versione 44 o, in alternativa, disinstallare Flash.

  4. Motivo interno del browser: a volte il browser impiega più di un minuto per rispondere alle chiamate Selenio. In tal caso, l’impostazione del timeout del comando del browser superiore a 60 secondi può risolvere il problema. per esempio:

    new FirefoxDriver("FfBinaryPath", FfProfileInstance, TimeSpan.FromMinutes(3));

Ho avuto lo stesso errore con il timeout. Stavo usando IEDriverServer (64 bit) e sui comandi sendKey lunghi sarebbe scaduto.

Il motivo è che il timeout predefinito sembra essere di 60 secondi.

Ciò che ha risolto il problema è che ho istanziato il driver con un metodo che consente di inserire la posizione di IEDriverServer, le opzioni per il driver E il valore di timeout.

Link alla documentazione: http://seleniumhq.github.io/selenium/docs/api/dotnet/

 public InternetExplorerDriver( string internetExplorerDriverServerDirectory, InternetExplorerOptions options, TimeSpan commandTimeout ) 

parametri

  1. InternetExplorerDriverServerDirectory :
    • Tipo: System.String
    • Il percorso completo della directory contenente IEDriverServer.exe
  2. opzioni
    • Tipo: OpenQA.Selenium.IE.InternetExplorerOptions
    • InternetExplorerOptions utilizzato per inizializzare il driver
  3. CommandTimeout
    • Digitare: System.TimeSpan
    • La quantità massima di tempo di attesa per ciascun comando

Il mio codice

 InternetExplorerOptions options = new InternetExplorerOptions(); IWebDriver driver = new InternetExplorerDriver("C:/Users/jeff/AppData/Local/Microsoft/WindowsApps", options, TimeSpan.FromSeconds(120)); 

Nel mio caso la pagina non è semplicemente completamente caricata. Alcuni plugin di Facebook sembrano caricarsi troppo a lungo. Ho provato a catturare l’eccezione e a manipolare il dom incompleto, ma questo non mi ha dato alcun risultato. 🙁

John

Abbiamo affrontato un problema simile sul nostro progetto. Il problema non aveva nulla a che fare con Selenium o la nostra app. Era scaduto perché la configurazione del build server per quel progetto avrebbe dovuto scadere in 5 minuti. Ma tutti i nostri test non sono stati completati in 5 minuti, quindi il build è fallito a causa di problemi di timeout casuali.

Inoltre abbiamo avuto un problema con firefox-19, i test usati per fallire casualmente. In qualche modo, firefox-10 ha funzionato solo per i nostri test di selenium.

Prova questo codice:

  DesiredCapabilities caps = DesiredCapabilities.Firefox(); //set the timeout to 120 seconds IWebDriver driver = new RemoteWebDriver(new Uri(""), caps, TimeSpan.FromSeconds(120)); 

Ho avuto lo stesso problema ma solo con il driver di Firefox. Risulta che potrebbe essere correlato a quando si utilizza il metodo di navigazione del driver e tenta di interagire troppo velocemente con la pagina. Chiamando sotto il codice lo aggiusto per me su Navigate (consiglio anche di usarlo prima di FindElement):

 public void VerifyPageIsLoaded() { var pageLoaded = false; for (var i = 0; i < DefaultTimeout.Timeout.Seconds; i++) { Thread.Sleep(1000); if (WebDriver.ExecuteJavaScript("return document.readyState").Equals("complete")) //jQuery.active might cause problems on some browser or browserstack so I commented it out //&& WebDriver.ExecuteJavaScript("return jQuery.active == 0").Equals(true)) { pageLoaded = true; break; } Thread.Sleep(1000); } if (!pageLoaded) { throw new Exception("Page was not with complete state)!"); } } 
 public static IWebElement WaitForElementVisible(By selector, uint timeout = Config.DefaultTimeoutSec) { IWebDriver driver = Browser.Instance.Driver; if (timeout > 0) { WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(timeout)); wait.Until(ExpectedConditions.ElementIsVisible(selector)); return driver.FindElement(selector); } else { // Search for element without timeout return driver.FindElement(selector); } } 

Lo usiamo per prevenire errori di questo tipo non trovati e funziona come un incantesimo.

Esiste anche una versione diversa se l’elemento può essere lì, ma non deve essere visibile.

Basta usare ExpectedConditions.ElementExists(selector) invece di ExpectedContitions.ElementIsVisible(selector)

modifica: Browser.Instance.Driver è una class contenente il driver istanziato