Load Test en el desarrollo móvil — qué es, escenarios y cómo se realiza

¿Qué es Load Test?

Load Test es un proceso de verificación de cómo se comporta un sistema bajo un número esperado de solicitudes o usuarios simultáneos. En el contexto del desarrollo móvil, Load Test se aplica tanto al backend (API, base de datos, caché) como al cliente (procesamiento de notificaciones push, sincronización de datos). La diferencia principal con las pruebas de estrés es que Load Test simula una carga real, no extrema. Según AWS Well-Architected Framework (2024), las pruebas de carga deben realizarse utilizando perfiles de carga basados en análisis de uso real.

Load Test puede realizarse a nivel de solicitudes HTTP a la API, conexiones WebSocket o transacciones de base de datos. El objetivo es garantizar que el tiempo de respuesta de cada solicitud no supere un umbral especificado (generalmente 500–1000 ms para API) y que el rendimiento (RPS — solicitudes por segundo) cumpla con los requisitos. Google Cloud Armor (2024) define valores umbral basados en percentiles: el tiempo de respuesta p95 no debe superar los 2 segundos para endpoints críticos.

Las pruebas de carga de un backend móvil incluyen la simulación de escenarios típicos: registro, autenticación, carga de feed, envío de formularios. Los escenarios se registran como archivos HAR (HTTP Archive) y se reproducen mediante la herramienta de pruebas de carga. Según la documentación de k6 (2025), la conversión HAR permite reducir el tiempo de preparación del Load Test en un 60%.

Objetivos de las pruebas de carga

El primer objetivo del Load Test es confirmar el rendimiento del sistema. Si la especificación requiere manejar 1000 RPS, la prueba de carga debe confirmarlo con un margen del 20%. Según Netflix Tech Blog (2024), las pruebas de carga en Netflix se realizan con un margen 2x respecto a la carga pico: si se esperan 10000 RPS, la prueba verifica 20000 RPS. Este enfoque garantiza la estabilidad durante picos repentinos de tráfico.

El segundo objetivo es identificar cuellos de botella en la arquitectura. Los cuellos de botella típicos en backends móviles son la base de datos (consultas lentas), la caché (estrategia de invalidación incorrecta) y las API externas (servicios de terceros lentos). El rastreo distribuido (Jaeger, Zipkin) ayuda a localizar el problema a nivel de un servicio o solicitud específica.

El tercer objetivo es determinar el punto de saturación. Este es el momento en que agregar nuevos usuarios ya no aumenta el rendimiento. En las aplicaciones móviles, el punto de saturación suele ocurrir al 70–80% de carga de CPU en los servidores de base de datos. El auto-escalado debe activarse antes de alcanzar este punto.

Escenarios de pruebas de carga

Prueba de pico (Spike Test) — simula un aumento repentino de actividad, como una campaña de notificaciones push matutina o el lanzamiento de una campaña publicitaria. Según Grafana k6 (2025), Spike Test simula un crecimiento de carga de 100 a 10000 RPS en 30 segundos. El sistema debe manejarlo sin perder solicitudes y sin superar el tiempo de respuesta en más del 50%.

Prueba de resistencia (Endurance Test) — verifica la estabilidad del sistema durante un funcionamiento prolongado bajo carga. La duración típica es de 1 a 4 horas. Endurance Test revela fugas de memoria en aplicaciones de servidor, problemas con el pool de conexiones de base de datos y degradación del rendimiento de la caché. El pool de conexiones de PostgreSQL bajo carga prolongada sin una configuración adecuada puede agotar las conexiones disponibles en 2–3 horas de operación.

Prueba de carga escalonada (Step Load Test) — aumento gradual de la carga con incrementos del 10–20% cada 2–5 minutos. Este escenario ayuda a encontrar el límite exacto después del cual el sistema se degrada. InfluxDB y Prometheus recopilan métricas en cada paso para construir un gráfico de tiempo de respuesta versus RPS.

Métricas de Load Test

Tiempo de respuesta

