Skip to main content
6 may 2026postman a k6

Por Performate

Cómo convertir colecciones Postman en pruebas de carga k6 (paso a paso)

Aprende un flujo confiable de migración Postman a k6, qué validar antes de escalar tráfico y cómo Performate acelera la ejecución.

Postman demuestra que tu API responde bien una vez. k6 demuestra que sobrevive concurrencia, think time y umbrales—pero muchos equipos se frenan en la migración: pre-request scripts, variables de colección y flujos encadenados no mapean 1:1 a JavaScript.

Esta guía paso a paso recorre import → forma del escenario → primera corrida significativa → promoción a CI. Verás qué corregir antes de escalar RPS, cómo preservar cadenas de auth, dónde va el think time y cómo un import en escritorio ahorra días frente a traducción manual. Al final tendrás un checklist repetible—no un script único que se pudre tras el segundo release.

Qué cambia al pasar de funcional a carga

Postman ejecuta requests en secuencia para un humano que pulsa Send. k6 modela usuarios virtuales con executors, sleeps y datos compartidos (escenarios). Ese cambio altera qué significa «pasar»:

  • Variables: vars de colección/entorno → __ENV, constantes a nivel módulo o SharedArray para archivos de datos—sin secretos duplicados en git.
  • Pestaña Tests: assertions de Postman → check() en k6—los umbrales son puertas globales aparte sobre métricas como http_req_duration.
  • Pre-request JS: suele ir a setup(), helpers o contexto init—revisa efectos secundarios (timestamps, IDs aleatorios) que rompen bajo concurrencia.
  • Carpetas: mapean a escenarios, tags o funciones exec—not siempre a repos separados.

Saltarse think time infla RPS falsos; revisa sanity de VUs antes de confiar en resultados. Saltarse cadenas de auth produce tormentas de 401 que parecen fallo del servidor.

Objetivo de migración: una corrida significativa, no hello world

Una primera corrida significativa tiene: base URL y secretos correctos, auth funcionando, al menos una ruta de negocio bajo carga, think time en el rango correcto y un umbral que producto reconoce. Todo lo demás—perfiles stress, tags multi-región—viene después de que esa baseline esté verde.

Conversión k6 paso a paso (con ejemplo)

Script de ejemplo (ilustrativo—no listo para producción). Flujo login + list migrado desde carpeta Postman onboarding.

Qué demuestra este ejemplo:

  • setup() hace login una vez por corrida y pasa token a los VUs—refleja auth a nivel colección en Postman sin re-login cada iteración cuando los tokens son long-lived.
  • Tags flow:onboarding reflejan nombre de carpeta Postman para reportes y filtros de stakeholders.
  • constant-vus para primera corrida—cambia a constant-arrival-rate cuando el comportamiento baseline esté claro.
  • Checks de estado y forma JSON—convertidos desde assertions de la pestaña Tests.
import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = __ENV.API_BASE || 'https://staging.example.com';

export function setup() {
  const login = http.post(`${BASE}/auth/login`, JSON.stringify({
    email: __ENV.SVC_EMAIL,
    password: __ENV.SVC_PASSWORD,
  }), { headers: { 'Content-Type': 'application/json' } });
  check(login, { 'login ok': (r) => r.status === 200 });
  return { token: login.json('accessToken') };
}

