Introducción
Las pruebas de carga verifican cuántos usuarios concurrentes puede soportar un sistema antes de que su rendimiento se degrade por debajo del umbral aceptable. No son lo mismo que las pruebas de estrés — aunque se confunden con frecuencia.
El error más común: creer que porque el sistema funciona bien en staging con 10 usuarios va a funcionar bien en producción con 500. Staging y producción son entornos distintos. La carga real es distinta. Los problemas de rendimiento aparecen a escala, no en el laboratorio.
¿Qué diferencia las pruebas de carga de las de estrés y rendimiento?
Los tres términos se usan a veces de forma intercambiable, pero describen objetivos distintos:
| Tipo | Objetivo | Pregunta que responde |
|---|---|---|
| Pruebas de carga | Verificar el comportamiento bajo el volumen esperado de usuarios | ¿El sistema responde correctamente con el tráfico que esperamos? |
| Pruebas de estrés | Llevar el sistema más allá del límite para identificar dónde se rompe | ¿Dónde está el punto de quiebre y cómo se recupera el sistema? |
| Pruebas de rendimiento | Término genérico que incluye carga, estrés, volumen y picos | ¿Cómo se comporta el sistema en distintos escenarios de uso? |
| Pruebas de volumen | Verificar el comportamiento con grandes volúmenes de datos | ¿El sistema funciona igual con millones de registros que con mil? |
| Pruebas de pico (spike) | Simular aumentos abruptos de tráfico en poco tiempo | ¿Qué pasa si el tráfico se duplica en 5 minutos? |
¿Cuándo hacer pruebas de carga?
Hay cinco situaciones donde las pruebas de carga son críticas, no opcionales:
- Antes de un lanzamiento con expectativa de tráfico significativo: si es la primera vez que el sistema va a recibir carga real, no se sabe cómo va a responder. Descubrirlo en producción con usuarios reales es la opción más costosa
- Antes de campañas de marketing o eventos de alta demanda: Black Friday, Cyber Monday, lanzamientos de producto, campañas que van a generar picos de tráfico predecibles. El pico es predecible; la falla no tiene que serlo
- Después de una migración de infraestructura: cambiar de servidor, pasar a la nube, cambiar de base de datos — cada migración puede afectar el perfil de rendimiento del sistema de formas inesperadas
- Cuando el sistema escala en usuarios: un sistema que funcionaba bien con 1.000 usuarios puede no funcionar igual con 10.000 si la arquitectura no fue diseñada para escalar
- Después de cambios arquitectónicos mayores: agregar un servicio, cambiar una integración, modificar el modelo de datos — cada cambio puede introducir cuellos de botella que no existían
¿Qué herramientas se usan para pruebas de carga?
Las herramientas más usadas en proyectos de software de tamaño mediano:
- k6: herramienta open source de Grafana, scripts en JavaScript, integración nativa con CI/CD. Es la elección estándar para equipos que ya usan pipelines modernos
- Gatling: basado en Scala, diseñado para generar carga muy alta con pocos recursos. Buena opción para sistemas que requieren simular miles de usuarios concurrentes
- Apache JMeter: más antiguo, con interfaz gráfica, amplia comunidad. Sigue siendo una opción válida especialmente para equipos con experiencia previa en la herramienta
- Artillery: pensado para APIs y microservicios, configuración en YAML, más fácil de aprender. Buena opción para equipos sin experiencia previa en testing de carga
La elección depende del tipo de sistema, el stack tecnológico y la experiencia del equipo. No hay una herramienta universalmente correcta.
¿Cómo se diseña un escenario de prueba de carga?
Un escenario de prueba de carga bien diseñado tiene tres elementos:
Perfil de carga
Define cuántos usuarios virtuales se van a simular y cómo evoluciona esa carga a lo largo del tiempo. Un perfil realista no arranca con 500 usuarios simultáneos desde el segundo 0 — el tráfico real tiene un período de calentamiento, un pico sostenido y una bajada.
Flujos a simular
No todos los endpoints tienen el mismo peso. Un escenario de carga realista simula la distribución real del tráfico: si el 60% de los usuarios solo consultan y el 40% transaccionan, el escenario debe reflejar esa proporción, no simular un 100% de tráfico transaccional.
Umbrales de aceptación
Sin criterios de aceptación explícitos, no se puede evaluar si los resultados son buenos o malos. Los umbrales más usados: tiempo de respuesta en el percentil 95 (p95) menor a X segundos, tasa de error menor al Y%, throughput mínimo de Z transacciones por segundo bajo carga nominal.
¿Qué cuellos de botella revelan las pruebas de carga?
Los problemas más frecuentes que aparecen bajo carga y que no se detectan en testing funcional:
- Pool de conexiones a base de datos agotado: el sistema funciona con 10 usuarios y falla con 100 porque el pool de conexiones tiene un límite no configurado correctamente
- Queries sin índices que escalan mal: una query que tarda 50ms con 1.000 registros puede tardar 5 segundos con 1 millón
- Sesiones no cerradas que acumulan memoria: memory leaks que solo se hacen visibles cuando hay muchos usuarios concurrentes durante un período sostenido
- Servicios externos sin timeout: si el sistema depende de una API externa que responde lento bajo carga, puede generar colas que bloquean el sistema completo
- Caché mal configurada: la ausencia de caché o su configuración incorrecta puede hacer que el servidor de base de datos reciba carga que debería absorber la caché
¿Qué se entrega al final de un proyecto de pruebas de carga?
Un proyecto de pruebas de carga bien ejecutado entrega:
- Informe de resultados: tiempos de respuesta (promedio, p95, p99), tasa de error, throughput y uso de recursos bajo distintos niveles de carga
- Identificación de cuellos de botella: qué parte del sistema se satura primero y bajo qué condiciones
- Capacidad máxima estimada: hasta cuántos usuarios concurrentes puede soportar el sistema con el rendimiento dentro de los umbrales aceptables
- Recomendaciones de optimización: priorizadas por impacto en el rendimiento, con estimación de esfuerzo de implementación
- Scripts de test: reutilizables para pruebas posteriores antes de cada release mayor