Erreur Selenium - La requête HTTP adressée au WebDriver distant a expiré au bout de 60 secondes.
J'utilise Selenium depuis plusieurs mois, que nous utilisons pour automatiser certains de nos processus de test internes. Les scripts ont bien passé. J'ai récemment effectué une mise à niveau vers un pilote Web C # 2.40.0 avec FF 27.01 et nos scripts échouent maintenant dans des emplacements aléatoires avec l'erreur suivante.
[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)
La dernière erreur que j'ai pu retrouver jusqu'à une seule ligne de code:
_setup.driver.FindElement(By.XPath("//button[@class='buttonSmall lockBookingButton']")).Click();
Le problème, c’est que tenter de résoudre le problème s’avère difficile, comme si j’exécutais le test sur mon ordinateur local, le débogage est réussi. De plus, si je l'exécute via le coureur NUNIT sur la machine de compilation sur laquelle je lance le test, cela passe également. Cela ne semble échouer que dans le cadre de notre processus d'exécution de génération automatisée lors de l'utilisation de Teamcity. Comme je le disais, cela fonctionnait bien depuis des mois et la seule chose qui a changé est le kit WebDriver de Selenium.
J'ai déjà rencontré ce problème auparavant, alors que j'étais en cours de débogage, et lorsqu'une ligne de code Click() était appelée, Firefox semblait se bloquer et seul le fait d'arrêter le test permettrait à Firefox de continuer. Il y a un certain nombre de suggestions ici incluant la modification de la source Webdriver? J'aimerais éviter cette voie si cela est possible si quelqu'un d'autre peut offrir des suggestions.
new FirefoxDriver(new FirefoxBinary(),new FirefoxProfile(),TimeSpan.FromSeconds(180));
Lancez votre navigateur en utilisant les lignes de code ci-dessus. Cela a fonctionné pour moi.
J'ai eu un problème similaire en utilisant le pilote Chrome (v2.23)/en exécutant les tests via TeamCity. J'ai pu résoudre le problème en ajoutant l'indicateur "no-sandbox" aux options de Chrome:
var options = new ChromeOptions();
options.AddArgument("no-sandbox");
Je ne suis pas sûr s'il existe une option similaire pour le pilote FF. D'après ce que je comprends, le problème a quelque chose à voir avec TeamCity exécutant Selenium sous le compte SYSTEM.
J'ai rencontré ce problème pour la première fois il y a des mois (également à l'aide de la commande click()), et cela me pose problème depuis. Cela semble être un problème avec les liaisons .NET Selenium. Ce billet de blog du gars qui travaille sur le pilote IE est utile pour expliquer ce qui se passe:
http://jimevansmusic.blogspot.com/2012/11/net-bindings-whaddaymean-no-response.html
Malheureusement, il ne semble pas y avoir de solution réelle à ce problème. Chaque fois que cette question a été posée aux développeurs Selenium ( see here ), il s’agit d’une réponse typique :
Nous avons besoin d'un scénario reproductible, qui doit inclure un exemple de page ou un lien vers la page d'un site public où le problème peut être reproduit.
Si vous êtes en mesure de soumettre un scénario de test reproductible de manière cohérente, cela pourrait être très utile pour supprimer définitivement ce bogue.
Cela dit, vous pouvez peut-être essayer cette solution de contournement d'ici là. Si le bouton HTML sur lequel vous essayez click() a un attribut onclick qui contient Javascript, envisagez d'utiliser un JavascriptExecutor pour exécuter ce code directement, plutôt que d'appeler la commande click(). J'ai constaté que l'exécution de la variable onclick Javascript permettait de réussir certains de mes tests.
Vous avez un problème similaire. Essayez de définir plus de temps dans le constructeur du pilote - ajoutez par exemple.
var timespan = TimeSpan.FromMinutes(3);
var driver = new FirefoxDriver(binary, profile, timeSpan);
Dans mon cas, le type de mon bouton est submit pas button et je change le Click en Sumbit alors tout fonctionne bien. Quelque chose comme ci-dessous,
de driver.FindElement(By.Id("btnLogin")).Click();
à driver.FindElement(By.Id("btnLogin")).Submit();
BTW, j'ai été essayé toute la réponse dans ce post mais ne fonctionne pas pour moi.
Dans mon cas, c'est parce que j'ai supprimé le dossier de mise à jour de chrome. Après la réinstallation de chrome, cela fonctionne bien.
Je pense que ce problème se produit lorsque vous essayez d'accéder à votre objet de pilote Web après
1) une fenêtre est fermée et vous n'êtes pas encore passé au parent
2) vous avez basculé vers une fenêtre qui n’était pas tout à fait prête et qui a été mise à jour depuis votre commutation
attendre que le windowhandles.count soit celui que vous attendez ne prend pas en compte le contenu de la page, pas plus que document.ready. Je cherche toujours une solution à ce problème
Le problème est que l'évaluation de Click() a dépassé le délai imparti à votre envoi de construction. Vous pouvez creuser dans ce qui se passe dans Click().
Essayez également d’ajouter Retrys pour le Click() car parfois les évaluations prennent plus de temps en fonction de la vitesse du réseau, etc.
changer le Selenium.WebDriver.ChromeDriver de 2.40.0 à 2.27.0 me convient
Dans mon cas, le problème était avec SendKeys () et Remote Desktop . J'ai posté jusqu'à présent la solution de contournement:
J'ai effectué un test Selenium qui échouerait s'il était exécuté dans le cadre d'un travail Jenkins sur un nœud hébergé sur vSphere et administré via RDP. Après un certain dépannage, il s'est avéré que si Remote Desktop était connecté et focalisé, il échouait sauf si Remote Desktop était déconnecté ou même réduit.
Pour contourner le problème, j’ai ouvert une session via vSphere Console au lieu de RDP. Même après la fermeture de vSphere, le test n’a plus échoué. Ceci est une solution de contournement, mais je devrais faire attention à ne jamais me connecter via RDP et à toujours administrer uniquement via vSphere Console.
Nous avons eu le même problème. Dans notre cas, le navigateur a été bloqué par une fenêtre de connexion (authentification Windows), ne revenant pas après 60 secondes. L'ajout de droits d'accès corrects au compte Windows Chrome était en cours d'exécution sous le problème résolu.
Dans mon cas, j'ai constaté que cette erreur se produisait dans le serveur de génération de nos équipes. Les tests ont fonctionné sur nos machines de développement locales.
Le problème était que le site Web cible n'était pas configuré correctement sur le serveur de génération et qu'il ne pouvait donc pas ouvrir le navigateur correctement.
Nous utilisions le pilote chromé mais je ne suis pas sûr que cela fasse une différence.
La new FirefoxDriver(binary, profile, timeSpan) est obsolète.
Vous pouvez maintenant utiliser new FirefoxDriver(FirefoxDriverService.CreateDefaultService(), FirefoxOptions options, TimeSpan commandTimeout) à la place.
Il y a aussi une new FirefoxDriver(string geckoDriverDirectory, FirefoxOptions options, TimeSpan commandTimeout) et cela fonctionne. Mais il n’est pas documenté et vous devez spécifier manuellement geckoDriverDirectory même s’il est déjà dans Path.