Comment utiliser Checksum pour les tests de bout en bout continus dans CI/CD

By Paulo Gardini Miguel on Aug 19, 2026

Ce guide s’adresse aux responsables de l’ingénierie et de l’assurance qualité qui souhaitent disposer de tests de bout en bout capables de se générer, de s’exécuter et de se réparer automatiquement au sein de leur pipeline CI/CD existant. Vous découvrirez comment configurer Checksum, l’intégrer à GitHub Actions ou GitLab CI et maintenir la suite de tests au vert à mesure que votre application évolue.

TABLE OF CONTENTS Comment Checksum prend en charge les tests de bout en bout continus Prérequis pour les tests de bout en bout continus dans Checksum Comment effectuer des tests de bout en bout continus dans Checksum À quoi ressemblent des tests de bout en bout continus réussis Erreurs courantes et conseils d’experts pour les tests de bout en bout continus Conclusion

PERSPECTIVES DES PARTENAIRES

Ceci est un contenu sponsorisé de la part de Checksum. Découvrez ici notre approche éditoriale transparente.

Les tests de bout en bout (E2E) exécutés dans CI/CD ne fonctionnent que si votre suite de tests peut évoluer avec votre application. À mesure que votre produit change, créer manuellement de nouveaux tests et corriger ceux qui sont défaillants peut rapidement devenir le goulot d'étranglement qui ralentit chaque mise en production.

Checksum est conçu pour automatiser une grande partie de ce processus.

Ce guide vous montre comment connecter Checksum à votre environnement et à votre référentiel, générer et exécuter des tests Playwright dans votre pipeline CI/CD, et activer la maintenance autonome à mesure que votre application évolue.

Comment Checksum prend en charge les tests E2E continus

Checksum prend en charge les tests E2E continus grâce à un flux de travail continu :

Configurer : connecte votre référentiel et votre environnement de test.
Détecter : analyse votre application et identifie les parcours utilisateur les plus importants à tester.
Générer : crée des tests Playwright prêts pour la production et les fournit sous forme de demandes d'extraction dans votre référentiel.
Exécuter : exécute ces tests localement ou dans votre pipeline CI/CD, tandis que la récupération automatique tente de résoudre les échecs temporaires pendant l'exécution.
Réparer : met à jour les tests Playwright défaillants lorsque votre application change et ouvre une demande d'extraction contenant la correction proposée.
Surveiller : suit l'état de santé des tests et alerte votre équipe lorsque des problèmes nécessitent une intervention.

Comme chaque test est du code Playwright standard, vous en conservez la pleine propriété et pouvez exécuter la suite avec ou sans Checksum.

Prérequis pour les tests E2E continus dans Checksum

Avant de configurer Checksum pour les tests E2E continus, assurez-vous que les éléments suivants sont prêts.

Un environnement de préproduction ou similaire à la production

Checksum effectue des tests sur une application en ligne ; vous aurez donc besoin d'un environnement de préproduction ou similaire à la production, accessible via une URL d'environnement. Si votre application nécessite une authentification, configurez une URL de connexion et fournissez les identifiants d'un utilisateur de test que Checksum pourra utiliser pour se connecter et analyser les parcours utilisateur de votre application.

Un référentiel connecté et un pipeline CI

Connectez votre référentiel GitHub ou GitLab afin que Checksum puisse analyser votre base de code et créer des demandes d'extraction contenant des tests Playwright générés ou mis à jour. Si vos tests se trouvent dans un référentiel distinct, connecter à la fois le référentiel source et le référentiel de tests améliore la précision de la détection des parcours.

Vous aurez également besoin d'une plateforme CI pour exécuter vos tests. Checksum prend en charge nativement GitHub Actions et GitLab CI/CD, tandis que les autres plateformes CI peuvent être intégrées via l'interface en ligne de commande Checksum ou l'API publique.

Un projet Checksum et une clé API

Créez un projet Checksum dans l'application web et générez une clé API de projet depuis les paramètres du projet. La clé API authentifie l'interface en ligne de commande Checksum et permet à votre pipeline CI de télécharger les variables d'environnement nécessaires à l'exécution de vos tests.

Si vous souhaitez consulter une présentation plus détaillée du processus de configuration initial, vous pouvez également consulter la page de démarrage de Checksum

Comment effectuer des tests E2E continus dans Checksum

Les étapes ci-dessous supposent que vous avez créé un projet Checksum et que vous disposez de votre clé API.

Étape 1. Connecter votre environnement et votre référentiel

Dans l'assistant de configuration de l'application web, définissez votre URL d'environnement (par exemple https://staging.myapp.com) et votre URL de connexion, puis ajoutez les identifiants de l'utilisateur de test avec lesquels Checksum s'authentifiera.