Tiempo de respuesta es la métrica principal de Load Test. Se mide en milisegundos y se analiza por percentiles: p50 (mediana), p95 y p99. Google SRE (2024) recomienda un umbral p95 de no más de 1000 ms para API REST y no más de 200 ms para gRPC. Los percentiles son más importantes que los promedios porque muestran el comportamiento de las peores solicitudes, que los usuarios notan primero. Apdex (Índice de rendimiento de aplicaciones) es una métrica compuesta que considera la proporción de usuarios satisfechos, tolerantes y frustrados.

Rendimiento

Rendimiento (Throughput) — el número de solicitudes exitosas por unidad de tiempo. Se mide en RPS (solicitudes por segundo) o TPS (transacciones por segundo). El gráfico de Throughput en coordenadas “tiempo — RPS” debe ser lineal hasta el punto de saturación. Una caída pronunciada del Throughput al aumentar la carga es una señal de haber alcanzado el límite del sistema. Apache Bench y wrk son herramientas CLI simples para verificaciones rápidas de Throughput durante el desarrollo.

Tasa de error

Tasa de error (Error Rate) — la proporción de respuestas con estado HTTP 4xx o 5xx respecto al total de solicitudes. El umbral aceptable es inferior al 1%. Los errores 429 (Demasiadas solicitudes) y 503 (Servicio no disponible) bajo alta carga indican la necesidad de configurar limitación de tasa y auto-escalado. Un limitador de tasa en el API Gateway protege el backend contra la superación de la carga permitida. La política de reintentos con retroceso exponencial ayuda a los clientes a manejar correctamente los errores temporales.

Herramientas para Load Test

k6 (Grafana)

k6 — la principal herramienta Open Source de pruebas de carga de Grafana. Los scripts se escriben en JavaScript, con soporte para escenarios modulares, umbrales e integración con Prometheus e InfluxDB. k6 puede ejecutarse tanto en CLI como en la nube Grafana Cloud k6. Grafana Cloud construye automáticamente paneles a partir de los resultados de Load Test y los compara con datos históricos. k6 admite Protocol Buffers y gRPC a través del módulo k6/net/grpc.

Apache JMeter

Apache JMeter — una herramienta clásica de Load Test con interfaz gráfica. Admite una amplia gama de protocolos: HTTP, JDBC, JMS, FTP y TCP. JMeter es mejor para escenarios complejos con muchos tipos diferentes de solicitudes, pero requiere más configuración manual en comparación con k6. Los complementos de JMeter amplían la funcionalidad para pruebas de WebSocket y gRPC. Para ejecución distribuida, JMeter utiliza una arquitectura maestro-esclavo con un controlador.

Locust

Locust — una herramienta basada en Python que permite describir escenarios de carga en código. Locust es conveniente para equipos que usan Python como su lenguaje principal de automatización. A diferencia de k6 y JMeter, Locust admite ejecución distribuida de forma nativa: un nodo maestro coordina varios nodos trabajadores. La ejecución distribuida permite generar carga de hasta 100000 RPS desde múltiples máquinas. Locust también admite pruebas de WebSocket a través de extensiones personalizadas.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

Ejemplo de escritura de Load Test en k6

El script de k6 mostrado arriba demuestra una estructura típica de prueba de carga. Options define el perfil de carga: aumento gradual durante 2 minutos hasta 100 usuarios, luego 5 minutos de carga constante y otro aumento hasta 200 usuarios. Los umbrales definen los criterios de aprobación de la prueba: tiempo de solicitud p95 no más de 500 ms, tasa de error inferior al 1%. Si se superan los umbrales, k6 finaliza con un código distinto de cero — esto permite integrar Load Test en CI/CD.

En el desarrollo móvil, Load Test del backend es especialmente importante al lanzar nuevas funciones que crean carga adicional: me gusta, comentarios, streaming. Recomendación — realizar un Load Test en cada staging antes de implementar en producción. Crear un perfil de carga base durante la fase de diseño de API ayuda a evitar problemas arquitectónicos en etapas posteriores.