---
title: "Tipos de escenarios k6 explicados con ejemplos prácticos"
description: "Entiende los tipos de escenario k6 principales, las métricas que importan y cómo Performate ayuda a equipos a comparar escenarios más rápido."
publishDate: "2026-05-09"
draft: false
coverImage: "/images/performate-k6-test-types-overview.png"
coverImageAlt: "Interfaz de Performate mostrando varios tipos de escenario k6 para pruebas de carga"
keyword: "tipos escenarios k6"
intent: "MOFU"
cta: "Arma y compara tipos de escenario k6 más rápido con la configuración visual de escenarios de Performate."
tags: ["k6", "escenarios", "performance-testing"]
translationOf: k6-scenario-types-explained
---

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](https://k6.io/docs/using-k6/scenarios/executors/)). 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](/es/blog/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](/es/blog/k6-ejecutores-ramping-arrival-rate) cuando prod mide req/s, y con [think time](/es/blog/k6-think-time-concurrencia) cuando modelas sesiones. Los umbrales deben variar por tipo—no copies SLO de load en smoke ([ejemplos de umbrales](/es/blog/ejemplos-umbrales-k6)).

## 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 o en 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`?

```javascript
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](/es/blog/pruebas-de-carga-en-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):**

```bash
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

| Escenario | Objetivo principal | Executor típico | Riesgo validado |
|:---|:---|:---|:---|
| Smoke | Chequeo de salud rápido | `shared-iterations`, pocos VU | Regresión básica, wiring roto |
| Carga | Confianza en demanda normal | `constant-arrival-rate` | SLO bajo tráfico esperado |
| Soak | Estabilidad a largo plazo | Arrival rate moderado, horas | Leaks, deriva de latencia, pools |
| Stress | Encontrar límite | Rampa hasta fallo | Punto de quiebre, degradación |
| Spike | Resiliencia a ráfaga | `ramping-arrival-rate` abrupto | Autoscaling, colas, recovery |

**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](/es/blog/p95-vs-p99-latencia)).
- [ ] 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](/es/blog/revision-salud-escenarios-k6-trimestral)).

## 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 capacidad.
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](/es/blog/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](https://performate.app) | [Guides](/guides) | [Read k6 scenarios docs](https://k6.io/docs/using-k6/scenarios/)