Ejecución automatizada con Collection Runner y flujos parametrizados en Postman

¿Qué aporta el Collection Runner a una suite de pruebas?

El Collection Runner permite ejecutar una colección (o una carpeta) de forma repetible y controlada: define cuántas iteraciones correr, con qué entorno, con qué archivo de datos y cómo reportar resultados por request y por iteración. Es la pieza clave para convertir una colección en una ejecución automatizada y para habilitar data-driven testing (múltiples casos con una misma lógica de requests y aserciones).

Configurar ejecuciones repetibles con Collection Runner

1) Elegir el alcance: colección vs carpeta

• Colección completa: útil para smoke/regresión rápida de un servicio.
• Carpeta: ideal para agrupar por feature (por ejemplo, “Auth”, “Orders”, “Payments”) y ejecutar solo lo necesario.

Recomendación práctica: organiza la colección en carpetas que representen flujos o módulos. Así podrás ejecutar por partes y aislar fallos con menos ruido.

2) Abrir Runner y seleccionar entorno

1. En Postman, abre la colección.
2. Haz clic en Run (o abre Collection Runner).
3. En Environment, selecciona el entorno que corresponda (por ejemplo, dev, qa, staging).

Buenas prácticas para repetibilidad: evita depender de valores “sueltos” en la colección. Asegúrate de que el entorno tenga los valores necesarios para la ejecución (base URL, credenciales de prueba, flags, etc.).

3) Controlar el orden de requests

El Runner ejecuta en el orden en que aparecen los requests dentro de la colección/carpeta. Para flujos end-to-end, el orden importa. Para pruebas independientes, conviene agrupar por tipo y minimizar dependencias.

• Orden recomendado para flujos: setup (crear datos) → acción (operación principal) → validación (consultas) → teardown (limpieza si aplica).
• Orden recomendado para suites: primero smoke (rápidas), luego validaciones profundas, y al final pruebas más costosas.

4) Definir iteraciones y manejo de fallos

En Runner, configura:

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

• Iterations: cuántas veces se ejecuta el conjunto. Si usas archivo de datos, normalmente se alinea a la cantidad de filas/objetos.
• Delay (si está disponible): útil para evitar rate limits o dar tiempo a procesos asíncronos.
• Stop on error (si está disponible en tu versión/flujo): detiene la ejecución ante el primer fallo. Útil en pipelines cuando un fallo invalida el resto.

Estrategia de fallos: en suites grandes, suele convenir no detener para obtener un panorama completo; en flujos críticos, conviene detener si un paso previo es requisito del siguiente.

Parametrización con archivos de datos (CSV/JSON): data-driven testing

El Runner puede inyectar datos por iteración desde un archivo CSV o JSON. Cada fila/objeto se convierte en un conjunto de variables accesibles en requests y tests mediante {{nombreCampo}}.

Formato CSV: ejemplo de matriz de casos

Ejemplo de archivo cases.csv para probar un endpoint de login con entradas y salidas esperadas:

caseId,email,password,expectedStatus,expectedErrorCode,shouldHaveToken
L01,valid.user@example.com,CorrectPass123,200,,true
L02,valid.user@example.com,WrongPass,401,INVALID_CREDENTIALS,false
L03,missing.user@example.com,AnyPass,404,USER_NOT_FOUND,false

Notas:

• Los campos vacíos en CSV quedan como cadena vacía; en tests, valida con cuidado (por ejemplo, expectedErrorCode puede ser "").
• Usa columnas booleanas como true/false y conviértelas en tests con comparaciones de string o normalización.

Formato JSON: ejemplo equivalente

Ejemplo cases.json (lista de objetos):

[ { "caseId": "L01", "email": "valid.user@example.com", "password": "CorrectPass123", "expectedStatus": 200, "expectedErrorCode": null, "shouldHaveToken": true }, { "caseId": "L02", "email": "valid.user@example.com", "password": "WrongPass", "expectedStatus": 401, "expectedErrorCode": "INVALID_CREDENTIALS", "shouldHaveToken": false }, { "caseId": "L03", "email": "missing.user@example.com", "password": "AnyPass", "expectedStatus": 404, "expectedErrorCode": "USER_NOT_FOUND", "shouldHaveToken": false } ]

Ventaja del JSON: tipos nativos (número/boolean/null) y menos ambigüedad en aserciones.

Guía paso a paso: ejecutar una colección parametrizada

Paso 1: preparar el request para consumir variables por fila

En el request POST /login, usa variables del archivo de datos en el body:

{ "email": "{{email}}", "password": "{{password}}" }

Si necesitas headers dinámicos por caso (por ejemplo, X-Client-Id), también puedes parametrizarlos con {{clientId}} como columna/campo.

Paso 2: escribir aserciones basadas en la matriz de esperados

En la pestaña Tests del request, valida status y comportamiento esperado por iteración. Ejemplo:

// Identificador del caso para rastreo en Runner
const caseId = pm.iterationData.get('caseId');

// Esperados (CSV entrega strings; JSON puede entregar tipos)
const expectedStatusRaw = pm.iterationData.get('expectedStatus');
const expectedStatus = Number(expectedStatusRaw);

