Tests de bout en bout vs tests d'intégration : ce que chacun attrape (avec des exemples)
Tests de bout en bout vs tests d'intégration : ce que voit chacun, le bug de paiement que seul un test de l'écran attrape, la pyramide des tests, et combien de tests de bout en bout il vous faut.
10 min de lecturePar Ait Nohaila, Chargée de développement commercial
Tests de bout en bout vs tests d'intégration : la différence en une ligne
Définition
Les tests d'intégration vérifient que deux parties ou plus d'une application fonctionnent ensemble à leur jointure, par le code ou par une API, tandis que les tests de bout en bout vérifient toute l'application à travers son écran, comme un utilisateur la parcourt.
- Un test d'intégration pose une question au code : le service du panier a-t-il renvoyé le total qu'attend la page de paiement ?
- Un test de bout en bout pose une question à l'écran : l'utilisateur voit-il le bon total là où il l'attend ?
- Les deux sont nécessaires, et aucun ne peut répondre à la question de l'autre.
On confond les deux parce que tous deux testent plus d'une pièce à la fois.La différence, c'est l'endroit où se tient le test.Un test d'intégration se tient à la jointure entre deux parties et observe ce qui la traverse.Un test de bout en bout se tient là où se tient l'utilisateur, devant l'écran, et observe le résultat de tout ce qui se trouve derrière.
Les tests d'intégration vérifient la jointure.Un test de bout en bout vérifie ce qui est dessiné.
Tests E2E vs tests d'intégration, côte à côte
Voici comment les deux se comparent sur les questions qu'une équipe se pose quand elle décide quoi automatiser.
| Question | Tests d'intégration | Tests de bout en bout |
|---|---|---|
| Portée | Deux parties ou plus de l'application, ensemble : un service et sa base de données, l'API et le module qui l'appelle. | Toute l'application telle que l'utilisateur la rencontre, avec chaque partie dont elle dépend : l'écran, les services derrière lui, souvent d'autres systèmes comme un prestataire de paiement. |
| Point d'entrée | Du code ou une API : le test appelle une fonction ou envoie une requête et lit la réponse. | L'écran : le test clique, saisit du texte et lit ce qui est dessiné, comme le ferait une personne. |
| Ce qu'il trouve | Une partie qui ne répond plus comme l'attend la partie suivante : un champ renommé, un mauvais statut, un enregistrement manquant. | Un parcours qui ne donne plus à l'utilisateur le bon résultat : un total faux à l'écran, un bouton qui ne fait rien, une page qui ne s'ouvre pas. |
| Vitesse | De quelques millisecondes à quelques secondes par test.Des centaines peuvent tourner à chaque commit. | De quelques secondes à quelques minutes par parcours.Une suite de quelques dizaines tourne à chaque build ou chaque nuit. |
| Coût | Peu coûteux à écrire pour le développeur qui connaît la jointure, et peu coûteux à exécuter. | Coûteux quand c'est du code : chaque refonte casse les sélecteurs.Peu coûteux quand il est enregistré depuis l'écran et maintenu sans code. |
| Qui l'écrit | Les développeurs, à mesure qu'ils construisent chaque jointure. | Les testeurs, les ingénieurs QA et les product owners qui savent ce que l'utilisateur attend ; les développeurs aussi. |
| Quand il tourne | À chaque commit, dans le build, avant que quoi que ce soit soit fusionné. | À chaque build ou pull request pour quelques parcours critiques, chaque nuit pour toute la suite, sur chaque navigateur et appareil avant une livraison. |
Le bug qu'un test d'intégration ne peut pas voir
Prenez une page de paiement.Le service du panier additionne les articles, le service des prix applique le tarif de livraison, et la page de paiement dessine le résultat sur trois lignes : Sous-total, Livraison et Total.Un jour, un développeur fait du ménage dans le modèle de la page de paiement.Une ligne se déplace.Le code derrière n'est pas touché.
Le test d'intégration demande à l'API le total du panier et le compare au nombre qu'il attend.Il obtient 48.90, exactement juste, et réussit.Chaque service a fait son travail, et la jointure entre eux est saine.
Le test de bout en bout fait ce que fait un client : ajouter deux articles, ouvrir la page de paiement, et lire le total avant de payer.À l'écran, la ligne Total est vide, et 48.90 se trouve désormais à côté de Livraison.Un client lit que la livraison coûte 48.90 et que rien n'est dû.C'est un bug que personne ne contesterait, et aucun test d'intégration ne peut le voir, parce qu'un test d'intégration ne regarde jamais la page.
Le même schéma cache beaucoup des bugs qui atteignent les utilisateurs.
- Un total calculé en dollars et dessiné avec un signe euro.
- Un bouton Payer poussé sous la ligne de flottaison par une nouvelle bannière.
- Un message de confirmation qui apparaît derrière la fenêtre.
- Un libellé trop long pour son champ après une traduction.
- Dans chaque cas, les données sont justes et l'écran est faux.
C'est le même écart que les bugs visuels que vos tests automatisés ratent décrit de l'autre côté : une assertion qui demande si un élément existe ne peut pas dire si une personne peut le voir, le lire ou cliquer dessus.
La pyramide des tests : où chaque couche mérite sa place
La pyramide des tests est l'image habituelle de la façon dont une suite doit être dimensionnée.Sa forme tient au coût, pas à l'importance : un test unitaire tourne en une milliseconde et peut être écrit pour chaque cas, un test de bout en bout lance la vraie application et suit un seul parcours, donc il y en a moins.
La pyramide des tests : combien de tests, et ce que voit chaque couche
Tests unitaires
Un test unitaire mérite sa place en attrapant un calcul faux au moment où il est écrit, dans la fonction qui l'a produit.
Tests d'intégration
Un test d'intégration mérite sa place en attrapant une jointure qui a cassé : un champ renommé dans un service et toujours attendu par un autre.
Tests de bout en bout
Un test de bout en bout mérite sa place en attrapant ce que seul l'écran montre : le bon nombre dans le mauvais champ, le bouton sur lequel on ne peut pas cliquer, la page qui ne s'ouvre jamais.
Les tests système se situent près du sommet de la pyramide, et beaucoup d'équipes utilisent les deux noms pour la même chose.La distinction utile : les tests système vérifient l'application assemblée par rapport à ses exigences, les tests de bout en bout suivent le parcours d'un utilisateur à travers tout ce que ce parcours touche.Ce que sont les tests de bout en bout présente le tableau complet.
Tests d'intégration vs tests de bout en bout : quand utiliser lequel
Le choix est rarement l'un ou l'autre.Chaque couche est la moins coûteuse pour un type de question différent, et une équipe qui sait quelle question elle pose met le test au bon endroit.
Utilisez un test d'intégration quand la question porte sur une jointure.
- L'API répond-elle toujours sous la forme qu'attend le module ?
- La commande arrive-t-elle dans la base de données avec tous ses champs ?
- Le refus du prestataire de paiement revient-il sous la forme de l'erreur que le code gère ?
- Ce sont beaucoup de petits cas, qu'il vaut mieux vérifier vite, à chaque commit, par le développeur qui a construit la jointure.
Utilisez un test de bout en bout quand la question porte sur le résultat de l'utilisateur.
- Un client peut-il se connecter, trouver un produit, payer et voir la confirmation avec le bon numéro de commande ?
- Le rapport que l'équipe financière exporte chaque lundi s'ouvre-t-il toujours avec les bonnes colonnes ?
- Ce sont quelques parcours complets, vérifiés là où l'utilisateur les vérifierait, à chaque build.
Utilisez les deux là où l'argent, les données ou la connexion sont en jeu.
- La page de paiement ci-dessus a besoin de ses tests d'intégration, pour qu'un total faux soit attrapé à la jointure qui l'a produit, et de son test de bout en bout, pour qu'un total juste dessiné au mauvais endroit soit attrapé aussi.
- Aucun des deux n'aurait pu remplacer l'autre ce jour-là.
Les deux couches sont des tests de non-régression : on les exécute de nouveau après chaque changement pour prouver que rien de ce qui fonctionnait n'a cassé.Ce qu'est un test de non-régression explique quand exécuter chacune et pourquoi les suites sont abandonnées quand elles coûtent plus qu'elles n'attrapent.
De combien de tests de bout en bout avez-vous besoin ?
Moins que vous ne le pensez, et mieux choisis.Le sommet de la pyramide n'est pas l'endroit où lister chaque écran.C'est l'endroit des parcours qui feraient le plus mal s'ils cassaient, chacun suivi de son premier clic jusqu'au résultat que l'utilisateur est venu chercher, et chacun vérifiant ce résultat.
La plupart des applications sont couvertes par une courte liste.
- 1L'inscription et la connexion, y compris l'erreur quand le mot de passe est faux.
- 2La tâche principale pour laquelle l'application existe : passer une commande, réserver un créneau, créer un client, déposer une réclamation.
- 3Le paiement, jusqu'à la confirmation et son numéro de commande.
- 4La recherche ou la liste d'où un utilisateur part chaque jour.
- 5L'export ou le rapport sur lequel un client compte.
- 6Chaque parcours qui a cassé une fois et a atteint les utilisateurs.
Cinq à quinze parcours comme ceux-ci, exécutés à chaque build, attrapent l'essentiel de ce qu'une suite d'intégration laisse passer.Chacun se termine par une assertion sur ce que montre l'écran : le total, la confirmation, le fichier exporté.Un test qui clique à travers un parcours et ne vérifie rien ne prouve pas grand-chose.
Ce qu'il faut vérifier à chaque étape est un choix qui mérite d'être fait délibérément : une image de l'élément, ses mots, ou ce qui est apparu à l'écran.Choisir ce qu'un test vérifie vous guide pas à pas.
Automatiser la couche de bout en bout sans code
La couche de bout en bout est celle que la plupart des équipes laissent maigre, parce qu'elle a été la plus coûteuse à maintenir : les tests codés trouvent les éléments par des sélecteurs, et chaque refonte les casse.GUI Test Studio retire le code de cette couche.Il teste les applications web, les applications de bureau Windows, les téléphones Android et les jeux vidéo à travers leur écran, comme le fait un utilisateur.
Enregistrez-le, ou décrivez-le
Cliquez sur Enregistrer et suivez le parcours dans votre vraie application : ajoutez les articles, ouvrez la page de paiement, lisez le total.Les clics, la saisie et les assertions sur ce qui est apparu deviennent un test, sans code à écrire.Vous pouvez aussi décrire le parcours dans une consigne à votre assistant IA, et le test est créé pour vous.Votre premier test, pas à pas prend environ dix minutes.
Le test vérifie ce que montre l'écran, pas le code derrière.
- Une assertion visuelle compare l'image d'un élément, une assertion de texte lit ses mots, et une assertion sur ce qui est apparu attrape la boîte de dialogue ou le message que l'étape a ouvert.
- 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.
Exécutez-le à chaque build
gtr-cli exécute la suite de bout en bout sur une machine de build Windows et répond comme un pipeline l'attend : un parcours en échec fait échouer le build, un fichier JUnit remplit l'onglet des tests, et chaque image de ce qui a échoué est gardée à côté des résultats d'intégration.
gtr-cli run tests\journeys --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.
Le rapport de confiance dit ce qui a changé
Chaque exécution se termine par un rapport de confiance.Pour chaque assertion, il dit si l'élément a été trouvé et s'il a toujours l'apparence enregistrée, avec l'image attendue et l'image trouvée côte à côte et la différence entourée.Pour la page de paiement ci-dessus, il montre la ligne Total vide et 48.90 une ligne plus haut : exactement ce qu'un testeur aurait écrit dans le rapport d'anomalie.
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, tandis qu'un mot changé, un badge manquant ou un nombre sur la mauvaise ligne fait échouer l'assertion.
- Quand une image diffère, l'analyse intelligente par IA peut jeter un second regard et dire ce qui a changé en mots simples, dans le cloud avec votre propre clé ou sur votre propre ordinateur avec un modèle d'IA local, l'un des nôtres ou le vôtre.
Une modification est poussée
Le modèle de la page de paiement est remanié
Le build s'exécute
Tests d'intégration, puis gtr-cli
Rapport de confiance
Le total est sur la mauvaise ligne
Corrigé avant la fusion
L'utilisateur ne l'a jamais vu
Points clés
- 1Les tests d'intégration vérifient la jointure entre les parties ; un test de bout en bout vérifie ce qui est dessiné pour l'utilisateur.
- 2Le même bug peut être vert et rouge à la fois : l'API renvoie le bon total, l'écran l'affiche dans le mauvais champ.
- 3La forme de la pyramide tient au coût, pas à l'importance : beaucoup de tests rapides en bas, quelques parcours complets au sommet, chacun attrapant ce que les autres ne peuvent pas.
- 4Utilisez les deux là où l'argent, les données ou la connexion sont en jeu, et choisissez la couche selon qui écrirait le rapport d'anomalie : un utilisateur ou un développeur.
- 5Cinq à quinze parcours, chacun vérifiant son résultat, couvrent l'essentiel de ce que la suite d'intégration laisse passer, et ils peuvent être enregistrés sans code.
Questions
Quelle est la différence entre les tests de bout en bout et les tests d'intégration ?
Les tests d'intégration vérifient que deux parties ou plus d'une application fonctionnent ensemble à leur jointure, généralement par le code ou par une API.Les tests de bout en bout vérifient toute l'application à travers son écran, comme un utilisateur la parcourt.Un test d'intégration peut réussir alors que l'écran montre la mauvaise chose.
Les tests de bout en bout sont-ils la même chose que les tests système ?
Ils se recoupent, et beaucoup d'équipes emploient les deux mots pour la même chose.Les tests système vérifient l'application complète et assemblée par rapport à ses exigences.Les tests de bout en bout suivent le parcours d'un utilisateur du premier clic jusqu'au résultat, à travers chaque partie que le parcours touche, autres systèmes compris.
Les tests d'intégration peuvent-ils remplacer les tests de bout en bout ?
Non.Les tests d'intégration prouvent que les parties sont d'accord entre elles, pas qu'un utilisateur obtient le bon résultat à l'écran.Un total peut être calculé juste par chaque service et être quand même dessiné dans le mauvais champ ou caché derrière une bannière, et seul un test qui regarde l'écran le voit.
Que faut-il écrire en premier, les tests d'intégration ou les tests de bout en bout ?
Les développeurs écrivent les tests d'intégration à mesure qu'ils construisent chaque jointure, donc ceux-là viennent généralement en premier.Les premiers tests de bout en bout reviennent aux parcours qui feraient le plus mal s'ils cassaient, comme la connexion et le paiement, et ils peuvent être enregistrés dès que ces parcours fonctionnent.
Combien de tests de bout en bout un projet doit-il avoir ?
Moins que vous ne le pensez, et mieux choisis.Cinq à quinze parcours couvrent ce que la plupart des applications ne peuvent pas se permettre de casser : l'inscription, la connexion, la tâche principale, le paiement, l'export sur lequel les clients comptent.Chacun suit un parcours jusqu'au résultat que l'utilisateur est venu chercher, et vérifie ce résultat.
Pourquoi les tests de bout en bout sont-ils plus lents que les tests d'intégration ?
Un test de bout en bout lance la vraie application, pilote ses écrans et attend que chacun réponde, si bien qu'un parcours prend de quelques secondes à quelques minutes là où un test d'intégration prend quelques millisecondes.C'est pourquoi les tests de bout en bout couvrent quelques parcours importants, et les tests d'intégration beaucoup de cas.
Qu'est-ce que la pyramide des tests ?
La pyramide des tests est une façon de dimensionner une suite de tests : beaucoup de tests unitaires rapides à la base, moins de tests d'intégration au milieu, et un petit nombre de tests de bout en bout au sommet.Chaque couche attrape ce que les couches inférieures ne peuvent pas, et la couche du sommet est la seule qui voit ce que voit l'utilisateur.
Qui écrit les tests de bout en bout ?
Quiconque sait ce que l'utilisateur attend le peut, quand l'outil ne demande pas de code.Avec GUI Test Studio, un testeur ou un product owner enregistre un parcours en utilisant l'application, ou le décrit dans une consigne, et le test s'exécute à chaque build avec gtr-cli.
TeamCity, Jenkins, GitHub, GitLab et Azure DevOps 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.