Acquérez une compréhension de base des concepts fondamentaux de Thunders afin de pouvoir configurer votre organisation et naviguer efficacement.
Concepts de base
Organisation
Une organisation Thunders est le conteneur de niveau supérieur qui regroupe toutes vos activités sur la plateforme. Lorsque vous vous inscrivez, vous créez une organisation ou rejoignez une organisation existante.
Depuis les paramètres de l'organisation, vous pouvez gérer les projets de test, les membres et leurs rôles, configurer des jetons API pour les intégrations CI/CD et contrôler la facturation.
Projet de test
Un projet de test regroupe les artefacts de test associés : plans de test, cas de test, groupes de test, environnements, variables et applications.
Chaque projet peut être connecté à des sources externes (Jira, Notion, Confluence, Linear, Xray) via des connecteurs. Thunders AI peut extraire le contexte de ces sources lors de la création de tests et y signaler les bogues.
En savoir plus : Ajouter / Modifier / Supprimer un projet de test
Applications
Une application représente une application distincte au sein d'un projet de test. Chaque application correspond à l'une des applications qui composent votre produit testé, comme une interface client, un tableau de bord d'administration ou une API backend.
Thunders prend en charge quatre types d'applications :
Application Web : application basée sur un navigateur et testée via l'automatisation de l'interface utilisateur
API : service REST testé via des appels API
Application mobile : application iOS ou Android testée sur des appareils réels
Application de bureau : application de bureau testée via la virtualisation
Un projet peut contenir plusieurs applications. Cela vous permet d'écrire des cas de test couvrant différentes applications au sein d'un même workflow (par exemple, modifier un paramètre dans le panneau d'administration, puis le vérifier sur le portail client).
Lorsque vous créez un projet, vous configurez votre première application en choisissant son type. Vous pouvez ajouter d'autres applications ultérieurement depuis la vue Applications. Chaque application dispose de sa propre URL par environnement ; Thunders sait ainsi quelle URL cibler lors de l'exécution de tests sur une application spécifique dans un environnement donné.
En savoir plus : Ajouter / Modifier / Supprimer un projet de test
Environnements
Un environnement représente un contexte de déploiement dans lequel les tests s'exécutent, tel que le développement, la préproduction ou la production. Chaque environnement dispose de sa propre URL par application, de ses propres variables et de ses propres identifiants. Cela vous permet d'exécuter les mêmes cas de test dans des conditions différentes sans les modifier.
Caractéristiques principales :
Mappage d'URL par application : chaque application du projet dispose de sa propre URL par environnement (par exemple, le front-end pointe vers
https://staging.example.comen préproduction et vershttps://example.comen production)Variables d'environnement : paires clé-valeur disponibles pendant l'exécution des tests, référencées à l'aide de la syntaxe
[VARIABLE_NAME]Identifiants : valeurs sensibles stockées en toute sécurité et référencées de la même manière que les variables
Hiérarchie de remplacement : les variables au niveau de l'environnement remplacent celles au niveau du projet lorsqu'elles partagent la même clé
En savoir plus : Ajouter / Modifier / Supprimer un environnement
Variables
Les variables vous permettent de paramétrer des cas de test afin qu'ils puissent être réutilisés dans différents environnements sans avoir à coder en dur les valeurs. Faites référence à n'importe quelle variable dans vos étapes de test à l'aide de la syntaxe [VARIABLE_NAME]. Thunders la remplace par la valeur réelle au moment de l'exécution.
Thunders prend en charge trois types de variables :
Statiques : définies dans les paramètres de votre environnement ou de votre projet et résolues avant l'exécution (par exemple
[BASE_URL],[EMAIL])Générées : créées dynamiquement pendant l'exécution avec des valeurs aléatoires ou selon un modèle (par exemple
[RANDOM_EMAIL],[OTP])Extraites : capturées à partir des réponses de l'application pendant l'exécution pour être utilisées dans les étapes suivantes (par exemple
[ORDER_ID],[TOKEN])
Les noms de variables doivent uniquement comporter des lettres majuscules, des chiffres et des traits de soulignement. Longueur maximale : 32 caractères, sans espaces ni caractères spéciaux.
Lors de la rédaction d'étapes de test, vous pouvez taper / ou [ pour activer la saisie semi-automatique et insérer rapidement une référence de variable.
Les variables peuvent être définies à deux niveaux :
Au niveau du projet : disponibles dans tous les environnements du projet
Au niveau de l'environnement : limitées à un seul environnement, elles remplacent les variables de niveau projet portant la même clé
En savoir plus : Variables
Profils authentifiés
Un Profil authentifié est une session de navigateur enregistrée une fois, qu'un cas de test rejoue pour que l'exécution démarre déjà connectée. Il contient les cookies et le stockage que votre application écrit après une connexion réussie, jamais un mot de passe, et il est conservé chiffré.
Les Profils remplacent les étapes de connexion en tête de chaque cas de test, qui sont la partie la plus répétée et la plus fragile de la plupart des suites. Un cas de test en injecte un par son nom avec une seule étape, et un Profil peut aussi être capturé par un cas de test pendant son exécution.
En savoir plus : Comment faire démarrer mes tests déjà connectés ? et Comment utiliser une connexion enregistrée dans un cas de test ?
Création de tests
Thunders AI
Thunders AI est l'assistant IA intégré à chaque projet. Il peut générer des plans de test à partir d'un fichier d'exigences ou d'une user story, rédiger les étapes d'un cas de test à partir d'une description en langage naturel, et parcourir votre application pour proposer des flux de test.
Thunders AI utilise les connecteurs et les sources de connaissances du projet pour s'ancrer dans le contexte, de sorte que les tests qu'il génère s'appuient sur vos exigences et votre documentation réelles. Vous pouvez également lui poser des questions sur vos tests existants, par exemple pour savoir combien de cas de test vous avez ou si un enchaînement spécifique est déjà couvert.
Plans de test
Un plan de test est un document structuré qui définit ce qui doit être testé pour une fonctionnalité, un module ou une user story. Plutôt que de rédiger manuellement des scénarios de test, vous pouvez importer un fichier d'exigences ou coller une user story et laisser Thunders AI générer les scénarios de test à votre place.
Chaque plan de test est organisé en sections et en scénarios. Les sections regroupent des scénarios connexes, et chaque scénario décrit un flux spécifique à valider. À partir de n'importe quel scénario, vous pouvez créer directement des cas de test, en maintenant le lien entre les exigences et les tests tout au long du cycle de vie.
En savoir plus : Générer des plans de test à partir de variables existantes
Cas de test
Un cas de test est une séquence d'étapes permettant de vérifier une fonctionnalité spécifique. Les cas de test appartiennent à un projet et peuvent faire référence à des variables, ainsi qu'à des applications et des environnements spécifiques.
Thunders prend en charge plusieurs types d'étapes :
Étape IA : instruction en langage naturel que Thunders interprète et exécute sur votre application
Étape Web : action déterministe du navigateur (clic, saisie, navigation) définie explicitement plutôt qu'interprétée par l'IA
Étape mobile : action déterministe pour le test d'applications mobiles sur des appareils réels
Appel d'API : requête REST directe avec méthode, en-têtes, corps et assertions configurables sur la réponse
Étape de comparaison visuelle : comparaison au pixel près par rapport à une capture d'écran de référence pour détecter les régressions visuelles
Étape de comparaison de fichiers : comparaison au niveau des fichiers pour vérifier les fichiers téléchargés ou générés
Étape conditionnelle (If) : logique if/else permettant de ramifier le flux de test en fonction des conditions d'exécution
Cas de test existant : réutilisation d'un autre cas de test en tant qu'étape au sein du cas de test actuel, de sorte que ses étapes s'exécutent en ligne dans le cadre du flux
Les cas de test prennent également en charge une phase principale et une phase de nettoyage, de sorte que les étapes de nettoyage s'exécutent toujours, même en cas d'échec du flux principal.
En savoir plus : Ajouter / Modifier / Supprimer un cas de test et Exécuter un cas de test
Gestion des tests
Groupes de test
Un groupe de test est un regroupement de cas de test destinés à tester une fonctionnalité, un composant ou un workflow spécifique. Un même cas de test peut appartenir à plusieurs groupes de test, ce qui vous permet d'organiser les mêmes tests de différentes manières sans les dupliquer.
Chaque groupe de test dispose de son propre espace de travail dédié où vous pouvez consulter le taux de réussite, afficher l'historique des exécutions au niveau du groupe et gérer tous les cas de test inclus en un seul endroit. Vous pouvez rechercher, filtrer, ajouter ou supprimer des tests depuis cette même page, et exécuter le groupe complet sans avoir à passer d'un écran à l'autre.
En savoir plus : Groupes de tests
Plannings
Un Planning est une règle récurrente attachée à un groupe de test qui l'exécute automatiquement, sans que personne ait à ouvrir le projet et à lancer l'exécution. Vous choisissez une fréquence, de Chaque heure à Mensuel, ainsi que l'Environnement et les paramètres que chaque exécution doit utiliser.
Un Planning pointe vers le groupe de test plutôt que vers une liste figée : chaque exécution couvre donc ce que le groupe contient au moment où elle se déclenche. Un même groupe de test peut porter plusieurs Plannings, chacun avec son propre Environnement et sa Persona, ce qui permet à une exécution des jours ouvrés sur Staging et à une exécution mensuelle sur Production de coexister.
En savoir plus : Comment planifier l'exécution automatique d'un groupe de test ?
Étiquettes
Les étiquettes sont des balises personnalisées que vous pouvez appliquer aux cas de test pour les classer par catégorie et les filtrer. Chaque étiquette possède un nom, une couleur et une description facultative. Vous pouvez créer des étiquettes à partir de l'onglet Étiquettes du projet, ou directement lors de la modification d'un cas de test.
Un cas de test peut comporter plusieurs étiquettes, et celles-ci peuvent faire l'objet de recherches et de filtrages à l'échelle du projet. Les étiquettes peuvent être archivées lorsqu'elles ne sont plus nécessaires, sans que cela n'affecte les cas de test auxquels elles ont été appliquées.
En savoir plus : Étiquettes personnalisées
Ressources de test
Les ressources de test sont des fichiers que vos cas de test utilisent comme entrées ou produisent comme sorties. Il peut s'agir, par exemple, d'images pour des comparaisons visuelles, de fichiers CSV pour des tests basés sur des données ou de documents pour des scénarios de téléversement de fichiers.
La bibliothèque de ressources de test vous offre une vue centralisée de tous les fichiers d'un projet. À partir de là, vous pouvez importer de nouvelles ressources, voir quels cas de test font référence à chaque fichier, télécharger des fichiers et modifier les métadonnées des ressources.
En savoir plus : Ressources de test
Exécution des tests
Exécutions de tests
Une exécution de test correspond à l'exécution effective d'un ou plusieurs cas de test dans un environnement spécifique. Elle enregistre les résultats (réussite/échec), la durée d'exécution, des captures d'écran et les journaux. Les exécutions de test vous offrent une vue claire de l'avancement des tests et vous aident à identifier les échecs.
En savoir plus : Consulter un rapport d'exécution de test
Personas
Les Personas sont configurées par projet de test. Quand vous exécutez un cas de test, vous choisissez la Persona qui l'exécute.
Thunders vous donne deux Personas. La Persona QA exécute vos tests fonctionnels. La Persona Accessibilité vérifie votre application par rapport à une norme d'accessibilité. Vous configurez les deux depuis la page Personas du projet de test.
En savoir plus : Rencontrez les Personas de test Thunders et Persona Accessibilité
Pools d'appareils
Un pool d'appareils est l'ensemble des téléphones et tablettes qu'une exécution mobile peut utiliser. Les cas de test mobiles s'exécutent sur un pool plutôt que sur un seul appareil, l'exécution démarre donc sur celui qui est libre.
Chaque projet de test dispose d'un pool par défaut, pour que les tests mobiles fonctionnent avant toute configuration. Vous créez votre propre pool quand vous voulez fixer des modèles précis, ou séparer Android d'iOS. Un pool contient une seule plateforme, et il peut réunir des appareils physiques, des émulateurs, ou les deux.
Les pools sont archivés plutôt que supprimés, pour que les cas de test qui les référencent continuent de fonctionner en basculant sur le pool par défaut.