Stress test vs prueba de carga vs spike test: cuándo usar cada una

Muchos equipos etiquetan cada corrida como «prueba de carga» cuando en realidad preguntan tres cosas distintas: ¿estamos bien con tráfico esperado? ¿dónde rompemos? ¿sobrevivimos a un salto brusco? Mezclar preguntas genera falsa confianza, malas decisiones de release y pipelines de CI tan pesados que alguien desactiva el único gate que tenías.

Carga, stress y spike difieren en forma de tráfico y riesgo validado—no en herramienta. En k6 expresas la forma con executors de escenario (constant-arrival-rate, ramping-vus, stages agudos en ramping-arrival-rate). Esta guía mapea riesgos de negocio a executors, da un script con tres perfiles y muestra cómo comparar sin tres repos.

Si armas tu primer flujo, empieza con Postman a k6 paso a paso.

Por qué el tipo de prueba debe coincidir con el riesgo

Cada tipo responde una pregunta distinta; usar el incorrecto desperdicia tiempo de staging y confunde stakeholders:

• Carga – demanda esperada sostenida; valida SLOs, regresiones y «¿somos rápidos un martes normal?»
• Stress – sobrecarga deliberada; encuentra puntos de quiebre, curvas de error y recuperación tras bajar la rampa.
• Spike – escalón abrupto; valida autoscaling, caminos fríos (serverless), absorción de colas y arranques de caché fría.

Solo carga antes de un flash sale omite modos de fallo por ráfaga. Solo stress en cada PR agota CI y desensibiliza al equipo ante umbrales rojos. Spike cuando necesitas prueba de SLO estable crea incidentes innecesarios en staging compartido.

Métricas clave por tipo

Combina con p95 vs p99 para stakeholders—los spike suelen reventar p99 primero mientras p95 parece aceptable.

k6 práctico: un script, tres executors

Ejemplo (ilustrativo—no listo para producción). Selecciona con TEST_TYPE.

Qué demuestra este ejemplo:

• Carga: constant-arrival-rate estable al RPS de negocio—modelo abierto alinea con lenguaje «pedidos por minuto».
• Stress: ramping-vus más allá del pico documentado—modelo cerrado explora colapso por concurrencia.
• Spike: stage agudo en ramping-arrival-rate (5 → 120 req/s)—cambio de escalón en segundos, no minutos.
• Checks y tags de ruta compartidos; umbrales distintos por perfil—stress puede permitir mayor tasa de error por diseño.

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

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

const configs = {
  load: {
    scenarios: {
      load: {
        executor: 'constant-arrival-rate',
        rate: 40,
        timeUnit: '1s',
        duration: '10m',
        preAllocatedVUs: 30,
        maxVUs: 120,
        tags: { test_type: 'load' },
      },
    },
    thresholds: {
      'http_req_duration{test_type:load}': ['p(95)<700', 'p(99)<1000'],
      http_req_failed: ['rate<0.01'],
    },
  },
  stress: {
    scenarios: {
      stress: {
        executor: 'ramping-vus',
        startVUs: 10,
        stages: [
          { duration: '5m', target: 100 },
          { duration: '5m', target: 200 },
          { duration: '3m', target: 0 },
        ],
        tags: { test_type: 'stress' },
      },
    },
    thresholds: { http_req_failed: ['rate<0.1'] },
  },
  spike: {
    scenarios: {
      spike: {
        executor: 'ramping-arrival-rate',
        startRate: 5,
        timeUnit: '1s',
        preAllocatedVUs: 50,
        maxVUs: 300,
        stages: [
          { duration: '1m', target: 5 },
          { duration: '30s', target: 120 },
          { duration: '3m', target: 120 },
          { duration: '1m', target: 5 },
        ],
        tags: { test_type: 'spike' },
      },
    },
    thresholds: { http_req_failed: ['rate<0.05'] },
  },
};

export const options = configs[type] || configs.load;

