Test de non-régression : définition et automatisation sans code
Qu'est-ce que le test de non-régression, et pourquoi les tests de régression de bout en bout attrapent ce que les tests unitaires ratent : quoi couvrir, quand les exécuter et comment les automatiser sans code.
11 min de lecturePar l'équipe de GUI Test Studio
Qu'est-ce qu'un test de non-régression ?
Définition
Le test de non-régression vérifie qu'un changement dans une application n'a rien cassé de ce qui fonctionnait déjà.
- Une nouvelle fonctionnalité, une correction de bug, la mise à jour d'une bibliothèque ou une nouvelle version de navigateur peuvent chacune casser une partie de l'application que personne n'a touchée.
- Les mêmes tests sont exécutés à nouveau après le changement, et un test qui réussissait avant et échoue maintenant a trouvé une régression.
Le mot vient de l'idée de recul : l'application a régressé, elle fait moins bien aujourd'hui qu'hier.C'est ce qui rend une régression si frustrante pour les utilisateurs.Quelque chose sur quoi ils comptaient a tout simplement cessé de fonctionner.
Les régressions arrivent parce que les parties d'une application dépendent les unes des autres d'une façon que personne n'a en tête.Un style partagé, une règle d'arrondi, un champ renommé dans une API : un petit changement à un endroit atteint des écrans très éloignés.La personne qui a fait le changement a vérifié ce qu'elle a modifié, et elle avait raison.La casse est ailleurs.
Test de non-régression ou retest : quelle différence ?
Les deux sont souvent confondus, et ils répondent à des questions différentes.
| Question | Retest | Test de non-régression |
|---|---|---|
| Que vérifie-t-il ? | Que le bug que vous avez corrigé l'est vraiment. | Que la correction, ou tout autre changement, n'a rien cassé d'autre. |
| Où regarde-t-il ? | À l'endroit du bug. | Partout ailleurs, surtout là où les utilisateurs comptent dessus. |
| Quels tests ? | Les étapes qui ont montré le bug. | La même suite, exécutée à nouveau après chaque changement. |
| Quand ? | Une fois, après la correction. | Après chaque changement, pendant toute la vie de l'application. |
Tests de régression unitaires, d'intégration et de bout en bout
Les tests de régression existent à chaque niveau d'une application, et chaque niveau en voit une part différente.
Quelle part de l'application chaque test voit
Tests unitaires
Une fonction, seule
Attrape : Un calcul qui renvoie la mauvaise valeur
Tests d'intégration
Deux ou trois parties ensemble
Attrape : Un service qui ne répond plus comme le suivant l'attend
Tests de bout en bout
Toute l'application, par son écran
Attrape : Un total, un bouton, une page ou un message que l'utilisateur voit cassé
Les tests unitaires et d'intégration sont rapides et précis, et chaque équipe devrait en avoir.Mais ils vérifient le code tel que le développeur le pense.Un utilisateur n'appelle jamais une fonction : il clique sur un bouton, lit un total et s'attend à ce que la page suivante s'ouvre.
Certaines régressions n'existent qu'à l'écran, là où les tests unitaires ne regardent jamais.
- Un changement de style cache le bouton Payer derrière un bandeau.
- Un total est bien calculé, mais affiché dans la mauvaise devise.
- Une boîte de dialogue s'ouvre derrière la fenêtre.
- Une traduction est trop longue et le libellé est coupé.
C'est pourquoi les tests de non-régression de bout en bout comptent le plus : un test de bout en bout pilote toute l'application par son interface, comme un utilisateur la parcourt, et vérifie ce que voit l'utilisateur.Voir ce qu'est un test de bout en bout pour une vue d'ensemble.
Vos utilisateurs n'exécutent pas vos tests unitaires.Ils utilisent votre application, écran après écran.
Tests de régression fonctionnels et non fonctionnels
Les tests fonctionnels vérifient ce que fait l'application : la commande est passée, le rapport est exporté, le message d'erreur apparaît quand un champ est vide.Les tests non fonctionnels vérifient comment elle le fait : à quelle vitesse, avec quelle apparence, comment elle se comporte sur un autre appareil ou un réseau lent.
Régression fonctionnelle
Le paiement passe toujours la commande, et la confirmation affiche toujours le numéro de commande.
Régression visuelle
L'écran a toujours la même apparence : pas d'icône manquante, pas de mot coupé, pas de bouton de la mauvaise couleur.
Régression non fonctionnelle
La page se charge toujours à temps, et la mise en page tient toujours sur un téléphone et sur une connexion lente.
La plupart des suites de régression sont fonctionnelles, et la plupart des casses visuelles et de mise en page passent au travers, car une assertion fonctionnelle demande si un élément existe, pas si une personne peut le voir.Les bugs visuels que vos tests automatisés ratent explique pourquoi.
Que mettre dans une suite de tests de régression de bout en bout ?
Une suite de régression qui essaie de tout couvrir n'est jamais terminée et ne gagne jamais la confiance.Commencez petit, par ce qui ferait le plus mal si cela cassait.
- 1
Lister les parcours dont les utilisateurs ne peuvent pas se passer
L'inscription, la connexion, la recherche, le paiement, le rapport que vos clients exportent chaque lundi.Cinq à dix parcours, chacun du premier clic jusqu'au résultat que l'utilisateur attend.
- 2
Ajouter ce qui a déjà cassé
Chaque bug qui a atteint les utilisateurs une fois mérite un test, pour qu'il ne puisse jamais revenir sans être remarqué.C'est ainsi qu'une suite de régression apprend.
- 3
Pondérer par le risque, pas par le nombre d'écrans
Un écran utilisé par chaque client tous les jours compte plus que dix pages de paramètres.L'argent, les données et la connexion passent en premier.
- 4
Vérifier les résultats, pas seulement les clics
Un test qui clique tout au long du paiement sans jamais vérifier le total ne prouve pas grand-chose.Chaque parcours se termine sur ce pour quoi l'utilisateur est venu, et le test le vérifie : le total, la confirmation, le fichier exporté.
- 5
La garder assez rapide pour l'exécuter à chaque changement
Désignez une poignée de parcours comme suite de smoke tests, ceux qui s'exécutent sur chaque pull request en quelques minutes.Le reste s'exécute chaque nuit.
Quand exécuter les tests de non-régression ?
Plus une régression est trouvée tôt, moins elle coûte : le changement est encore frais dans l'esprit du développeur, et rien n'a encore été construit par-dessus.
| Quand | Ce qui s'exécute | Pourquoi |
|---|---|---|
| Chaque pull request ou chaque build | La suite de smoke tests : les parcours critiques. | Une casse est attrapée avant d'être fusionnée, tant que le changement est petit. |
| Chaque nuit | Toute la suite. | Tout est vérifié une fois par jour, sans ralentir personne. |
| Avant une release | Toute la suite, sur chaque navigateur et appareil que vous prenez en charge. | Ce que les utilisateurs recevront vraiment est vérifié là où ils le recevront. |
| Après une mise à jour que vous ne maîtrisez pas | Toute la suite. | Une nouvelle version de navigateur, de système d'exploitation ou de bibliothèque peut casser l'application sans qu'une ligne de votre code ait changé. |
Parcours de paiement, huit derniers builds
- #38
- #39
- #40
- #41
- #42
- Premier échec#43
- #44
- #45
#42 la dernière exécution réussie#43 le changement à examiner en premier#45 corrigé, puis vérifié à nouveau
Pourquoi les suites de tests de régression automatisés finissent abandonnées
La plupart des équipes s'accordent à dire que les tests de non-régression devraient être automatisés.Beaucoup ont essayé, et beaucoup de suites automatisées finissent désactivées ou ignorées.Les raisons sont presque toujours les mêmes.
La suite coûte plus cher à entretenir qu'elle ne fait gagner.
- Les tests codés trouvent les boutons par des sélecteurs, et chaque refonte en casse des dizaines d'un coup.
- Seuls les développeurs peuvent les réparer, et les développeurs construisent des fonctionnalités.
- Les tests échouent pour des raisons sans conséquence, une nuance de couleur ou un pixel d'anticrénelage, alors les gens cessent de lire les résultats.
- La suite complète prend des heures, alors elle s'exécute une fois par semaine, et les régressions attendent des jours avant d'être trouvées.
Automatiser les tests de non-régression de bout en bout sans code
GUI Test Studio est conçu pour les tests de non-régression de bout en bout des applications web, des applications de bureau Windows, des téléphones et des jeux, par leur interface, sans code de test à écrire ni à maintenir.
Enregistrer chaque parcours une fois
Cliquez sur Enregistrer dans GUI Test Runner-Recorder et suivez le parcours dans votre vraie application, comme le ferait un utilisateur.Les clics, la saisie et les assertions sur ce qui est apparu deviennent un test.Vous pouvez aussi décrire le parcours dans une consigne à votre assistant IA, et le test est créé pour vous.
Le test vérifie ce que l'écran affiche, pas le code derrière.
- Une assertion visuelle compare l'image d'un élément, une assertion de texte lit ses mots.
- Le GTS Engine + AI trouve chaque élément d'abord par les informations d'accessibilité de l'application, et à vue quand l'application ne le dit pas, si bien qu'une refonte du code derrière un bouton ne casse pas le test.
Modifiez-le comme une vidéo
Chaque test s'ouvre dans GUI Test Studio sur une chronologie : ses étapes sous forme de blocs, ses assertions à côté, l'enregistrement au-dessus.Modifiez une assertion, ajoutez une attente, groupez les étapes d'un parcours : sans code, et n'importe qui dans l'équipe peut le faire.Voir la chronologie.
Exécutez-le à chaque build
gtr-cli exécute la suite sur une machine de build Windows et répond comme un pipeline l'attend : un test échoué fait échouer le build, un fichier JUnit remplit l'onglet des tests, et chaque image de ce qui a échoué est conservée.
gtr-cli run tests\regression --countdown 0 --junit results\junit.xml --artifacts results\artifactsCela fonctionne dans TeamCity, Jenkins, GitHub Actions, GitLab et Azure DevOps.Voir Exécuter des tests dans votre pipeline.
Une vraie régression, ou un bruit sans conséquence ?
Chaque exécution se termine par un rapport de confiance.Pour chaque assertion, il indique si l'élément a été trouvé et s'il a toujours l'apparence enregistrée, avec les images attendue et obtenue côte à côte et la différence entourée.
Le bruit est ignoré et les régressions sont attrapées.
- Les légères différences de rendu qu'aucune personne ne remarquerait ne sont pas comptées.
- Un mot modifié, un badge manquant ou un bouton devenu gris fait échouer l'assertion.
- Quand une image diffère, l'analyse intelligente par IA peut jeter un second regard et dire en mots simples ce qui a changé.
Un changement voulu s'accepte en un clic
Toute différence n'est pas une régression : parfois, le nouvel écran est le bon.Dans le rapport de confiance, acceptez ce que l'exécution a trouvé comme nouvelle image attendue, et l'exécution suivante s'y compare.Pour les écrans qui diffèrent volontairement, un mode sombre ou une autre langue, les références gardent une version par environnement.
Savoir quand cela a commencé
Chaque exécution est conservée dans l'historique du test.Quand un parcours commence à échouer, l'historique montre la dernière exécution réussie et la première qui a échoué, et deux exécutions peuvent être comparées assertion par assertion.
Chaque navigateur et appareil, et un bug dans votre outil de suivi
Un test web enregistré une fois s'exécute dans Chrome, Edge et Firefox, sur téléphones et tablettes, dans d'autres langues et tailles d'écran : voir le test multi-navigateurs.Et une exécution échouée peut devenir d'elle-même un ticket Jira, avec les étapes pour reproduire et les images : voir les tests échoués comme bugs Jira.
Une modification est poussée
Une fonctionnalité, une correction, une mise à jour
Le build s'exécute
gtr-cli exécute la suite
Rapport de confiance
Régression ou bruit, avec images
Fusionner, ou corriger d'abord
Un échec bloque le changement
À faire
- Une petite suite de parcours critiques à chaque build
- Des assertions sur ce que voit l'utilisateur à la fin de chaque parcours
- Un test pour chaque bug qui a atteint les utilisateurs
- Chaque navigateur et appareil avant une release
À éviter
- Une suite si grande qu'elle ne s'exécute qu'une fois par semaine
- Des tests qui cliquent tout au long d'un parcours sans rien vérifier
- Des échecs que personne ne lit parce que la moitié est du bruit
- Des tests que seuls les développeurs peuvent modifier
Points clés
- 1Le test de non-régression vérifie qu'un changement n'a rien cassé de ce qui fonctionnait. Les mêmes tests, exécutés à nouveau après chaque changement.
- 2Le retest prouve une correction ; le test de non-régression prouve qu'elle n'a rien coûté d'autre.
- 3Les tests de régression de bout en bout attrapent ce que ressentent les utilisateurs : les totaux, boutons, pages et messages que les tests unitaires ne voient jamais.
- 4Commencez petit : cinq à dix parcours critiques à chaque build, la suite complète chaque nuit, chaque navigateur et appareil avant une release.
- 5Une suite doit distinguer une régression du bruit, et coûter peu à entretenir, sinon elle sera abandonnée.
Questions
Qu'est-ce qu'un test de non-régression ?
Le test de non-régression vérifie qu'un changement dans une application n'a rien cassé de ce qui fonctionnait déjà.Après une nouvelle fonctionnalité, une correction de bug ou une mise à jour, les mêmes tests sont exécutés à nouveau, et tout test qui réussissait avant et échoue maintenant signale une régression.
Quelle est la différence entre le test de non-régression et le retest ?
Le retest vérifie que le bug que vous avez corrigé l'est vraiment.Le test de non-régression vérifie que la correction, ou tout autre changement, n'a pas cassé le reste de l'application.Le retest regarde un seul endroit, le test de non-régression regarde partout ailleurs.
Qu'est-ce que le test de non-régression de bout en bout ?
Le test de non-régression de bout en bout exécute les parcours importants d'une application par son interface, comme un utilisateur les suit, après chaque changement.Il attrape les casses qui ne se voient qu'à l'écran : un total faux, un bouton qui n'ouvre plus sa boîte de dialogue, une page qui ne se charge pas.
Le test de non-régression est-il fonctionnel ou non fonctionnel ?
Les deux.La plupart des tests de régression sont fonctionnels : ils vérifient que les fonctionnalités font toujours ce qu'elles doivent.Une régression peut aussi être non fonctionnelle, comme une page devenue lente ou une mise en page cassée sur un téléphone, et celles-là méritent leurs propres tests.
À quelle fréquence exécuter les tests de non-régression ?
Exécutez une courte suite de parcours critiques sur chaque pull request ou chaque build, la suite complète chaque nuit, et la suite complète sur chaque navigateur et appareil avant une release.Plus une régression est attrapée tôt, moins elle coûte à corriger.
Peut-on automatiser les tests de non-régression sans écrire de code ?
Oui.Avec GUI Test Studio, vous enregistrez un parcours une fois en utilisant l'application, ou vous le décrivez dans une consigne, et le test est créé pour vous.Il s'exécute à nouveau à chaque build avec gtr-cli, et personne n'a de code de test à maintenir.
Qu'est-ce que le test de régression visuelle ?
Le test de régression visuelle compare ce que l'écran affiche maintenant avec ce qu'il affichait avant, pour attraper les changements qu'un utilisateur verrait : une icône manquante, un mot coupé, un bouton de la mauvaise couleur.C'est une forme d'assertion de régression de bout en bout.
OpenAI, Anthropic, Jira, TeamCity, Jenkins, GitHub, GitLab, Azure DevOps, Chrome, Edge et Firefox 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.