J'ai une série de tests Selenium qui fonctionnent parfaitement dans mon environnement local et qui utilisent Browserstack Automate, mais échouent sur Azure DevOps.
Il n'y a aucune modification de configuration ou de paramètre lors de l'exécution sur Azure Devops.
Nous avons suivi toute la documentation ici: https://docs.Microsoft.com/en-us/Azure/devops/pipelines/test/continuous-test-selenium?view=vsts
Les tests aléatoires échouent, jamais les mêmes.
Les tests échouent toujours à cause des délais d'attente. J'attends que les pages se chargent pendant 5 minutes pour que les délais ne soient pas trop courts.
Il n'y a pas de pare-feu en place, l'application est publique.
L'authentification réussit toujours pour que les tests puissent charger l'application.
Vous ne savez pas quoi essayer ensuite.
Vous trouverez ci-dessous une copie du journal Azure DevOps. 4 tests ont été réussis mais tous les autres ont échoué. Habituellement, seuls 4 ou 5 tests échouent.
Ces tests fonctionnent parfaitement avec BrowserStack Automate (Selenium distant) et localement.
2018-11-17T05:40:28.6300135Z Failed StripeAdmin_WhenOnTab_DefaultSortIsByIdDescending
2018-11-17T05:40:28.6300461Z Error Message:
2018-11-17T05:40:28.6304198Z Test method CS.Portal.E2e.Tests.Admin.StripeAdmin.StripeAdminTests.StripeAdmin_WhenOnTab_DefaultSortIsByIdDescending threw exception:
2018-11-17T05:40:28.6305677Z OpenQA.Selenium.WebDriverTimeoutException: Timed out after 300 seconds
2018-11-17T05:40:28.6307041Z Stack Trace:
2018-11-17T05:40:28.6307166Z at OpenQA.Selenium.Support.UI.DefaultWait`1.ThrowTimeoutException(String exceptionMessage, Exception lastException)
2018-11-17T05:40:28.6307999Z at OpenQA.Selenium.Support.UI.DefaultWait`1.Until[TResult](Func`2 condition)
2018-11-17T05:40:28.6308188Z at CS.Portal.E2e.Tests.Utility.WebDriverUtilities.WaitForElement(IWebDriver driver, By by, Boolean mustBeDisplayed) in D:\a\1\s\CS.Portal.E2e.Tests\Utility\WebDriverUtilities.cs:line 26
2018-11-17T05:40:28.6319651Z at CS.Portal.E2e.Tests.Admin.StripeAdmin.StripeAdminTests.StripeAdmin_WhenOnTab_DefaultSortIsByIdDescending() in D:\a\1\s\CS.Portal.E2e.Tests\Admin\StripeAdmin\StripeAdminTests.cs:line 51
2018-11-17T05:40:28.6319982Z
2018-11-17T05:40:34.4671568Z Results File: D:\a\1\s\TestResults\VssAdministrator_factoryvm-az416_2018-11-17_03_08_24.trx
2018-11-17T05:40:34.4692222Z
2018-11-17T05:40:34.4695222Z Attachments:
2018-11-17T05:40:34.4697610Z D:\a\1\s\TestResults\672f4d28-5082-42e9-a7e7-f5645aadcfd8\VssAdministrator_factoryvm-az416 2018-11-17 03_02_43.coverage
2018-11-17T05:40:34.4697943Z
2018-11-17T05:40:34.4698278Z Total tests: 34. Passed: 4. Failed: 30. Skipped: 0.
Voici quelques étapes que je ferais:
Ce qui nous a aidé dans un cas similaire est d’ajouter temporairement un enregistreur vidéo aux tests, puis de suivre le processus d’exécution des tests sur un VM du début à la fin. Il pourrait y avoir des indices sur une vidéo qui permettent de voir ce qui ne va pas réellement j'ai pu trouver ce lien pour un exemple en C #
De plus, je revérifierais pour m'assurer que les versions de navigateur sur Azure sont exactement les mêmes que dans l'exécution où tout fonctionne bien. Leur donner la même chose est crucial pour s'assurer qu'il n'y a pas de «magie». Pareil pour la taille de la fenêtre du navigateur par défaut.
Je ferais une analyse plus détaillée des endroits où différents tests échouent.
Si vous utilisez des API Date/Heure dans votre code, assurez-vous que les paramètres Heure système/Paramètres régionaux/Fuseau horaire sont exactement les mêmes. Ou que les jours ne changent pas pendant les tests. Dans l'ensemble - enquêter sur les dates.
Je sais que ce qui précède ressemble davantage à un conseil général, mais d’après mon expérience, de tels "échecs aléatoires" pourraient être causés par littéralement tout ce qui semble "ne mérite pas l’attention".