4. Los tipos: smoke, load, stress, spike, soak

Descripción

"Prueba de carga" no es una sola cosa. Según qué pregunta quieras responder, le das al sistema una forma de tráfico distinta, y cada forma tiene nombre. Hay cinco que forman el vocabulario estándar de la industria, y saber cuál usar es la mitad de diseñar una prueba útil. Smoke: ¿el sistema siquiera funciona bajo una carga mínima? Load: ¿aguanta la carga que esperas en un día normal? Stress: ¿dónde está su límite —el punto de quiebre—? Spike: ¿sobrevive a un pico súbito y brutal de tráfico? Soak (o endurance): ¿se degrada cuando lo sometes a carga sostenida durante horas —fugas de memoria, conexiones que no se liberan—? Cada uno responde una pregunta que los otros no, y cada uno es un perfil de carga distinto: una manera de subir, sostener y bajar el número de usuarios en el tiempo. En esta lección los recorremos uno por uno, con su pregunta, su forma y para qué sirve —y establecemos la regla de oro: siempre se empieza por el smoke.

Conexión con el módulo: esta lección conecta las tres preguntas de la lección 3 con las herramientas concretas. La pregunta de "punto de quiebre" se responde con un stress test; la de "capacidad esperada" con un load test; y aparecen dos preguntas nuevas (picos súbitos, degradación a lo largo del tiempo) que traen el spike y el soak. Aquí describimos la forma de cada tipo a nivel conceptual; darle esa forma con código —los stages, las rampas, los executors de k6— es el módulo 4 completo. Piensa en esta lección como el catálogo: qué existe y para qué, antes de aprender a construir cada uno.

Cinco maneras de probar un puente

Volvamos al ingeniero de puentes de la lección 2, porque sus pruebas se corresponden una a una con los cinco tipos.

Antes de nada, hace una prueba de humo: manda un solo auto a cruzar, despacio. No busca estresar nada; busca confirmar que el puente está abierto, que no hay un agujero evidente, que se puede pasar. Si el puente se cae con un auto, no tiene sentido traer los camiones. Eso es el smoke test.

Luego, la prueba de carga normal: pone sobre el puente el tráfico de una hora pico típica —la cantidad de vehículos que de verdad va a soportar cada día— y mide cuánto se flexiona. ¿Cumple con el tráfico esperado sin deformarse de más? Eso es el load test.

Después, la prueba de estrés: sigue añadiendo camiones, más y más, mucho más allá del tráfico normal, hasta encontrar el punto donde la estructura empieza a ceder. No espera pasar ese punto en la vida real; quiere conocerlo, para saber cuánto margen tiene. Eso es el stress test.

Luego, la prueba de pico: en vez de subir el peso poco a poco, deja caer de golpe cincuenta camiones en dos segundos —como si un semáforo soltara toda una fila a la vez— y mira si el puente absorbe el golpe o se resiente. Eso es el spike test.

Y por último, la prueba de resistencia: pone una carga moderada, la del tráfico normal, y la deja ahí veinticuatro horas seguidas, vigilando si algo se va aflojando con el tiempo —un tornillo que vibra suelto, una junta que se fatiga— que jamás aparecería en una prueba de diez minutos. Eso es el soak test.

Un ingeniero serio hace los cinco, porque cada uno revela un fallo que los otros no verían. Tu API es igual.

Los cinco tipos, uno por uno

Smoke: ¿funciona con carga mínima?

El smoke test (prueba de humo) usa una carga diminuta —uno o pocos usuarios, unos segundos— y su única meta es confirmar que el sistema responde y no está roto antes de gastar tiempo en pruebas grandes. Su nombre viene de la electrónica: enchufas el aparato y ves si "echa humo". No mide rendimiento en serio; verifica que el script de prueba es correcto y que la API está viva y devuelve lo esperado.

Qué esperar — un smoke contra Reservo son unas pocas peticiones que confirman que la API responde y devuelve el número-ancla correcto. Salida real del generador con 5 peticiones y 1 concurrente:

$ python3.14 load_generator.py http://127.0.0.1:PORT 5 1
peticiones .......... 5 (concurrencia 1)
todas devolvieron ... price_cents=7500 (correcto: True)
duracion total ...... 0.009 s
throughput .......... 554.4 req/s
latencia min ........ 0.34 ms
latencia promedio ... 1.73 ms
latencia max ........ 7.09 ms
latencia p95 ........ 7.09 ms

No mires los números de rendimiento (con 5 peticiones no significan nada); mira correcto: True. El smoke confirmó dos cosas: la API está viva y responde el 7500 esperado. Regla de oro: siempre se empieza por el smoke. Si tu smoke falla, ninguna prueba mayor tiene sentido —arreglas el script o la API primero—. Correr un stress de 1000 VUs cuando ni siquiera un usuario obtiene una respuesta correcta es tirar tiempo.

Load: ¿aguanta la carga esperada?

El load test es el tipo por defecto, el que la gente imagina cuando dice "prueba de carga". Somete al sistema a la carga que esperas en operación normal o en un pico razonable previsible —por ejemplo, "300 usuarios concurrentes, que es nuestro martes por la tarde típico"— y verifica que cumple tus objetivos de latencia y error bajo esa carga. Responde: ¿el sistema hace su trabajo, a tiempo, con la demanda real? Su perfil típico es una rampa de subida, un tramo sostenido en la carga objetivo, y una rampa de bajada. Es la prueba que confirma que estás listo para un día normal.

Stress: ¿dónde está el límite?

El stress test empuja al sistema más allá de su carga esperada, subiendo la concurrencia de forma sostenida hasta que algo cede: la latencia se dispara de forma no lineal o la tasa de error deja de ser cero. Responde la tercera pregunta de la lección 3: ¿dónde está el punto de quiebre? Su perfil es una rampa que sigue subiendo por escalones, cada vez más alto, observando en qué peldaño el p95 se descontrola. No esperas operar ahí; quieres conocer tu límite para saber cuánto margen tienes y cómo se comporta el sistema cuando se satura (¿degrada con elegancia, rechazando peticiones limpiamente, o colapsa con errores feos?).

Spike: ¿sobrevive a un pico súbito?

El spike test es un stress con una diferencia crucial: la carga no sube gradualmente, sino de golpe. Se pasa de casi nada a una carga altísima en segundos, se mantiene un momento, y se corta. Simula eventos reales y brutales: una campaña que sale al aire, una mención viral, la apertura de venta de entradas, un anuncio en la Super Bowl. Responde: ¿el sistema absorbe un golpe súbito o se cae? —y también ¿se recupera cuando el pico pasa, o queda tumbado?—. Un sistema puede aguantar 1000 usuarios si llega a ellos en diez minutos (load/stress) y aun así caerse si esos 1000 llegan en diez segundos (spike), porque no tuvo tiempo de escalar recursos ni de vaciar colas.

Soak: ¿se degrada con horas de carga sostenida?

El soak test (o endurance, resistencia) aplica una carga moderada —normalmente la esperada, no la extrema— pero durante mucho tiempo: horas, a veces un día entero. Su objetivo no es el pico sino la duración, porque hay fallos que solo se manifiestan con el tiempo: fugas de memoria (la memoria usada crece y crece hasta que el proceso muere), conexiones a la base de datos que no se devuelven al pool y se agotan, archivos de log que llenan el disco, cachés que crecen sin límite. Responde: ¿el sistema se mantiene estable bajo carga sostenida, o se degrada lentamente hasta fallar? Un sistema puede pasar un load test de diez minutos con sobresaliente y morir a las tres horas por una fuga que en diez minutos era invisible.

El cuadro resumen

Tipo	Pregunta que responde	Forma de la carga	Cuándo lo usas
Smoke	¿Funciona con carga mínima?	Diminuta (1-2 usuarios, segundos)	Siempre primero; validar script y salud básica
Load	¿Aguanta la carga esperada?	Rampa → sostener en la carga objetivo → rampa de bajada	Verificar que cumples tus objetivos en un día normal
Stress	¿Dónde está el punto de quiebre?	Rampa creciente por escalones, más allá de lo normal	Conocer tu límite y tu margen
Spike	¿Sobrevive a un pico súbito?	Salto brusco a carga alta, breve, y corte	Preparar campañas, virales, aperturas de venta
Soak	¿Se degrada con horas de carga?	Carga moderada sostenida durante horas	Cazar fugas de memoria/conexiones y degradación lenta

