25 avril 2026 Mis à jour : oct. 2026 Oussama Belakhdar 10 min de lecture

Data-Driven Testing : Guide Complet avec Python

Le Data-Driven Testing (DDT) consiste à séparer les données de test du code de test, permettant d'exécuter le même scénario avec de multiples jeux de données. C'est l'une des pratiques les plus puissantes pour augmenter la couverture sans dupliquer le code.

À retenir

pytest.mark.parametrize : méthode la plus directe en Python — itère automatiquement sur plusieurs tuples de paramètres, générant un test distinct pour chacun
Sources de données supportées : CSV (données volumineuses), JSON (structures hiérarchiques), Excel via openpyxl (équipes métier), PostgreSQL via psycopg2 (données dynamiques)
Règle d'isolation : chaque test doit fonctionner indépendamment : utiliser les fixtures pytest (setup/teardown) pour préparer et nettoyer les données
Toujours inclure les cas limites : valeurs nulles, chaînes vides, entiers négatifs — et versionner les fichiers CSV/JSON dans Git avec le code de test

Ce guide fait partie de notre dossier sur l'automatisation des tests : définition, outils et étapes pour automatiser vos tests logiciels.

Qu'est-ce que le Data-Driven Testing ?

Le DDT permet d'exécuter un même test avec différentes combinaisons d'entrées et de résultats attendus. Les données sont stockées séparément (CSV, JSON, Excel, base de données) et injectées dynamiquement dans les tests. Résultat : une couverture maximale avec un minimum de code.

L'approche augmente la couverture sans dupliquer le code de test, et elle permet à des personnes qui n'écrivent pas de code, comme les analystes métier, de relire ou d'enrichir les cas de test directement dans le fichier de données. Ajouter un cas revient à ajouter une ligne, pas à écrire du code.

Quand utiliser le Data-Driven Testing ?

Utilisez-le quand le même comportement doit être vérifié sur de nombreuses combinaisons d'entrées : calculs, règles de validation, tarification, droits d'accès, champs de formulaire ou payloads d'API. Évitez-le quand chaque cas demande des étapes différentes : forcer des scénarios différents dans un seul test paramétré produit une logique conditionnelle plus difficile à lire que des tests séparés.

1. DDT avec pytest.mark.parametrize

La méthode la plus directe en Python. Le décorateur @pytest.mark.parametrize permet d'itérer automatiquement sur plusieurs jeux de données.

Exemple : Tester une fonction de calcul de remise avec différents scénarios (0%, 10%, 25%) en une seule définition de test. pytest génère automatiquement un test distinct pour chaque tuple de paramètres.

Décorez la fonction de test avec @pytest.mark.parametrize, nommez les arguments et passez une liste de tuples. pytest génère un test par tuple : chaque cas réussit ou échoue indépendamment et apparaît séparément dans le rapport. Par exemple, @pytest.mark.parametrize("price, discount, expected", [(100, 0, 100), (100, 10, 90), (100, 25, 75)]) au-dessus de def test_discount(price, discount, expected) produit trois tests. Options utiles :

Noms lisibles : passez ids=[...], ou enveloppez une ligne dans pytest.param(..., id="dix-pourcent"), pour que le rapport indique quel cas a échoué
Bugs connus : pytest.param(..., marks=pytest.mark.xfail) garde visible une ligne en échec sans casser le build
Combinaisons : empiler deux décorateurs parametrize exécute toutes les combinaisons des deux listes
Données dynamiques : le hook pytest_generate_tests dans conftest.py paramètre les tests depuis n'importe quelle source au moment de la collecte

Évitez l'alternative qui consiste à boucler sur les données à l'intérieur d'un seul test : la première ligne en échec arrête la boucle, les lignes suivantes ne s'exécutent jamais, et le rapport affiche un seul échec au lieu de dire quels cas ont cassé.

2. Données depuis un fichier CSV

Pour des données volumineuses ou maintenues par des non-développeurs, le CSV est idéal. La bibliothèque standard csv ou pandas permettent de charger les données et de les passer à parametrize.

3. Données depuis JSON

Le JSON est préférable quand les données ont une structure hiérarchique (objets imbriqués, tableaux). Il est lisible humainement et facile à versionner avec Git.

Comment charger un fichier CSV ou JSON dans pytest ?

Lisez le fichier au moment de la collecte, convertissez chaque ligne en tuple ou en pytest.param, et passez la liste obtenue à parametrize.

Rangez le fichier à côté des tests, par exemple dans tests/data/discounts.csv, et versionnez-le dans Git avec le code.
Écrivez une petite fonction de chargement qui ouvre le fichier avec csv.DictReader ou json.load et convertit chaque valeur dans le bon type.
Donnez à chaque ligne une colonne identifiant et utilisez-la comme id du test.
Appelez la fonction dans le décorateur : @pytest.mark.parametrize("case", load_cases("discounts.csv"), ids=lambda c: c["id"]).
Faites échouer bruyamment le chargement si le fichier est vide ou qu'une colonne manque : un fichier de données cassé ne doit jamais aboutir à zéro test exécuté en silence.

4. Données depuis Excel avec openpyxl

Pour les équipes métier qui maintiennent leurs données de test dans Excel, openpyxl permet de lire les feuilles directement. Attention à verrouiller la structure du fichier pour éviter les ruptures.

5. Données depuis une base de données

Pour des données dynamiques ou liées à l'environnement de test, une connexion directe à la base (SQLite, PostgreSQL via psycopg2) est la meilleure option. Les données reflètent toujours l'état réel du système.

Quelle source de données choisir : CSV, JSON, Excel ou base de données ?

