Pruebas de Rendimiento

Resumen de Pruebas de Rendimiento

Una prueba de rendimiento aplica un número definido de usuarios concurrentes o solicitudes a un sitio web, aplicación web o API, aumenta esa demanda a lo largo de una curva planificada y registra qué cambia: tiempos de respuesta, rendimiento, tasa de errores y cuánta capacidad del servidor, base de datos y red utiliza el sistema para mantenerse al día. El resultado es un conjunto de números comparados con un objetivo, no una impresión de qué tan rápido se siente el sitio.

El objetivo puede ser un sitio público, un recorrido autenticado a través de un portal o aplicación SaaS, una secuencia de llamadas API, o una aplicación web interna detrás de un firewall.

El objetivo no es hacer que un sitio sea rápido en general. Es confirmar que sus páginas, flujos de trabajo y llamadas API más importantes cumplan con los requisitos definidos en niveles de tráfico esperados. Un proceso de compra puede funcionar normalmente para un usuario, pero ralentizarse o expirar cuando cientos de clientes realizan pedidos al mismo tiempo.

Las pruebas funcionales confirman que una página o transacción funciona correctamente. Las pruebas de rendimiento miden si se mantiene rápido, estable y confiable a medida que aumenta el tráfico.

¿Qué Puedes Probar en Rendimiento?

Las pruebas de rendimiento comúnmente cubren cuatro objetivos HTTP/S: sitios web, aplicaciones web, APIs y aplicaciones web internas. Cada uno requiere diferentes scripts y mediciones.

Por Qué Son Importantes las Pruebas de Rendimiento

El valor de una prueba de rendimiento es una respuesta específica que llega antes de que los usuarios encuentren el problema:

• Los cuellos de botella aparecen antes del lanzamiento. Una consulta lenta o un pool de conexiones insuficiente aparece en un informe de prueba en lugar de en una cola de soporte.
• Se verifican planes de capacidad y escalabilidad. Las reglas de autoscaling, configuraciones de caché CDN y tamaños de instancia son suposiciones hasta que el tráfico las prueba.
• Los recorridos que generan ingresos se mantienen protegidos. Inicio de sesión, búsqueda, pago, carga de archivos y las llamadas API detrás de ellos son los caminos para probar primero.
• Los eventos pico producen menos ralentizaciones, errores y caídas. Lanzamientos, campañas, ventanas de inscripción y ventas estacionales a menudo tienen patrones de tráfico previsibles que se pueden probar de antemano.
• Se detectan regresiones. Cambios en código, API, base de datos, infraestructura y servicios externos alteran el rendimiento un poco, y la deriva se acumula a través de lanzamientos.
• Las decisiones de lanzamiento y los objetivos de nivel de servicio tienen evidencia. Un número p95 contra un objetivo es más fácil de actuar que una opinión de que el sitio “se siente lento”.

Tipos de Pruebas de Rendimiento

Cada tipo aplica tráfico en una forma diferente para responder a una pregunta diferente. La mayoría de los programas combinan varios.

Las pruebas de resistencia y soak son dos nombres para la misma prueba, no dos tipos distintos. Y la línea entre pruebas de carga y de estrés es la que los equipos más difuminan, por lo que tiene su propia página: prueba de carga vs. prueba de estrés.

Las pruebas de rendimiento son la categoría. Cada tipo debajo cambia cuánto tráfico llega, qué tan rápido y por cuánto tiempo.

Pruebas de Rendimiento vs. Pruebas de Carga

Las pruebas de rendimiento son la práctica más amplia de evaluar velocidad, estabilidad, escalabilidad y uso de recursos bajo diferentes condiciones. Las pruebas de carga son un tipo de prueba de rendimiento centrado en la demanda esperada y máxima.

Los términos a menudo se usan indistintamente porque la prueba de carga es comúnmente la primera prueba de rendimiento que los equipos ejecutan. Otros tipos de prueba son necesarios para encontrar puntos de quiebre, degradación a largo plazo o problemas de escalabilidad.

Para una comparación que también cubre pruebas de estrés, lea pruebas de rendimiento vs. estrés vs. carga.

Cómo Realizar Pruebas de Rendimiento

Los pasos a continuación aplican a una página de destino, un flujo de pago o una secuencia autenticada de API.

1. Defina el Objetivo y los Criterios de Aceptación

Indique qué debe demostrar la prueba, en números. Ejemplos: tiempo de respuesta p95 menor a 2 segundos para pago con 1,500 usuarios concurrentes; tasa de error inferior a 0.5%; la API de órdenes mantiene 400 transacciones por segundo. Una prueba sin criterios de aprobación o rechazo produce datos pero no una decisión.

2. Modele el Tráfico del Sitio Web, Aplicación o API

