Exécutez vos tests de bout en bout à chaque build : un exemple TeamCity qui fonctionne avec n'importe quel outil CI/CD
L'automatisation des tests de bout en bout dans votre pipeline : ajoutez vos tests GUI Test Studio à un build TeamCity en une étape avec gtr-cli, et lisez chaque test, les échecs, la vidéo et les images dans TeamCity.La même commande exécute vos tests d'interface, fonctionnels et de régression dans Jenkins, GitHub Actions, GitLab, Azure DevOps ou n'importe quel script.
7 min de lecturePar l'équipe de GUI Test Studio
Pourquoi exécuter des tests de bout en bout à chaque build
Un test de bout en bout pilote votre application comme un utilisateur : il l'ouvre, clique et tape tout au long d'un parcours complet, puis vérifie ce que l'écran affiche à la fin.C'est le test qui attrape ce que les tests unitaires ne peuvent pas voir : un bouton cassé, un formulaire qui ne s'envoie plus, une page qui a perdu son contenu.
Un test de bout en bout qui ne s'exécute que lorsque quelqu'un pense à le lancer attrape ces problèmes tard.Exécutez-le à chaque changement, et une régression est attrapée quelques minutes après avoir été poussée, tant que le changement est encore frais dans l'esprit du développeur.
GUI Test Studio est livré avec un exécuteur en ligne de commande fait pour cela : gtr-cli.Il s'installe avec les applications.Il exécute les tests de bout en bout que vous avez enregistrés et modifiés, sans ouvrir de fenêtre, et répond comme un pipeline l'attend : un code de sortie, un fichier JUnit, un journal que votre outil de CI comprend.
Un développeur pousse son code
N'importe quelle branche
TeamCity lance un build
Une seule étape de build
gtr-cli exécute les tests
Sur l'écran de la machine de build, ou en mode headless
Vous lisez le résultat
Tests, journal, vidéo et images
Ce qu'il vous faut
| Quoi | Pourquoi | Où l'obtenir |
|---|---|---|
| Un test créé avec GUI Test Studio | Le test de bout en bout que le pipeline exécute, gardé dans votre dépôt comme n'importe quel fichier | Votre premier test, pas à pas |
| Une machine de build Windows avec GUI Test Studio installé | gtr-cli est fourni avec le programme d'installation et rejoue le test sur cette machine | Installer et configurer |
| TeamCity (ou un autre outil de CI) | Lance un build à chaque changement et affiche ses résultats | TeamCity de JetBrains |
Étape 1 : préparer la machine de build
Un test de bout en bout rejoue des clics et de la saisie sur un vrai écran : l'agent de build a donc besoin d'un bureau pour travailler.
- 1
Installer GUI Test Studio et se connecter une fois
Le programme d'installation ajoute gtr-cli au PATH.Connectez-vous une fois aux applications sur cette machine, avec le compte sous lequel l'agent s'exécute.
- 2
Exécuter l'agent dans une session Windows ouverte
Démarrez l'agent TeamCity depuis une session utilisateur ouverte, pas comme service Windows : un service n'a pas d'écran sur lequel rejouer un test.Gardez la taille d'écran et la mise à l'échelle de l'enregistrement.Voir Préparer la machine de build.
- 3
Ou exécuter les tests web en mode headless
Un test d'application web peut s'exécuter sans aucune fenêtre de navigateur, avec
--headless on.Il n'a alors besoin d'aucun écran libre, et plusieurs navigateurs et appareils s'exécutent côte à côte.
Étape 2 : construire la commande
Vous n'avez pas à apprendre les options.Dans l'une ou l'autre application, ouvrez la fenêtre Ligne de commande & CI/CD, cochez ce que vous voulez, et copiez la commande, ou l'extrait prêt à l'emploi pour votre outil de CI avec vos vrais chemins.
Voici la commande qu'exécute notre pipeline d'exemple :
gtr-cli run tests\Checkout\Checkout.GTS --branch all --countdown 0 --format teamcity ^
--junit ci-out\junit.xml --json ci-out\result.json ^
--artifacts ci-out\artifacts --bug-report pdf| Option | Ce qu'elle fait |
|---|---|
| --branch all | Exécute le test sur chaque navigateur et appareil pour lequel il a été créé |
| --countdown 0 | Démarre aussitôt : personne n'est devant la machine de build pour lâcher la souris |
| --format teamcity | Écrit chaque test et chaque échec dans le langage de journal propre à TeamCity |
| --junit / --json | Écrit les résultats dans des fichiers que tout outil peut lire |
| --artifacts | Conserve la vidéo de l'exécution, son rapport, et les images de chaque échec |
| --bug-report pdf | Écrit un rapport d'anomalie rempli pour chaque test échoué |
Chaque option est expliquée dans Exécuter des tests dans votre pipeline et par gtr-cli help sur tout ordinateur où GUI Test Studio est installé.
Étape 3 : ajouter l'étape de build dans TeamCity
Créez une configuration de build pour votre dépôt, ajoutez une étape de build et donnez-lui la commande.Une étape PowerShell ou Command Line convient l'une comme l'autre.Dans notre exemple, l'étape exécute un petit script du dépôt qui démarre la boutique, puis appelle gtr-cli.
Ajoutez un déclencheur VCS pour que chaque push sur chaque branche lance un build.C'est toute la configuration : TeamCity n'a besoin d'aucun plugin, car gtr-cli parle son langage de journal.
Étape 4 : lire les résultats dans TeamCity
Poussez un changement et observez.Chaque navigateur et appareil est un test à part entière, vous voyez donc d'un coup d'œil où cela a échoué.
Le journal de build
gtr-cli écrit une ligne par étape et dit clairement ce qui a échoué : quelle assertion, sur quel navigateur et quel appareil, et pourquoi.
Le build échoué
La vue d'ensemble du build nomme les tests échoués et leur raison, sans ouvrir le journal.
Les tests
L'onglet Tests liste chaque test du build.Comme chaque résultat est rapporté comme un test, TeamCity conserve aussi son historique, sa durée et la fréquence de ses échecs.
Les preuves
Les artefacts contiennent tout ce que l'exécution a vu : un dossier par navigateur et appareil avec la vidéo de l'exécution, son rapport et son rapport d'anomalie, et pour chaque échec les images attendue et obtenue, avec ce qui a changé entouré en rouge.Ouvrez la même exécution dans GUI Test Runner-Recorder pour le rapport de confiance complet.
Chaque navigateur et appareil dans un seul build
Un test web peut être créé une fois et exécuté sur plusieurs navigateurs et appareils : Chrome, Edge et Firefox, ordinateurs de bureau, téléphones et tablettes.Dans le pipeline, --branch all les exécute tous dans un seul build, et ceux sans fenêtre s'exécutent côte à côte.Lisez Chaque navigateur et chaque appareil à partir d'un seul enregistrement.
Vous n'utilisez pas TeamCity ?La même commande partout
gtr-cli n'est lié à aucun outil.C'est un programme qui exécute des tests et renvoie un code de sortie : tout ce qui peut lancer une commande peut lancer vos tests de bout en bout, un serveur de CI, une tâche planifiée, un script de release.Tests fonctionnels, tests de régression, smoke tests, tests d'acceptation : quel que soit le nom que vous donnez aux tests qui pilotent votre application par son interface, ils s'exécutent de la même façon.
| Votre outil | Ce qu'il faut ajouter à la commande |
|---|---|
| TeamCity | --format teamcity |
| Azure DevOps | --format azure |
| GitHub Actions | --format github |
| Jenkins, GitLab, Bamboo et les autres | --junit results\junit.xml, lu par le rapport de tests de l'outil |
| Un script à vous | Rien : lisez le code de sortie, ou le fichier --json |
- name: End-to-end tests
run: gtr-cli run tests --countdown 0 --format github --junit results\junit.xml --artifacts results\artifacts| Code de sortie | Signifie |
|---|---|
| 0 | Tous les tests ont réussi |
| 1 | Un test a échoué |
| 2 | La commande elle-même était incorrecte |
| 3 | Un test n'a pas pu s'exécuter, par exemple à cause d'un fichier manquant |
| 4 | L'exécution a été arrêtée |
Où aller ensuite
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.