Tipos de escenarios k6 explicados con ejemplos prácticos

El informe del viernes mezcló un smoke de cinco minutos con una prueba de stress de dos horas en un solo PDF. Producto concluyó «pasamos»; el lunes un spike de tráfico tumba colas que solo aparecen bajo ráfagas. Nadie corrió el patrón equivocado por maldad—corrieron el patrón único que tenían a mano.

Elegir el tipo de escenario k6 correcto es la diferencia entre decisiones útiles y gráficos ruidosos. La mayoría de equipos no falla por «no correr pruebas»; falla por no hacer la pregunta de riesgo que cada forma de tráfico responde. En esta guía verás smoke, carga, soak, stress y spike con executors concretos, qué métricas importan en cada uno, y cómo mapear escenario → riesgo antes del próximo release.

Por qué el diseño de escenario cambia lo que aprendes—no solo la duración

k6 implementa patrones de tráfico mediante ejecutores dentro de scenarios (executor reference). A nivel de riesgo, cada tipo ejercita fallos distintos:

• Smoke — salud básica en minutos; detecta regresiones groseras, no capacidad.
• Carga (load) — tráfico esperado sostenido; valida SLO bajo demanda normal.
• Soak (endurance) — tráfico moderado por horas; expone leaks, deriva de latencia, pools agotados en el tiempo.
• Stress — empuja más allá de capacidad; encuentra punto de quiebre y calidad del modo de fallo.
• Spike — salto abrupto de tráfico; valida autoscaling, colas y recovery.

Correr solo una prueba genérica oculta cuellos que aparecen bajo una forma de tráfico. Para una lente de decisión por riesgo, lee también stress vs carga vs spike testing.

Cuando un smoke verde engaña sobre capacidad

CI verde con 5 VUs no implica que Black Friday aguante. Combina tipos de escenario con ejecutores arrival-rate cuando prod mide req/s, y con think time cuando modelas sesiones. Los umbrales deben variar por tipo—no copies SLO de load en smoke (ejemplos de umbrales).

Implementación práctica con k6: cuatro escenarios paralelos para comparar riesgos

Define smoke, load, spike y soak como escenarios separados en un solo script—or archivos distintos en CI—cada uno con executor y umbrales acordes a la pregunta.

Script de ejemplo (ilustrativo—no es una prueba lista para producción). El snippet usa URLs y duraciones acortadas para demo. Adapta rates, VUs y duraciones a tu entorno.

Qué demuestra este ejemplo:

• Smoke: shared-iterations bajo—¿responde la API?
• Load: constant-arrival-rate a tasa de prod—¿cumple SLO sostenido?
• Spike: stage abrupto en ramping-arrival-rate—¿sobrevive autoscaling?
• Soak: arrival rate moderado por duración larga—¿hay deriva de p99?

import http from 'k6/http';
import { check, sleep } from 'k6';

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

export const options = {
  scenarios: {
    smoke: {
      executor: 'shared-iterations',
      vus: 2,
      iterations: 20,
      maxDuration: '2m',
      exec: 'hitApi',
      tags: { scenario: 'smoke' },
    },
    load: {
      executor: 'constant-arrival-rate',
      rate: 30,
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 15,
      maxVUs: 60,
      exec: 'hitApi',
      startTime: '2m',
      tags: { scenario: 'load' },
    },
    spike: {
      executor: 'ramping-arrival-rate',
      startRate: 10,
      timeUnit: '1s',
      preAllocatedVUs: 20,
      maxVUs: 150,
      stages: [
        { duration: '30s', target: 10 },
        { duration: '10s', target: 120 },
        { duration: '1m', target: 120 },
        { duration: '30s', target: 10 },
      ],
      exec: 'hitApi',
      startTime: '8m',
      tags: { scenario: 'spike' },
    },
    soak: {
      executor: 'constant-arrival-rate',
      rate: 15,
      timeUnit: '1s',
      duration: '30m',
      preAllocatedVUs: 10,
      maxVUs: 40,
      exec: 'hitApi',
      startTime: '12m',
      tags: { scenario: 'soak' },
    },
  },
  thresholds: {
    'http_req_duration{scenario:smoke}': ['p(95)<500'],
    'http_req_duration{scenario:load}': ['p(95)<400', 'p(99)<800'],
    'http_req_duration{scenario:spike}': ['p(99)<2000'],
    'http_req_duration{scenario:soak}': ['p(99)<900'],
    http_req_failed: ['rate<0.02'],
  },
};