Recoja analíticas web, registros de acceso, datos APM y pronósticos comerciales. Identifique las páginas o recorridos críticos, cómo se divide el tráfico entre ellos, concurrencia pico, tasas de solicitudes, tiempo de espera entre pasos, mezcla geográfica y llamadas API por sesión. Las vistas de página no son usuarios concurrentes: 100,000 vistas diarias pueden significar un pico de unos pocos cientos de sesiones simultáneas, y el modelo debe indicar cuál.

3. Prepare un Entorno de Prueba Representativo

Iguale lo más posible la pila web de producción, la build de la aplicación, el tamaño de la base de datos, el comportamiento de CDN y caché, las dependencias API, integraciones y reglas de escalado. Use cuentas de prueba seguras y entornos sandbox de pagos. Donde el entorno deba diferir, anote la diferencia para que nadie lea el resultado como una garantía de producción.

4. Elija el Tipo de Prueba y Método de Prueba

Seleccione carga, estrés, pico, resistencia, volumen, escalabilidad o una combinación según la pregunta del paso 1. Luego elija cómo generar tráfico. Las pruebas HTTP/S envían solicitudes directamente y son eficientes para alto volumen contra páginas y APIs. Las pruebas con navegador real ejecutan JavaScript y siguen comportamientos multietapa, por lo que miden lo que una persona espera. Muchos equipos ejecutan pruebas de protocolo para escala y un grupo más pequeño de usuarios con navegador real para la experiencia de usuario.

5. Establezca una Línea Base

Ejecute una prueba controlada con carga moderada antes de cambiar algo. Esto confirma que el script se completa, que los datos de prueba son válidos y que los generadores de carga no son el cuello de botella. Registre el resultado y condiciones de prueba porque diferencias en caché, datos o entorno pueden hacer comparaciones posteriores poco confiables.

6. Ejecute la Prueba y Monitoree el Sistema Completo

Aumente la demanda a lo largo de la curva de carga planificada (rampas constantes, pasos o picos repentinos) en lugar de aplicar un número inexplicado de usuarios a la vez. Capture datos de servidor web, aplicación, infraestructura, base de datos, red y servicios externos junto con los resultados. Sin datos del servidor, sólo sabrá que algo se ralentizó pero no qué.

7. Analice Cuellos de Botella

Compare resultados primero con los criterios de aceptación. Luego correlacione transacciones lentas o errores con comportamiento de CPU, memoria, base de datos, caché, cola, grupo de conexiones, red y dependencias en la misma ventana temporal. Deténgase cuando pueda nombrar el componente y la condición bajo la que se degrada, no cuando tenga un tiempo de respuesta promedio.

8. Corrija, Repruebe y Automatice

Cambie una variable importante a la vez cuando pueda, vuelva a ejecutar el mismo escenario y compárelo con la línea base. Luego añada pruebas de regresión menores a CI/CD para que las transacciones críticas se ejecuten en cada build y programe pruebas mayores antes de lanzamientos importantes, campañas y picos estacionales.

Métricas Clave de Pruebas de Rendimiento

Las métricas de prueba describen lo que experimentan los usuarios. Las métricas del sistema ayudan a explicar por qué. Necesita ambas para los mismos minutos de prueba para llegar a una causa.

Las métricas de prueba identifican síntomas. Los datos del servidor, base de datos y observabilidad localizan la causa. Los informes de rendimiento de LoadView cubren el lado de la prueba, desde gráficos resumen hasta un gráfico de cascada por sesión para rastrear una transacción lenta a una solicitud específica. Pero el lado del servidor debe venir de su propia monitorización o APM, sincronizado con la línea de tiempo de la prueba.

Cómo Leer los Resultados de las Pruebas de Rendimiento

Algunos patrones se repiten en la mayoría de sistemas web. Ninguno prueba una causa raíz por sí solo, pero cada uno indica dónde investigar a continuación.

Cuando el rendimiento se estabiliza y el tiempo de respuesta comienza a subir, el sistema probablemente ha alcanzado un límite de capacidad.

Cuándo Ejecutar Pruebas de Rendimiento

Las pruebas de rendimiento no son una tarea única antes del lanzamiento. Los desencadenantes útiles:

• Temprano en el diseño, mientras la arquitectura y los recorridos de usuario importantes aún se deciden y los cambios son baratos.
• Después de cambios significativos en código, esquema de base de datos, infraestructura o integraciones, incluyendo cambios en scripts externos y configuración CDN.
• En CI/CD, como chequeos cortos de regresión en las transacciones que más importan.
• Antes de lanzamientos importantes, campañas, picos estacionales y migraciones, al nivel de tráfico que se pronostica para el evento.
• Después de un incidente en producción, para confirmar que la solución aguanta bajo las condiciones que lo causaron.
• En un calendario, para detectar degradación de rendimiento que ninguna versión explicó por sí sola.

Pruebas de Rendimiento vs. Pruebas de Velocidad de Sitios Web