Choisissez la source selon qui maintient les données et leur degré de structure. Les listes en ligne conviennent tant que le jeu de données reste petit ; passez à un fichier quand il grossit ou que des non-développeurs doivent le modifier.

Source	Idéale pour	Outils Python	Point de vigilance
Liste en ligne	Petits jeux maintenus par les développeurs	`parametrize`	Devient illisible au-delà d'un écran
CSV	Tables plates, gros volumes, diffs faciles dans Git	`csv.DictReader`, pandas	Tout est lu comme du texte : convertir les types explicitement
JSON	Données imbriquées comme les payloads d'API	`json.load`	Garder un schéma clair par fichier
Excel	Données maintenues par les équipes métier	openpyxl, pandas	Fichier binaire difficile à relire : verrouiller la disposition des colonnes
Base de données	Données qui doivent refléter l'état réel de l'environnement	sqlite3, psycopg2, SQLAlchemy	Les tests dépendent de l'état d'un système partagé

Le Data-Driven Testing fonctionne-t-il pour les tests API et Playwright ?

Oui. Pour les tests d'API, paramétrez le payload et le code de statut attendu, puis envoyez chaque ligne avec requests ou le client HTTP de votre framework ; notre comparatif des outils de test API indique quel client convient à votre stack. Dans Playwright Test (TypeScript), l'approche documentée consiste à boucler sur un tableau de données et à déclarer un test() par élément, chacun avec un titre unique. Avec pytest-playwright, parametrize fonctionne exactement comme pour tout autre test pytest.

6. Stratégie de gestion des données de test

Isolation : Chaque test doit pouvoir fonctionner indépendamment — ne pas dépendre de données créées par un autre test
Nettoyage : Utiliser des fixtures pytest (setup/teardown) pour préparer et nettoyer les données
Données réalistes : Utiliser des générateurs (Faker) pour créer des données proches de la production
Versionner les données : Stocker CSV/JSON dans Git avec le code de test
Cas limites : Toujours inclure des cas limites (valeurs nulles, chaînes vides, entiers négatifs, entrées très longues, caractères spéciaux)

Ne copiez jamais de données personnelles de production : elles changent avec le temps, rendent les tests imprévisibles et exposent de vrais clients. Préférez des données synthétiques (Faker) ou des extraits anonymisés, donnez un responsable à chaque fichier de données et faites passer ses modifications en revue de code. Quand les données viennent de pipelines plutôt que de fichiers de test, il faut aussi contrôler les données elles-mêmes : voyez notre guide sur la qualité des données, tests et validation.

Combien de lignes de données faut-il ?

Moins que vous ne le pensez : une ligne par classe d'équivalence, plus les valeurs à chaque limite. La partition d'équivalence regroupe les entrées que le système doit traiter de la même façon ; l'analyse des valeurs limites teste les valeurs aux bords de chaque groupe, là où les défauts se concentrent. Ces deux techniques figurent au syllabus ISTQB Niveau Fondation. Pour une remise valable de 1 à 50 articles, testez 0, 1, 50 et 51 plutôt que vingt quantités prises au hasard.

Data-driven ou keyword-driven : quelle différence ?

Le data-driven testing fait varier les données tandis que les étapes restent fixes ; le keyword-driven testing (test piloté par mots-clés) décrit les étapes elles-mêmes sous forme de mots-clés réutilisables, comme dans Robot Framework. Les outils de BDD comme Cucumber ou pytest-bdd prennent en charge les deux idées : un « Scenario Outline » avec un tableau « Examples » est du data-driven testing écrit en Gherkin.

Conclusion

Le Data-Driven Testing est un multiplicateur de couverture. En séparant données et logique de test, vous réduisez la duplication, facilitez la maintenance et rendez votre suite de tests accessible aux non-développeurs. Commencez simple avec parametrize, puis évoluez vers des sources externes selon la complexité de votre projet. Pour savoir si l'automatisation sera rentable dans votre équipe, faites le calcul avec notre calculateur de ROI de l'automatisation des tests.

Questions fréquentes

Qu'est-ce que le data-driven testing, en termes simples ?

C'est exécuter plusieurs fois le même test automatisé avec des données d'entrée et des résultats attendus différents, stockés séparément du code de test. Ajouter un cas de test revient à ajouter une ligne de données, pas à écrire un nouveau test.

Comment paramétrer un test avec pytest ?

Utilisez le décorateur @pytest.mark.parametrize avec les noms des arguments et une liste de tuples de valeurs. pytest génère un test indépendant par tuple et rapporte chacun séparément.

Faut-il stocker les données de test en CSV ou en JSON ?

Le CSV pour les données tabulaires plates et les gros volumes, le JSON pour les structures imbriquées comme les payloads d'API. Ce sont deux fichiers texte que l'on versionne et relit dans Git avec les tests.

Peut-on utiliser des données de production pour le data-driven testing ?

À éviter. Les données de production contiennent souvent des informations personnelles et évoluent avec le temps, ce qui rend les tests imprévisibles. Générez des données synthétiques avec une bibliothèque comme Faker, ou utilisez des extraits anonymisés.

Quelle différence entre data-driven et keyword-driven testing ?

Le data-driven testing garde les étapes fixes et fait varier les données. Le keyword-driven testing exprime les étapes elles-mêmes sous forme de mots-clés réutilisables, comme dans Robot Framework. Beaucoup de frameworks combinent les deux.

Approfondissez avec nos formations

Notre formation QA Automation Python couvre le DDT en profondeur : pytest, fixtures avancées, intégration CI/CD.

Voir la formation QA Automation

équipe ADC — Experts QA & IA

AutomationDataCamp — Certifiés ISTQB

Experts Python et QA Automation spécialisés en data-driven testing, pytest et pipelines de test robustes. Découvrir l'équipe →