Installez ensuite l'application Git pour GitHub ou GitLab afin que Checksum puisse lire votre code et ouvrir des demandes d'extraction. Si vos tests doivent se trouver à côté de votre code source, connectez le même référentiel pour les deux.

Étape 2. Initialiser votre référentiel de tests

Créez (ou désignez) un dépôt pour vos tests et initialisez-le avec la CLI :

mkdir my-checksum-tests && cd my-checksum-tests
npm init -y
npm install @checksum-ai/runtime playwright
npx checksumai init

Cela génère un dossier checksum/ contenant la configuration, une configuration Playwright et un exemple de test. Vérifiez la configuration avant d'aller plus loin :

npm install
npx playwright install --with-deps
npx checksumai dotenv --download --api-key=<YOUR_API_KEY>
npx checksumai test -g "example"

L'exemple de test confirme que la connexion fonctionne dans votre environnement. Un résultat positif signifie que vous êtes prêt à détecter de vrais parcours.

Étape 3. Laissez l'Agent détecter les parcours utilisateur critiques

Déclenchez une session de détection et laissez l'agent E2E analyser votre application afin d'identifier les parcours utilisateur importants. Une fois la détection terminée, examinez les parcours proposés et donnez la priorité à ceux qui sont les plus pertinents pour votre version avant de générer les tests.

Étape 4. Générez des tests Playwright prêts pour la production

Générez des tests Playwright pour les parcours que vous avez sélectionnés.

L'agent planifie, implémente, examine et vérifie chaque test avant d'ouvrir une demande de fusion contenant un fichier de scénario lisible par un humain et le test Playwright.

Examinez la demande de fusion comme n'importe quelle autre modification de code, puis fusionnez les tests que vous êtes prêt à ajouter à votre suite.

Étape 5. Intégrez les tests à votre pipeline CI/CD

Pour GitHub Actions, stockez votre clé API et les valeurs d'environnement en tant que secrets du dépôt, puis ajoutez un workflow qui installe Playwright, télécharge le fichier d'environnement Checksum et exécute la suite :

name: Exécuter les tests Checksum
on:
workflow_dispatch:        # déclenchement manuel pour démarrer
# schedule:
#   - cron: '0 0 * * *'   # chaque nuit, une fois vérifié
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Installer les dépendances npm
run: npm install
- name: Installer Playwright avec ses dépendances
run: npx playwright install --with-deps
- name: Télécharger le fichier .env depuis Checksum
run: npx checksumai dotenv --download --api-key="${{ secrets.CHECKSUM_API_KEY }}"
- name: Exécuter les tests Checksum
run: npx checksumai test
env:
CHECKSUM_API_KEY: ${{ secrets.CHECKSUM_API_KEY }}
USERNAME: ${{ secrets.USERNAME }}
PASSWORD: ${{ secrets.PASSWORD }}
LOGIN_URL: ${{ secrets.LOGIN_URL }}
BASE_URL: ${{ secrets.BASE_URL }}
CI: true

GitLab CI/CD suit la même structure dans .gitlab-ci.yml . Commencez par un déclenchement manuel ( workflow_dispatch / when: manual ) pour confirmer que l'exécution fonctionne correctement, puis passez à une planification pour les contrôles d'intégrité nocturnes ou à un déclenchement lors d'une fusion afin d'effectuer une vérification après les déploiements.

Étape 6. Ajoutez des exécutions pour chaque demande de fusion et activez la correction autonome

Si vous souhaitez que Checksum exécute les tests pour chaque demande de fusion, utilisez l'action GitHub officielle au lieu d'exécuter la CLI sur votre propre exécuteur. Cette solution est utile pour valider les modifications introduites dans chaque demande de fusion.

name: Tests Checksum
on: pull_request
permissions:
contents: read
pull-requests: read
jobs:
checksum:
runs-on: ubuntu-latest
steps:
- uses: checksum-ai/test-run-action@v1
with:
api-key: ${{ secrets.CHECKSUM_API_KEY }}
grep: 'checkout'
auto-heal: true

L'option grep filtre les tests exécutés par nom, tandis que auto-heal: true active la correction automatique lorsqu'un test échoue.

Par défaut, le workflow se termine une fois l'exécution acceptée et publie les résultats sous forme de commentaire sur la demande de fusion. Si vous souhaitez que le workflow attende le résultat final et réussisse ou échoue en conséquence, définissez wait: true.

Lorsque l’auto-réparation est activée, Checksum tente une récupération en temps réel pendant l’exécution du test. Si le test échoue toujours, il met à jour le test Playwright, ouvre une demande de fusion avec la correction proposée et publie l’avancement sous forme de commentaire sur la demande de fusion d’origine.

Votre équipe peut ensuite examiner et fusionner les modifications comme toute autre contribution de code.

À quoi ressemble une réussite des tests E2E continus

Une fois Checksum intégré à votre pipeline CI/CD, vous devriez observer les éléments suivants :

