Postman aide les testeurs QA à explorer les API et à transformer une requête manuelle réussie en vérification reproductible. Son intérêt commence par l’explication du contrat violé, des données envoyées et de la raison pour laquelle la réponse est inacceptable pour l’utilisateur. Cliquer sur Send et voir 200 ne suffit pas : le serveur peut renvoyer la commande d’un autre utilisateur, une mauvaise devise ou un succès sans enregistrer les données. Organisez le travail autour de scénarios et d’attentes vérifiables.
Ce que contient une collection exploitable
Une requête définit une méthode, une URL, des en-têtes, une autorisation et un corps. Une collection regroupe les requêtes liées et leurs paramètres communs ; un dossier peut représenter un parcours utilisateur. Un environnement fournit les paramètres d’un déploiement précis. Les scripts avant requête préparent les données et les scripts après réponse vérifient les résultats. Les réponses et l’historique facilitent l’analyse, mais ne remplacent pas un scénario enregistré : les collègues doivent pouvoir le reproduire sans votre état local ni vos explications orales.
Commencer une analyse d’API
Trouvez d’abord le contrat de comportement : OpenAPI, exigences, exemples clients et restrictions de rôles. Vérifiez l’URL de l’environnement et la version du service, puis envoyez la requête valide minimale. Retirez les champs facultatifs et identifiez ceux qui influencent le résultat. Enregistrez un exemple fonctionnel avec son objectif. Modifiez ensuite une seule condition à la fois : type d’un champ, valeur obligatoire absente, permissions ou état d’objet. L’observation devient une expérience contrôlée.
Des variables sans dépendances cachées
Stockez l’adresse du service dans baseUrl et l’identifiant de la commande créée dans orderId. {{baseUrl}}/orders/{{orderId}} est plus clair qu’une adresse arbitraire avec un nombre en dur. Dans Postman, les valeurs dépendent de la portée : globale, collection, environnement, données d’itération et locale. Réutiliser un nom à plusieurs niveaux complique le diagnostic. Avant les tests, vérifiez l’environnement sélectionné et l’adresse réellement résolue ; ne vous fiez pas au seul nom de l’onglet.
Stockez jetons et mots de passe dans un mécanisme prévu pour les secrets, et fournissez les secrets CI via l’environnement d’exécution. Avant l’export, inspectez séparément les variables et les exemples de réponses. Marquer une valeur comme sensible et la masquer dans l’interface ne prouve pas son absence des fichiers, de la console ou des rapports joints.
Pratique : créer et relire une commande
Supposons que l’API de test crée les commandes via POST /orders et renvoie 201, id et totalMinor en unités monétaires mineures. Vous disposez de l’utilisateur buyer-a, d’un produit de test et de paiements réels désactivés. Dans cet exemple, le produit coûte 1250, la quantité est deux et la livraison est gratuite. Il s’agit des données et résultats attendus de ce test, pas d’un format API universel.
- 1.Créez une commande avec quantity=2. Attendez 201, un identifiant non vide et totalMinor=2500 ; enregistrez id seulement après validation de la réponse.
- 2.Appelez GET /orders/{{orderId}} avec le même utilisateur. Attendez le même propriétaire, le même contenu et le même total ; confirmez la création par une relecture.
- 3.Répétez la lecture avec buyer-b. Attendez le refus défini par le contrat, sans contenu de la commande d’autrui ; le code précis dépend de la politique du service.
- 4.Envoyez quantity=0. Attendez l’erreur de validation convenue et aucune nouvelle commande ; vérifiez l’effet de bord par un moyen disponible.
Des vérifications qui établissent des résultats utiles
Un script après réponse doit vérifier les valeurs métier et la structure, en plus du code HTTP. Une requête de création peut par exemple utiliser les assertions suivantes. Enregistrer id sous condition protège l’étape suivante de données manifestement invalides, sans rendre toute la chaîne indépendante de son état.
pm.test('Order created', () => {
pm.response.to.have.status(201);
const body = pm.response.json();
pm.expect(body.id).to.be.a('string').and.not.empty;
pm.expect(body.totalMinor).to.eql(2500);
});
if (pm.response.code === 201) {
const body = pm.response.json();
if (typeof body.id === 'string' && body.id.length > 0) {
pm.environment.set('orderId', body.id);
}
}Évitez de comparer toute la réponse à un unique instantané figé si elle contient des dates de création et des identifiants aléatoires. Vérifiez les champs requis, leurs types et les relations valides entre valeurs. Évaluez les attributs supplémentaires selon le contrat de compatibilité au lieu de signaler automatiquement un défaut.
Exécutions reproductibles et nettoyage des données
La collection doit créer ses propres données ou décrire explicitement la préparation. Effacez les anciennes valeurs orderId avant une nouvelle exécution pour ne pas relire une ancienne commande. Expliquez comment supprimer ou marquer les entités de test et reprendre après un échec partiel. Utilisez un marqueur unique pour les exécutions concurrentes. Un utilisateur partagé et une commande permanente transforment souvent des vérifications valides en courses aléatoires entre testeurs.
Exécution en CI
En octobre 2026, la documentation de Postman v12 décrit le format de collection v3 et recommande Postman CLI. Newman est déprécié, n’est plus pris en charge et ne peut pas exécuter v3. Identifiez d’abord le format de la collection, les scripts disponibles et l’exécuteur choisi. Testez toujours le passage d’une requête de l’application à la CI : ne supposez pas que coffres locaux, cookies et fonctions d’interface existent dans l’autre environnement.
Pour les opérations asynchrones, un succès peut seulement indiquer l’acceptation d’une tâche. Si la création renvoie un statut de traitement en cours, définissez la condition finale, le délai maximal et les réponses intermédiaires acceptables. Une longue pause arbitraire gaspille du temps dans un environnement rapide et reste instable dans un environnement lent. Vérifiez séparément la nouvelle tentative après expiration du délai : un résultat inconnu du client ne signifie pas qu’aucun objet n’a été créé. Si les clés d’idempotence sont prises en charge, gardez la même clé pour les tentatives d’une même intention et vérifiez l’absence de seconde commande.
Analyser les écarts
Comparez l’URL réelle, l’autorisation, les en-têtes et le corps envoyés, puis le statut, la réponse et les temps. Vérifiez la résolution des variables et les redirections automatiques. Un succès manuel suivi d’un échec CI implique souvent un autre jeton, un fuseau horaire différent, des données absentes ou le réseau. Joignez au défaut une requête minimale anonymisée, l’attente du contrat, la réponse réelle, le build et l’ID de corrélation. Un export complet de l’environnement contient souvent plus de données inutiles que de preuves.
Erreurs fréquentes et résultats QA
Les erreurs fréquentes sont de garder toute la régression dans des onglets non enregistrés, de prendre un statut vert pour une preuve de justesse, de changer manuellement les adresses dans des dizaines de requêtes ou d’exécuter des écritures dans le mauvais environnement. Autre piège : une chaîne non maîtrisée où le premier échec en provoque vingt autres. Une bonne collection possède une préparation claire, des vérifications utiles, des dépendances analysables et un nettoyage sûr. Postman permet alors de discuter des API à partir de faits reproductibles.
Lectures complémentaires
- →Postman : variables dans les scripts
- →Postman : présentation de Newman CLI
- →Postman : commandes de collection
Une collection locale reproductible : statut, schéma et état métier
Utilisez une API fictive avec GET /items et POST /items. Son contrat accepte un nom non vide et une quantité entière de 1 à 10 ; une écriture valide renvoie 201, une quantité hors limites 422 et du JSON mal formé 400. Ces statuts appartiennent à cet exemple, pas à toutes les API. Partez d’un élément préparé et réinitialisez l’environnement jetable avant chaque exécution de la collection.
Ordre d’exécution Requête Résultat attendu
1 Réinitialiser l’environnement de test jetable Un élément initial
2 GET /items 200 ; items est un tableau de longueur 1
3 POST /items {"name":"Pen","quantity":2} 201 ; id=2, name=Pen, quantity=2
4 POST /items {"name":"Pen","quantity":11} 422 ; erreur de plage pour quantity
5 POST /items avec du JSON mal formé 400 ; erreur de JSON invalide
6 GET /items Exactement 2 éléments ; les écritures refusées n’ont rien ajoutéUne assertion de statut seule peut manquer un résultat métier incorrect. Ajoutez une assertion de schéma pour les champs requis et leurs types, puis comparez les valeurs importantes. Une lecture finale vérifie la persistance et l’absence d’effets de bord. Gardez baseUrl dans un environnement séparé ; n’exportez jamais de vrais identifiants dans la collection pédagogique.
pm.test('Created', () => pm.response.to.have.status(201));
pm.test('Business values', () => {
const item = pm.response.json();
pm.expect(item.name).to.eql('Pen');
pm.expect(item.quantity).to.eql(2);
});Pour une nouvelle automatisation, consultez le fonctionnement actuel de Postman CLI. La documentation officielle recommande désormais son CLI maintenu ; Newman reste une option de compatibilité pour des collections v2.1 existantes. Pour une collection locale v2.1 exportée, la commande de compatibilité est newman run collection.json -e environment.json. Liez le serveur pédagogique à l’interface de boucle locale et réinitialisez les données jetables avant l’exécution.