Ai deschis Postman, ai construit o colecție frumoasă de requesturi, totul merge perfect în local. Apoi vine momentul adevărului: trebuie să rulezi aceleași teste pe staging. Și apoi pe producție. Și brusc te trezești că schimbi manual URL‑ul în fiecare request, că suprascrii token‑uri, că te întrebi dacă ai prins toate endpoint‑urile sau ai lăsat vreunul cu adresa de localhost. Sună familiar?
Nu e vina ta. Aproape toată lumea trece prin asta la început. Dar există o soluție elegantă, construită direct în Postman, care elimină complet problema: Environments și Variables. Odată ce înțelegi cum funcționează, o să te întrebi cum ai putut lucra altfel.
Shall we?
Ce sunt Postman Environments și de ce contează
Un Environment în Postman este, în esență, un set de perechi cheie‑valoare pe care le poți activa sau dezactiva dintr‑un dropdown. Gândește‑te la el ca la un profil de configurare: ai un profil pentru local, unul pentru staging, unul pentru producție. Fiecare profil știe ce URL de bază să folosească, ce credențiale să trimită, ce token de autorizare să injecteze.
Variables sunt variabilele propriu‑zise din interiorul unui Environment — sau din alte scopuri (Collection, Global, Local). Când scrii `{{base_url}}` într‑un request, Postman înlocuiește automat acea expresie cu valoarea corespunzătoare din Environment‑ul activ. Schimbi Environment‑ul, schimbi instant contextul întregii colecții. Fără să atingi un singur request.
Concret: dacă ai 60 de requesturi într‑o colecție de API testing — ceea ce nu e deloc neobișnuit într‑un proiect real, fie că e vorba de un API bancar, un backend de retail sau un sistem de gestiune din zona automotive — diferența dintre a schimba manual 60 de URL‑uri și a schimba un singur dropdown este uriașă. Nu doar ca timp, ci ca risc de eroare umană.
Cum configurezi Environments pas cu pas
Primul pas: în Postman, mergi în panoul din stânga și selectează secțiunea Environments. Creează trei environments: `Local`, `Staging`, `Production`. În fiecare, definește aceleași variabile — doar valorile diferă.
Variabilele pe care aproape sigur le vei folosi
- `base_url` — adresa rădăcină a API‑ului (ex: `http://localhost:3000`, `https://staging.api.companiatamea.ro`, `https://api.companiatamea.ro`)
- `auth_token` — token‑ul de autorizare, care de obicei diferă între environments
- `user_id`, `product_id` sau alți identificatori de test pe care îi folosești frecvent
- `db_prefix` sau `env_label` — util când vrei să loghezi sau să trasezi de unde vine un request
Al doilea pas: în requesturile tale, înlocuiește orice valoare hardcoded cu sintaxa `{{nume_variabila}}`. În loc de `https://staging.api.companiatamea.ro/users`, scrii `{{base_url}}/users`. Postman va rezolva variabila la runtime.
Al treilea pas: activezi Environment‑ul dorit din dropdown‑ul din colțul dreapta sus al interfeței Postman. De acum, tot ce rulezi folosește valorile din acel profil.
Variable scopes: unde trăiește o variabilă și de ce e important
Postman are mai multe niveluri de variabile, iar ordinea de prioritate contează. De la cel mai local la cel mai global: Local → Data → Environment → Collection → Global.
Variabilele de tip Global sunt disponibile în toate colecțiile și toate environments. Sunt utile pentru valori care nu se schimbă niciodată — de exemplu, un API key de third‑party care e același peste tot. Dar folosite în exces, devin o sursă de confuzie. Regula de aur: folosește cel mai îngust scope care rezolvă problema.
Variabilele de Collection sunt ideale pentru valori specifice unui proiect: versiunea de API (`v1`, `v2`), un header comun, un timeout. Le definești o dată la nivel de colecție și le folosești în toți membrii ei.
Variabilele de Environment sunt, în opinia mea, cele mai puternice în contextul testării pe multiple environments — exact pentru că sunt izolate pe profil. Schimbi profilul, schimbi tot contextul.
Un #FunFact util: dacă o variabilă există atât în Environment cât și în Collection cu același nume, cea din Environment câștigă. Deci poți seta un fallback la nivel de Collection și îl suprascrii per environment când e necevoie.
Scripting pentru variabile dinamice: Pre‑request și Tests
Environments și Variables devin cu adevărat puternice când le combini cu scripturile Postman. Să zicem că API‑ul tău necesită un token JWT obținut printr‑un endpoint de autentificare. În loc să copiezi manual token‑ul după fiecare login, poți automatiza treaba.
În tab‑ul Tests al requestului de autentificare, adaugi ceva de genul
`pm.environment.set("auth_token", pm.response.json().token);`
De acum, orice request care folosește `{{auth_token}}` va primi automat token‑ul proaspăt obținut. Funcționează indiferent de Environment‑ul activ — pentru că scriptul setează valoarea în Environment‑ul curent, oricare ar fi el.
Același principiu se aplică pentru IDs dinamice. Creezi un user în primul request, salvezi ID‑ul returnat într‑o variabilă, îl folosești în al doilea request pentru a face un GET sau un DELETE. Asta se numește request chaining și e una dintre tehnicile care diferențiază un tester care știe să folosească Postman de unul care abia supraviețuiește cu el.
La proiectele complexe — cum ar fi un sistem de comenzi online cu zeci de entități sau un backend de ospitalitate cu rezervări, camere și tarife — request chaining combinat cu Environments reduce dramatic timpul de setup al unui test run complet.
Rularea colecțiilor cu Newman și integrarea în pipeline
Odată ce ai Environments bine definite, poți rula colecțiile și din linia de comandă, prin Newman — runner‑ul oficial Postman pentru CLI. Comanda arată cam așa:
`newman run colectia‑mea.json -e staging‑environment.json`
Schimbi fișierul de environment și rulezi același set de teste pe orice target vrei. Asta înseamnă că poți integra testele Postman direct într‑un pipeline CI/CD — GitHub Actions, Jenkins, GitLab CI — fără nicio modificare în colecție. Echipa de dev face un push, pipeline‑ul rulează Newman cu environment‑ul de staging, rezultatele apar în raport. Dacă ceva se rupe, bug‑ul ajunge în JIRA înainte ca feature‑ul să ajungă în producție.
La DevTalks și la A4Q Summit am văzut din ce în ce mai multe echipe românești care adoptă exact această abordare — Postman pentru explorare și design de teste, Newman pentru execuție automată în pipeline. Nu e rocket science, dar necesită să ai fundamentele puse corect de la început. Environments și Variables sunt acele fundamente.
Câteva bune practici înainte să închei
Nu pune niciodată credențiale reale de producție în Environments pe care le exporți și le urci pe Git. Postman are conceptul de Current Value vs. Initial Value tocmai pentru asta: Initial Value e cel sincronizat și potențial vizibil altora, Current Value rămâne local pe mașina ta.
Numește variabilele consistent și descriptiv. `base_url` e bun. `url` e ambiguu. `my_url_final_v3` e o catastrofă.
Documentează Environment‑urile tale — Postman permite adăugarea de descrieri. Un coleg nou în echipă va aprecia enorm să știe ce reprezintă fiecare variabilă fără să te întrebe pe tine.
Și cel mai important: testează-ți Environments înainte de a rula o colecție critică. Un simplu `console.log(pm.environment.get("base_url"))` în Pre‑request Script te scutește de surprize neplăcute.
---
Dacă simți că Postman e un instrument pe care îl folosești la 30% din capacitate și vrei să ajungi la 100% — și să adaugi în portofol competențe de API testing, automation și integrare în pipeline — cursurile noastre de la Academia Testarii sunt locul potrivit. Am pregătit până acum sute de testeri care lucrează azi în proiecte reale, din banking până în energie și retail. Găsești toate detaliile și te poți înscrie pe academiatestarii.ro. 🎯
Te așteptăm!
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestAutomation #QualityAssurance