Cómo crear pruebas de carga realistas en k6 para sistemas web

Por qué las pruebas sintéticas tradicionales fallan en la práctica

Muchos equipos confían en scripts sencillos que disparan mil solicitudes a la vez contra un servidor web, imaginando que esto representa una prueba de carga real. En la práctica, el comportamiento humano es caótico: las personas entran al sitio gradualmente, hacen clic en botones en momentos diferentes, esperan a que las páginas carguen y abandonan el carrito a mitad del proceso. Cuando simulamos solo una ráfaga ciega de datos, recopilamos métricas artificiales que no revelan cómo el sistema maneja el agotamiento progresivo de conexiones o el uso excesivo de memoria RAM.

Para cerrar esta brecha, necesitamos herramientas que permitan escribir código legible para simular flujos reales de navegación. Es exactamente aquí donde k6, una moderna herramienta de pruebas de rendimiento desarrollada en JavaScript, destaca en la ingeniería de software actual. En lugar de requerir interfaces gráficas pesadas, se ejecuta mediante la línea de comandos y permite versionar las pruebas junto con el código de la aplicación, integrándose perfectamente en los pipelines de entrega continua (el proceso automatizado que lleva código nuevo desde la computadora del programador hasta producción).

Simulando picos de tráfico complejos con k6 y escenarios

Crear una prueba de carga realista exige modelar el tráfico en fases, simulando la llegada de usuarios por la mañana, el pico de acceso a la hora del almuerzo y la calma de la madrugada. En k6, esto se hace a través de opciones de ejecución avanzadas que definen el número de usuarios virtuales (las entidades que navegan por el sistema de forma simulada) a lo largo del tiempo. Cuando configuramos rampas de aceleración gradual, damos tiempo a la base de datos para calentar sus cachés internos y al balanceador de carga para distribuir las conexiones orgánicamente.

Más allá de planificar las etapas de tráfico, debemos asegurar que el código de la prueba refleje recorridos reales de uso. Esto significa que un usuario simulado no debe limitarse a golpear la página de inicio; necesita iniciar sesión, buscar un producto, agregarlo al carrito y finalizar la compra. Para estructurar sistemas tolerantes a fallos en la nube, puedes consultar la guía sobre cómo diseñar arquitecturas resilientes que soporten variaciones bruscas de acceso sin derribar los servicios esenciales.

Escribiendo tu primer script de prueba con k6

Vamos a la práctica con un ejemplo de script escrito en JavaScript para k6. Este código define una rutina donde los usuarios virtuales acceden de forma continua a un punto final de API, simulando una carga constante y midiendo el tiempo de respuesta obtenido. La estructura utiliza funciones nativas de k6 para verificar si el código de estado HTTP devuelto es el esperado, asegurando que el sistema no solo responda rápido, sino que responda con éxito.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 20 },
    { duration: '1m', target: 50 },
    { duration: '10s', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const res = http.get('https://api.ejemplo.com/productos');
  check(res, {
    'el estado es 200': (r) => r.status === 200,
  });
  sleep(1);
}

En este ejemplo, el bloque de opciones establece tres momentos distintos: treinta segundos subiendo hasta veinte usuarios, un minuto manteniendo cincuenta usuarios activos simultáneamente, y diez segundos descendiendo hasta cero. La propiedad thresholds funciona como un juez automatizado que reprueba la prueba si el noventa y cinco por ciento de las solicitudes tardan más de quinientos milisegundos en responder. Esta automatización es vital para garantizar que la infraestructura se mantenga estable antes de que cualquier cambio llegue al entorno de producción.

Analizando cuellos de botella e integrando pruebas en el pipeline

Ejecutar pruebas de carga manualmente en la máquina del desarrollador no garantiza que el sistema soporte el tráfico real, ya que los recursos locales de red y hardware difieren drásticamente de los servidores en la nube. La verdadera madurez operacional ocurre cuando integramos k6 directamente en el pipeline de entrega continua, como GitHub Actions o GitLab CI. Así, cada vez que un desarrollador altera una consulta a la base de datos o actualiza una biblioteca, el sistema ejecuta una prueba rápida de rendimiento para certificar que no se introdujo ninguna regresión.

Durante estas ejecuciones automatizadas, debemos monitorear métricas vitales como el uso de CPU, la saturación de memoria y el tiempo de espera en las colas de disco. Si la aplicación comienza a tambalearse bajo una carga moderada, el cuello de botella suele encontrarse en consultas SQL mal indexadas o bloqueos de concurrencia. Para mantener la estabilidad general de la infraestructura corporativa, vale la pena revisar las recomendaciones sobre cómo gestionar infraestructura con Terraform para aprovisionar recursos elásticos que sigan el ritmo de la demanda de las pruebas.

Consideraciones finales sobre las pruebas de rendimiento continuas

Crear pruebas de carga realistas deja de ser un evento aislado y se convierte en una práctica diaria de ingeniería cuando incorporamos la simulación de picos de tráfico en el ciclo de vida del software. Herramientas como k6 facilitan la transición de pruebas manuales y lentas a validaciones automatizadas rápidas integradas directamente en el código. Al anticipar fallas de concurrencia y cuellos de botella de infraestructura antes de que lleguen a los usuarios finales, los equipos ganan la confianza necesaria para entregar nuevas funcionalidades con velocidad, seguridad y alta disponibilidad operativa.