Niveaux de test
Chaque niveau de test a une intention, un périmètre et des intervenants différents. Les combiner forme la pyramide des tests, une stratégie équilibrée qui maximise la couverture tout en gardant des retours rapides.
01 — Les quatre niveaux
Que fait chaque niveau exactement ?
Tests unitaires
Développeurs · à chaque commit
Objectif : vérifier le comportement d'un composant isolé (fonction, classe, module) indépendamment du reste du système.
Le plus bas niveau de la pyramide : rapides, automatisés et exécutés en continu, ils forment le filet de sécurité de base. Ils s'appuient sur des doublures (mocks, stubs, fakes) pour isoler le code testé de ses dépendances.
Forces :
- Très rapides
- Localisent précisément les défauts
- Documentent l'intention du code
Limites :
- Ne valident pas les interactions
Exemples : JUnit, NUnit, pytest, Jest, mocks, stubs. Cycle TDDTest-Driven Development : Red → Green → Refactor.
Couverture cible : 70-80% des lignes critiques.
Tests d'intégration
Développeurs & QA · après l'unitaire, avant le système
Objectif : valider les interactions entre composants ou systèmes : appels APIApplication Programming Interface, accès base de données, files de messages, services externes.
On distingue l'intégration composant (entre modules d'une même application) et l'intégration système (entre applications ou services). Stratégies classiques : big bang, top-down, bottom-up, sandwich, incrémental.
Forces :
- Valident les échanges réels entre composants
- Détectent les problèmes d'interface
Limites :
- Plus lents et coûteux que les tests unitaires
- Plus complexes à mettre en place et à maintenir
- Diagnostic parfois moins précis
Exemples : Intégration composant, intégration système (APIApplication Programming Interface / BDDBase De Données), contrat d'interface.
Couverture cible : Couvrir les chemins critiques inter-composants.
Tests système
QA · après un build stable, sur un environnement stable dédié
Objectif : évaluer le système complet par rapport aux exigences fonctionnelles et non-fonctionnelles.
Réalisés en boîte noire sur un environnement représentatif de la production. Ils couvrent les flux de bout en bout, la sécurité, la performance, la compatibilité multi-navigateurs / multi-OS, et le comportement sous charge.
Forces :
- Vue globale du produit
- Représentatifs de l'expérience utilisateur
Limites :
- Plus lents et coûteux
- Plus fragiles (flaky testsTests instables : résultat différent à chaque exécution, sans changement de code)
Exemples : Tests de bout en bout, tests de charge, tests de sécurité.
Couverture cible : Couvrir les scénarios critiques de bout en bout.
Tests d'acceptation
Utilisateurs / Métier · avant la mise en production
Objectif : confirmer que le système répond aux besoins métier et que l'utilisateur peut l'accepter.
L'ISTQB distingue plusieurs formes : UATUser Acceptance Testing, tests contractuels et réglementaires, tests alpha (chez l'éditeur) et bêta (chez de véritables utilisateurs).
Forces :
- Validation par le vrai utilisateur
- Réduisent le risque de rejet
Limites :
- Détectent tardivement les défauts
- Dépendent de la disponibilité du métier
Exemples : Tests d'acceptation, tests contractuels, tests opérationnels.
Couverture cible : Couvrir le cas réel d'usage et conformité aux critères d'acceptation.
02 — Stratégies d'intégration
Comment assembler et tester les composants ?
L'ISTQBInternational Software Testing Qualifications Board recense plusieurs approches, chacune avec ses compromis entre rapidité de mise en place et facilité de diagnostic.
Big bang
Tout est intégré d'un coup, puis testé. Simple, mais diagnostic difficile en cas d'échec.
Top-down
On part des modules de haut niveau et on descend, en utilisant des stubs pour les modules inférieurs.
Bottom-up
On commence par les modules bas niveau avec des drivers, puis on remonte vers les couches supérieures.
Sandwich
Combinaison top-down et bottom-up, on se rejoint au milieu. Bon compromis sur les gros systèmes.
Incrémental
On intègre les composants un par un, en validant à chaque étape. Diagnostic facile, mais plus long.
03 — Les schémas à éviter
Les différentes organisations de test à éviter
Cône de glace
Beaucoup de bout en bout, peu d'unitaires. Suite lente, fragile et coûteuse à maintenir.
Sablier
Beaucoup d'unitaires et de bout en bout, très peu d'intégration. Les bugs d'interface passent entre les mailles.
Cupcake
Tout manuel sur le dessus, avec une base importante de tests unitaires. Pas durable dès que le produit grossit.
04 — La pyramide idéale
La pyramide des tests
Théorisée par Mike Cohn, elle propose une répartition saine : beaucoup d'unitaires à la base, moins d'intégration au milieu, peu de bout en bout au sommet. L'objectif est l'équilibre entre vitesse, coût et confiance.
BeBBout en Bout / UIUser Interface
Peu nombreuxLents et coûteux = scénarios critiques.
Intégration / APIApplication Programming Interface
ModérésValident les contrats et interactions.
Unitaires
Très nombreuxRapides, nombreux =fondation de la confiance.
A retenir
En bref
- Chaque niveau a un objectif et un responsable distincts (ne pas les confondre) ;
- Les tests unitaires offrent des retours rapides, les tests d'intégration valident les échanges, les tests système couvrent les parcours complets, et les tests d'acceptation confirment la valeur métier ;
- La pyramide des tests est un repère utile, mais elle doit être adaptée au produit et à ses risques ;
- Un test mal placé (BeBBout en Bout pour ce qui pourrait être unitaire) coûte plus cher : cela revient à reporter la détection des bugs vers la fin du projet.
Pour aller plus loin