Encore un « element not found » ? Comment tester quand les sélecteurs et les localisateurs échouent

« Element not found » signifie que votre test a cherché un élément avec un localisateur et que rien n'a correspondu à temps.La solution est rarement un meilleur localisateur : c'est un test qui vérifie ce que voit l'utilisateur.

Tout ingénieur QA connaît ce matin-là : vingt tests rouges, et pas une seule vraie anomalie.Un développeur a renommé une classe, l'équipe design a déplacé une bannière, une mise à jour du framework a changé les identifiants.Cet article explique pourquoi les localisateurs cassent, comment corriger l'erreur quand elle arrive, où s'arrêtent les solutions habituelles et comment tester sans sélecteur à maintenir.

Que signifie « element not found » ?

La page de dépannage de Selenium donne trois causes probables : vous cherchez au mauvais endroit, vous cherchez au mauvais moment, ou le localisateur a changé depuis que vous avez écrit le code.Seule la dernière concerne le localisateur lui-même, et c'est celle qui grandit à chaque version.

Pourquoi les sélecteurs et les localisateurs cassent-ils ?

Un localisateur est une supposition sur la façon dont l'application est construite.Tout ce qui change la construction sans changer ce que voit l'utilisateur peut le casser.

Identifiants dynamiques et noms de classe générés

Beaucoup de frameworks écrivent leurs propres identifiants et noms de classe, comme save-8f3a2c ou css-1x7hq.Ils sont uniques, ce qui les fait ressembler à des localisateurs parfaits, et ils changent à la compilation suivante.Un test enregistré sur eux passe aujourd'hui et échoue après le prochain déploiement, sur une page que personne n'a touchée.

Refontes, refactorings et tests A/B

Un sélecteur CSS comme .form > div:nth-child(3) button ou un XPath comme //div[3]/form/button[2] décrit un chemin à travers la page.Enveloppez le formulaire dans un nouveau conteneur, ajoutez une bannière au-dessus ou inversez deux champs, et le chemin mène ailleurs.Un test A/B fait la même chose exprès : la moitié des visiteurs reçoit une page pour laquelle vos localisateurs n'ont pas été écrits.

La documentation de Playwright le dit clairement : les sélecteurs XPath et CSS peuvent être liés à la structure du DOM, et ils peuvent casser quand elle change.

Localisation et localisateurs par texte

Les localisateurs par texte, libellé ou nom accessible survivent à une refonte, c'est pourquoi ils sont recommandés.Ils ne survivent pas à une traduction.Un bouton trouvé par le nom Save n'est plus trouvé quand la version française dit Enregistrer, donc un produit localisé a besoin d'un localisateur par langue, ou d'un identifiant de test.

Shadow DOM et iframes

Une iframe est une page dans la page, et un composant web garde ses éléments internes dans une shadow root.Selenium ne connaît que les éléments du document de premier niveau : un test codé doit donc d'abord être dirigé dans le cadre, sinon il signale que l'élément n'existe pas.Certains localisateurs, comme XPath, ne peuvent pas du tout entrer dans un composant.

Listes et grilles virtualisées

Un tableau de dix mille lignes est rapide parce qu'il ne les dessine pas toutes.AG Grid, une grille de données très utilisée, explique qu'elle ne dessine que ce que vous voyez à l'écran, plus une petite réserve de lignes au-dessus et en dessous.La ligne 500 n'est pas dans la page tant que personne n'a fait défiler jusqu'à elle, donc un localisateur ne la trouve pas, alors qu'une personne ferait simplement défiler.

Comment corriger une erreur « element not found »

Dans Selenium, Playwright ou Cypress, corriger l'erreur est votre travail, et il revient à chaque version.Dans GUI Test Studio, il n'y a aucun localisateur à corriger.

Quand un test GUI Test Studio s'arrête bien sur un élément, ces cinq étapes règlent la question, sans rien coder.

1. 1

   Ouvrez le Rapport de confiance de l'exécution

   Le rapport s'ouvre après chaque exécution, sur le premier échec.Il montre l'image attendue à côté de l'écran au moment où l'assertion a abandonné, pour que vous voyiez si l'élément manquait, était masqué ou se trouvait ailleurs.

2. 2

   Vérifiez où l'exécution a commencé

   Un test part de l'écran d'où son enregistrement est parti.Si l'application était sur une autre page ou contenait d'autres données, remettez-la comme elle était et relancez le test.

3. 3

   Élargissez la zone de recherche si l'élément a beaucoup bougé

   Quand rien n'est trouvé dans la zone de recherche d'une assertion, la recherche s'élargit déjà d'elle-même à tout l'écran.Si l'élément se trouve désormais ailleurs pour de bon, cliquez sur Élargir la zone de recherche dans le rapport et définissez la nouvelle zone dans GUI Test Studio.

4. 4

   Acceptez un changement voulu

   Si l'élément a un autre aspect parce que le design a changé, cliquez sur Accepter le résultat obtenu comme attendu dans le Rapport de confiance et enregistrez.Le test est à jour, sans code à modifier.

5. 5

   Signalez l'anomalie si l'élément a vraiment disparu

   Si l'élément a disparu, le test a fait son travail.Cliquez sur Rapport d'anomalie pour le signaler en PDF ou en ticket Jira, avec les images jointes.

CSS, XPath, rôle ou identifiant de test : chaque localisateur a son point faible

Les équipes qui écrivent des tests codés choisissent un localisateur pour chaque élément qu'elles touchent.Chaque type échoue à sa manière.

XPath ou sélecteur CSS est la question la plus posée, et elle compte moins qu'il n'y paraît.CSS est plus court et plus facile à lire ; XPath peut remonter dans la page et chercher un texte.Les deux décrivent la façon dont la page est construite, donc les deux cassent de la même façon.

