Tests instables et faux positifs : pourquoi des tests échouent à tort
Tests instables et faux positifs : pourquoi des tests échouent sur une application qui fonctionne, et comment les arrêter sans manquer de vraies régressions.
12 min de lecturePar l'équipe de GUI Test Studio
Un build rouge devrait vouloir dire une seule chose : l'application est cassée.Trop souvent, il veut dire autre chose : un test a cliqué trop tôt, une police s'est affichée avec une nuance différente, un indicateur de chargement tournait encore.Ce sont les tests instables et les faux positifs, et ils sont l'une des principales raisons pour lesquelles les équipes cessent de croire leurs tests de bout en bout.
Ce guide explique d'où ils viennent dans les tests codés et visuels, et comment arrêter les faux positifs sans laisser passer les vrais bugs.
Que sont les tests instables (flaky) et les faux positifs ?
Un faux positif est un test qui échoue alors que l'application fonctionne comme elle le doit.Les testeurs parlent aussi de faux échec ou de fausse alerte.Le test donne l'alerte, quelqu'un enquête, et rien ne cloche.
Un test instable (flaky) est un test qui réussit et échoue sur le même code, sans que rien ne change entre les exécutions.Chaque échec instable est un faux positif.Tous les faux positifs ne sont pas instables pour autant : un test qui échoue à chaque fois parce que son image attendue est périmée est faux, pas instable.
L'erreur inverse est le faux négatif : un test qui réussit alors qu'un vrai bug est à l'écran.C'est la plus dangereuse des deux, car personne ne regarde deux fois un test vert.
| Ce qui s'est passé | Son nom |
|---|---|
| Le test échoue, l'application fonctionne | Un faux positif, faux échec ou fausse alerte |
| Le test réussit, l'application est cassée | Un faux négatif : un bug manqué |
| Même code, parfois rouge, parfois vert | Un test instable |
| Le test échoue, l'application est cassée | Un vrai échec : le test a fait son travail |
Ce que les faux positifs coûtent à une équipe
Une fausse alerte coûte une enquête.Quelqu'un ouvre les journaux, relance le test et ne trouve rien.
Le vrai coût vient plus tard.Quand la plupart des builds rouges sont du bruit, on cesse de les lire : c'est la lassitude face aux alertes.Viennent ensuite les habitudes qui cachent les bugs : relancer un test jusqu'à ce qu'il passe au vert, accepter chaque nouvelle capture d'écran comme référence sans la regarder, désactiver le test qui échoue toujours.
Chacune de ces habitudes transforme le faux positif d'aujourd'hui en faux négatif de demain.Le bug pour lequel le test a été écrit passe, parce que plus personne ne croit le test.
Qu'est-ce qui rend les tests de bout en bout instables ?
Les tests de bout en bout pilotent toute une application par son interface, donc ils rencontrent tout ce qu'un vrai utilisateur rencontre : serveurs lents, animations, autres fenêtres.Les tests codés ajoutent des causes qui leur sont propres.
| Cause | Ce qui se passe |
|---|---|
| Minutage et attentes | Le test clique avant que le bouton soit prêt, ou une pause fixe est trop courte un jour de forte charge. |
| Éléments périmés | La page a été redessinée entre le moment où l'élément a été trouvé et le clic, et le test tient un élément qui n'existe plus. |
| Sélecteurs modifiés | Un développeur a renommé une classe ou une mise à jour du framework a changé la structure de la page, et le localisateur ne trouve rien, ou le mauvais élément. |
| Données de test | Un test précédent a laissé une donnée derrière lui, ou deux tests modifient le même compte en même temps. |
| Environnement | Une autre taille d'écran, une autre version du navigateur, un autre système d'exploitation ou une machine surchargée. |
| Animations | L'élément est trouvé alors qu'il glisse ou apparaît encore en fondu. |
| Réseau | Une requête lente ou en échec laisse la page à moitié chargée, ou un script tiers arrive en retard. |
Le minutage vient en premier pour une raison.La documentation de Selenium elle-même appelle la course entre le test et le navigateur l'une des principales causes de tests instables.
Pourquoi les tests de régression visuelle donnent des faux positifs
Le test de régression visuelle compare une image de l'application avec une image de référence approuvée.Il détecte ce que les assertions codées manquent : une mauvaise couleur, un libellé qui en chevauche un autre, une icône manquante.Il voit aussi des différences que personne n'appellerait un changement.
| Source du 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. |
| Rendu des polices au sous-pixel | Sous Windows, le texte est dessiné avec de légères franges colorées qui dépendent de l'écran et de ses réglages. |
| Bruit de vidéo et de compression | Une image tirée d'un enregistrement, ou compressée, perd un fin détail de couleur que l'écran en direct garde. |
| Cartes graphiques et pilotes | Deux machines peuvent mélanger et mettre à l'échelle la même page un peu différemment. |
| Contenu dynamique | Une date, un compteur, une publicité ou un flux en direct change à chaque exécution. |
| Pointeurs et curseurs de texte | Le pointeur de la souris ou un curseur de texte clignotant est sur une image et pas sur l'autre. |
| États de survol | Le pointeur s'est arrêté sur un bouton pendant une exécution, donc le bouton n'est mis en évidence que sur une seule image. |
| Une page encore en chargement | La capture a été prise avant la fin d'une image, d'une police ou d'une transition. |
Une comparaison stricte, pixel par pixel, échoue sur chacun de ces cas.Une comparaison lâche laisse passer de vrais bugs.Tout l'art du test visuel est de distinguer les deux.
Comment les équipes corrigent les tests instables aujourd'hui
Dans les tests codés
Playwright attend avant chaque action que l'élément soit visible, stable, activé et non recouvert par un autre élément, et échoue sinon après un délai d'attente.
Cypress relance ses requêtes et ses assertions jusqu'à ce qu'elles réussissent, pendant 4 secondes au plus par défaut.Il peut aussi relancer tout un test échoué, ce qui est désactivé par défaut.
Selenium propose des attentes explicites qui interrogent l'application jusqu'à ce qu'une condition soit remplie, et sa documentation déconseille de les mélanger avec des attentes implicites.
Les relances servent aussi à détecter l'instabilité.Playwright signale comme instable (flaky) un test qui a échoué puis réussi lors d'une relance, et Cypress Cloud marque un tel test d'un badge Flaky.Une relance rend le build vert, mais elle ne supprime pas la cause.
Dans les tests visuels
Dans Playwright, toHaveScreenshot accepte un seuil de couleur par pixel, 0.2 par défaut, et soit un maxDiffPixels absolu, soit un maxDiffPixelRatio.Il peut masquer des zones dynamiques, et par défaut il arrête les animations et cache le curseur de texte.
BackstopJS tolère un pourcentage de pixels différents, 0.1 par défaut, et peut cacher ou retirer les éléments que vous désignez avant de prendre ses captures.
Chromatic ignore par défaut les pixels anticrénelés, et son diffThreshold, 0.063 par défaut, règle la quantité de changement tolérée.
Argos stabilise chaque capture d'écran par défaut : il attend les polices et les images, cache le curseur de texte et les barres de défilement, et signale les captures qui changent d'une exécution à l'autre.
Percy fige les animations et les autres éléments dynamiques, et les changements s'approuvent par build, par groupe ou une capture à la fois.Son Visual Review Agent met en évidence les changements qu'il juge significatifs.
Applitools Eyes compare avec des niveaux de correspondance.Strict vise à ignorer ce que l'œil humain ne verrait pas, Layout ne vérifie que l'agencement, et Dynamic accepte toute date, adresse e-mail ou URL valide.
Chacun de ces outils aide.Chacun vous demande aussi de choisir un nombre, un masque ou un niveau, test par test, et de revoir les nouvelles images à la main.Pour voir ces outils côte à côte, lisez l'étude comparative.
Pourquoi une tolérance plus large n'est pas la réponse
Une tolérance est une promesse : telle quantité de différence est du bruit.Toute la question est de savoir en quoi se mesure cette quantité.
Un ratio grandit avec l'image.Sur un plein écran de 1920×1080 pixels, 0.1 % représente environ 2000 pixels, plus qu'un mot modifié.Sur un bouton de 100×40 pixels, cela fait 4 pixels, moins qu'un seul bord rendu différemment.
Un nombre absolu ne grandit pas avec l'image, mais il additionne le bruit dispersé sur toute l'image comme s'il s'agissait d'un seul changement.Un masque cache le bruit, et il cache aussi tout bug à l'intérieur du masque.
Comment GUI Test Studio arrête les faux positifs sans laisser passer les bugs
GUI Test Studio est une suite d'automatisation des tests de bout en bout pour les applications web, les applications de bureau Windows, Android et les jeux.Vous enregistrez un test une fois, ou vous le décrivez dans un prompt, vous le modifiez sur une chronologie et vous l'exécutez à chaque build.Ses assertions suivent une règle : un test échoue quand une personne verrait un problème, et seulement alors.
Trouver
Interroger l'application, ou trouver l'élément à vue
Attendre
L'écran, jamais une minuterie
Comparer
Compter ce qui a nettement changé, et où
Décider
L'analyse intelligente par IA, si vous l'activez
Rapport
Ce qui a changé, en mots simples
Les éléments sont trouvés de deux façons, sans sélecteur qui casse
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 dans un navigateur.Quand l'application ne dit rien, il trouve l'élément à vue, sur l'écran.Il n'y a aucun localisateur à écrire, donc une classe renommée ou un nouveau framework ne cassent pas un test.Voir comment GUI Test Studio trouve chaque élément.
Les assertions attendent l'écran, jamais une minuterie
Chaque assertion continue de chercher jusqu'à ce que ce qu'elle attend soit à l'écran, dans la limite de son délai d'attente de 5 secondes par défaut, et le test continue dès que c'est là.Une assertion d'absence visuelle attend qu'un indicateur de chargement disparaisse : une page lente est attendue, pas devinée.
Quand une assertion visuelle ou une assertion de texte n'a pas trouvé son élément dans sa zone de recherche au bout d'une seconde, elle cherche aussi sur tout l'écran, donc une fenêtre déplacée ne fait pas échouer le test.Avant le début d'une exécution, GUI Test Runner-Recorder compare votre écran avec le premier moment de l'enregistrement et retient l'exécution quand l'application est sur une autre page.Voir les réglages d'une assertion.
La phase de vérification compte ce qui a changé, et où
Une fois l'élément trouvé, la phase de vérification le compare avec ce que vous attendez.Elle compte les pixels qui ont nettement changé dans la petite zone de l'élément où ils se concentrent le plus : un nombre absolu, jamais un pourcentage de l'image.
Le bruit est dispersé : un bord plus doux ici, une nuance plus claire là.Un vrai changement est concentré à un endroit : une lettre, un chiffre, une icône.C'est pourquoi la même règle fonctionne sur une petite icône comme sur une boîte de dialogue entière.
| À l'écran | Ce que fait la phase de vérification |
|---|---|
| Un pixel à peine différent | Jamais compté seul, tandis qu'une lettre qui change de casse fait toujours échouer l'assertion |
| Bords lissés | Tolérés par Ignorer les petits artefacts de rendu, activé par défaut, tandis qu'une icône manquante fait toujours échouer l'assertion |
| Un détail de couleur que seul l'écran en direct peut garder | Non compté, tandis qu'un bouton ou un badge qui change de couleur fait toujours échouer l'assertion |
| Un curseur de texte clignotant, isolé | Non compté, tandis qu'une lettre modifiée à côté fait toujours échouer l'assertion |
| Un chiffre ou un mot modifié | Fait échouer l'assertion, là où c'est arrivé |
Chaque assertion a une Rigueur de vérification : Exacte, Stricte, Standard ou Souple.Standard convient aux boutons, libellés et icônes de tous les jours, et Souple aux grandes zones et aux écrans chargés.Voir les assertions visuelles.
Le bon moment, avec le pointeur là où il était
Un élément est souvent trouvé alors que l'écran se stabilise encore : un menu qui apparaît en fondu, une page encore en chargement.La passe de précision renforcée regarde les images qui suivent la correspondance, garde celle où l'élément a sa meilleure apparence, et s'arrête là où commence l'étape suivante du test.Voir la passe de précision renforcée.
Dans un test enregistré, l'exécution remet le pointeur de la souris là où il était quand l'image a été prise.Un bouton est alors mis en évidence pendant l'exécution exactement quand il l'était dans l'enregistrement.
Un test que vous venez d'enregistrer, et pas encore modifié, reçoit une aide supplémentaire.Quand un élément n'apparaît pas tel qu'il a été enregistré, l'exécution ajuste intelligemment le test pour le trouver, et elle ne le fait jamais pour cacher une vraie différence.
Différent exprès : les profils de référence
Certaines différences sont réelles et voulues : le mode sombre, un écran de portable au lieu d'un moniteur 4K, une autre version de Windows, l'application dans une autre langue.Un profil de référence garde une version attendue d'une assertion par environnement, si bien qu'un seul test les sert tous.Où chercher, combien de temps attendre et quelle rigueur appliquer restent communs à toutes les versions.Voir les profils de référence.
L'analyse intelligente par IA rend le verdict final
Quand une assertion trouve des pixels changés, l'analyse intelligente par IA peut jeter un second regard et décider, avec un modèle dans le cloud et votre propre clé, ou un modèle d'IA local sur votre propre ordinateur, l'un des nôtres ou le vôtre.Elle reste désactivée tant que vous ne l'activez pas.
Elle fait réussir une assertion quand elle ne trouve que des différences mineures qu'un utilisateur risque de ne pas remarquer, tandis qu'un mot, un nombre ou une valeur qui change, ou une icône ou un badge manquant, n'est jamais mineur et fait échouer l'assertion.Le rapport dit de quel cas il s'agit.
Le pointeur de la souris et le curseur de texte clignotant ne comptent jamais comme une différence, tandis qu'une lettre ou une icône qui a changé compte toujours.Vous pouvez aussi donner à une assertion des instructions pour l'IA dans vos propres mots, par exemple : la date dans le coin change tous les jours.Voir l'analyse intelligente par IA.
Un rapport qui dit ce qui a changé
Le rapport de confiance montre chaque assertion visuelle en deux phases.La phase de recherche dit si l'élément a été trouvé, et la phase de vérification s'il ressemble à ce qui est attendu.Pulsation met en lumière ce qui a changé à l'écran, et le verdict le dit en mots simples.
Ses maillons faibles désignent les assertions qui ont réussi avec la plus petite marge, celles qui risquent le plus d'échouer ensuite.L'historique montre quand une assertion a commencé à échouer.Quand un changement est voulu, vous acceptez la nouvelle apparence dans le rapport, et rien n'est écrit tant que vous ne sauvegardez pas.Voir le rapport de confiance.
Arrêter ou continuer : vous décidez de ce que veut dire un échec
Chaque assertion dit ce que fait son échec : arrêter le test, ou le continuer.Une assertion dont dépendent les clics suivants arrête le test par défaut, car cliquer sans elle toucherait le mauvais endroit.Une assertion qui ne fait que confirmer ce qui est à l'écran continue, si bien qu'une exécution signale chaque problème qu'elle rencontre.
Dans un pipeline, gtr-cli peut exécuter une fois de plus un test échoué avec son option de relance.Gardez-la en dernier recours : ce sont les causes ci-dessus qu'il faut corriger.
Une liste de contrôle contre les faux positifs
Do
- Attendre une condition : un élément, un texte, un indicateur de chargement disparu.
- Garder chaque assertion visuelle petite et distinctive.
- Donner à chaque environnement légitime sa propre référence.
- Lire pourquoi une assertion a échoué avant de la relancer.
- Surveiller les assertions qui réussissent de justesse.
Avoid
- Les pauses fixes.
- Relever une tolérance jusqu'à ce que le build passe au vert.
- Accepter de nouvelles références sans les regarder.
- Relancer les échecs jusqu'à ce qu'ils réussissent.
- Masquer des zones entières de l'écran.
Envie de voir cela sur votre propre application ?Les tests visuels avec GUI Test Studio montrent toute l'idée en une page.
Questions
Qu'est-ce qu'un faux positif en test logiciel ?
Un faux positif est un test qui échoue alors que l'application fonctionne comme elle le doit.Les testeurs parlent aussi de faux échec ou de fausse alerte.L'inverse, un test qui réussit alors qu'un bug est à l'écran, est un faux négatif.
Quelle est la différence entre un test instable et un faux positif ?
Un test instable réussit et échoue sur le même code, sans que rien ne change entre les exécutions.Chaque échec instable est un faux positif, mais un test peut aussi échouer à chaque fois pour une mauvaise raison, comme une image attendue périmée.
Qu'est-ce qui rend les tests de bout en bout instables ?
Le plus souvent le minutage : le test agit avant que l'application soit prête.Les sélecteurs modifiés, les éléments périmés, les données de test partagées, les animations, les réseaux lents et les différences entre machines sont les autres causes fréquentes.
Comment réduire les faux positifs en test de régression visuelle ?
Attendez que l'écran se stabilise, gardez chaque zone comparée petite, ignorez le bruit de rendu comme l'anticrénelage, et gardez une référence par environnement.GUI Test Studio ne compte que les pixels qui ont nettement changé à un même endroit, si bien que le bruit de rendu passe tandis qu'une lettre, un chiffre ou une couleur qui change fait toujours échouer le test.
Faut-il relancer les tests instables ?
Une relance rend un build vert, mais elle ne supprime pas la cause, et elle peut cacher un vrai bug qui ne se produit que parfois.Servez-vous des relances pour repérer les tests instables, puis corrigez le minutage, les données ou la comparaison qui les causent.
L'IA peut-elle distinguer un vrai bug visuel du bruit ?
Oui, en second regard après la comparaison des pixels.Dans GUI Test Studio, l'analyse intelligente par IA rend le verdict final d'une assertion échouée : les différences mineures passent, tandis qu'un mot, un nombre ou une valeur qui change, ou une icône manquante, fait toujours échouer l'assertion.
Selenium, Playwright, Cypress, BackstopJS, Chromatic, Argos, Percy et Applitools Eyes sont des marques de leurs propriétaires respectifs.
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.