Test de captures d'écran au pixel près : pourquoi il échoue, et ce qui détecte les vrais bugs visuels
Le test de captures d'écran au pixel près échoue deux fois : le bruit de rendu déclenche de fausses alertes, et un seuil en pourcentage cache de vrais bugs.Voici ce qui marche à la place.
Le test de captures d'écran au pixel près compare chaque pixel d'une capture avec une image de référence.Il échoue deux fois : un bruit de rendu sans conséquence déclenche de fausses alertes, et un seuil en pourcentage assez souple pour les faire taire laisse passer un chiffre faux ou une icône manquante.
Qu'est-ce que le test de captures d'écran au pixel près ?
Définition
Le test de captures d'écran au pixel près est une vérification visuelle qui compare une nouvelle capture avec une capture de référence, pixel par pixel.
- Tout pixel dont la couleur diffère compte comme une différence.
- Un test échoue dès qu'il y a des différences, ou plus qu'un seuil n'en autorise.
C'est la forme la plus simple du test de régression visuelle, et celle par laquelle la plupart des équipes commencent.
L'idée est juste : une personne juge un écran en le regardant, alors un test devrait le regarder aussi.Le problème, c'est la mesure.Un écran n'est pas dessiné avec les mêmes pixels sur chaque machine, et les bugs qui comptent ne font souvent que quelques pixels.
Rien ne va mal
Quelque chose ne va pas
Pourquoi la comparaison pixel par pixel produit des faux positifs
Un faux positif est un test qui échoue alors que l'application fonctionne.Dans une comparaison pixel par pixel, il vient de tout ce qui change des pixels sans changer ce qu'une personne voit.
| Source de bruit | Pourquoi les pixels diffèrent |
|---|---|
| Anticrénelage | Les bords du texte et des formes sont lissés avec des couleurs intermédiaires, et ce lissage varie d'une machine à l'autre. |
| Lissage des polices | Sous Windows, ClearType dessine le texte avec de légères franges colorées qui dépendent de l'écran et de ses réglages. |
| La carte graphique et son pilote | Dégradés, ombres et coins arrondis peuvent sortir d'une nuance différente sur une autre carte. |
| Enregistrement et compression | Une image de référence tirée d'une vidéo garde moins de détail de couleur que l'écran réel n'en montre. |
| Un décalage d'un pixel | Une fenêtre ou une mise en page déplacée d'un pixel change tous les bords de l'image. |
| Un curseur de texte qui clignote | Le curseur est allumé sur une capture et éteint sur l'autre. |
| Un état de survol ou de focus | Le pointeur repose sur un bouton lors d'une exécution et pas lors de l'autre, alors le bouton n'est éclairé que sur une seule image. |
| Contenu dynamique | Une date, une horloge, un compteur ou un badge de notification change chaque jour. |
| Une autre mise à l'échelle de l'écran | Un portable à 150 % et un moniteur à 100 % dessinent le même bouton avec d'autres pixels. |
Les tests instables ont aussi d'autres causes, comme les attentes et le minutage.Elles sont traitées dans tests instables et faux positifs.
Pourquoi un seuil de test de régression visuelle cache de vrais bugs
La réponse habituelle au bruit est un seuil : laisser passer la comparaison tant que moins d'une certaine part de l'image diffère, souvent 1 ou 2 %.Les fausses alertes s'arrêtent.Les vrais bugs commencent à passer.
Les vrais bugs peuvent être tout petits à l'écran.
- Un chiffre faux dans un prix ou un total change quelques dizaines de pixels.
- Une majuscule devenue minuscule en change quelques dizaines de plus.
- Une petite icône manquante en change quelques centaines.
- Sur un panneau ou un écran entier, chacun reste loin sous 1 %.
Les bugs qui coûtent le plus sont souvent les plus petits à l'écran : un chiffre d'une facture, un mot d'une mention légale.
Une part de l'image est la mauvaise mesure
Le bruit et les bugs se ressemblent quand on les compte sur toute l'image.Ils ne se ressemblent pas pour une personne.
- Le bruit, c'est ce que personne ne voit : un bord plus doux, une nuance plus claire, un curseur qui a clignoté.
- Un vrai changement, c'est ce qu'une personne lit ou reconnaît : une lettre, un chiffre, une icône, une couleur.
Attendu
$12,480
Cette exécution
$12,430
Mesuré comme une part de l'image
Un chiffre est une infime part du panneau, bien en dessous d'un seuil de 2 %.
Réussit : le bug passe inaperçu
Vu avec les yeux d'une personne
Une personne qui lit le total voit tout de suite le chiffre faux, et GUI Test Studio aussi.
Échoue : le bug est détecté
La bonne question n'est donc pas quelle part de l'image a changé.C'est la question qu'une personne se pose : quelqu'un qui regarde cet écran verrait-il une différence ?La réponse ne dépend pas de la taille de l'image, alors elle vaut pour une petite icône comme pour une boîte de dialogue entière.
Les remèdes habituels aux tests de captures instables, et ce qu'ils coûtent
| Remède | Ce qu'il coûte |
|---|---|
| Relever le seuil | Le bruit passe, et les petits bugs aussi. |
| Masquer les parties qui changent | Chaque date, horloge et badge est masqué à la main, et un bug sous un masque n'est jamais vu. |
| Relancer un test échoué | Un vrai échec obtient une seconde chance de réussir par hasard, et chaque exécution dure plus longtemps. |
| Garder une image de référence par machine | Chaque navigateur, système et mise à l'échelle a besoin de ses propres images, et chacune doit être reprise après chaque changement. |
| Figer l'environnement | Une seule image de machine exécute chaque test, et un test qui y réussit ne dit rien des écrans de vos utilisateurs. |
Dans un framework codé comme Playwright, toHaveScreenshot prend un seuil de couleur par pixel et un nombre ou un ratio maximal de pixels différents pour toute l'image.Vous choisissez ces nombres, vous écrivez les masques et vous gardez une image de référence par navigateur et par plateforme, dans du code que vous maintenez.
Comment GUI Test Studio compare les captures d'écran
GUI Test Studio crée des tests de bout en bout d'applications web, d'applications de bureau Windows, de téléphones Android et de jeux à partir d'un enregistrement, sans code.Chaque élément sur lequel vous cliquez ou dans lequel vous tapez reçoit une assertion visuelle, une assertion qui garde une petite image de l'élément, sa cible visuelle.Voir les assertions visuelles.
Trouver
La phase de recherche
Comparer
La phase de vérification
Second regard
Analyse intelligente par IA
Rapport
Le rapport de confiance
D'abord, trouver l'élément
La phase de recherche trouve l'élément sur l'écran réel, où qu'il se trouve maintenant.Le GTS Engine + AI interroge d'abord l'application, par ses informations d'accessibilité ou les éléments propres de la page, et trouve l'élément à vue quand l'application ne le dit pas.Voir comment GUI Test Studio trouve chaque élément.
La comparaison se fait ensuite là où se trouve l'élément.Une fenêtre déplacée, ou un bouton décalé d'un pixel, n'est pas une différence du tout.
Ensuite, le comparer comme une personne le regarde
La phase de vérification compare l'élément avec sa cible visuelle de façon perceptuelle, comme le fait l'œil humain.Elle remarque ce qu'une personne remarquerait, et elle ignore ce que personne ne voit.
| À l'écran | Ce que fait la phase de vérification |
|---|---|
| Bords lissés et lissage des polices | Ignorés : ils diffèrent d'une machine à l'autre, et personne ne les voit. |
| Enregistrement et compression | Ignorés : une image tirée d'une vidéo garde un peu moins de détail de couleur que l'écran réel, et une personne y voit le même écran. |
| Un décalage d'un pixel | Ignoré : l'élément est comparé là où il se trouve maintenant. |
| Un curseur de texte qui clignote | Ignoré, tandis qu'une lettre modifiée à côté est détectée. |
| Un chiffre faux | Détecté : c'est ce qu'une personne lit en premier. |
| Une majuscule devenue minuscule | Détecté : une personne le voit tout de suite. |
| Une couleur modifiée | Détecté, dès qu'une personne le remarquerait : une icône rouge devenue orange échoue. |
| Une icône manquante | Détecté : une personne voit le vide. |
Survols et dates
Dans un test enregistré, l'exécution remet le pointeur de la souris là où il se trouvait quand l'image a été prise.Un bouton est éclairé pendant l'exécution exactement quand il l'était pendant l'enregistrement.
Une valeur qui change chaque jour n'a pas sa place dans une cible visuelle.Gardez la cible sur l'élément lui-même, et vérifiez une date, un total ou un compteur avec une assertion de texte dynamique, qui vérifie son format quelle que soit sa valeur.Voir les assertions de texte.
Et quand un écran a raison d'être différent en mode sombre, dans une autre langue ou sur un autre écran, gardez une version attendue par environnement avec un profil de référence : voir tester le mode sombre, d'autres langues, d'autres écrans.
Comparaison de pixels contre GUI Test Studio, cas par cas
| La différence | Une comparaison de pixels avec un seuil en pourcentage | GUI Test Studio |
|---|---|---|
| Bords lissés sur une autre machine | Échoue si stricte, réussit si souple | Réussit : personne ne le voit |
| Franges colorées du lissage des polices | Échoue si stricte | Réussit : personne ne le voit |
| L'élément s'est déplacé d'un pixel | Échoue : chaque bord diffère | Réussit : l'élément est comparé là où il se trouve |
| Un curseur de texte qui clignote | Échoue si stricte | Réussit : un curseur qui clignote est ignoré |
| Un survol mis en évidence | Échoue | Réussit : le pointeur se trouve là où il était lors de l'enregistrement |
| La date du jour | Échoue chaque jour | Pas comparée : une assertion de texte dynamique vérifie son format |
| Un chiffre faux | Réussit avec un seuil de 1 ou 2 % | Échoue : une personne voit le chiffre faux |
| Une majuscule devenue minuscule | Réussit avec un seuil de 1 ou 2 % | Échoue : une personne voit la minuscule |
| Une petite icône manquante | Réussit sur une grande image | Échoue : une personne voit que l'icône a disparu |
Comment choisir la tolérance d'une comparaison d'images
Dans GUI Test Studio, la tolérance d'une assertion visuelle est sa rigueur de vérification, choisie en mots simples : plus stricte pour les détails fins, plus tolérante pour les écrans chargés.Il n'y a aucun pourcentage à deviner.
| Rigueur de vérification | À utiliser pour |
|---|---|
| Exacte | Les images qui doivent rester exactement telles qu'elles sont. |
| Stricte | Le petit texte et les détails fins où le moindre changement compte. |
| Standard | Les boutons, libellés et icônes de tous les jours.Le réglage par défaut. |
| Souple | Les grandes zones et les écrans chargés, comme une page entière ou une scène de jeu. |
- 1
Sélectionner l'assertion visuelle
Ouvrez le test dans GUI Test Studio et cliquez sur l'assertion visuelle dans la chronologie.Ses réglages apparaissent dans le panneau Propriétés.
- 2
Choisir une rigueur de vérification
Gardez Standard pour les boutons, libellés et icônes de tous les jours.Choisissez un niveau plus strict pour le petit texte et les détails fins, un niveau plus tolérant pour les grandes zones et les écrans chargés, et Exacte seulement pour une image qui doit rester exactement telle qu'elle est.
- 3
Laisser Ignorer les petits artefacts de rendu activé
Il est activé par défaut, donc les bords lissés qui diffèrent d'une machine à l'autre sont ignorés.Désactivez-le seulement quand ces bords sont ce que vous testez.
- 4
Exécuter le test et lire le rapport
Cliquez sur Exécuter le test.Le rapport de confiance met en lumière ce qui a changé et dit en une phrase pourquoi l'assertion a échoué.
- 5
Ajouter des instructions pour l'IA si une différence est attendue
Sous Avancé, écrivez quelques mots comme : ignorer la taille de la police.L'Analyse intelligente par IA les suit quand elle juge cette assertion.
La plupart des tests n'ont jamais besoin de plus.Les réglages exacts de chaque niveau, et les réglages avancés pour la rare assertion qui en a besoin, sont dans les assertions visuelles et les réglages d'une assertion.
Le test visuel par IA : un second regard en mots simples
Une comparaison visuelle dit que quelque chose a changé, et où.Un second avis en mots vous aide à décider quoi en faire.C'est le rôle de l'Analyse intelligente par IA, désactivée tant que vous ne l'activez pas.
Le pointeur de la souris et le curseur de texte qui clignote ne comptent jamais comme une différence pour l'IA.Une assertion réussie ne lui est jamais envoyée.
Elle fonctionne avec un modèle dans le cloud et votre propre clé, ou avec un modèle d'IA local sur votre propre ordinateur : un modèle que nous fournissons, ou le vôtre.Certaines différences sont attendues, et vous seul savez lesquelles : donnez à une assertion des instructions pour l'IA, comme « ignorer la taille de la police » ou « l'icône peut être de n'importe quelle couleur ».Voir l'Analyse intelligente par IA.
Lire un échec visuel
Après une exécution, le rapport de confiance montre chaque assertion échouée avec l'image attendue, l'image trouvée et ce qui a changé mis en lumière sur l'écran.Le verdict dit en une phrase ce qui a changé, et où.
Quand le changement est voulu, acceptez le nouvel aspect depuis le rapport, et le test l'attend désormais.
Les bugs visuels qu'une vérification codée manque complètement sont le sujet de les bugs visuels que les tests automatisés manquent.
Points clés
- 1Le test de captures d'écran au pixel près échoue deux fois : le bruit de rendu fait échouer des écrans corrects, et un seuil en pourcentage laisse passer de vrais bugs.
- 2Le bruit, c'est ce que personne ne voit, un vrai changement, c'est ce qu'une personne remarque : un chiffre, une lettre, une icône, une couleur.
- 3Une part de l'image est la mauvaise mesure. Demandez-vous plutôt ce que verrait une personne qui regarde l'écran.
- 4GUI Test Studio trouve d'abord l'élément, puis le compare comme le fait l'œil humain, si bien que le lissage, la compression et un curseur qui clignote ne font jamais échouer un test.
- 5L'Analyse intelligente par IA ajoute un second regard en mots simples, et sa réponse est le verdict final quand vous l'activez.
Questions
Qu'est-ce que le test au pixel près ?
Le test au pixel près compare une capture d'écran d'une application avec une capture de référence, pixel par pixel, et échoue quand elles diffèrent.Il voit chaque changement, y compris ceux que personne ne voit.C'est pourquoi il déclenche de fausses alertes sur des écrans corrects.
Pourquoi les tests de comparaison de captures échouent-ils quand rien n'a changé ?
Parce que le même écran n'est pas dessiné partout avec les mêmes pixels.Les bords lissés, le lissage des polices, la carte graphique, la mise à l'échelle de l'écran, un curseur de texte qui clignote ou un survol changent quelques pixels sans rien changer qu'une personne remarquerait.Une comparaison pixel par pixel les compte tous.
Quel est un bon seuil pour le test de régression visuelle ?
Aucun pourcentage ne convient à toutes les images.Une part assez petite pour détecter un chiffre faux sur un grand panneau échoue sur un bruit sans conséquence, et une part assez souple pour ignorer le bruit laisse passer ce chiffre.Posez plutôt la question qu'une personne se pose : quelqu'un qui regarde l'écran verrait-il une différence ?C'est ainsi que GUI Test Studio compare.
L'anticrénelage provoque-t-il des faux positifs dans les tests visuels ?
Oui, c'est l'une des causes les plus courantes.Les bords du texte et des formes sont lissés avec des couleurs intermédiaires, et ce lissage diffère selon les machines, les cartes graphiques et les réglages.GUI Test Studio compare comme une personne regarde un écran, donc le lissage que personne ne voit est ignoré.
Un seuil de différence de pixels peut-il cacher un vrai bug ?
Oui.Un chiffre faux, une majuscule devenue minuscule ou une petite icône manquante change de quelques dizaines à quelques centaines de pixels, une part infime d'une grande image.Un seuil de 1 ou 2 % les laisse tous passer.
Comment GUI Test Studio compare-t-il les captures d'écran ?
En deux phases.La phase de recherche trouve l'élément à l'écran, où qu'il se soit déplacé.La phase de vérification le compare ensuite avec ce que vous attendez, comme le fait l'œil humain : elle détecte un chiffre faux, un mot modifié, une icône manquante ou une autre couleur, et ignore le bruit de rendu que personne ne voit.
Le test visuel par IA est-il meilleur que la comparaison de pixels ?
Ils fonctionnent mieux ensemble.Une comparaison visuelle soignée est rapide et reproductible, et elle décide seule de la plupart des assertions.Dans GUI Test Studio, l'Analyse intelligente par IA porte un second regard seulement sur une assertion échouée, dit en mots simples ce qui a changé, et rend le verdict final quand vous l'activez.
Comment gérer les dates et les compteurs dans les tests visuels ?
Gardez-les hors de l'image qu'une assertion visuelle compare, et vérifiez-les plutôt avec une assertion de texte.Une assertion de texte dynamique vérifie qu'une valeur a le bon format, comme une date ou un montant, quelle que soit sa valeur aujourd'hui.
Playwright, ClearType et Windows sont des marques de Microsoft Corporation.
À lire aussi
Tous les articles
Tests visuels
Tester le mode sombre, d'autres langues, d'autres écrans : un seul test pour toutes les variantes
10 min de lecture
Tests visuels
Bugs visuels que vos tests ratent : tester ce que voient vos utilisateurs
10 min de lecture
Automatisation des tests
Tests manuels ou tests automatisés : pourquoi les tests manuels ne suffisent pas pour les tests de bout en bout
15 min de lecture