Correction du sélénium dans votre pipeline CI / CD

Exécuter des tests automatisés en continu peut sembler une évidence. Un système CI est essentiel, offrant aux équipes de développement agiles une visibilité rapide sur la santé de leurs applications. Si les tests automatisés réussissent, l'application est saine. Si les tests échouent, l'application est cassée d'une manière ou d'une autre. Ou est-ce?

La triste réalité est que les tests automatisés ne nous donnent pas toujours une telle confiance, en particulier lors de l'exécution de tests Selenium. Les tests au sélénium peuvent échouer pour de nombreuses raisons différentes, que l'application soit cassée de quelque manière que ce soit ou qu'elle ait changé. Ces problèmes sont bien détaillés dans un précédent blog. Ici, je vais expliquer comment modifier le pipeline CI / CD pour résoudre automatiquement ces problèmes, améliorant ainsi la confiance dans les résultats des tests du système CI.

Sélénium CI Sorrow

CI / CD amplifie les problèmes de test de sélénium. Regardons comment cela se produit. Premièrement, le développement entraîne des changements de code. Le système CI détecte le changement et déclenche le pipeline de construction. Les modules sont compilés, les tests unitaires sont exécutés et réussis (yay!), Puis l'application est emballée pour le déploiement. Le pipeline de déploiement se déclenche ensuite, organisant un environnement de test, déployant l'application testée, puis lance les tests d'intégration, dont beaucoup sont écrits à l'aide de Selenium. Tous les tests Selenium ne réussissent pas, à quel point le système CI notifie les échecs de test à diverses personnes par e-mail. Ces personnes réagissent, ce qui prend parfois beaucoup de temps à enquêter et à dépanner. Les propriétaires de produits, les responsables et les autres parties intéressées voient également les échecs sur leurs tableaux de bord qui détournent leur attention d'autres choses. Sachant que les tests Selenium eux-mêmes sont instables, comment peut-on être sûr que CI / CD a signalé une régression ou un défaut réel? Combien de temps faut-il perdre à résoudre les faux positifs?

Améliorer simplement les tests Selenium peut être non trivial, impliquant parfois des essais et des erreurs, en particulier lorsque les problèmes sont intermittents ou difficiles à reproduire. D'une construction à l'autre, il y a des échecs qui peuvent se déplacer, où il n'y a aucun test à blâmer. Il peut s'agir de problèmes systémiques ou environnementaux qui vont et viennent. Le système CI peut utiliser des exécuteurs virtuels ou basés sur le cloud qui ont des caractéristiques de performances incohérentes. Les tests s'exécutent et passent sur les postes de travail des développeurs, mais échouent dans l'automatisation CI. Semble familier?

Selenium CI résolu

Parasoft Sélénic a été développé pour aider à combattre de tels défis. Selenic automatise l'analyse et la correction des problèmes de test Selenium, en fournissant des correctifs ou des informations sur ces problèmes, et rend ces résultats disponibles au moment où les humains sont notifiés par leur système CI. Le fardeau est déplacé vers le système CI, loin des humains qui réagissent aux notifications du système CI. En seulement deux étapes simples, vous pouvez automatiser le processus de correction des tests Selenium dans le cadre du pipeline CI / CD à l'aide de Parasoft Selenic.

Injecter l'agent sélénique

Pour intégrer Parasoft Selenic, vous apportez une modification d'une ligne à votre script d'exécution de test existant. Disons que j'ai une étape d'exécution Maven dans le pipeline qui pilote mes tests Selenium basés sur Java. En règle générale, je spécifie deux objectifs Maven, «nettoyer» et «tester», qui sont passés comme arguments de ligne de commande à Maven. Ici, vous ajoutez simplement un argument de ligne de commande Maven supplémentaire:

-DargLine = -javaagent: $ {SELENIC_HOME} /selenic_agent.jar=selfHealing=true,sessionId = $ {BUILD_TAG}

Dans Jenkins CI, cela pourrait ressembler à ceci:

L'agent Selenic est maintenant injecté dans le processus d'exécution du test, à condition que Selenic soit installé et autorisé à l'emplacement référencé par la variable «SELENIC_HOME». L'agent Selenic peut faire diverses choses, mais à des fins de stabilisation des tests, j'active uniquement la fonction «auto-guérison» qui tente d'identifier et de résoudre les problèmes de test Selenium à la volée.

Une chose à considérer attentivement est de savoir si vos tests Selenium vivent tous dans un module ou s'il y a des tests dans plusieurs modules. Il est courant que les tests soient divisés en plusieurs modules à des fins d'organisation. Pour que Selenic agrège les informations de plusieurs modules de test, un argument «sessionId» doit être configuré. Dans l'exemple ci-dessus, j'utilise "BUILD_TAG" qui est une variable prédéfinie dans le système Jenkins CI qui fonctionne bien à cette fin. Quel que soit le système CI que vous utilisez, ma recommandation est de créer un identifiant de session unique à l'aide des variables fournies par votre système CI.

Après avoir effectué ce changement d'une ligne, Selenic identifie et corrige automatiquement les problèmes de stabilité des tests, donnant à chacun beaucoup plus de confiance dans les résultats des tests publiés par le système CI. Cependant, il y a un autre composant Selenic que je recommande d'intégrer.

