¿Qué son las pruebas de carga y de estrés? Una guía práctica para aplicaciones web

Cualquier aplicación funciona bien mientras solo la usa un puñado de personas a la vez. La pregunta real es qué pasa cuando una campaña se vuelve viral, empieza una rebaja o la base de usuarios de un cliente se duplica en tres meses. Las pruebas de carga y de estrés son las dos disciplinas que responden a eso antes de que sus usuarios - o sus inversores - lo descubran de la peor manera.

Ambas pertenecen a la categoría más amplia de pruebas de rendimiento y ambas simulan tráfico contra su aplicación. Pero hacen preguntas distintas, usan patrones de tráfico distintos y producen tipos de información distintos. Confundirlas es habitual, y lleva a los equipos a probar el escenario equivocado.

1. ¿Qué es una prueba de carga?

Una prueba de carga comprueba cómo se comporta su sistema bajo un volumen de tráfico esperado y realista: el número de usuarios simultáneos, peticiones o transacciones que realmente planea en producción. El objetivo no es romper nada, sino confirmar que los tiempos de respuesta, la tasa de errores y el uso de recursos se mantienen dentro de límites aceptables a esa carga.

Una prueba de carga típica simula, digamos, 500 usuarios simultáneos navegando por una tienda, añadiendo artículos al carrito y pagando, y mide cómo rinde la aplicación frente a su acuerdo de nivel de servicio (SLA) objetivo. Si páginas que deberían cargar en menos de 500ms empiezan a tardar tres segundos bajo esa carga, ha encontrado un cuello de botella que conviene arreglar antes del lanzamiento.

2. ¿Qué es una prueba de estrés?

La prueba de estrés hace lo contrario: empuja deliberadamente el tráfico por encima de los niveles esperados y sigue aumentándolo hasta que el sistema se ralentiza, empieza a devolver errores o falla del todo. El objetivo no es confirmar un comportamiento normal, sino encontrar el punto de ruptura y observar cómo falla el sistema.

¿Se degrada la aplicación con elegancia, devolviendo datos en caché o un mensaje de error amigable? ¿O se cae por completo, corrompe datos o arrastra a la base de datos con ella? La prueba de estrés responde a eso, y a menudo es la única forma de descubrir fallos en cascada que nunca aparecen bajo carga normal.

3. Prueba de carga vs. prueba de estrés: diferencias clave

Ambas técnicas comparten herramientas y metodología, pero difieren en su propósito:

• Objetivo: la prueba de carga valida el rendimiento en el tráfico esperado. La prueba de estrés encuentra el punto de fallo y cómo se comporta el sistema más allá de él.
• Patrón de tráfico: la prueba de carga usa una carga constante y realista. La prueba de estrés incrementa el tráfico de forma continua, a menudo mucho más allá de cualquier escenario real.
• Criterio de éxito: una prueba de carga pasa cuando las métricas se mantienen dentro de su SLA. Una prueba de estrés «tiene éxito» cuando encuentra el punto de fallo y confirma que la caída es segura (sin pérdida de datos, un error claro y recuperación cuando el tráfico baja).
• Cuándo ejecutarlas: la prueba de carga suele hacerse antes de cada lanzamiento importante. La prueba de estrés se ejecuta con menos frecuencia: antes de un gran lanzamiento, un pico de tráfico conocido o tras cambios de arquitectura significativos.

4. Métricas clave a seguir

Sea cual sea la prueba que ejecute, el mismo puñado de métricas le dice si el sistema está sano:

• Tiempo de respuesta / percentiles de latencia: las medias esconden problemas - siga la latencia p95 y p99, ya que un pequeño porcentaje de peticiones muy lentas puede arruinar la experiencia de usuarios reales.
• Rendimiento (throughput): peticiones por segundo (RPS) o transacciones por segundo (TPS) que el sistema puede sostener sin degradarse.
• Tasa de errores: el porcentaje de peticiones fallidas (timeouts, respuestas 5xx) a medida que aumenta la carga.
• Uso de recursos: CPU, memoria, conexiones a la base de datos y profundidad de colas en cada capa del stack, no solo en el servidor de la aplicación.
• Usuarios concurrentes / punto de ruptura: el número máximo de usuarios o peticiones simultáneos que el sistema soporta antes de que el rendimiento o la disponibilidad se derrumben.

5. Herramientas populares

No necesita construir esto desde cero: herramientas maduras de código abierto y comerciales cubren la mayoría de las necesidades:

• k6: una herramienta de pruebas de carga moderna y amigable para desarrolladores, con tests escritos en JavaScript, fácil de ejecutar en pipelines CI/CD.
• Apache JMeter: el estándar histórico tanto para pruebas de carga como de estrés, con GUI y amplio soporte de protocolos.
• Gatling: una herramienta basada en Scala construida para escenarios de alto rendimiento, con informes HTML claros y legibles.
• Locust: un framework de Python donde se define el comportamiento del usuario en código, muy adecuado para escenarios complejos y realistas.
• Artillery: una herramienta ligera basada en YAML que encaja de forma natural en proyectos Node.js y APIs serverless.

6. Cuándo ejecutar estas pruebas

Las pruebas de rendimiento funcionan mejor cuando son un hábito, no un evento único antes de una gran fecha límite:

• Antes de un lanzamiento público o de una gran versión de una función, para detectar cuellos de botella mientras aún hay tiempo de arreglarlos.
• Antes de picos de tráfico predecibles: una rebaja, un anuncio de producto, una campaña de marketing o demanda estacional.
• Tras cambios de arquitectura significativos: una nueva base de datos, una nueva capa de caché, una migración a serverless o una nueva integración con terceros.
• De forma recurrente para los sistemas críticos del negocio, como parte del pipeline CI/CD, para que las regresiones de rendimiento se detecten igual que las de funcionalidad.

Conclusión: por qué esto importa para su negocio

Las pruebas de carga y de estrés no son solo una casilla de QA: son un seguro contra el peor momento posible para un fallo, el instante en que su producto por fin llama la atención. Una página de pago que expira durante una rebaja, o un sistema de reservas que se cae cuando una campaña se vuelve viral, cuesta ingresos reales y confianza real.

Si está construyendo un producto que espera crecer - más usuarios, más tráfico, más integraciones - integrar las pruebas de rendimiento en el proceso de lanzamiento desde el principio es mucho más barato que descubrir sus cuellos de botella en producción, delante de sus clientes.