---
title: "Stress test vs prueba de carga vs spike test: cuándo usar cada una"
description: "Aprende cuándo correr pruebas de carga, stress y spike, qué métricas seguir y cómo ejecutar cada escenario más rápido con Performate."
publishDate: "2026-05-07"
draft: false
coverImage: "/images/performate-test-execution-dashboard.png"
coverImageAlt: "Panel de ejecución de pruebas de carga comparando rendimiento de escenarios y métricas de respuesta"
keyword: "stress test vs prueba de carga"
intent: "TOFU"
cta: "Usa escenarios Performate para correr carga, stress y spike lado a lado y comparar resultados."
tags: ["pruebas-de-carga", "stress-testing", "spike-testing", "k6"]
translationOf: stress-vs-load-vs-spike-testing
---

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](https://k6.io/docs/using-k6/scenarios/executors/) (`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](/es/blog/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](/es/blog/pruebas-carga-cold-starts-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

| Tipo | Métricas principales | Señales secundarias |
|:---|:---|:---|
| Carga | `p95`/`p99`, tasa de error, throughput estable al RPS objetivo | Saturación, espera en pool (APM) |
| Stress | Tiempo al fallo, pendiente de curva de errores, recuperación tras ramp-down | RPS/VUs máximos antes de breach de SLO |
| Spike | Errores en transición, ventana de estabilización, requests caídos | Timing de eventos de autoscale, tasa de cold start |

Combina con [p95 vs p99](/es/blog/p95-vs-p99-latencia) 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.

```javascript
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](/es/blog/pipeline-ci-smoke-carga-stress)).
- **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](/es/blog/usuarios-virtuales-think-time-chequeos-ia)).
- 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.

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

| Pregunta de negocio | Tipo | Frecuencia típica |
|:---|:---|:---|
| ¿Cumplimos SLO en tráfico normal? | Carga | Por release / nocturno |
| ¿Techo de capacidad? | Stress | Pre-lanzamiento / cambio infra |
| ¿Ráfaga viral o flash sale? | Spike | Campañas / temporada |
| ¿Gate en cada PR? | Carga o smoke solo | Cada merge |
| ¿Validar cold path serverless? | Spike (idle luego escalón) | Antes de cambio de tráfico |

**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](/es/blog/datos-prueba-rendimiento-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](/es/blog/playbook-soak-testing-memory-leaks)).
- [ ] Notas de fidelidad de staging en reportes ([staging vs prod](/es/blog/pruebas-carga-staging-vs-produccion)).

## 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](/images/performate-test-execution-dashboard.png)). *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](/es/blog/pipeline-ci-smoke-carga-stress)—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—no otra corrida de carga estable.

[Try Performate free](https://performate.app) | [Guides](/guides) | [Escenarios k6](https://k6.io/docs/using-k6/scenarios/)