Exécutez l'analyseur sélénique

Comment savons-nous quels problèmes Selenic a trouvé ou ce qu'il a corrigé? Dois-je apporter des modifications aux tests Selenium pour éviter les types de problèmes détectés par Selenic? Pour obtenir ces informations, vous exécuteriez Selenic Analyzer comme une autre étape d'exécution dans le pipeline. Il s'agit d'un deuxième changement d'une ligne mais toujours insignifiant:

java -jar $ SELENIC_HOME / selenic_analyzer.jar -report target / selenic-reports -sessionId $ {BUILD_TAG}

Dans Jenkins CI, cela pourrait ressembler à ceci:

Le Selenic Analyzer collecte les informations qui ont été enregistrées précédemment par Selenic Agent, effectue des analyses supplémentaires sur les données, puis crée des rapports qui peuvent ensuite être archivés par le système CI. Par défaut, l'analyseur traite les informations de la session la plus récente, mais pour plus de robustesse, je recommande de configurer explicitement l'argument «-sessionId» avec la même valeur que celle utilisée précédemment lors de la configuration de Selenic Agent.

Par défaut, Selenic Analyzer écrit les rapports dans le répertoire de travail actuel. Cependant, afin de faciliter l'archivage des rapports, vous devez ajouter un argument «-report» pour demander à Selenic d'écrire des rapports dans un dossier «selenic-reports» dans le répertoire de sortie de construction de votre projet. Après cela, vous ajouterez une étape supplémentaire dans le pipeline pour archiver "target / selenic-reports / **":

Les fichiers de rapport sont désormais accessibles à tous via le système CI. Dans le cas de Jenkins CI, les rapports sont facilement accessibles aux URL stables:

http://{ci_server}/job/{test_job}/lastSuccessfulBuild/artifact/target/selenic-reports/report.html

http://{ci_server}/job/{test_job}/lastSuccessfulBuild/artifact/target/selenic-reports/report.json

La première URL pointe vers le rapport Selenic HTML qui peut être consulté directement dans un navigateur Web. La deuxième URL est vers le rapport JSON que les développeurs peuvent fournir au plug-in Selenic IDE pour importer les recommandations du dernier test automatisé.

Autres considérations

Selenic propose de nombreuses autres options que vous pouvez envisager d'activer en fonction de votre environnement de test et d'autres besoins spécifiques.

Selenic enregistre les données pour chaque session de test. Les données enregistrées servent de base de connaissances, permettant à Selenic d'apprendre et de prendre de meilleures décisions et recommandations d'auto-guérison au fil du temps. Par défaut, ces données sont stockées sur la machine sur laquelle le test s'exécute. Par conséquent, si vous disposez d'un pool d'exécuteurs, vous souhaitez que ces données se trouvent dans un dossier partagé accessible à tous vos exécuteurs. L'emplacement des données peut être configuré explicitement en passant un paramètre «data = {path}» à Selenic Agent et un argument «-data {path}» à Selenic Analyzer, où «{path}» serait un chemin d'accès au système de fichiers un dossier partagé. Sous Windows, il peut s'agir d'un chemin UNC tel que \\ HostName \ SharedFolder. Les données enregistrées s'accumuleront également indéfiniment à moins d'être contraintes. Cela peut éventuellement conduire à une utilisation élevée du disque. Une limite du nombre de sessions de test enregistrées peut être configurée en transmettant un paramètre «maxSessionDaysToKeep = {num_days}» à Selenic Agent. «{Num_days}» est le nombre de jours pendant lesquels les données ont été enregistrées et non de jours civils. En d'autres termes, Selenic ne compte pas les jours où aucune donnée de session de test n'a été enregistrée. Ceci est utile si vous exécutez vos tests rarement, ou à des intervalles incohérents, ou si le serveur a été interrompu lorsque vous avez manqué l'exécution des tests pendant quelques jours.

Selenic peut également être configuré pour capturer des informations de diagnostic supplémentaires à différents niveaux de granularité. Par exemple, Selenic peut être configuré pour capturer des captures d'écran pour chaque action Selenium ou uniquement pour les actions ayant échoué. Pour activer les captures d'écran sur les échecs de test, vous pouvez passer un paramètre «screenshot = échecs» à Selenic Agent. Des captures d'écran des échecs sont disponibles dans le rapport HTML produit par Selenic Analyzer.

CI / CD + Sélénique = ❤

Parasoft Selenic a été conçu pour accélérer le développement agile en utilisant Selenium dans le cadre de CI / CD. Les développeurs et les testeurs peuvent être plus productifs, passer moins de temps à chasser les «fantômes» de Selenium et plus de temps à travailler sur des choses réelles. Augmentez la confiance dans vos résultats de test Selenium avec Selenic. Téléchargez votre essai gratuit aujourd'hui.

De Joseph Benken

Joseph est ingénieur logiciel senior chez Parasoft. Il a contribué au développement de nombreuses fonctionnalités et technologies de base utilisées dans divers produits, notamment SOAtest, Virtualize et Selenic. Il travaille chez Parasoft depuis 2006.