Léelo como un árbol de decisión: si nunca probaste, smoke. Si quieres saber si aguantas tu tráfico real, load. Si quieres saber tu techo, stress. Si temes un pico repentino, spike. Si temes que algo se pudra con el tiempo, soak. La mayoría de los equipos vive con smoke + load como rutina, y saca el stress, el spike y el soak cuando la pregunta lo pide.

Un mismo blanco, cinco pruebas

Fíjate en que los cinco tipos golpean la misma API (Reservo, o la tuya) y usan las mismas métricas (latencia p95, throughput, tasa de error, de la lección 3). Lo único que cambia entre ellos es el perfil de carga: cuántos usuarios, cómo suben, cuánto se sostienen, cuánto dura todo. Un smoke y un soak pueden usar el mismísimo script de k6 (la misma función que hace /quote); lo que los distingue es la configuración de stages/duration/vus —la forma—. Por eso, cuando en el módulo 4 aprendas a escribir perfiles de carga (rampas, escalones, picos), estarás aprendiendo a construir cualquiera de estos cinco tipos con solo cambiar unos números. El vocabulario de esta lección es el catálogo; el módulo 4 es la fábrica.

Errores comunes

Saltarse el smoke y lanzar directo un stress de mil usuarios. Qué pasa: alguien configura una prueba enorme, la corre media hora, y descubre al final que el script tenía un error (la URL estaba mal, el cuerpo JSON malformado) y todas las peticiones fallaron —no por el sistema, por la prueba—. Por qué pasa: la emoción de "probar en serio" salta el paso aburrido. Cómo detectarlo: si tu primera prueba de un script nuevo es grande, te falta el smoke. Cómo corregirlo: siempre corre primero un smoke de 1-2 usuarios; confirma que el script funciona y la API responde correcto, y solo entonces escala.

Confundir spike con stress porque "los dos usan mucha carga". Qué pasa: alguien quiere probar una campaña viral (un pico súbito) pero configura una rampa lenta y gradual, y concluye "aguanta" —cuando en la vida real el tráfico habría llegado de golpe y lo habría tumbado—. Por qué pasa: ambos llegan a carga alta, y la diferencia (gradual vs súbito) parece un detalle. Pero cómo llega la carga es justo lo que el spike prueba. Cómo detectarlo: si tu prueba de "pico" sube en minutos en vez de segundos, no es un spike. Cómo corregirlo: para simular un pico, la carga debe saltar casi instantáneamente; es un perfil distinto (módulo 4).

Creer que un load test de 10 minutos descarta las fugas de memoria. Qué pasa: el load test pasa perfecto, se declara el sistema estable, y en producción el proceso muere cada seis horas por una fuga. Por qué pasa: una fuga lenta es invisible en diez minutos; solo emerge con el tiempo. Cómo detectarlo: si tu preocupación es "¿se degrada con el uso prolongado?" y tu prueba dura minutos, estás mirando el fenómeno equivocado. Cómo corregirlo: eso lo caza un soak test de horas, vigilando el uso de memoria/conexiones a lo largo del tiempo, no la latencia de un rato.

Ejercicios

Ejercicio 1 — Elige el tipo. Para cada objetivo, di qué tipo de prueba (smoke, load, stress, spike, soak) lo cumple. (a) "Antes de la prueba grande, confirmar que mi script de k6 y la API funcionan." (b) "Saber a partir de cuántos usuarios concurrentes la latencia de Reservo se descontrola." (c) "Comprobar que el servidor no se cae si mañana nos mencionan en las noticias y llega un aluvión en segundos." (d) "Verificar que Reservo aguanta los 300 concurrentes de un martes normal cumpliendo el p95." (e) "Detectar si el proceso pierde memoria tras ocho horas de tráfico continuo."

Ver solución

• (a) Smoke. Validar script + salud básica con carga mínima, antes de escalar.
• (b) Stress. Buscar el punto de quiebre subiendo la carga hasta que la latencia cede.
• (c) Spike. Un aluvión súbito en segundos: el perfil de salto brusco.
• (d) Load. La carga esperada de operación normal, verificando los objetivos.
• (e) Soak. Fuga de memoria que solo aparece con carga sostenida durante horas.

