Bases de test
"On ne peut tester correctement que ce que l’on peut vérifier."
Objectifs pédagogiques
- Comprendre ce qu’est une base de test
- Identifier les documents de référence
- Relier exigences, tests et résultats
- Assurer la traçabilité des tests
Qu’est-ce qu’une base de test ?
La base de test regroupe l’ensemble des éléments de référence utilisés pour :
- concevoir les tests
- exécuter les tests
- analyser les résultats
Elle répond à la question essentielle :
« Par rapport à quoi teste-t-on ? »
Sans base de test claire, il est impossible de :
- définir des cas de test fiables
- décider objectivement si un test est réussi ou échoué
Exemples de bases de test
Selon le contexte du projet, une base de test peut être constituée de :
- cahier des charges
- spécifications fonctionnelles
- exigences utilisateur
- user stories
- maquettes (UX/UI)
- règles métier
- contraintes légales ou réglementaires
👉 En pratique, une base de test est souvent un ensemble de documents cohérents.
Bases de test selon le niveau de test
| Niveau de test | Base de test typique |
|---|---|
| Tests unitaires | Code source, spécifications techniques |
| Tests d’intégration | Contrats d’API, interfaces |
| Tests système | Exigences fonctionnelles |
| Tests d’acceptation | Besoins utilisateur |
| Tests de conformité | Normes, lois, standards |
Importance de la traçabilité
La base de test permet de :
- relier chaque exigence à un ou plusieurs tests
- démontrer la couverture fonctionnelle
- faciliter la validation et les audits
Cette relation est souvent représentée par une matrice de traçabilité.
Erreurs fréquentes
- Tester sans document de référence
- Tester des fonctionnalités non demandées
- Mélanger hypothèses et exigences réelles
- Ne pas mettre à jour la base de test
Exemple concret de base de test – MyEvents
Pour illustrer la notion de base de test, nous utilisons l’application MyEvents
comme exemple fil rouge.
Présentation de l’application
MyEvents
est une application web et mobile permettant :
- la création et la gestion d’événements
- l’achat ou la réservation de billets
- l’invitation de participants
- l’envoi de notifications par e-mail ou SMS
L’application interagit avec plusieurs services externes :
- API de paiement (Stripe / PayPal)
- service d’e-mails et SMS (SendGrid / Twilio)
- API de géolocalisation (Google Maps)
- base de données utilisateur partagée front/back-end
Exemple d’exigence servant de base de test
Exigence fonctionnelle EF-01
Lorsqu’un utilisateur achète un billet pour un événement :
- le paiement doit être validé via l’API de paiement
- le billet doit être enregistré dans la base de données
- une confirmation doit être envoyée par e-mail
- l’événement doit apparaître dans l’espace personnel de l’utilisateur
👉 Cette exigence constitue une base de test.
Définition de tests à partir de la base de test
1️⃣ Cas de test fonctionnels
Objectif : vérifier le comportement normal du système.
Exemple : achat de billet réussi
- Précondition : utilisateur connecté, événement disponible
- Action : paiement valide
- Résultat attendu :
- paiement accepté
- billet enregistré
- e-mail envoyé
- billet visible dans l’espace utilisateur
2️⃣ Tests d’erreur (cas négatifs)
Objectif : vérifier la robustesse du système.
Exemple : paiement refusé
- Action : paiement avec carte invalide
- Résultat attendu :
- paiement refusé
- aucun billet créé
- message d’erreur explicite
- aucune notification envoyée
3️⃣ Tests d’intégration – API de paiement
Objectif : vérifier les échanges avec les services externes.
Scénarios possibles :
- réponse OK de l’API → traitement normal
- API indisponible → message d’erreur technique
- réponse inattendue → gestion sécurisée
Résultat attendu :
- pas d’incohérence de données
- utilisateur informé correctement
- système stable
Lien avec la stratégie de test
À partir de cette base de test, il est possible de :
- identifier les fonctionnalités critiques
- prioriser les tests
- définir les tests automatisés
- anticiper les risques
👉 La base de test alimente directement la stratégie de test.