// En CSV puede venir ""; normalizamos a null
const expectedErrorCodeRaw = pm.iterationData.get('expectedErrorCode');
const expectedErrorCode = (expectedErrorCodeRaw === '' || expectedErrorCodeRaw === undefined) ? null : expectedErrorCodeRaw;

const shouldHaveTokenRaw = pm.iterationData.get('shouldHaveToken');
const shouldHaveToken = (String(shouldHaveTokenRaw).toLowerCase() === 'true');

pm.test(`[${caseId}] Status esperado`, function () {
  pm.response.to.have.status(expectedStatus);
});

let json;
pm.test(`[${caseId}] Respuesta JSON parseable`, function () {
  json = pm.response.json();
  pm.expect(json).to.be.an('object');
});

pm.test(`[${caseId}] Validación de token/errores según caso`, function () {
  if (shouldHaveToken) {
    pm.expect(json).to.have.property('token');
    pm.expect(json.token).to.be.a('string').and.not.empty;
  } else {
    pm.expect(json).to.not.have.property('token');
    if (expectedErrorCode !== null) {
      pm.expect(json).to.have.nested.property('error.code', expectedErrorCode);
    }
  }
});

Claves del enfoque:

• Las aserciones se “mueven” con los datos: no duplicas requests por caso.
• El caseId aparece en el nombre del test, facilitando diagnóstico en Runner.
• Normalizas tipos para evitar falsos negativos (muy común con CSV).

Paso 3: cargar el archivo de datos en Runner

1. Abre Runner para la carpeta o colección.
2. En Data, selecciona cases.csv o cases.json.
3. Verifica que el Runner muestre el número de iteraciones basado en el archivo (si aplica).
4. Ejecuta con Run.

Si quieres ejecutar solo un subconjunto de casos, crea un archivo reducido (por ejemplo, cases_smoke.csv) o filtra previamente en tu fuente de datos.

Interpretar resultados del Runner y aislar fallos

Cómo leer el reporte

El Runner suele mostrar:

• Iteración: número de corrida (o fila del archivo de datos).
• Request: nombre del request ejecutado.
• Tests: cuántos pasaron/fallaron.
• Tiempo: duración por request y total.

Para diagnóstico rápido:

• Ordena mentalmente por primera falla: si un request de setup falla, muchas fallas posteriores pueden ser cascada.
• Usa el caseId en el nombre de los tests para ubicar la fila exacta del dataset.
• Abre el detalle del request fallido y revisa: status, body, headers y el resultado de cada test.

Aislar tests fallidos con mínima fricción

• Ejecuta solo la carpeta donde ocurre el fallo (en lugar de toda la colección).
• Reduce el dataset a la(s) fila(s) problemática(s) (por ejemplo, deja solo L02).
• Repite con una sola iteración para depurar sin ruido.
• Agrega trazas controladas en tests (por ejemplo, incluir caseId y valores esperados en el nombre del test).

Optimización de tiempos en ejecuciones automatizadas

1) Deshabilitar requests no necesarios

Si tu suite tiene requests auxiliares (documentación, exploración, endpoints no críticos), desactívalos temporalmente para el Runner. Mantén una carpeta “Smoke” con lo mínimo indispensable y otra “Full” para regresión.

2) Agrupar por carpetas para ejecución selectiva

Estructura recomendada:

• 00-Setup (si aplica)
• 10-Smoke
• 20-Feature-A
• 30-Feature-B
• 90-Teardown (si aplica)

Esto permite ejecutar por bloques y reducir el tiempo de feedback en QA y CI.

3) Reutilizar pre-scripts para evitar duplicación

Cuando varios requests comparten preparación (por ejemplo, construir headers, calcular timestamps, generar correlación), centraliza esa lógica en un punto común para que sea más fácil de mantener y más rápida de ejecutar.

• Coloca lógica común en el nivel más alto aplicable (colección o carpeta) para que herede a los requests.
• Evita cálculos costosos repetidos en cada request si puedes calcular una vez por iteración y guardar en variables.

Ejemplo: generar un correlationId una vez por iteración y reutilizarlo en todos los requests del flujo:

// En un pre-script a nivel carpeta/colección
if (!pm.variables.get('correlationId')) {
  pm.variables.set('correlationId', `corr-${Date.now()}-${pm.info.iteration}`);
}

Luego en headers de cada request:

X-Correlation-Id: {{correlationId}}

4) Evitar trabajo innecesario por iteración

• Si un token o configuración puede reutilizarse durante una iteración, evita regenerarlo en cada request.
• Si un request de setup es idéntico para todas las filas, considera ejecutarlo una sola vez fuera del dataset (por ejemplo, en una carpeta previa sin data file) y luego correr la carpeta parametrizada.
• Si hay endpoints lentos, sepáralos en una carpeta “lenta” para no bloquear el feedback rápido.

Ejemplo completo: tabla de entradas/salidas esperadas y cómo mapearla al dataset

Una forma práctica de diseñar data-driven testing es partir de una matriz (puede vivir en una hoja de cálculo) y luego exportarla a CSV/JSON.

Mapeo directo al archivo de datos:

• Columnas de entrada se usan en el body/headers con {{email}}, {{password}}.
• Columnas de salida esperada se usan en tests con pm.iterationData.get(...).
• caseId se usa para nombrar tests y rastrear fallos en Runner.