Ejercicio 2 — Mismo script, distinta forma. Explica en dos o tres frases por qué un smoke test y un soak test pueden usar exactamente el mismo script de k6 (la misma función que golpea /quote) y aun así ser pruebas distintas. ¿Qué es lo único que cambia entre ellos?

Ver solución

Lo que hace cada petición (llamar a /quote, verificar el 7500) es idéntico en ambos: la misma función del VU, el mismo endpoint, la misma métrica. Lo único que cambia es el perfil de carga —la configuración de cuántos usuarios y por cuánto tiempo—: el smoke usa 1-2 usuarios durante segundos; el soak usa una carga moderada durante horas. La forma de la carga (número de VUs y duración), no el trabajo de cada petición, es lo que convierte el mismo script en un tipo de prueba u otro. (Construir esas formas es el módulo 4.)

Ejercicio 3 — El orden de una campaña. Tu equipo va a lanzar una promoción de Black Friday en Reservo. Diseña, en orden, qué secuencia de tipos de prueba correrías antes del lanzamiento y por qué cada uno, en una frase.

Ver solución

Una secuencia razonable:

1. Smoke — primero de todo: confirmar que el script y la API responden correcto con carga mínima; si esto falla, nada más tiene sentido.
2. Load — verificar que Reservo aguanta la carga esperada del Black Friday (p. ej. 1000 concurrentes) cumpliendo el objetivo de p95 y error.
3. Stress — empujar más allá de lo esperado para conocer el punto de quiebre y saber cuánto margen tenemos si la estimación se queda corta.
4. Spike — simular el golpe súbito del minuto en que sale la promoción, cuando todos entran a la vez, y ver si el sistema absorbe y se recupera.
5. Soak (si la promo dura muchas horas) — sostener la carga durante horas para descartar fugas de memoria que tumben el sistema a mitad del evento.

Lo importante es el patrón: se empieza por el smoke, se sube al load, y se saca stress/spike/soak según los riesgos concretos del evento.

Resumen y siguiente paso

En esta lección recorriste los cinco tipos de prueba de carga y la pregunta que responde cada uno: smoke (¿funciona con carga mínima? — siempre primero), load (¿aguanta la carga esperada?), stress (¿dónde está el punto de quiebre?), spike (¿sobrevive a un pico súbito?) y soak (¿se degrada con horas de carga sostenida?). Los viste con el ingeniero de puentes —un auto de prueba, el tráfico normal, más y más camiones, un golpe súbito, veinticuatro horas seguidas— y confirmaste la regla de oro: se empieza siempre por el smoke, como el generador de 5 peticiones que solo confirmó que Reservo está viva y devuelve 7500.

La idea que se lleva la lección es que los cinco golpean la misma API con las mismas métricas; lo único que cambia es la forma de la carga —cuántos usuarios, cómo suben, cuánto duran—. Ese perfil de carga es lo que convierte un mismo script en un tipo de prueba u otro.

Antes de avanzar deberías poder: nombrar los cinco tipos y su pregunta; explicar por qué el smoke va primero; distinguir un stress (subida gradual hasta el límite) de un spike (salto súbito); y decir qué caza un soak que un load de diez minutos no vería.

Lo que sigue es conocer la herramienta con la que se construyen estas pruebas en la industria. En la lección 5 entra k6: qué es, por qué sus scripts se escriben en JavaScript pero corren en un runtime propio (no en Node), y qué implica eso para cómo se escriben y por qué en esta guía van como contenido.

Recursos

• k6 — Tipos de prueba de carga (smoke, load, stress, spike, soak) — la referencia oficial que define los cinco tipos con sus perfiles; la fuente directa de esta lección.
• k6 — Smoke testing — el detalle del tipo con el que siempre se empieza; útil de cara al módulo 4.
• Google SRE — Addressing Cascading Failures — por qué los sistemas colapsan bajo picos y sobrecarga, el fenómeno que buscan el stress y el spike.
• k6 — Load test types (perfiles con stages) — adelanto de cómo se construye la forma de cada tipo con escenarios y stages; el corazón del módulo 4.