Entornos y variables en Postman para pruebas reproducibles

Por qué usar entornos y variables para pruebas reproducibles

Cuando ejecutas la misma colección contra dev, staging y prod, lo único que debería cambiar es el contexto (URL base, credenciales/tokens, datos de prueba permitidos). En Postman, esto se logra separando la lógica de las solicitudes y pruebas (que permanece igual) de los valores (que cambian) mediante entornos y variables. El objetivo es que tus requests y tests no “tengan hardcodeado” nada sensible ni dependan de IDs estáticos.

Tipos de variables y cuándo usar cada una

Variables globales

Disponibles en todo el workspace. Úsalas con moderación: son cómodas, pero facilitan colisiones y fugas si guardas valores sensibles. Recomendación: reservarlas para valores no sensibles y realmente transversales (por ejemplo, timezone o flags de depuración).

Variables de entorno

Son el núcleo de la reproducibilidad. Un entorno representa un contexto de ejecución (dev, staging, prod) y define valores como baseUrl, credenciales no secretas, y parámetros de configuración. Cambiar de entorno debe ser suficiente para apuntar toda la suite a otro sistema.

Variables de colección

Viven dentro de una colección. Son ideales para valores compartidos por todas las requests de esa colección y que no dependen del entorno (por ejemplo, apiVersion, rutas base, o nombres de recursos). También son útiles para almacenar datos generados durante una ejecución (IDs creados) cuando quieres que se mantengan dentro del alcance de la colección.

Variables locales

Son efímeras y existen solo durante la ejecución de una request (o script). Son la mejor opción para cálculos temporales (fechas, payloads construidos al vuelo) o para evitar persistir datos sensibles por accidente.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Precedencia de variables (qué valor gana)

Si defines la misma clave en varios niveles, Postman resuelve el valor por precedencia. Regla práctica: lo más cercano a la ejecución gana.

Nota: el orden exacto puede variar según el contexto (por ejemplo, variables definidas en el request), pero esta tabla te sirve para diseñar sin sorpresas. Si tienes dudas, depura el valor en tiempo de ejecución (sección de depuración).

Guía práctica: configurar dev, staging y prod paso a paso

Paso 1: define una plantilla de variables

Antes de crear entornos, define una lista de claves estándar para que todos los entornos tengan la misma “interfaz”. Ejemplo de plantilla:

• baseUrl
• authToken (si aplica, idealmente efímero)
• clientId, clientSecret (evitar persistir secretos; ver prácticas)
• testUserEmail, testUserPassword (evitar persistir password real)
• tenantId / orgId
• createdUserId, createdOrderId (IDs dinámicos)
• today, nowIso, fromDate, toDate
• seed (para datos pseudoaleatorios reproducibles)
• debug (true/false)

Paso 2: crea los entornos

En Postman, crea tres entornos: dev, staging, prod. En cada uno, define al menos:

• baseUrl: URL del API en ese entorno
• tenantId / orgId: si aplica
• debug: recomendado true en dev/staging y false en prod

Ejemplo de valores:

Paso 3: referencia variables en requests y scripts

Usa la sintaxis {{variable}} en URL, headers y body. Ejemplos:

• URL: {{baseUrl}}/v1/users
• Header Authorization: Bearer {{authToken}}
• Query param: from={{fromDate}}&to={{toDate}}

Paso 4: inicializa variables dinámicas (fechas, IDs, datos)

Para evitar editar valores manualmente, genera variables en scripts. Recomendación: genera fechas como variables locales o de entorno según necesidad.

Ejemplo: generar fechas ISO y rangos (en Pre-request Script de una request o a nivel de colección):

// Fechas reproducibles para la ejecución actual (no persistentes si usas pm.variables.set)const now = new Date();const nowIso = now.toISOString();const today = nowIso.slice(0, 10); // YYYY-MM-DD// Rango: últimos 7 díasconst from = new Date(now.getTime() - 7 * 24 * 60 * 60 * 1000).toISOString().slice(0, 10);const to = today;pm.variables.set('nowIso', nowIso);pm.variables.set('today', today);pm.variables.set('fromDate', from);pm.variables.set('toDate', to);

Ejemplo: datos de prueba con semilla (útil para reproducibilidad):

// Semilla por entorno o colección (si no existe, crea una)let seed = pm.environment.get('seed') || pm.collectionVariables.get('seed');if (!seed) {  seed = String(Date.now());  pm.environment.set('seed', seed);}function pseudoRandomInt(str) {  // hash simple  let h = 0;  for (let i = 0; i < str.length; i++) h = (h * 31 + str.charCodeAt(i)) & 0xffffffff;  return Math.abs(h);}const n = pseudoRandomInt(seed) % 100000;pm.variables.set('uniqueEmail', `qa.user.${n}@example.test`);

Paso 5: captura IDs creados y reutilízalos

Cuando una request crea un recurso, guarda el ID para usarlo en requests posteriores. Decide el ámbito:

• Colección: si varias requests lo necesitan durante la suite.
• Entorno: si quieres que persista entre ejecuciones (cuidado con datos obsoletos).
• Local: si solo lo usas en la misma request (poco común para IDs).

Ejemplo: guardar userId en variable de colección (en Tests):

pm.test('201 Created', () => {  pm.response.to.have.status(201);});const json = pm.response.json();pm.collectionVariables.set('createdUserId', json.id);

Luego, en otra request: {{baseUrl}}/v1/users/{{createdUserId}}

Depuración: cómo saber qué valor se está usando realmente

Inspeccionar variables resueltas

Para ver qué se envió exactamente, usa la consola de Postman y el panel de información de la request. En scripts, imprime valores:

console.log('baseUrl:', pm.variables.get('baseUrl'));console.log('authToken exists:', Boolean(pm.variables.get('authToken')));console.log('createdUserId:', pm.variables.get('createdUserId'));

pm.variables.get() es clave para depurar porque respeta la precedencia y te devuelve el valor efectivo.

Detectar colisiones por precedencia

Si un valor “no cambia” al cambiar de entorno, suele ser porque existe la misma clave en un ámbito con mayor precedencia. Estrategias:

• Busca la clave en Global, Colección y Entorno y elimina duplicados innecesarios.
• Prefija variables para evitar choques: por ejemplo env_baseUrl (entorno) y col_apiVersion (colección).
• Durante depuración, imprime también el origen de forma indirecta: prueba a leer explícitamente pm.environment.get('baseUrl') y pm.collectionVariables.get('baseUrl') para comparar.

console.log('env baseUrl:', pm.environment.get('baseUrl'));console.log('col baseUrl:', pm.collectionVariables.get('baseUrl'));console.log('effective baseUrl:', pm.variables.get('baseUrl'));

Estructura recomendada de variables por entorno

Diseña tus entornos como “configuración” y evita mezclar estado temporal. Una estructura práctica:

1) Configuración (persistente, no sensible)

• baseUrl
• apiAudience / tenantId
• rateLimitProfile (si aplica)
• debug

2) Credenciales y secretos (evitar persistir)

• authToken (preferible efímero; si se guarda, que sea de corta vida)
• clientId (no siempre secreto, depende del sistema)
• clientSecret, passwords, API keys (no guardarlos en entornos compartidos)

3) Estado de ejecución (temporal)

• createdUserId, createdOrderId
• nowIso, fromDate, toDate
• uniqueEmail

Recomendación: el estado temporal guárdalo en variables de colección (si es para la suite) o locales (si es para una request), y limpia al final si es necesario.

Plantilla reutilizable: entorno “base” + duplicación controlada

Para estandarizar, crea un entorno plantilla llamado _template con todas las claves y valores ficticios (no secretos). Luego duplica para dev, staging, prod y reemplaza solo lo necesario.

Ejemplo de plantilla (valores ilustrativos):

Prácticas para evitar fugas de datos sensibles

No persistir secretos en variables sincronizadas

Evita guardar clientSecret, passwords o API keys en variables de entorno si el workspace es compartido o sincronizado. Alternativas:

• Usar variables locales (pm.variables.set) para tokens obtenidos en runtime.
• Inyectar secretos en tiempo de ejecución desde el sistema de CI (por ejemplo, variables de entorno del runner/agent) y mapearlas a Postman mediante scripts o configuración del runner.
• Separar un workspace privado para pruebas con secretos y otro para compartir colecciones sin secretos.

Enmascarar y minimizar logs

No imprimas tokens completos en consola. Si necesitas depurar, muestra solo prefijos:

const t = pm.variables.get('authToken');if (t) console.log('authToken prefix:', t.slice(0, 10), '...');

Limpiar variables al finalizar flujos

Si guardas tokens o IDs en entorno por conveniencia, limpia al terminar un flujo (por ejemplo, en una request final “Cleanup”):

pm.environment.unset('authToken');pm.collectionVariables.unset('createdUserId');

Versionado seguro: qué guardar en Git y qué no

Versiona la estructura, no los secretos

Buena práctica: versionar colecciones y plantillas de entornos con valores ficticios. No versionar entornos con secretos reales.

• Incluye en Git: colección, scripts, y un entorno _template con placeholders.
• Excluye de Git: entornos reales con tokens/keys/passwords.

Usar placeholders y documentación de variables

En la plantilla, usa valores tipo <REPLACE_ME> o dominios de ejemplo. Además, documenta en una tabla (como la anterior) qué variables son obligatorias y cuáles se generan en runtime.

Checklist rápido para pruebas reproducibles

• Las URLs usan {{baseUrl}} y no dominios fijos.
• Los IDs se capturan desde respuestas y se guardan en colección/entorno según necesidad.
• Fechas y datos variables se generan en scripts (preferible local).
• No hay secretos persistidos en variables compartidas o versionadas.
• Se depura con pm.variables.get() y logs mínimos.