¿Qué es load testing?

¿Qué es load testing?

Load testing es la práctica de simular tráfico de usuarios realista contra una web, API o servicio y medir cómo el sistema se comporta bajo esa carga. El objetivo es verificación: tienes una previsión de tráfico (peak de Black Friday, una campaña de launch day, el pico diario de las 9 a.m.) y quieres saber si tu infraestructura puede manejarla antes de que lo hagan usuarios reales.

Un load test típicamente rampa usuarios virtuales (VUs) hasta una concurrencia objetivo, los mantiene en ese nivel durante un periodo sostenido y registra las métricas que importan: tiempos de respuesta, throughput, error rate. Si esas métricas se mantienen dentro de tu performance budget (tus service-level objectives, o SLOs), el test pasa.

Por qué importa el load testing

Sin load testing, cada release es una apuesta. La primera vez que descubres que tu flujo de checkout no aguanta 5.000 compradores concurrentes es el momento en que tus clientes no pueden comprar. Load testing convierte esa apuesta en evidencia.

Específicamente, un load test responde:

• ¿Cumplirá el sistema mis SLOs al tráfico peak esperado? Si tu SLO es "p95 latency bajo 1 segundo" y el load test muestra p95 subiendo a 3 segundos en peak, tienes una decisión arreglar-o-posponer antes del launch, no durante.
• ¿Dónde empieza a degradarse la latencia? El response time suele escalar linealmente con la concurrencia hasta cierto punto, después sube bruscamente. Conocer ese codo te dice tu techo real de capacidad.
• ¿Cuál es el error rate a la carga objetivo? Un p95 que pinta perfecto no significa nada si el 10% de las peticiones están dando timeout. Error rate es un gate de cumplimiento de SLO tanto como la latencia.

Load testing vs stress testing vs performance testing

Estos términos se solapan y se usan de forma intercambiable a menudo, pero responden preguntas distintas.

• Performance testing es el término paraguas para cualquier test que mida comportamiento no funcional del sistema: velocidad, fiabilidad, escalabilidad bajo carga.
• Load testing es un subconjunto que se centra específicamente en niveles de tráfico esperados. Es verificación.
• Stress testing es lo opuesto a load testing: en lugar de correr a la carga esperada, empujas más allá para encontrar el breaking point. Es descubrimiento.

Un equipo de ingeniería típico corre load tests antes de cada release major (amigable con CI/CD, rápido) y stress tests con menos frecuencia (trimestralmente o tras cambios de arquitectura).

Métricas clave en load testing

Cinco métricas importan más al leer un informe de load test:

1. Percentiles de response time (p50, p95, p99). El promedio engaña porque los outliers tiran de él. p95 significa "95% de las peticiones fueron más rápidas que esto", lo cual es un proxy mucho mejor de experiencia de usuario.
2. Throughput (peticiones por segundo). Cuánto trabajo el sistema realmente completa. Vigila el momento en que el throughput deja de escalar linealmente con carga añadida.
3. Error rate. Porcentaje de peticiones fallidas (HTTP 5xx, timeouts, assertion failures). Cualquier cosa por encima de ~0,5% bajo carga esperada suele ser un fail.
4. Usuarios virtuales activos. La concurrencia que el test realmente genera. Importante cruzarlo con tu objetivo, porque muchas herramientas capan silenciosamente la creación de threads cuando los recursos locales se agotan.
5. Uso de recursos en el sistema bajo test. CPU, memoria, conexiones de base de datos, red. El load test muestra el síntoma (respuestas lentas), pero el uso te dice la causa.

Cuándo ejecutar un load test

• Antes de cada release major. Cablea load testing en CI/CD para que cada build se mida contra tus SLOs.
• Antes de un peak conocido. Pre-Black-Friday, pre-lanzamiento de producto, pre-campaña de marketing.
• Tras cambios de infraestructura. Base de datos nueva, capa de caché nueva, región nueva. Re-ejecuta el load test para confirmar que los SLOs siguen aguantando.
• Tras cambios significativos de código. Refactors mayores, upgrades de framework o cambios de dependencia pueden mover las características de rendimiento sutilmente.

Cómo encaja load testing con stress, spike y soak testing

Load testing es una de varias "formas" de testing no funcional:

• Load testing: sostenido al peak esperado.
• Stress testing: rampado más allá del peak esperado para encontrar el breaking point.
• Spike testing: salto instantáneo de normal a peak (o más allá) para testear elastic scaling y warm-up.
• Soak / endurance testing: sostenido a carga moderada durante muchas horas para sacar memory leaks y degradación lenta.

Los mismos scripts ejecutan los cuatro. Solo el perfil de carga (ajustes de thread group / scenario) cambia.

Herramientas para load testing

Los dos estándares open source son:

• JMeter: proyecto Apache, basado en Java, dirigido por GUI. Cobertura de protocolos sólida (HTTP, JDBC, JMS, MQTT, gRPC), miles de plugins de la comunidad, el estándar de toda la vida en QA enterprise.
• k6: moderno, code-first (JavaScript), construido en Go. Menor footprint de memoria por VU, DX developer-friendly, integra limpio con CI/CD.

Ambos corren en local para tests pequeños. Para carga realista (miles de usuarios concurrentes desde múltiples regiones geográficas) necesitas un cloud runner. LoadFocus ejecuta tanto JMeter como k6 desde 25+ regiones cloud con análisis IA de los resultados.

Si prefieres no escribir los scripts tú mismo, LoadFocus ofrece load testing services donde los ingenieros escriben los scripts para tus escenarios, los ejecutan a escala y entregan el informe.