Votre suite de tests E2E s’exécute automatiquement en fonction du déclencheur que vous avez configuré, notamment les demandes de fusion, les exécutions planifiées et les déploiements.
Les nouveaux parcours utilisateur sont détectés et convertis en tests Playwright sans avoir à rédiger manuellement chaque test.
Les échecs de test causés par des modifications de l’application sont résolus grâce à la récupération automatique ou à l’auto-réparation avant de nécessiter des mises à jour manuelles.
Votre équipe consacre moins de temps à la maintenance des tests Playwright et davantage à l’examen des modifications de test pertinentes fournies par le biais de demandes de fusion.

Pour mesurer l’état de santé de votre implémentation, surveillez votre taux de réussite des tests, le pourcentage de tests réparés automatiquement, le délai moyen de résolution des échecs de test et le taux de faux positifs.

Ces indicateurs vous aident à comprendre avec quelle fiabilité votre suite E2E s’exécute à mesure que votre application évolue. Pour comparer vos résultats aux références de production, le rapport de référence QA de Checksum fournit des données pour ces indicateurs basées sur plus d’un million d’exécutions réelles en production.

Erreurs courantes dans les tests E2E continus et conseils de professionnels

Même avec une configuration adaptée, quelques erreurs courantes peuvent affecter la qualité, l’exécution et la maintenance des tests. Voici les points à surveiller et les moyens de les éviter.

Exécuter des tests sur un environnement instable

Si les résultats de vos tests sont incohérents ou si les tests échouent avant le début d’une exécution significative, votre environnement de test n’est peut-être pas prêt. Assurez-vous que votre environnement de préproduction ou similaire à la production est stable, que les identifiants de votre utilisateur de test fonctionnent correctement et que le test d’exemple réussit avant de générer une couverture supplémentaire.

Générer trop de parcours utilisateur

Checksum peut identifier davantage de parcours utilisateur que nécessaire au départ. Générer des tests pour chaque candidat augmente le temps d’exécution et l’effort d’examen. Commencez par les flux de travail les plus critiques pour vos mises en production, puis élargissez progressivement la couverture.

Fusionner des tests générés sans les examiner

Les tests générés et réparés sont fournis sous forme de demandes de fusion afin que votre équipe puisse valider chaque modification avant son intégration à la suite de tests. Examinez attentivement les nouveaux tests au début de l’adoption et renforcez progressivement votre confiance dans le processus de génération.

Automatiser votre pipeline trop tôt

Avant de planifier des exécutions ou de déclencher des tests pour chaque demande de fusion, vérifiez que votre pipeline est stable lors d’exécutions manuelles. Une fois que vous obtenez régulièrement des résultats fiables, vous pouvez automatiser le flux de travail avec davantage de confiance.

Bloquer chaque demande de fusion

Activer wait: true oblige le flux de travail à attendre la fin de l’exécution du test avant de s’achever. Utilisez cette option uniquement pour les flux de travail qui doivent bloquer une fusion. Pour tout le reste, le commentaire par défaut sur la demande de fusion fournit un retour sans monopoliser les exécuteurs CI.

Conclusion

Vous avez maintenant vu comment Checksum s’intègre à un flux de travail de tests E2E continus, de la connexion de votre environnement et de votre dépôt à la génération de tests Playwright, à leur intégration dans votre pipeline CI/CD et à l’activation de la maintenance autonome.

À mesure que votre application évolue, Checksum contribue à maintenir la fiabilité de votre suite de tests E2E sans ajouter le même niveau de maintenance manuelle.

Si vous souhaitez approfondir votre découverte de la plateforme, vous pouvez consulter notre analyse approfondie de Checksum pour en savoir plus sur ses fonctionnalités, ou voir comment Checksum fonctionne avec votre propre application en prenant directement contact avec leur équipe.

Questions fréquemment posées

Oui. Checksum génère des tests Playwright standard qui sont enregistrés dans votre dépôt, afin que vous puissiez les lire, les modifier et les exécuter avec ou sans Checksum.

Checksum tente d’abord une récupération automatique pendant l’exécution du test. Si le problème ne peut pas être résolu, la correction automatique met à jour le test Playwright et ouvre une demande de tirage pour que votre équipe l’examine.

Les deux options sont prises en charge. Vous pouvez exécuter l’interface de ligne de commande sur votre propre exécuteur CI ou utiliser l’action GitHub pour permettre à Checksum d’exécuter la série de tests.

Un service de test géré s’appuie sur des personnes pour créer et maintenir vos tests. Checksum automatise une grande partie de ce travail en générant et en maintenant directement les tests Playwright dans votre propre pipeline CI/CD.

Oui. Checksum fonctionne avec vos tests Playwright existants, comble les lacunes de couverture et génère de nouveaux tests au fur et à mesure que votre application évolue.