Una prueba de velocidad de sitio web carga una página o una sesión en un momento específico, usualmente sin otro tráfico en el sitio, y reporta cuánto tardó. Es útil para optimización de front-end y para comparar una build con otra.

Las pruebas de rendimiento aplican niveles cambiantes de tráfico o usuarios concurrentes para ver cómo se comporta un sitio web, aplicación o API a medida que aumenta la demanda. Ambas reportan tiempos de página o respuesta. Las pruebas de rendimiento agregan lo que una prueba de velocidad no puede responder: cuántos usuarios soporta el sistema, la tasa de error en pico, dónde se aplana el rendimiento y cuánto tiempo se mantiene estable. Y una página que obtiene buen puntaje en una prueba de velocidad puede fallar con 500 sesiones concurrentes.

Cómo Elegir una Herramienta de Pruebas de Rendimiento

Evalúe una herramienta de pruebas de rendimiento y carga en la nube según las pruebas que necesita ejecutar, no según la cantidad de funciones:

• Soporta sitios web, aplicaciones web multietapa y los protocolos API que usa, incluyendo flujos de autenticación.
• Puede modelar tráfico realista: recorridos de navegador, secuencias API, tiempo de espera, variación de datos y curvas de carga ajustables.
• Proporciona suficiente escala para su pico, desde ubicaciones que coinciden con donde están sus usuarios.
• Soporta pruebas de protocolo, pruebas con navegador real o ambas, según lo que necesite medir.
• Produce percentiles utilizables, desglose de errores, resultados por transacción e informes que puede compartir con personas que no ejecutaron la prueba.
• Se integra con CI/CD y con sus herramientas de monitorización u observabilidad para el lado del servidor.
• Soporta aplicaciones web internas cuando se requiere prueba detrás del firewall.
• Es mantenible por las personas que crearán y repetirán las pruebas.

Buenas Prácticas de Pruebas de Rendimiento

• Comience con una pregunta específica de negocio o ingeniería, luego diseñe la prueba que la responda.
• Construya cargas de trabajo a partir de analíticas, registros y pronósticos en lugar de suposiciones.
• Pruebe inicio de sesión, búsquedas y transacciones de pago, no sólo la página principal.
• Use volúmenes de datos realistas y entornos que coincidan con producción donde sea posible, y documente dónde difieren.
• Separe problemas en el sistema bajo prueba de límites en la configuración del generador de carga. Verifique CPU y red del generador antes de culpar a la aplicación.
• Monitoree percentiles, errores, rendimiento y recursos del servidor juntos para la misma ventana de prueba.
• Cambie una variable importante a la vez cuando diagnostique mejoras.
• Guarde líneas base y compare el mismo escenario tras cada cambio.
• Incluya dependencias externas y latencia geográfica cuando afecten el recorrido del usuario, ya que los usuarios en producción no las saltan.

Pruebas de Rendimiento con LoadView

LoadView es una plataforma de pruebas de carga en la nube para medir el rendimiento de sitios web, aplicaciones web multietapa y APIs bajo tráfico. La carga proviene de una nube gestionada, por lo que no hay infraestructura de generación de carga que construir o mantener.

Cuando el volumen de solicitudes es la pregunta, las pruebas HTTP/S envían miles de solicitudes concurrentes y reportan tiempos de respuesta, rendimiento y errores por endpoint. Cuando lo que importa es el recorrido del usuario, la prueba de carga de aplicaciones web ejecuta scripts en navegadores reales, por lo que la ejecución de JavaScript y el tiempo de renderizado forman parte de la medición. Los scripts se graban con EveryStep Web Recorder haciendo clic una vez durante el recorrido. La prueba de carga de API cubre endpoints REST y SOAP, incluyendo secuencias de llamadas autenticadas y multietapa.

Las curvas de carga son ajustables: una curva de paso de carga cambia gradualmente usuarios concurrentes en un período definido, una curva basada en objetivo genera una tasa de transacción requerida en un intervalo fijo, y una curva ajustable dinámica permite a los equipos cambiar la carga de usuarios mientras la prueba corre. El tráfico puede provenir de más de 40 zonas en la red geográficamente distribuida, por lo que la latencia regional y el comportamiento del CDN forman parte del resultado.

Los informes muestran el plan de ejecución, transacciones por minuto, tiempos de respuesta y errores por tipo, con un gráfico de cascada para cada sesión para rastrear una transacción lenta a una solicitud específica. LoadView se integra con Jenkins, Azure DevOps y CircleCI. Jenkins y CircleCI pueden usar un Umbral de Sesiones Fallidas para marcar builds cuando las sesiones fallidas superan el porcentaje permitido. Las aplicaciones internas pueden probarse mediante IPs estáticas en lista blanca o un inyector de carga instalado localmente con pruebas detrás del firewall.

Preguntas Frecuentes sobre Pruebas de Rendimiento