export function hitApi() {
  const res = http.get(`${BASE}/v1/health`, {
    headers: { Authorization: `Bearer ${__ENV.TOKEN}` },
    tags: { route: 'health' },
  });
  check(res, { '2xx': (r) => r.status >= 200 && r.status < 300 });
  sleep(0.1);
}

Patrones que funcionan

• startTime escalonado — corre smoke antes de load en el mismo k6 run sin mezclar métricas.
• Tags scenario:* — reportes y umbrales segmentados por tipo.
• Duraciones realistas — soak en horas en nightly, no en cada PR (CI/CD).
• Spike corto y brutal — mejor detectar colas que rampas suaves de 30 minutos.

Anti-patrones a evitar

• Presentar smoke como prueba de capacidad a stakeholders.
• Soak de 30 minutos con la misma tasa que stress—no es soak ni stress.
• Un solo umbral p(95)<400 para spike y smoke—contextos distintos, SLO distintos.

Tip pro (comando de ejemplo):

k6 run scenarios-multi.js --include-system-env-vars --summary-trend-stats="p(95),p(99)"

Qué demuestra este comando: percentiles por tag de escenario en el summary—compara smoke vs spike sin exportar a Grafana para una revisión rápida.

Marco de decisión: escenario → riesgo

Usa smoke si necesitas feedback en minutos en CI o pre-demo.

Usa load si validas SLO bajo tráfico que prod verá el próximo trimestre.

Usa soak si el incidente anterior fue memory leak o conexiones zombis tras horas.

Usa spike si lanzamientos, TV spots o webhooks en ráfaga son tu perfil de riesgo.

Observabilidad, documentación y siguientes pasos

Los escenarios solo sirven si el equipo sabe qué pregunta respondió cada uno. Antes del release review:

• Etiqueta cada corrida con scenario:* y archiva summary JSON por tipo.
• Define métricas de éxito antes de correr—p95, p99, error rate, throughput (p95 vs p99).
• Documenta qué escenarios corren en CI vs nightly vs pre-release manual.
• Correlaciona spike failures con métricas de autoscaling y colas en APM.
• Revisa trimestralmente si el mix de escenarios sigue alineado al perfil de riesgo del producto (revisión de salud).

Cómo Performate simplifica comparar tipos de escenario

Armar cuatro bloques options.scenarios a mano cada sprint no escala. Abajo hay un ejemplo concreto de flujo para la misma API /v1/health—adapta rates y duraciones a tu calendario de releases.

Ejemplo: smoke, load, spike y soak desde un workspace

1. Importa el request de health (o colección Postman completa). Problema resuelto: una fuente de requests para todos los tipos de escenario.
2. Crea escenario smoke—2 VU, 20 iteraciones, umbrales relajados de duración. Problema resuelto: gate CI en minutos sin confundir con capacity.
3. Duplica a load con arrival rate 30 req/s por 5 minutos y SLO de prod. Problema resuelto: mismo request, pregunta distinta, sin fork de script.
4. Añade spike con rampa abrupta a 120 req/s en el editor visual. Problema resuelto: validación de ráfaga sin editar stages en JS.
5. Programa soak nocturno—15 req/s por 30 minutos (o horas en runner dedicado). Problema resuelto: deriva de latencia visible en reporte integrado.
6. Compara reportes lado a lado y exporta scripts k6 por escenario para CI (pruebas de carga en CI/CD).

Ese flujo conecta directo con el cta de este post: armar y comparar tipos de escenario más rápido con configuración visual.

Cierre

No preguntes «¿qué escenario es el mejor?» Pregunta «¿qué escenario responde este riesgo?» y corre la prueba más pequeña que dé una decisión confiable.

Mapea tu próximo release a smoke + load como mínimo—y añade spike o soak si el postmortem del trimestre pasado lo justifica.

Try Performate free | Guides | Read k6 scenarios docs