Por Que Importa el Testing de Rendimiento

La correccion funcional no es suficiente. Una aplicacion que funciona para un usuario pero se cae con 100 concurrentes es un producto fallido.

Consecuencias reales:

  • Amazon: cada 100ms de latencia costaba 1% en ventas
  • Google: 0.5 segundos de retraso causaba 20% menos trafico
  • 1 segundo de retraso en carga reduce conversiones 7%
  • 40% de usuarios abandonan sitios que tardan mas de 3 segundos

Tipos de Testing de Rendimiento

Load Testing

Verifica que el sistema se desempena aceptablemente bajo la carga normal esperada.

Ejemplo: Tu sitio espera 5,000 usuarios concurrentes. Simulas 5,000 realizando acciones tipicas y mides si los tiempos de respuesta se mantienen bajo 2 segundos.

Stress Testing

Empuja el sistema mas alla de su capacidad para encontrar puntos de quiebre.

Ejemplo: Incrementar usuarios de 5,000 a 50,000 gradualmente. Donde se rompe? Como falla? Se recupera?

Endurance (Soak) Testing

Ejecuta bajo carga sostenida por periodo extendido (horas o dias) para detectar problemas temporales.

Ejemplo: 5,000 usuarios por 72 horas. La memoria se mantiene estable o crece gradualmente? Los tiempos de respuesta se degradan?

Spike Testing

Aplica aumentos repentinos y extremos de carga para ver como maneja rafagas de trafico.

Ejemplo: Carga normal 5,000. Saltar a 50,000 por 5 minutos (venta flash), luego volver a 5,000. Sobrevive? Que tan rapido se recupera?

Volume Testing

Evalua comportamiento con grandes cantidades de datos — millones de registros, gigabytes de archivos.

Ejemplo: Poblar BD con 10 millones de usuarios y 50 millones de transacciones. Las consultas siguen completandose en 2 segundos?

Scalability Testing

Mide que tan bien escala cuando se agregan recursos. 2x servidores = 2x capacidad?

Capacity Testing

Determina el maximo de usuarios o transacciones manteniendo criterios de rendimiento.

Tipos Mapeados a Escenarios

graph TB subgraph "Operaciones Normales" LOAD[Load Testing
Usuarios esperados
Condiciones normales] ENDURANCE[Endurance Testing
Carga sostenida
Horas/Dias] end subgraph "Mas Alla de lo Normal" STRESS[Stress Testing
Mas alla de capacidad
Punto de quiebre] SPIKE[Spike Testing
Rafaga repentina
Escenario venta flash] end subgraph "Datos y Escala" VOLUME[Volume Testing
Grandes datasets
Millones de registros] SCALE[Scalability Testing
Agregar recursos
Crecimiento lineal?] CAPACITY[Capacity Testing
Maximo usuarios
Limite de infraestructura] end style LOAD fill:#22c55e,color:#000 style ENDURANCE fill:#84cc16,color:#000 style STRESS fill:#f97316,color:#000 style SPIKE fill:#ef4444,color:#000 style VOLUME fill:#eab308,color:#000 style SCALE fill:#06b6d4,color:#000 style CAPACITY fill:#8b5cf6,color:#000

Metricas Clave

Tiempo de Respuesta

  • Promedio: Media de todas las solicitudes
  • P95: 95% de solicitudes son mas rapidas que este valor
  • P99: 99% mas rapidas. Revela la experiencia de los usuarios mas lentos
  • Maximo: Solicitud individual mas lenta

Throughput

Solicitudes/transacciones por segundo (RPS/TPS).

Tasa de Error

  • Aceptable: < 0.1% bajo carga normal
  • Preocupante: 0.1% - 1% — investigar
  • Critico: > 1% — el sistema esta fallando

Utilizacion de Recursos

  • CPU: > 80% sostenido es alerta
  • Memoria: Aumento gradual indica memory leaks
  • Disco I/O: Altos tiempos de espera = cuellos de botella
  • Red: Acercandose a limites = necesita CDN u optimizacion

