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 oSharedArraypara 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 comohttp_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:onboardingreflejan nombre de carpeta Postman para reportes y filtros de stakeholders. constant-vuspara primera corrida—cambia aconstant-arrival-ratecuando 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_BASEde 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-vusporque 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
- Exporta colección; anota auth y dependencias de datos por carpeta.
- Importa a k6 (herramienta o Performate)—URLs a
__ENV.API_BASE. - Corre smoke 1 VU; arregla TLS/env.
- Añade think time desde logs o mediana de analytics.
- Elige executor según tu pregunta; añade un umbral ligado a un SLO.
- Exporta script para CI cuando umbrales pasen en local (pipeline smoke/carga).
Marco de decisión: executor para primera migración
| Objetivo | Empezar con | Pasar a cuando |
|---|---|---|
| Validar corrección del script | per-vu-iterations, 1–5 VUs | Cableado verde |
| Concurrencia esperada | constant-vus | Producto habla en «usuarios concurrentes» |
| RPS de negocio | constant-arrival-rate | Analytics da pedidos/min o req/s |
| Punto de quiebre después | ramping-vus stress | Tras 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
- Importa colección—requests aparecen agrupados por carpeta Postman. Problema resuelto: evita transcripción manual y requests olvidados en carpetas anidadas.
- Mapea entornos a perfiles Performate—
API_BASE, credenciales de servicio, defaults de think time. Problema resuelto: sin deriva de.enventre compañeros ni secretos de «funciona en mi máquina». - 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.
- 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.
- Añade umbrales cuando
p95sea estable en tres corridas—firma de producto en una línea. Problema resuelto: disciplina de gate antes de promoción a CI. - 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.