L'accessibilité d'abord, la vision quand l'application ne dit rien : comment GUI Test Studio trouve chaque élément
La plupart des tests de bout en bout cassent parce qu'ils ne trouvent plus un élément.Le GTS Engine + AI trouve chaque élément de deux façons : il interroge l'application par ses informations d'accessibilité, et trouve l'élément à vue quand l'application ne dit rien.Pourquoi deux chemins vers un même élément rendent un test robuste, sans aucun localisateur à écrire ni à maintenir.
6 min de lecturePar l'équipe de GUI Test Studio
Pourquoi les tests de bout en bout cassent
Demandez à une équipe pourquoi ses tests de bout en bout sont rouges, et la réponse est rarement un bug.Le plus souvent, un test ne trouvait plus un bouton : un développeur a renommé une classe, une mise à jour du framework a changé la structure de la page, une boîte de dialogue s'est ouverte un peu plus bas, un thème a changé une couleur.L'application allait bien ; c'est le test qui n'allait pas.
Les tests codés trouvent les éléments avec des localisateurs : un identifiant, un sélecteur CSS, un XPath, une position.Chacun est une supposition sur la façon dont l'application est construite, et chaque refonte en casse quelques-uns.Les outils basés sur l'image ont la faiblesse inverse : ils voient l'écran, mais ne savent rien de ce que l'application en dit.
Deux chemins vers un même élément
Le GTS Engine + AI, le moteur derrière chaque assertion de GUI Test Studio, ne choisit pas entre les deux.Il trouve chaque élément de deux façons, et utilise celle qui fonctionne sur l'écran devant lui.
Interroger
L'application dit où se trouve l'élément
Voir
Ou le moteur le trouve à vue
Comparer
Ce qui est là, face à ce que vous attendez
Rapporter
Le verdict, en mots simples
D'abord : interroger l'application
La plupart des applications décrivent leur propre interface à Windows : chaque bouton, champ, liste et libellé avec son nom, son rôle et son emplacement à l'écran.Ce sont les informations d'accessibilité qu'utilisent les lecteurs d'écran, et elles sont précises et immédiates.Une page web fait de même par ses propres éléments.
Quand un test est enregistré, ou décrit dans une consigne, GUI Test Studio garde ce que l'application a dit de chaque élément à partir duquel une assertion a été créée.Quand le test s'exécute, le moteur demande d'abord cet élément à l'application en cours : où il se trouve maintenant, s'il est visible, si quelque chose le recouvre.Une assertion de texte demande à l'application ce que dit l'élément avant de lire les mots à l'écran.
| Ce que dit l'application | Ce que le test en tire |
|---|---|
| Le nom et le rôle de l'élément | Le même bouton est retrouvé, même parmi d'autres qui lui ressemblent |
| Son emplacement à l'écran | L'élément est trouvé là où il a bougé, immédiatement |
| S'il est visible ou recouvert | Une boîte de dialogue ou un menu devant lui est remarqué, jamais cliqué au travers |
| Ce qu'il dit | Une assertion de texte obtient les mots exacts, jamais une mauvaise lecture |
Ensuite : le trouver à vue
Certaines applications ne disent rien.Un jeu vidéo dessine ses menus lui-même.Un canevas, un graphique ou une carte est une seule image pour Windows.Un bureau à distance, une machine virtuelle ou un téléphone affiché sur votre écran est une seule fenêtre sans rien dedans.Les anciens programmes dessinés par leur propre boîte à outils ressemblent à un seul panneau vide.
Là, le GTS Engine trouve l'élément à vue, sur l'écran réel, comme le fait une personne : il cherche l'image de l'élément dans sa zone de recherche, tolère les petites différences que tout écran présente, et distingue les éléments qui se ressemblent par l'endroit où ils se trouvent.Il prend aussi le relais quand la réponse de l'application ne tient pas : un élément qu'elle signale mais qui est caché, recouvert ou loin de l'endroit où il devrait être.
Pourquoi deux chemins rendent un test robuste
Chaque chemin couvre le point faible de l'autre.Les informations d'accessibilité ne se soucient pas de l'apparence d'un élément, donc un nouveau thème, une police ou une autre mise à l'échelle de l'écran ne le font pas perdre.La vision ne se soucie pas de la façon dont l'application a été construite, donc une classe renommée, un nouveau framework ou une application sans aucune information d'accessibilité ne le font pas perdre non plus.
| Ce qui a changé | Ce qui trouve encore l'élément |
|---|---|
| Le code derrière le bouton a été réécrit | Les deux : l'application le nomme toujours, et il a toujours le même aspect |
| La fenêtre a bougé, ou la disposition s'est décalée | L'application dit où il se trouve maintenant, et la vision l'y trouve |
| Une nouvelle couleur ou un nouveau thème | Les informations d'accessibilité de l'application |
| Un jeu vidéo, un canevas, un bureau à distance | La vision |
| Plusieurs boutons identiques | Les noms donnés par l'application et l'emplacement de l'élément les distinguent |
Le résultat est un test qui continue de trouver ce qu'il cherche pendant que votre application change autour de lui, et qui n'échoue que pour une seule raison : ce que l'utilisateur verrait est faux.
Trouver, c'est la moitié de l'assertion
Une fois l'élément trouvé, le GTS Engine compare ce qui est à l'écran avec ce que vous attendez : l'image, les mots, l'agencement.Il ignore le bruit que tout écran présente, l'anticrénelage et la compression, et détecte les vraies régressions, ce qu'une personne appellerait un changement : une mauvaise couleur, une icône manquante, un mot qui a changé de casse.
Quand une assertion échoue, l'analyse intelligente par IA, le volet IA optionnel du moteur, peut poser un second regard et expliquer la différence en mots simples, avec un modèle dans le cloud et votre propre clé ou un modèle local sur votre propre ordinateur, l'un des nôtres ou le vôtre.Voir Analyse intelligente par IA.
Rien à configurer
Il n'y a aucun localisateur à écrire, aucun réglage d'accessibilité à activer, aucun mode à choisir.Enregistrez le test vous-même, ou décrivez-le dans une consigne à Claude, à ChatGPT ou à un modèle d'IA sur votre propre ordinateur : GUI Test Studio garde ce dont il a besoin sur chaque élément, et le moteur décide à chaque exécution quel chemin le trouve.Tout s'exécute sur votre propre ordinateur.
Questions
GUI Test Studio utilise-t-il l'arbre d'accessibilité ?
Oui.Le GTS Engine + AI demande d'abord à l'application où se trouve un élément, par ses informations d'accessibilité sous Windows, ou par les propres éléments de la page web dans un navigateur.Il ne trouve l'élément à vue sur l'écran que lorsque l'application ne le dit pas.
Et si mon application n'a aucune information d'accessibilité ?
Le test fonctionne quand même.Les jeux, les canevas, les bureaux à distance et les programmes dessinés par leur propre boîte à outils n'exposent rien, alors le GTS Engine trouve leurs éléments à vue, sur l'écran, comme le fait une personne.
Dois-je écrire des localisateurs ou des sélecteurs ?
Non.GUI Test Studio garde de lui-même ce dont il a besoin sur chaque élément lorsque le test est enregistré ou décrit dans un prompt.Il n'y a aucun localisateur, sélecteur ou identifiant d'élément à écrire ou à maintenir.
La vérification reste-t-elle visuelle quand l'élément est trouvé par l'accessibilité ?
Oui.Trouver l'élément est la première moitié d'une vérification.La seconde moitié compare toujours ce qui est à l'écran avec ce que vous attendez, si bien qu'un test détecte ce que vos utilisateurs verraient, comme une mauvaise couleur ou une icône manquante.
Prêt à enregistrer votre premier test ?
Toutes les fonctionnalités, pendant 15 jours.
Vous préférez le voir sur le type d'application que vous testez ?Réservez un appel gratuit de 30 minutes avec notre équipe.