El Proceso

  1. Definir requisitos — Objetivos de rendimiento (respuesta < 2s, throughput > 500 TPS)
  2. Identificar escenarios — Que acciones de usuario simular
  3. Preparar ambiente — Hardware y datos similares a produccion
  4. Crear scripts — Automatizar con herramientas (k6, JMeter, Gatling, Locust)
  5. Ejecutar — Carga progresiva: 10%, 25%, 50%, 75%, 100%
  6. Monitorear — Metricas de aplicacion, servidor, BD, red
  7. Analizar — Comparar contra requisitos, identificar cuellos de botella
  8. Reportar y optimizar — Compartir hallazgos, recomendar mejoras

Ejercicio: Define Escenarios de Testing de Rendimiento

Eres QA Lead para una plataforma de redes sociales con:

  • 2 millones de usuarios registrados, 200,000 activos diarios
  • Pico concurrente: 50,000 (horario nocturno)
  • Acciones: ver feed, publicar, subir fotos, mensajes, buscar
  • Infraestructura: 4 servidores app, 2 servidores BD, CDN
  • SLA: carga < 3 seg, API < 500ms, 99.9% uptime

Disena escenarios de load, stress, endurance y spike. Para cada uno: tipo, perfil de carga, duracion y metricas.

PistaMapea cada tipo a un escenario real. Load = pico nocturno normal. Stress = evento viral. Endurance = uso sostenido de fin de semana. Spike = publicacion viral de celebridad.
Solucion

1. Load Test: Pico Normal Nocturno

  • 50,000 usuarios concurrentes: 60% viendo feed, 20% publicando, 10% subiendo fotos, 5% mensajes, 5% buscando
  • Duracion: 1 hora
  • Metricas: Feed < 3s (P95), publicacion < 500ms, subida foto < 5s, busqueda < 1s, errores < 0.1%, CPU < 70%

2. Stress Test: Evento Viral

  • Rampa de 50,000 a 200,000 en 30 minutos
  • Duracion: 30 min rampa + 30 min sostenido + 30 min enfriamiento
  • Metricas: Punto de degradacion, inicio de errores, comportamiento de crash o degradacion, auto-scaling, tiempo de recuperacion

3. Endurance Test: Fin de Semana Sostenido

  • 30,000 usuarios sostenidos por 48 horas
  • Metricas: Tendencia de memoria (estable), tendencia de respuesta, pool de conexiones BD, crecimiento de logs, pausas de GC, tasa de error a lo largo del tiempo

4. Spike Test: Publicacion Viral

  • Base: 30,000 → Spike: 150,000 en 2 min → 5 min sostenido → Retorno en 3 min
  • Duracion: 15 min total
  • Metricas: Respuesta durante spike (aceptable hasta 5s), errores (hasta 2%), profundidad de cola, recuperacion en 5 min

5. Volume Test: Crecimiento de BD

  • 50 millones posts, 500 millones comentarios, 200 millones fotos, 2 mil millones items de feed
  • 50,000 usuarios concurrentes
  • Metricas: Generacion de feed, rendimiento de busqueda, planes de ejecucion, I/O de storage

Herramientas

HerramientaLenguajeMejor ParaOpen Source
k6JavaScriptAPI y load testing modernoSi
JMeterJava/GUITesting de protocolo, enterpriseSi
GatlingScalaSimulacion alto rendimientoSi
LocustPythonDistribuido, code-firstSi
ArtilleryJavaScriptTesting rapido de APISi (core)

Tips Profesionales

Tip 1: Prueba en ambiente similar a produccion. Resultados de un laptop de desarrollo no significan nada.

Tip 2: Monitorea todo. No solo metricas de aplicacion. CPU/memoria del servidor, consultas BD, latencia de red, tasas de cache CDN, tiempos de servicios externos.

Tip 3: Establece baselines antes de optimizar. Sin baseline, no puedes medir si tu optimizacion mejoro algo.

Conclusiones Clave

  • Siete tipos: load, stress, endurance, spike, volume, escalabilidad, capacidad
  • Cada tipo responde una pregunta diferente sobre comportamiento bajo presion
  • Metricas clave: tiempo de respuesta (P95/P99), throughput, tasa de error, utilizacion de recursos
  • Requiere ambientes similares a produccion y datos realistas
  • Probar antes de releases mayores, picos de trafico y cambios de arquitectura
  • Monitorear holisticamente: aplicacion, servidor, BD, red y servicios externos