Apprendre / Glossaire
Glossaire du test logiciel
Des définitions claires des termes que les ingénieurs QA et les SDET utilisent au quotidien, chacune avec un exemple et des liens vers les leçons, labs et questions d’entretien qui les abordent.
77 termes · Fondamentaux du test 26 · Conception des tests 5 · Automatisation de l’UI 18 · Test d’API 8 · CI/CD et DevOps 5 · Performance 5 · Sécurité 4 · L’IA dans le test 6
Fondamentaux du test
- Cas de test Test case Ensemble précis de préconditions, de données d'entrée, d'étapes et de résultats attendus qui vérifie un comportement du système et donne un verdict clair, réussi ou échoué.
- Couverture de code Code coverage Le pourcentage de code source (lignes, instructions, branches ou fonctions) exécuté pendant les tests. Il montre ce qui n’est pas testé, pas ce qui est bien testé.
- Critères d’acceptation Acceptance criteria Les conditions précises et testables qu’une user story ou une fonctionnalité doit remplir pour être acceptée comme terminée par le product owner.
- Doublure de test (test double) Test double Tout objet qui remplace une vraie dépendance dans un test, comme un dummy, un stub, un fake, un spy ou un mock, pour que le code testé s'exécute vite et de façon prévisible.
- Matrice de traçabilité des exigences Requirements traceability matrix Tableau qui relie chaque exigence aux cas de test qui la vérifient et à leurs résultats, pour rendre visibles les trous de couverture et l'impact des changements.
- Oracle de test Test oracle La source de vérité qu'un test utilise pour décider si un résultat est correct, comme une spécification, une version précédente, un modèle de référence ou une règle.
- Plan de test Test plan Document qui définit le périmètre, l'approche, les ressources, le planning, les environnements, les risques et les critères d'entrée et de sortie des tests d'une release.
- Priorité d’un bug Bug priority L’urgence avec laquelle un défaut doit être corrigé par rapport au reste du travail, selon les besoins métier ; elle est fixée par le product owner ou en triage.
- Pyramide des tests Test pyramid Modèle pour équilibrer une suite automatisée : beaucoup de tests unitaires rapides à la base, moins de tests d'intégration au milieu et peu de tests end-to-end au sommet.
- Recette utilisateur (UAT) User acceptance testing Phase de test finale où de vrais utilisateurs ou représentants métier confirment que le système répond à leurs besoins et peut être accepté pour la mise en production.
- Sanity test (test de cohérence) Sanity testing Vérification étroite et ciblée après une petite modification ou un correctif, pour confirmer que la zone concernée fonctionne comme prévu avant de poursuivre les tests.
- Scénario de test Test scenario Énoncé de haut niveau d'un objectif utilisateur ou d'une fonctionnalité à tester, comme « vérifier le paiement avec une carte enregistrée », décliné ensuite en cas de test.
- Sévérité d’un bug Bug severity L’impact d’un défaut sur le système ou ses utilisateurs, d’un plantage complet ou d’une perte de données jusqu’au simple problème cosmétique ; elle est fixée par la QA.
- Shift-left testing Déplacer les activités de test et de qualité plus tôt dans le cycle de livraison, pour prévenir les défauts ou les détecter quand ils coûtent le moins cher à corriger.
- Smoke test (test de fumée) Smoke testing Vérification rapide et superficielle des fonctions les plus critiques d'un nouveau build, pour décider s'il est assez stable pour mériter des tests plus poussés.
- Test basé sur les risques Risk-based testing Approche qui priorise l'effort de test selon le risque (probabilité de défaillance x impact) pour tester d'abord et plus en profondeur les zones les plus risquées.
- Test boîte blanche White-box testing Tests conçus à partir de la connaissance du code interne, comme ses branches, conditions et chemins, pour s'assurer que l'implémentation se comporte correctement.
- Test boîte noire Black-box testing Tester un système par ses entrées et ses sorties au regard des exigences, sans examiner ni utiliser le code ou la conception interne.
- Test d’intégration Integration test Un test qui vérifie que deux composants ou plus, comme un service et sa base de données ou deux API, fonctionnent correctement ensemble via leurs vraies interfaces.
- Test de mutation Mutation testing Technique qui injecte de petits bugs volontaires (mutants) dans le code puis relance les tests pour mesurer si la suite détecte réellement les défauts.
- Test de régression Regression testing Relancer les tests existants après une modification pour confirmer que ce qui fonctionnait fonctionne toujours et que le correctif ou la fonctionnalité n'a rien cassé.
- Test end-to-end (E2E) End-to-end test Un test qui pilote un parcours utilisateur complet à travers le système réel entièrement déployé, depuis l’UI ou l’API publique jusqu’à la base de données, et retour.
- Test exploratoire Exploratory testing Une approche où le testeur conçoit et exécute les tests en même temps, en s’appuyant sur ce que révèle chaque résultat pour décider quoi essayer ensuite.
- Test flaky (test instable) Flaky test Un test qui réussit puis échoue sur le même code sans aucun changement, généralement à cause du timing, d’un état partagé, de l’ordre des tests ou d’un environnement instable.
- Test unitaire Unit test Test automatisé qui vérifie un petit morceau de code, comme une fonction ou une classe, de façon isolée des bases de données, du réseau et des autres services.
- Vérification et validation Verification and validation La vérification demande « construisons-nous le produit correctement ? » selon la spécification ; la validation, « construisons-nous le bon produit ? » pour les vrais besoins.
Conception des tests
- Analyse des valeurs limites Boundary value analysis Une technique de conception de tests boîte noire qui choisit des entrées sur les bornes des plages valides et juste autour, là où se concentrent les erreurs de décalage d’un.
- Partitionnement en classes d’équivalence Equivalence partitioning Une technique de conception de tests qui divise les entrées en groupes que le système doit traiter de la même façon, puis teste une valeur représentative de chaque groupe.
- Test de transition d'états State transition testing Technique de conception de tests qui modélise un système en états et en événements qui le font passer de l'un à l'autre, puis teste les transitions valides et invalides.
- Test pairwise Pairwise testing Technique combinatoire qui sélectionne un petit jeu de cas de test où chaque paire de valeurs de paramètres apparaît ensemble au moins une fois.
- Test par table de décision Decision table testing Une technique de conception de tests qui liste les combinaisons de conditions et l’action que chacune doit déclencher, afin que chaque règle métier ait son test.
Automatisation de l’UI
- Attente explicite (explicit wait) Explicit wait Une attente qui interroge une condition précise, par exemple un élément devenu cliquable, jusqu’à un timeout. Dans Selenium, elle s’écrit avec WebDriverWait.
- Attente implicite (implicit wait) Implicit wait Un réglage global de Selenium qui fait que chaque appel à findElement continue de chercher l’élément pendant une durée donnée avant de lever NoSuchElementException.
- Auto-waiting (attente automatique) Auto-waiting Une fonctionnalité du framework qui attend qu’un élément soit prêt (visible, stable, activé) avant d’agir dessus, au lieu de s’appuyer sur des pauses fixes.
- BDD (Behavior-Driven Development) Behavior-Driven Development Une pratique collaborative où métier, développement et test s’accordent sur le comportement attendu à l’aide d’exemples concrets, souvent écrits en Gherkin et automatisés.
- Data-driven testing (tests pilotés par les données) Data-driven testing Exécuter la même logique de test sur de nombreux jeux d’entrées et de résultats attendus, stockés dans un tableau, un fichier ou une source de données.
- Fixture de test Test fixture La mise en place fixe dont un test a besoin avant de s'exécuter, comme une page de navigateur, un utilisateur préparé ou une base de données, plus le nettoyage qui suit.
- Gherkin La syntaxe en texte brut Given-When-Then utilisée pour écrire des scénarios BDD dans des fichiers .feature, que des outils comme Cucumber exécutent comme tests automatisés.
- Isolation des tests Test isolation Propriété selon laquelle chaque test prépare son propre état et peut réussir seul, dans n'importe quel ordre et en parallèle, sans dépendre des autres tests ni les affecter.
- Locator La requête qu'un test d'interface utilise pour trouver un élément de la page, comme un rôle et un nom, un test id, un sélecteur CSS ou une expression XPath.
- Navigateur headless Headless browser Un véritable moteur de navigateur qui tourne sans fenêtre visible, utilisé pour exécuter des tests d’UI sur des serveurs de CI et d’autres machines sans écran.
- Page Object Model (POM) Page Object Model Design pattern qui encapsule chaque page ou composant de l'interface dans une classe, pour que les tests appellent des méthodes métier au lieu de répéter les locators.
- Sélecteur CSS CSS selector Un motif du langage CSS qui cible des éléments par balise, id, classe, attribut ou position, très utilisé comme locator rapide et lisible dans les tests d’UI.
- Selenium Grid Serveur Selenium qui route les sessions WebDriver vers des nœuds distants, pour exécuter les tests en parallèle sur de nombreux navigateurs, versions et machines.
- Sharding des tests Test sharding Découper une suite de tests en tranches, appelées shards, exécutées en même temps sur des machines distinctes, pour qu'une longue suite se termine en une fraction du temps.
- StaleElementReferenceException Erreur Selenium levée quand un test utilise un WebElement dont le nœud DOM a été supprimé ou remplacé après sa recherche, généralement à la suite d'un re-rendu.
- Test de régression visuelle Visual regression testing Comparer des captures d'écran de l'interface à des images de référence approuvées pour détecter les changements visuels involontaires (décalages, styles manquants).
- Web-first assertion Assertion Playwright qui reçoit un locator et réessaie jusqu'à ce que la condition soit remplie ou que le timeout expire, au lieu de vérifier une valeur une seule fois.
- XPath Langage de requête qui sélectionne des nœuds dans un document XML ou HTML, utilisé en automatisation d'interface pour localiser des éléments par structure, attributs ou texte.
Test d’API
- API REST REST API API HTTP conçue autour de ressources identifiées par des URL, manipulées avec les méthodes standard GET, POST, PUT, PATCH et DELETE, via des requêtes sans état.
- Code de statut HTTP HTTP status code Le nombre à trois chiffres présent dans chaque réponse HTTP, qui indique si la requête a réussi, a été redirigée ou a échoué à cause du client ou du serveur.
- Contract testing (test de contrat) Contract testing Vérifier qu’un fournisseur d’API et ses consommateurs s’accordent sur les requêtes et réponses échangées, sans les déployer ensemble pour un test end-to-end.
- Idempotence Idempotency La propriété selon laquelle envoyer la même requête une ou plusieurs fois laisse le serveur dans le même état. GET, PUT et DELETE sont idempotents, POST ne l’est pas.
- JSON Schema Un vocabulaire JSON qui décrit la structure attendue de données JSON (types, champs obligatoires, formats), utilisé pour valider les réponses d’API.
- JWT (JSON Web Token) JWT Un JSON Web Token est un jeton compact et signé, de la forme header.payload.signature, qui transporte des claims comme l’id utilisateur, l’expiration et l’audience.
- OAuth 2.0 Framework d'autorisation qui permet à une application d'obtenir un jeton d'accès limité pour appeler une API au nom d'un utilisateur ou d'elle-même, sans mot de passe.
- Rate limiting Plafonner le nombre de requêtes qu'un client peut envoyer à une API sur une période et rejeter l'excédent, en général avec 429 Too Many Requests et un en-tête Retry-After.
CI/CD et DevOps
- Conteneur Docker Docker container Une instance isolée d’une image Docker qui embarque une application ou un service avec ses dépendances, pour un comportement identique en local et en CI.
- Feature flag Un interrupteur à l’exécution qui active ou désactive du code sans déploiement, pour livrer du travail masqué, déployer progressivement et revenir en arrière vite.
- Intégration continue (CI) Continuous integration La pratique consistant à fusionner souvent de petits changements dans une branche partagée, chaque push étant compilé et testé automatiquement en quelques minutes.
- Quality gate Contrôle automatisé réussite/échec dans un pipeline, comme des tests au vert ou une couverture au-dessus d'un seuil, à valider avant de merger ou de livrer du code.
- Testcontainers Bibliothèque qui démarre de vraies dépendances, comme des bases de données, des brokers ou des navigateurs, dans des conteneurs Docker jetables depuis votre code de test.
Performance
- Débit (throughput) Throughput Quantité de travail qu'un système accomplit par unité de temps, en général en requêtes ou transactions par seconde, mesurée avec la latence et le taux d'erreur.
- Latence en percentile Percentile latency Mesure du temps de réponse comme le p95 ou le p99, qui indique le temps sous lequel cette part des requêtes s'est terminée et révèle la queue lente que la moyenne cache.
- Test d'endurance (soak test) Soak testing Test de performance qui maintient une charge normale et réaliste pendant de nombreuses heures pour révéler les problèmes qui s'accumulent, comme les fuites mémoire.
- Test de charge Load testing Test de performance qui soumet un système au trafic réel attendu pour vérifier temps de réponse, taux d'erreur et débit par rapport à des objectifs convenus.
- Test de stress Stress testing Test de performance qui pousse la charge au-delà du niveau attendu pour trouver le point de rupture, observer comment le système défaille et vérifier qu'il se rétablit.
Sécurité
- Cross-site scripting (XSS) Cross-site scripting Le XSS est une faille où une saisie non fiable s’exécute comme script dans le navigateur d’un autre utilisateur, permettant à un attaquant d’agir à sa place.
- IDOR Insecure Direct Object Reference : une faille de contrôle d’accès où modifier un identifiant dans une requête permet de lire ou modifier les données d’un autre utilisateur.
- Injection SQL SQL injection Vulnérabilité où une saisie utilisateur est concaténée dans une requête SQL, permettant à un attaquant d'en modifier la logique pour lire, altérer ou supprimer des données.
- OWASP Top 10 Liste de sensibilisation de l'OWASP qui recense les dix catégories de risques de sécurité web les plus critiques, utilisée pour cadrer tests et revues de code.
L’IA dans le test
- Évaluation des LLM (LLM evals) LLM evaluation Mesurer systématiquement la qualité d’une fonctionnalité à base de LLM sur un ensemble fixe d’entrées et de critères, car les sorties varient d’une exécution à l’autre.
- Golden dataset (jeu de données de référence) Golden dataset Un ensemble versionné d’entrées avec des sorties attendues vérifiées, utilisé comme référence fixe pour les tests de régression de modèles, prompts ou pipelines.
- Injection de prompt Prompt injection Attaque dans laquelle un texte fourni à un LLM, saisi par l'utilisateur ou caché dans un contenu lu, supplante les instructions du développeur pour modifier son comportement.
- LLM-as-judge (LLM juge) LLM-as-judge Utiliser un modèle de langage et une grille écrite pour noter les sorties d’un autre modèle : un substitut évolutif mais biaisé à la revue humaine.
- Locator auto-réparant (self-healing) Self-healing locator Locator qui, lorsqu'il ne trouve plus rien, laisse l'outil de test choisir un élément de remplacement probable via des attributs stockés ou un modèle, et poursuit le test.
- Model Context Protocol (MCP) Model Context Protocol MCP est un protocole ouvert qui connecte assistants et agents IA à des outils et données externes, comme un navigateur, un dépôt ou un outil de gestion des tests.