Test API : Postman/Newman

1) Pourquoi Postman/Newman

• régressions répétables et smokes rapides ;
• paramétrage des environnements/secrets ;
• métriques de qualité et rapports lisibles par machine.

2) Modèle de base

La collection est un arbre de requêtes et de dossiers avec des scripts partagés.
L'environnement est le jeu '{{vars}}' pour dev/stage/prod (URL, clés).
Pré-request script - préparation : signatures, tokens, corollaire de données.
Tests - approbations et conservation des variables/artefacts.
Data-files - CSV/JSON pour data-driven run.
Mock/Monitor - meutes et contrôles périodiques.

<API v1>
├─ _bootstrap (auth, health, seeds)
├─ Public
├─ Authenticated
│  ├─ Accounts
│  ├─ Payments
│  └─ Reports
└─ _teardown (cleanup)

3) Variables et secrets

Nommez les variables par un préfixe explicite : 'baseUrl',' tenant ',' clientId '.
Gardez les secrets (mots de passe, client_secret, clés HMAC) dans les variables d'environnement CI, ne communiquez pas au référentiel.
Utiliser scoop : collection → locale → environnement → globals (minimum possible).

json
{
"name": "stage-eu",
"values": [
{"key":"baseUrl","value":"https://api. stage. example. com","type":"text","enabled":true},
{"key":"tenant","value":"eu-1","type":"text","enabled":true}
]
}

4) Authentification : modèles

4. 1 OAuth2/OIDC (Client Credentials)

js if (!pm.environment. get("access_token")          Date. now() > pm. environment. get("token_exp")) {
pm. sendRequest({
url: pm. environment. get("authUrl"),
method: 'POST',
header: {'Content-Type':'application/x-www-form-urlencoded'},
body: { mode:'urlencoded', urlencoded:[
{key:'grant_type',value:'client_credentials'},
{key:'client_id',value:pm. environment. get('clientId')},
{key:'client_secret',value:pm. environment. get('clientSecret')},
{key:'scope',value:'payments:read payments:write'}
]}
}, (err, res) => {
pm. environment. set("access_token", res. json(). access_token);
pm. environment. set("token_exp", Date. now()+ (res. json(). expires_in-30)1000);
});
}

Dans la requête : 'Autorisation : Bearer {{access _ token}}'.

4. 2 HMAC (webhooks/partenaires)

js const body = pm. request. body? pm. request. body. raw          '': '';
const ts = Math. floor(Date. now()/1000);
const msg = `${ts}.${body}`;
const sig = CryptoJS. HmacSHA256(msg, pm. environment. get('hmacSecret')). toString();
pm. variables. set('ts', ts);
pm. variables. set('sig', sig);

Titres : 'X-Timestamp : {{ts}', 'X-Signature : {{sig}}'.

5) Tests : approbations et corollation

Utilisez 'pm. expect(...)` и `pm. test("...", fn)`.
Gardez les identifiants pour les étapes suivantes via 'pm. collectionVariables. set`.

js pm. test("HTTP 200", () => pm. response. to. have. status(200));
pm. test ("Scheme is valid," () => {
const schema = pm. collectionVariables. get("schema_wallet");
pm. expect(tv4. validate(pm. response. json(), JSON. parse(schema))). to. be. true;
});
pm. test ("Contains id," () => {
const id = pm. response. json(). id;
pm. expect(id). to. be. a('string');
pm. collectionVariables. set("wallet_id", id);
});

6) Validation du schéma (OpenAPI/JSON Schema)

Conservez JSON Schema dans les variables de collection ou dans un fichier distinct.
Pour OpenAPI : utilisez les feuilles prêtes à l'emploi dans pré-request/test (ajv, tv4) - via 'pm. sendRequest 'sur le fichier raw ou l'inline JSON.

js pm. collectionVariables. set("schema_wallet", JSON. stringify({
"type":"object",
"required":["id","currency","balance"],
"properties":{
"id":{"type":"string"},
"currency":{"type":"string","pattern":"^[A-Z]{3}$"},
"balance":{"type":"number","minimum":0}
}
}));

7) Scénarios de données driven

email, password, currency u1@example. com, P@ss1, EUR u2@example. com, P@ss2, USD

La requête utilise '{{email}}', '{{currency}}'.

newman run collection. json -e stage-eu. json -d users. csv

JSON (tableau d'objets) - pratique pour les cas/structures complexes.

8) Cas négatifs et résilience

• 401/403 (pas de token/faux scope/rôle).
• 400/422 (validation du régime, champs obligatoires, limites).
• 404 (BOLA/ressource étrangère).
• 409 (conflits, clés idempotentes).
• 429 (limites) - vérifier « Retry-After ».
• 5xx est la dégradation correcte et les retraits du client.

js pm. test ("There is Retry-After at 429," () => {
if (pm. response. code === 429) pm. expect(pm. response. headers. has('Retry-After')). to. be. true;
});