export const options = {
  scenarios: {
    onboarding: {
      executor: 'constant-vus',
      vus: Number(__ENV.VUS || 10),
      duration: '5m',
      tags: { flow: 'onboarding' },
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
    'http_req_duration{flow:onboarding}': ['p(95)<700'],
  },
};

export default function (data) {
  const headers = {
    Authorization: `Bearer ${data.token}`,
    'Content-Type': 'application/json',
  };
  const list = http.get(`${BASE}/items`, { headers, tags: { route: 'items', flow: 'onboarding' } });
  check(list, {
    'items 2xx': (r) => r.status === 200,
    'items no vacío': (r) => r.json('items').length > 0,
  });
  sleep(Number(__ENV.THINK_SEC || 1));
}

Patrones que funcionan

  • Exporta JSON de colección y anota dependencias de auth por carpeta antes de tocar sintaxis k6.
  • Resuelve URLs a __ENV.API_BASE de inmediato—hosts hardcodeados de staging sobreviven exactamente un rename de infra.
  • Corre smoke de 1 VU antes de diez VUs—arregla TLS, DNS y env en segundos.
  • Añade think time desde mediana de analytics—no cero porque k6 «se siente lento» con sleeps.
  • Elige executor según tu pregunta (stress vs carga vs spike)—no defaultees a ramping-vus porque suena impresionante.

Anti-patrones a evitar

  • Traducir cada pre-request script de Postman verbatim sin preguntar si corre por VU o una vez en setup().
  • Copiar credenciales de producción al repo «solo para probar rápido».
  • Declarar migración terminada tras corrida de 30 segundos sin umbrales.
  • Mantener Postman y k6 como fuentes de verdad divergentes sin historia de re-import.

Pro tip (comando de ejemplo): valida cableado de env antes de escalar VUs.

k6 run onboarding.js --vus 1 --duration 30s --env API_BASE=https://staging.example.com

Qué demuestra este comando: una corrida de treinta segundos con un VU expone errores de auth y env sin esperar cinco minutos ni inundar staging mientras depuras un typo en SVC_EMAIL.

Checklist de migración

  1. Exporta colección; anota auth y dependencias de datos por carpeta.
  2. Importa a k6 (herramienta o Performate)—URLs a __ENV.API_BASE.
  3. Corre smoke 1 VU; arregla TLS/env.
  4. Añade think time desde logs o mediana de analytics.
  5. Elige executor según tu pregunta; añade un umbral ligado a un SLO.
  6. Exporta script para CI cuando umbrales pasen en local (pipeline smoke/carga).

Marco de decisión: executor para primera migración

ObjetivoEmpezar conPasar a cuando
Validar corrección del scriptper-vu-iterations, 1–5 VUsCableado verde
Concurrencia esperadaconstant-vusProducto habla en «usuarios concurrentes»
RPS de negocioconstant-arrival-rateAnalytics da pedidos/min o req/s
Punto de quiebre despuésramping-vus stressTras carga baseline estable

Usa per-vu-iterations el día uno si el equipo nunca corrió k6 contra esta API—feedback de fallo más rápido.

Usa constant-arrival-rate cuando liderazgo pregunta «¿podemos con 500 checkouts por minuto?»—el modelo abierto coincide con lenguaje de negocio.

Diferir stress y spike hasta que el escenario de carga pase tres corridas consecutivas sin violaciones de umbral.

Observabilidad y validación antes de escalar

Los fallos de migración a menudo aparecen solo a RPS moderado—límites de pool de conexiones, rate limits o idempotencia faltante. Antes de invitar a QA a revisar:

  • Credenciales de staging, no prod (secretos k6).
  • IDs encadenados existen en data sintética (datos GDPR).
  • Tags de rutas = nombres de carpetas Postman para continuidad de reporte.
  • Archiva primer run verde con commit SHA y nombre de perfil de env.
  • Documenta brechas de fidelidad vs producción (staging vs prod).
  • Verifica que rutas de escritura sean idempotentes o aisladas si reruns comparten cuentas de prueba.

Cómo Performate acelera Postman → k6

Abajo un ejemplo de flujo concreto para el flujo onboarding anterior—adapta nombres de carpeta a tu colección.

Ejemplo: colección a script listo para CI en una sesión de escritorio

  1. Importa colección—requests aparecen agrupados por carpeta Postman. Problema resuelto: evita transcripción manual y requests olvidados en carpetas anidadas.
  2. Mapea entornos a perfiles Performate—API_BASE, credenciales de servicio, defaults de think time. Problema resuelto: sin deriva de .env entre compañeros ni secretos de «funciona en mi máquina».
  3. Genera k6 con un escenario por carpeta o flujo unificado—tú eliges radio de impacto. Problema resuelto: carpeta onboarding puede salir antes de que checkout esté lista.
  4. Corre smoke en escritorio; edita think time visualmente desde notas de analytics. Problema resuelto: más rápido que bucles editar-correr-parsear CLI en la semana uno de migración.
  5. Añade umbrales cuando p95 sea estable en tres corridas—firma de producto en una línea. Problema resuelto: disciplina de gate antes de promoción a CI.
  6. Exporta al repo para pipeline CI—mismo script que validó el escritorio. Problema resuelto: gates de merge coinciden con evidencia local.

Ese flujo mapea directamente al cta de este post: convertir tu colección Postman en prueba k6 ejecutable en minutos—no días de traducción manual.

Cierre

Postman → k6 es migración de flujo: variables, auth, checks, luego executors—no un export único. Importa, smoke con pocos VUs, think time realista, después escala arrival rate—no al revés.

Convierte esta semana tu carpeta Postman más ruidosa, corre diez VUs cinco minutos y recién ahí pide a QA el reporte exportado.

Try Performate free | Book a demo | Flujo escritorio Postman → k6

¿Listo para optimizar el rendimiento de tu API?

Descarga Performate y convierte tu colección Postman en una prueba k6 ejecutable en minutos.

← Volver a todas las entradas