Si se acerca un lanzamiento, una rebaja o una campaña, quizá te preguntes si tu aplicación aguantará cuando todo el mundo llegue a la vez. Las pruebas de carga te permiten comprobarlo antes del gran día: envían una multitud de usuarios simulados a tu aplicación o sitio web y miden con qué rapidez responde tu producto, con qué frecuencia fallan las peticiones y cuánto trabajan tus servidores.
Como uno de los varios tipos de pruebas de rendimiento, las pruebas de carga responden a la pregunta que se hace la mayoría de los equipos cuando el tráfico está a punto de dispararse: ¿seguiremos en pie? Si el sistema no da abasto, los clientes suelen ser los primeros en enterarse. Cuando se abrieron las reservas de la Nintendo Switch 2 en abril de 2025, los compradores de Target, Walmart y Best Buy informaron de errores en el pago, fallos en la verificación de direcciones y problemas con los cobros. Un mes antes, OpenAI impuso límites temporales a su nueva herramienta de imágenes de ChatGPT porque la demanda superó su capacidad de cómputo. Ambos fallos tenían la misma causa: más visitantes en un mismo momento de los que los sistemas podían soportar.
A continuación verás las tres mediciones que vigila toda prueba de carga, dónde terminan las pruebas de carga y empiezan las de estrés, y cómo saber si tu producto necesita una. Nuestro ejemplo real es un juego móvil cuyo servidor empezó a rechazar peticiones cuando 1.000 jugadores entraron en 10 segundos.
¿Qué miden las pruebas de carga?
Las pruebas de carga imitan lo que hacen los visitantes reales, solo que a una escala mucho mayor. Una herramienta crea cientos o miles de compradores ficticios que inician sesión, navegan y compran a la vez. Los testers los llaman usuarios concurrentes, es decir, personas en el sistema en el mismo momento.
Mientras esa multitud está activa, la prueba registra tres cosas:
- Tiempo de respuesta: cuánto espera cada persona a que la aplicación reaccione tras un toque o un clic. Una buena prueba también revisa las respuestas más lentas, porque una media saludable puede ocultar a los visitantes que se quedan mirando una pantalla de carga.
- Tasa de error: la proporción de peticiones que fallan. Una petición es cada mensaje que tu aplicación envía al servidor, como cargar una página o guardar un pedido. Bajo demasiada presión, algunas vuelven como errores en lugar de como resultados.
- Uso de recursos: cuánto trabajan tus servidores, medido por la capacidad de proceso (CPU) y la memoria a corto plazo (RAM). En cuanto el procesador o la memoria se acercan al límite, todo lo demás empieza a ralentizarse.
Estas mediciones solo resultan útiles cuando las comparas con un objetivo. Antes de probar, el equipo acuerda límites como “ninguna petición tarda más de 3 segundos con 5.000 usuarios conectados”. La prueba muestra entonces si el sistema cumple el objetivo y, si no, el punto en el que el rendimiento empieza a decaer.
En una aplicación, las ralentizaciones pueden empezar en el propio teléfono o en el servidor que hay detrás. Cuando realizamos pruebas de aplicaciones móviles, revisamos ambos en busca de puntos débiles que afecten al uso de memoria, la estabilidad y la resistencia a la carga, es decir, lo bien que aguanta todo a medida que sube el tráfico.
Pruebas de carga y pruebas de estrés: ¿cuál es la diferencia?
Es habitual confundir las pruebas de carga con las de estrés, porque ambas usan las mismas herramientas. Cada tipo de prueba responde a una pregunta distinta. Las pruebas de carga comprueban que todo funcione bien con el tráfico que esperas, hasta tu pico habitual. Las pruebas de estrés siguen añadiendo usuarios más allá de ese punto hasta que el sistema cede, de modo que descubres dónde está el límite y qué falla primero.
Ambas definiciones coinciden con la guía de pruebas de rendimiento del International Software Testing Qualifications Board (ISTQB), que certifica a testers de todo el mundo. El ISTQB describe además dos tipos de pruebas relacionados: las pruebas de picos y las pruebas de resistencia, que muchos equipos llaman pruebas de saturación.
Carga
¿Podemos con nuestro día normal más ajetreado?
Sube hasta el pico previsto y se mantiene ahí
Páginas lentas y peticiones fallidas con el tráfico pico normal
Estrés
¿Dónde está nuestro punto de ruptura?
Sigue subiendo más allá de ese pico
El límite real, y si el sistema cede con suavidad o se cae
Picos
¿Qué pasa cuando llega una multitud de golpe?
Se dispara de repente y luego baja
Recuperación lenta y sistemas que no añaden capacidad de cómputo con suficiente rapidez
Saturación
¿Seguimos sanos a lo largo de muchas horas?
Se mantiene estable durante mucho tiempo
Memoria que se llena poco a poco y conexiones que se abren pero nunca se cierran
Un sistema puede superar una prueba de carga gradual y aun así venirse abajo cuando la multitud aparece en cuestión de segundos, y por eso merece la pena ejecutar pruebas de picos por separado. Para cualquier producto que funcione las 24 horas, nuestra guía sobre las pruebas de saturación que detectan fugas de memoria explica cuánto debe durar cada ejecución.
Qué detectaron nuestras pruebas de carga reales en el servidor de un juego móvil
Realizamos pruebas de carga a Couple Up!, un juego móvil con estética de reality de citas, cuando su audiencia empezó a crecer. El estudio del juego quería saber si el servidor seguiría siendo rápido y estable durante una avalancha mucho mayor.
Nuestros ingenieros usaron Apache JMeter, una herramienta gratuita de pruebas de carga, para ejecutar cuatro rondas de jugadores simulados:
- 1 jugador añadido en 1 segundo
- 100 jugadores añadidos en 1 segundo
- 1.000 jugadores añadidos en 10 segundos
- 10.000 jugadores añadidos a lo largo de unos 17 minutos
Cada petición tenía que completarse en 3 segundos, entraran los jugadores que entraran.
La ronda de 10 segundos, que funcionó como una pequeña prueba de picos, incumplió ese límite con creces. La mayoría de las peticiones tardaron más de 3 segundos, y la más lenta necesitó 27. Una de cada cinco falló directamente con un error de servidor, lo que en un juego puede significar que un jugador pierda su progreso guardado.
La ronda más grande fue mejor. Cuando 10.000 jugadores llegaron de forma gradual a lo largo de unos 17 minutos, la mayoría de las peticiones volvieron a tiempo, aunque los tiempos de respuesta seguían superando los 6 segundos de forma puntual. La velocidad de llegada puede importar tanto como el número de usuarios, y por eso los lanzamientos y las ventas flash conllevan más riesgo que el crecimiento constante. Los grandes estudios también planifican ese riesgo. Por ejemplo, antes del lanzamiento de Battlefield 6 en octubre de 2025, EA añadió colas de inicio de sesión porque el equipo esperaba que muchos jugadores entraran a la vez.
Junto a la prueba de carga de Couple Up!, buscamos qué causaba las ralentizaciones. Nuestro ingeniero de DevOps, especializado en alojamiento, revisó cómo estaba configurado el servidor. Mientras tanto, nuestro desarrollador sénior de Python revisó el código del servidor. Entre los dos especialistas, entregaron al estudio un plan paso a paso, desde arreglos rápidos y baratos hasta cambios de diseño de mayor calado.
¿Preparando tu propio juego para el lanzamiento? Sigue los mismos pasos de pruebas de carga en nuestra lista de verificación de pruebas de juegos móviles.
¿Cuándo necesitas pruebas de carga?
Ejecuta una prueba de carga siempre que tu tráfico o tu sistema estén a punto de cambiar de forma importante. Los momentos típicos incluyen:
- El lanzamiento de un producto o una gran versión nueva
- Una rebaja o una promoción de temporada
- Una campaña de marketing, un anuncio en televisión o una publicación de un influencer que traiga una oleada de visitantes
- Un cambio a un nuevo alojamiento o una modificación importante de cómo está construido el sistema
- Un crecimiento sostenido que te haya acercado al tráfico para el que hiciste la última prueba
En el extremo, la red de Shopify alcanzó un pico de 489 millones de peticiones por minuto durante el Black Friday y el Cyber Monday de 2025. La mayoría de las tiendas nunca verán tráfico a esa escala, pero una rebaja funciona igual a cualquier tamaño: llega una multitud en una ventana corta, y el proceso de pago tiene que aguantar. Si tienes una tienda online, nuestro servicio de pruebas para el Black Friday prepara tu sitio para esas horas punta.
Las pruebas de carga no son solo para productos que aún no se han lanzado. Couple Up! ya estaba en el mercado y creciendo cuando probamos el juego. Las pruebas de carga suelen ejecutarse contra una copia del sistema en producción, para que los clientes reales no se vean afectados. El momento adecuado es antes de tu próximo día de mucho movimiento.
Sin embargo, no todos los productos necesitan miles de usuarios simulados. Para el sitio web de Elsewhen, omitimos la prueba de alta carga a propósito. Elsewhen es un estudio de producto digital, y los sitios web de empresa a empresa rara vez reciben multitudes repentinas de visitantes.
En su lugar, comprobamos la velocidad de carga y encontramos el problema real. En móvil, algunas páginas tardaban más de 10 segundos en mostrar el contenido principal, cuando la gente espera 2 o 3 segundos como mucho.
Como regla general, empieza por comprobar la velocidad de páginas concretas si tu tráfico es pequeño y estable. Si esperas multitudes, aunque sea de forma ocasional, una prueba de carga es la apuesta más segura.
¿Qué herramientas de pruebas de carga usan los equipos?
Las herramientas de pruebas de carga crean la multitud simulada. Cada usuario ficticio sigue un guion que describe lo que hace un cliente real, como abrir la aplicación, buscar y pagar. La herramienta ejecuta entonces miles de esos guiones a la vez. Nuestros ingenieros eligen la herramienta adecuada para tu producto, escriben los guiones y ejecutan las pruebas.
Estas son las herramientas con las que trabajamos, y en qué destaca cada una:
- JMeter es software gratuito de la Apache Software Foundation con interfaz visual, y cubre una amplia gama de pruebas de sitios web y aplicaciones. Lo usamos en el proyecto Couple Up!.
- k6 viene de Grafana Labs, y sus pruebas en JavaScript encajan con naturalidad en las comprobaciones automáticas que los desarrolladores ejecutan en cada versión.
- Gatling funciona bien para suites de pruebas grandes basadas en código y genera informes detallados después de cada ejecución.
- Locust ejecuta pruebas escritas en Python, una opción natural cuando el código de tu propio producto usa el mismo lenguaje.
- LoadRunner es una herramienta de pago con una larga trayectoria en grandes empresas que operan sistemas complejos.
- Grafana es un panel de control más que un generador de carga, y nos permite seguir los resultados en directo mientras se ejecuta una prueba.
Elegimos entre estas herramientas según tu producto, el software que ya usan tus desarrolladores y lo que haya que probar. Si te preocupa más cómo funciona tu producto en el teléfono, algo distinto de cómo gestiona el servidor el tráfico, nuestra selección de herramientas de pruebas de rendimiento para aplicaciones móviles cubre ese lado.
Cómo aborda QAwerk las pruebas de carga
No necesitas un equipo interno de pruebas de rendimiento para prepararte ante un pico de tráfico. QAwerk puede incorporarse a un proyecto en cualquier etapa, antes del lanzamiento o durante el crecimiento. Empezamos con una estimación del esfuerzo, de modo que el alcance queda claro antes de arrancar. Después acordamos los objetivos de rendimiento, construimos pruebas en torno al comportamiento real de los usuarios y entregamos un informe que prioriza los arreglos más urgentes. Como nuestro equipo incluye ingenieros de DevOps y desarrolladores junto a los testers, el informe explica tanto qué salió mal como qué cambiar.
¿Tienes una fecha de mucho movimiento en el calendario? Contacta con nuestro equipo de QA para programar pruebas de carga antes de que llegue esa fecha.
Preguntas frecuentes
¿Qué son las pruebas de carga en el testing de software?
Las pruebas de carga en el testing de software son un ensayo general para tu día de más actividad. Una herramienta envía miles de visitantes virtuales a un sitio web o una aplicación al mismo tiempo. Mientras esa multitud navega, los testers comprueban que las páginas sigan siendo rápidas, que los inicios de sesión y los pagos se completen y que los servidores tengan potencia suficiente. Los resultados muestran cuánto tráfico puede soportar el sistema antes de ralentizarse, de modo que los problemas se corrigen antes de que los clientes los noten.
¿Son las pruebas de carga lo mismo que las pruebas de rendimiento?
No, aunque las pruebas de carga y las de rendimiento están muy relacionadas. Las pruebas de rendimiento son la categoría amplia que cubre velocidad, estabilidad y capacidad. Las pruebas de carga son una parte de esa categoría y comprueban cómo se comporta un sistema con el número de usuarios al que se espera atender, incluidos los picos normales. Las pruebas de estrés, de picos, de saturación, de escalabilidad y de volumen pertenecen a la misma familia, y cada una comprueba un tipo de riesgo distinto.
¿Cuántos usuarios debe simular una prueba de carga?
Basa la cifra en tus propios datos de tráfico. Toma el tráfico más alto que hayan registrado tus analíticas y súmale los visitantes adicionales que esperas del próximo lanzamiento, rebaja o campaña. Un enfoque habitual es ejecutar la prueba con ese pico previsto y de nuevo algo por encima, como margen de seguridad. También merece la pena ejecutar una prueba de picos aparte, con miles de usuarios entrando en cuestión de segundos.
¿Se puede hacer una prueba de carga a una aplicación que ya está en producción?
Sí, y las pruebas de carga suelen ser más útiles después del lanzamiento, cuando el crecimiento empuja a un producto más allá del tráfico para el que se construyó. La opción más segura es un entorno de pruebas construido para que coincida con el real, de modo que los clientes nunca noten la carga adicional. Cuando eso no es posible, los testers pueden actuar sobre el sistema en producción en horas de poca actividad, subir el tráfico de forma gradual y detenerse en cuanto los tiempos de respuesta o los errores crucen un límite acordado.
¿Con qué frecuencia hay que ejecutar una prueba de carga?
Las pruebas de carga funcionan mejor como un hábito periódico. Planifica una prueba a escala completa antes de cada evento que se espere que traiga un tráfico inusual, y repítela después de cambios importantes en el alojamiento o en el diseño del sistema. Los equipos que publican actualizaciones a menudo también pueden añadir una pequeña prueba de carga automatizada a cada versión, lo que detecta una nueva ralentización el mismo día en que aparece.
Descubre cómo ayudamos a Couple Up! a realizar pruebas de carga y a mejorar significativamente el rendimiento del servidor en múltiples dispositivos