9) Idempotence, Retrai, Pagination

Passez 'Idempotency-Key' et assurez-vous que la répétition donne le même 'id/status'.
Testez la pagination : 'limit/offset '/' cursor', un détail de duplications et de passes.
Simulation de retraits dans le script Test : appels successifs avec la même clé.

js pm. test ("Idempotent repetition," () => {
pm. sendRequest(pm. request, (err, res2) => {
pm. expect(res2. code). to. eql(pm. response. code);
pm. expect(res2. json(). id). to. eql(pm. response. json(). id);
});
});

10) Newman в CI/CD

10. 1 Démarrage

newman run collection. json \
-e stage-eu. json \
-d data. csv \
--timeout-request 30000 \
--reporters cli,htmlextra,junit \
--reporter-htmlextra-export./reports/report. html \
--reporter-junit-export./reports/junit. xml

10. 2 Actions GitHub (fragment)

yaml
- uses: actions/setup-node@v4 with: { node-version: '20' }
- run: npm i -g newman newman-reporter-htmlextra
- run: newman run collection. json -e stage-eu. json --reporters cli,junit --reporter-junit-export reports/junit. xml
- uses: actions/upload-artifact@v4 with: { name: newman-reports, path: reports }

10. 3 Jenkins/GitLab CI

Exportez JUnit ('--reporter-junit-export') pour la visualisation native.
En pipline, séparez les jobs : smoke (rapide), région (complète), sécurité (négative/limites).

10. 4 Docker

docker run --rm -v $PWD:/etc/newman postman/newman \
run collection. json -e stage-eu. json

11) Moki et surveillance

Mock servers Postman sont des meutes rapides pour le front et les contrats.
Monitors est une chasse périodique de smoks à partir du nuage (latency, 5xx, SSL).
Dans le référentiel, gardez les fichiers d'exemples de réponses pour les moquettes déterministes.

12) Données de test et nettoyage

Créez/supprimez des entités (_bootstrap/_teardown).
Marquer les objets de test avec le préfixe 'e2e _' et TTL.

js pm. collectionVariables. set("uniq", Date. now()+"_"+Math. floor(Math. random()1e6));

13) Performance « sur le genou »

• mesurer 'pm. response. responseTime`;
• Lancer 5 à 10 itérations et fixer les p95/seuils ;
• performances lourdes - en JMeter/k6/Gatling (en dehors de cet article).

14) Localisation et polyvalence

Les variables 'tenant', 'region', 'lang' ; basculer dans les milieux.
Les tests doivent vérifier que les données ne « coulent » pas entre les tenants (BOLA-read, interdictions croisées).
Collections/dossiers individuels sur les caractéristiques régionales (limites, devises).

15) Rapports et artefacts

Gardez les artefacts CI : HTML reports, 'junit. xml ', logs de réponses échouées (response bodies).
Connectez les notifications Slack/Teams sur les chutes de figues.

16) Qualité et revêtement

• CRUD par ressource (200/201/204 + négatifs).
• Autorisation : rôles/copains/multi-tenants.
• Pagination/filtres/tri.
• Idempotentialité et retrai.
• Limites : 413/414/431/429.
• Formats et schémas (JSON Schema/OpenAPI).
• Intégration (webhooks avec HMAC/mTLS) - anti-replay.

17) Anti-modèles

Un « chemin heureux » sans tests négatifs.
Tokens à longue durée de vie dans la collection/référentiel.
Mélange des données de test avec les données de prod.
Dépendance latente de l'ordre des tests sans corollation explicite.
Fichiers de données géants sans échantillonnage.
Aucun rapport JUnit/HTML → aucune visibilité dans CI.

18) Chèque-liste prod-prêt

• Les collections sont divisées par domaine, il y a '_ bootstrap/_ teardown'.
• Environnement pour dev/stage/prod ; Secrets du coffre-fort CI.
• Pre-request для auth (OAuth2/HMAC); les jetons sont mis en cache et tournés.
• Tests : positif + négatif, schémas (JSON Schema), pagination, 429/Retry-After.
• Idempotence : vérification 'Idempotency-Key', double appel équivalent.
• Data-driven CSV/JSON, suffixes aléatoires pour l'unicité.
• Newman in CI : JUnit/HTML rapports, artefacts comme build outputs.
• Moki/moniteurs pour les itinéraires clés ; SLA par figues.
• Documentation sur les variables, les étiquettes et l'ordre de démarrage.

19) TL; DR

Stockez la logique des tests dans les collections Postman, les paramètres dans les environnements, et faites la course dans le CI via Newman avec les rapports JUnit/HTML. Couvrir les négatifs, les schémas, l'idempotence, la pagination et les limites. Corrélez les étapes avec des variables, utilisez les entrées data-driven et moki/moniteurs. Les secrets ne viennent que de CI, les rapports sont des artefacts.