Dans GUI Test Studio, personne ne choisit de localisateur.Un test enregistré garde de lui-même plusieurs moyens d'atteindre chaque élément, comme le montrent les sections suivantes.

L'automatisation de tests auto-réparatrice corrige-t-elle les localisateurs cassés ?

Les outils auto-réparateurs gardent des détails supplémentaires sur chaque élément pendant qu'un test réussit.Quand le localisateur principal ne correspond plus, ils cherchent l'élément avec ces détails et continuent.

Là où tout localisateur s'arrête : canvas, jeux et applications sans arbre d'accessibilité

Toutes les stratégies ci-dessus supposent que l'application décrit ses éléments.Beaucoup ne le font pas, et il n'y a aucun localisateur à écrire, bon ou mauvais.

Pour les applications de bureau Windows, Alternatives à WinAppDriver pour les applications sans arbre d'accessibilité indique quels programmes se décrivent et lesquels ne le font pas.

L'automatisation de tests sans sélecteurs à maintenir

GUI Test Studio, qui automatise les tests de bout en bout sur Windows, prend un autre chemin : personne n'écrit ni ne maintient de sélecteur.Vous enregistrez le test en faisant vous-même le parcours, ou vous le décrivez dans un prompt, et chaque assertion porte sur ce que voit l'utilisateur.

Pour trouver chaque élément, le GTS Engine + AI utilise deux chemins.Il interroge d'abord l'application : les informations d'accessibilité qu'une application Windows donne sur ses contrôles, ou les propres éléments d'une page web.Quand l'application ne dit rien, il trouve l'élément à vue, à l'écran.Comment GUI Test Studio trouve les éléments à l'écran explique les deux chemins en détail.

Sur une page web : plusieurs chemins vers un même élément

Pour un test web, GUI Test Studio garde plusieurs chemins vers chaque élément sur lequel il agit, classés : son identifiant de test, son identifiant, son rôle et son nom, son libellé, son texte indicatif, son texte, et sa place dans la page en dernier.Un identifiant qui semble généré par un framework est placé vers la fin de la liste, après tout ce qu'une personne peut lire.

Ainsi, un identifiant de test supprimé ou une classe renommée n'arrête pas le test : le chemin suivant trouve toujours l'élément.Les mêmes chemins atteignent les éléments dans une racine shadow, et ils permettent à un test généré pour un téléphone d'ouvrir le menu qui y cache un lien.

C'est ce dernier point qui permet à un seul test web enregistré de tourner dans Chrome, Edge, Firefox et sur des téléphones émulés, comme le montrent les tests multi-navigateurs à partir d'un seul enregistrement.

Dans une application de bureau : le contrôle d'abord, puis l'écran

Dans une application Windows, une assertion faite sur un bouton garde ce que l'application a dit de ce bouton : son nom, son type, sa place.À chaque exécution, le moteur demande d'abord ce bouton à l'application en cours, et cherche son image dans le cadre que l'application donne.Parmi plusieurs boutons identiques, il prend celui qui est le plus près de la place du bouton enregistré.

Une assertion de texte demande à l'application ce que dit l'élément avant de lire les mots à l'écran, donc un mot difficile à lire à l'écran est quand même vérifié par rapport à ce que l'application dit vraiment.

Partout ailleurs : à vue

Un jeu, un canvas, une session Citrix ou un programme sans arbre d'accessibilité se teste à vue, sans rien ajouter à l'application.L'assertion cherche l'image de l'élément dans sa zone de recherche, et une assertion de texte lit les mots à l'écran.

Ce qui se passe quand l'élément bouge ou change

Un test qui ne dépend pas d'un seul localisateur doit quand même faire face au changement.Voici ce que fait GUI Test Studio à chaque étape.

1. Interroger

   L'application dit où est l'élément

2. Regarder

   Ou son image est trouvée dans sa zone de recherche

3. Élargir

   Rien : tout l'écran

4. Rapporter

   Où il a été trouvé, et pourquoi

Les clics suivent aussi l'élément : chaque clic est visé à travers l'assertion qui le précède, donc quand le bouton bouge, le clic bouge avec lui.Voir les assertions visuelles et les assertions de texte pour le réglage de chaque assertion.

Ce qui demande encore votre décision

Aucune approche ne rend chaque changement gratuit.Voici les cas où une personne décide.

Accepter une nouvelle apparence détaille la mise à jour en un clic, et tests instables et faux positifs explique comment une assertion distingue un bruit sans conséquence d'un vrai changement.

Pour les anomalies visuelles qu'une assertion fondée sur un localisateur laisse passer sans les voir, lisez les anomalies visuelles que vos tests automatisés ne voient pas.

Points clés

• 1« Element not found » est en général un problème de test, pas une anomalie : le localisateur, le moment ou le contexte est faux plus souvent que l'application.
• 2Les localisateurs cassent pour des raisons ordinaires : identifiants générés, refontes, tests A/B, traductions, shadow DOM, iframes et listes virtualisées.
• 3Chaque stratégie déplace le risque : CSS et XPath dépendent de la structure, les rôles et les noms des mots, les identifiants de test d'une habitude d'équipe, l'auto-réparation d'une relecture.
• 4Certaines applications ne donnent rien à un localisateur : canvas, jeux, sessions Citrix et applications sans arbre d'accessibilité ne se testent qu'à vue.
• 5GUI Test Studio n'a ni sélecteurs ni localisateurs à maintenir : il interroge d'abord l'application, trouve l'élément à vue quand l'application ne dit rien, et vérifie ce que voit l'utilisateur.

Questions

Selenium, Playwright, Cypress, AG Grid, Flutter, Qt, Java, Delphi, Citrix, Chrome, Edge, Firefox et Windows sont des marques de leurs propriétaires respectifs.