Cuando un sitio web experimenta un alto tráfico, puede ralentizarse, devolver errores o incluso colapsar si no se prueba adecuadamente. Eso es lo que sucede cuando un sitio web no puede manejar muchos usuarios a la vez.
Para evitar esto, necesitamos hacer más que solo comprobar si las funciones básicas funcionan. Necesitamos probar cómo se desempeña nuestro sitio web bajo presión. Esto se llama prueba de carga o prueba de estrés. Piénsalo como probar un puente. No solo cruzarías una vez, querrías ver si puede soportar tráfico pesado e incluso resistir condiciones extremas. La prueba de carga nos ayuda a ver si nuestro sitio web puede manejar un gran número de usuarios sin ralentizarse o colapsar.
Planificación de tu prueba de carga: Hacer las preguntas correctas
Antes de comenzar la prueba de carga, necesitamos responder algunas preguntas clave:
- ¿Cuántos usuarios deberíamos simular? Necesitamos estimar el número de usuarios que esperamos tener en nuestro sitio web en su momento de mayor actividad.
- ¿Qué hacen los usuarios reales? Necesitamos crear escenarios de prueba que imiten cómo los usuarios reales interactúan con nuestro sitio web.
- ¿Dónde están ubicados nuestros usuarios? Debemos simular usuarios de diferentes partes del mundo para ver cómo funciona nuestro sitio web para todos.
- ¿Con qué gradualidad deberíamos aumentar la carga? No deberíamos saturar el sitio web repentinamente con usuarios; deberíamos aumentar gradualmente el número de usuarios para ver cómo reacciona el sitio web.
- ¿Cuánto tiempo debería durar la prueba? Necesitamos ejecutar la prueba el tiempo suficiente para obtener resultados significativos.
Al planificar cuidadosamente nuestras pruebas de carga, podemos garantizar que nuestro sitio web proporcione una experiencia fluida y agradable para todos los usuarios, incluso durante los picos de tráfico.
Actualización 2026: Las aplicaciones modernas generan tráfico desde muchas fuentes más allá de los navegadores web tradicionales, incluyendo aplicaciones móviles, APIs e integraciones de terceros. Debido a esto, las estrategias de prueba de carga ahora suelen simular una mezcla de comportamiento de usuario y tráfico de API para reflejar mejor los entornos de producción reales.
Usuarios concurrentes requeridos para la prueba de carga
Antes de configurar una prueba que refleje el comportamiento cercano a un usuario real, debemos dedicar algo de tiempo a determinar cuántos usuarios concurrentes se necesitan simular para nuestra prueba. Los usuarios concurrentes definen cuántos usuarios estarán navegando nuestro sitio web o aplicación web y realizando transacciones durante un período de tiempo específico. El tráfico en tus sitios y aplicaciones probablemente fluctúa durante la semana, pero para probar correctamente tus sitios y aplicaciones, querrás configurar tu prueba para que esté por encima de los tiempos de mayor tráfico. Pero, ¿cómo encontrar correctamente el número correcto de usuarios concurrentes?
Podemos usar herramientas de analítica web para determinar las estadísticas de tráfico actuales en nuestro sitio web con detalles a observar como el conteo de visitas, duración de las sesiones en el sitio web. Google Analytics y muchas otras herramientas de analítica pueden proveer métricas de sesiones que tu sitio web tiene por un intervalo de tiempo regular y la duración promedio de la sesión, y el tiempo que los usuarios pasan en el sitio. Podemos usar la siguiente fórmula para estimar el número de usuarios concurrentes:
Usuarios concurrentes = Sesiones por hora x Duración promedio de sesión (en minutos) / 60
Si no disponemos de datos de analítica web, podemos usar el número esperado de visitas de usuarios para calcular el número de usuarios concurrentes:
Usuarios concurrentes = Número esperado de visitas por minuto * Duración de visita (en minutos)
Para más información y consejos relacionados con la configuración de usuarios concurrentes, visita nuestra Base de Conocimiento y lee nuestro artículo sobre cómo calcular usuarios concurrentes a partir de analítica web.
Simulación de escenarios de prueba con usuarios reales
Ahora que estamos listos con usuarios concurrentes, necesitamos encontrar los escenarios de prueba de tráfico frecuente y alto para formar parte de nuestras pruebas de estrés. Ten en cuenta que no es necesario usar muchos scripts para cada situación. Típicamente, encontrarás que solo un pequeño número de casos de uso son necesarios para determinar la carga real de todas tus transacciones.
Una vez que hemos determinado el nivel relevante de usuarios concurrentes, deberíamos elegir el enfoque adecuado de simulación de tareas para la prueba de carga, basado en la aplicación bajo prueba.
Prueba de carga para aplicaciones web y páginas web
Para simular escenarios de usuario y transacciones para aplicaciones web y sitios web, necesitamos guionar los recorridos de usuario para simular nuestro escenario de prueba. Para este caso de uso, podemos usar el EveryStep Web Recorder, que graba nuestras interacciones en el navegador y crea un guion que puede ser usado para nuestra prueba de carga. El EveryStep Web Recorder es fácil de usar, pero capaz de guionar los escenarios más complejos. Además, los usuarios pueden establecer demoras, editar palabras clave o variables de campos, configurar limitación de red y mucho más. Para aprender más sobre cómo editar un guion con el EveryStep Web Recorder, visita nuestra Base de Conocimiento para más información.
Para ejecutar pruebas de carga para páginas web, los equipos pueden usar la opción Web Page en LoadView, que inicia el proceso de prueba de páginas web con usuarios concurrentes.
Además, la plataforma LoadView permite a los equipos de desarrollo probar la carga de APIs y medios de transmisión. Para más información sobre API y páginas de medios de transmisión, visita nuestra página de Productos.
Cargas virtuales geodistribuidas
Como probablemente ya sabes, la latencia de la red tiene un gran impacto en los sitios web, así que durante nuestra prueba de estrés no deberíamos descuidar que los usuarios concurrentes tengan una carga geográficamente distribuida para simular el mismo comportamiento que vemos en el entorno de producción, así como para verificar los tiempos de respuesta para usuarios ubicados lejos de tu centro de datos. Considera una página web que descarga 2MB de contenido durante la actualización y 10ms para cada solicitud al back-end. El tiempo de carga en tu centro de datos será menor a cinco segundos debido a la proximidad y baja latencia.
En ubicaciones específicas en el extranjero, como Asia, con una latencia de 200ms, los tiempos de respuesta de este sitio web serán cinco segundos para el back-end y más de 200ms para la transferencia de la red. No deberíamos cometer el error de medir los tiempos de respuesta solo dentro de nuestro centro de datos. Podemos usar LoadView aquí, que ofrece una amplia gama de máquinas de inyección de carga alrededor del mundo. De todas estas opciones, podemos seleccionar todas aquellas que representen la ubicación habitual de nuestros clientes.
Período de aumento gradual entre escalas
Generalmente, nuestros sitios web tienen usuarios concurrentes dispersos en diferentes momentos del día, tenemos unas pocas horas pico durante las cuales el tráfico es más alto. Deberíamos usar el mismo enfoque para escalar y probar la carga de aplicaciones usando la misma estrategia de aumento gradual. LoadView te da la posibilidad de configurar tu aumento gradual, tiempos de espera y a qué ritmo necesitas disminuir la carga.
Duración de la prueba de carga
La duración de la prueba es un factor realmente importante durante las pruebas de carga por la única razón de proporcionar suficiente tiempo a la aplicación para que genere resultados realistas con detalles como tiempo de respuesta, rendimiento y si hay algún mecanismo de caché presente en la aplicación, se cachea durante nuestro periodo de aumento gradual. Para decidir la duración de la prueba, necesitamos considerar nuestro escenario y requerimiento. Podemos tener en cuenta los siguientes casos al decidir la duración de la prueba de carga:
- Necesitamos asegurarnos de que cada solicitud/paso de prueba se ejecute al menos 10 veces. Deberíamos mantener una duración de prueba mayor para escenarios largos en comparación con los más cortos.
- También necesitaremos decidir qué tipo de prueba de carga planeamos ejecutar porque podríamos necesitar establecer una duración más larga si debemos verificar la estabilidad y características de rendimiento de la aplicación durante un período extendido.
- Siempre reserva unos minutos adicionales para el calentamiento de la aplicación, como se mencionó anteriormente.
Conclusión: Cómo simular correctamente el tráfico en sitios web o aplicaciones web
Como puedes ver, hay muchos factores que deben tenerse en cuenta antes de configurar y ejecutar tus pruebas de carga. Asegurar que tu aplicación web y sitios funcionen perfectamente para tus clientes es crítico para el éxito de tu negocio. La plataforma LoadView fue diseñada de tal manera que te guiará rápida y fácilmente a través del proceso paso a paso para configurar tus pruebas. La plataforma puede configurar escenarios del mundo real y ayudar a medir el rendimiento desde múltiples ubicaciones.
Regístrate para la prueba gratuita de LoadView y obtén pruebas de carga gratis para comenzar, o regístrate para una demostración de LoadView. Uno de nuestros ingenieros de rendimiento te guiará por toda la solución y responderá cualquier pregunta sobre la plataforma o tu proceso específico de prueba de carga.