export default function () {
  const res = http.get(`${BASE}/api/orders`, {
    tags: { route: 'orders', test_type: type },
  });
  check(res, { ok: (r) => r.status < 500 });
  sleep(type === 'spike' ? 0.1 : 0.5);
}

Patrones que funcionan

• Un catálogo de requests, tres perfiles de executor—Performate clona escenarios sin duplicar imports de Postman.
• Carga en CI nocturno, spike manual pre-lanzamiento (capas CI).
• Documenta criterios de abort para stress/spike—staging compartido necesita owner del kill switch.
• Archiva exports por test_type—revisión trimestral compara baselines de carga separados de exploraciones stress.

Anti-patrones a evitar

• Llamar stress a una rampa de un minuto cuando producto preguntó por spike de flash sale.
• Think time cero en pruebas de carga—RPS falso (sanity VUs).
• Spike sin monitorizar eventos de autoscale—ves errores, no causa.
• Stress en cada merge—pipeline desactivado en semanas.

Pro tip (comando de ejemplo): corre perfiles en local antes de reservar ventanas de staging.

k6 run orders-profiles.js --env TEST_TYPE=spike --summary-trend-stats="p(95),p(99)"

Qué demuestra este comando: el perfil spike reproduce el cambio de escalón en minutos en local—valida script antes de reservar on-call de platform para el ensayo completo.

Marco de decisión

Regla rápida: demanda predecible → carga; mapa de fallos → stress; salto súbito → spike.

Usa carga cuando las revisiones de error budget necesitan «mismo RPS que el mes pasado, ¿regresamos?»

Usa stress cuando finanzas pregunta «¿cuánto margen antes de gastar en nodos más grandes?»

Usa spike cuando marketing anuncia «10x tráfico en cinco minutos»—no cuando validas tráfico de martes por la tarde.

Observabilidad y checklist pre-corrida

• Auth y datos de prueba realistas (datos GDPR).
• Escrituras idempotentes o aisladas—stress/spike multiplican duplicados.
• Umbrales ligados a SLOs de negocio para carga; límites exploratorios documentados para stress/spike.
• APM activo para correlacionar ventana k6 con infra—autoscale, conexiones DB, profundidad de cola.
• Programa spikes cuando on-call pueda abortar (ops soak/spike).
• Notas de fidelidad de staging en reportes (staging vs prod).

Cómo Performate corre carga, stress y spike en paralelo

Abajo hay un ejemplo concreto de flujo para perfiles de API de pedidos—adapta tasas a tu doc de SLO y calendario de lanzamiento.

Ejemplo: tres perfiles, un import

1. Importa colección de pedidos/checkout una vez—requests se convierten en catálogo compartido. Problema resuelto: sin tres carpetas Postman que divergen.
2. Clona escenario a tres perfiles (carga/stress/spike) en UI—executors distintos, requests idénticos. Problema resuelto: comparas resultados con fairness—mismos payloads, forma distinta.
3. Ajusta perfil de carga primero hasta umbrales verdes tres corridas—establece baseline. Problema resuelto: exploraciones stress/spike referencian estado estable conocido.
4. Corre carga, stress, spike secuencialmente en staging; compara panel (vista métricas). Problema resuelto: revisión de release muestra tres respuestas, no un gráfico ambiguo.
5. Exporta tres reportes con filtros test_type para revisión de release. Problema resuelto: liderazgo ve riesgo spike separado de SLO diario de carga.
6. Promueve solo perfil de carga a CI smoke/carga—spike queda manual. Problema resuelto: gates de merge rápidos sin costo diario de stress.

Ese flujo encaja con el cta de este post: correr carga, stress y spike lado a lado y comparar resultados desde un workspace.

Cierre

La pregunta no es cuál prueba es «mejor»—es qué riesgo validas hoy. Usa carga, stress y spike como lentes complementarios; un catálogo de requests, executors distintos, evidencia archivada por tipo.

Si el riesgo de mañana es un escalón de tráfico, agenda un spike—not otra corrida de carga estable.

Try Performate free | Guides | Escenarios k6