Cómo hacer una prueba de carga: guía paso a paso

Para hacer una prueba de carga, decide qué es un buen resultado, programa un recorrido de usuario realista, comprueba ese script con un solo usuario y después sube la carga por escalones mientras vigilas los tiempos de respuesta y los errores. Compara lo que mediste con el objetivo que fijaste al principio y cambia una sola cosa antes de la siguiente ejecución.

¿Qué debes decidir antes de hacer una prueba de carga?

Decide para qué carga pruebas y qué resultado cuenta como éxito. Sin las dos cosas, una prueba de carga produce números, pero no una respuesta.

Parte del tráfico real si lo tienes. Tu analítica o tus logs de acceso te dicen cuál es la hora de más tráfico, cuántas peticiones por segundo llegan y qué páginas o endpoints se llevan la mayoría. Pon el objetivo por encima de ese pico, porque la idea es saber que tienes margen. Después escribe los criterios como números, por ejemplo: el percentil 95 del tiempo de respuesta se mantiene por debajo de 500 ms y fallan menos del 1 % de las peticiones con 200 usuarios virtuales.

Aquí también entran dos decisiones prácticas. Elige un entorno parecido a producción en tamaño y configuración, porque un servidor de staging con una cuarta parte de la capacidad dice poco sobre producción. Y asegúrate de tener permiso para probarlo: lanzar una prueba de carga contra un sistema que no es tuyo, o que compartes con otros equipos, sin avisar se parece exactamente a un ataque.

¿Cómo se programa un recorrido de usuario realista?

Programa el recorrido que más importa al negocio, paso a paso, con pausas donde una persona real leería o escribiría. Un script que llama a una sola URL lo más rápido posible mide algo, pero rara vez lo que te interesa.

En una tienda podría ser: abrir la portada, buscar, abrir un producto, añadirlo al carrito. En una API: iniciar sesión, listar elementos, obtener uno. Añade una pausa corta entre pasos (tiempo de reflexión), usa datos de prueba variados para que las cachés se comporten como en la vida real y comprueba cada respuesta para que una página de error no pase por una respuesta rápida.

Este es el script que usamos para el ejemplo de esta guía, escrito para k6. Sube a 10 usuarios virtuales, mantiene la carga y baja, con dos criterios de éxito incluidos:

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

export const options = {
  stages: [
    { duration: "10s", target: 10 },
    { duration: "20s", target: 10 },
    { duration: "5s", target: 0 },
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  const res = http.get("http://127.0.0.1:8765/");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Un recorrido real tiene varias peticiones y URLs reales. Este es diminuto a propósito, para que los pasos sean fáciles de seguir.

¿Por qué hacer primero una prueba de humo con un solo usuario?

Una prueba de humo con un usuario virtual demuestra que el script funciona antes de poner carga real sobre nada. Es la forma más barata de detectar una URL equivocada, un token de inicio de sesión que falta o una comprobación que siempre falla.

Con k6 puedes sobrescribir la carga desde la línea de comandos, así que el mismo script se ejecuta una vez con un solo usuario:

k6 run --vus 1 --iterations 1 script.js

En nuestra ejecución, la única comprobación pasó, así que el script estaba listo para la carga. Si aquí falla una comprobación, arregla el script antes de seguir: los errores con un usuario se convierten en ruido con cien.

¿Cómo se debe subir la carga?

Sube la carga por escalones y mantén cada escalón el tiempo suficiente para que se estabilice, en lugar de saltar directamente al objetivo. Una rampa por escalones te muestra a partir de qué nivel empiezan a empeorar las cosas.

Una forma habitual es subir a un primer escalón, mantenerlo unos minutos, subir al siguiente, mantenerlo otra vez y así hasta el objetivo, y después bajar. Si miras cada tramo por separado, ves si los tiempos de respuesta suben de forma gradual con la carga o se mantienen planos y luego saltan. Ese salto, el punto en el que cada usuario extra hace más lenta cada petición, es lo más útil que puede encontrar una prueba de carga. Nuestro ejemplo solo sube a 10 usuarios y mantiene 20 segundos, suficiente para mostrar los escalones pero demasiado corto para una prueba real.

¿Qué hay que vigilar mientras corre la prueba?

Vigila los percentiles del tiempo de respuesta, la tasa de errores y el rendimiento en el lado del generador de carga, y la CPU, la memoria y la carga de la base de datos en el sistema que pruebas. Las tres primeras cosas te dicen cómo lo notarían los usuarios, y las tres últimas, por qué.

Acuerda condiciones de parada antes de empezar, por ejemplo: parar si la tasa de errores pasa del 5 % o si los tiempos de respuesta llegan a varios segundos. Seguir empujando un sistema que ya se ha caído no enseña nada, y en un entorno compartido estorba el trabajo de otros.

Vigila también el generador de carga. Si está al 100 % de CPU, las respuestas lentas pueden venir de tu propio portátil y no del servidor.

¿Cómo se leen los resultados de una prueba de carga?

Lee los percentiles y la tasa de errores frente a los criterios que anotaste al principio. El tiempo de respuesta medio es la cifra menos útil del informe.

Esto es lo que dio nuestra ejecución de ejemplo (35 segundos, hasta 10 usuarios virtuales, una pequeña página estática servida en un portátil, el 8 de octubre de 2026):

Las cifras son diminutas porque el objetivo era un archivo estático en la misma máquina, así que no sirven como benchmark. La lección está en la forma: la media quedó por encima del percentil 90, porque un puñado de peticiones lentas la arrastró hacia arriba. Los percentiles describen lo que vivió la mayoría de las peticiones, y el percentil 99 y la petición más lenta muestran la cola que sufren unos pocos usuarios. Juzga la ejecución por el percentil de tus criterios y usa la cola para decidir si algo merece una mirada más atenta.

Si una ejecución no cumple su objetivo, cambia una sola cosa (una consulta, un ajuste de caché, un tamaño de instancia) y vuelve a lanzar la misma prueba, para saber qué marcó la diferencia.

¿Cuándo conviene lanzar la prueba desde la nube?

Lleva el generador de carga a la nube cuando una máquina no puede producir la carga que necesitas, o cuando importa dónde están tus usuarios. Un portátil en el Wi-Fi de la oficina mide tu conexión tanto como tu servidor.

El mismo script de k6 puede ejecutarse en infraestructura que gestionas tú, en el servicio alojado de Grafana o en LoadFocus, que ejecuta scripts de k6 desde 25 regiones en la nube. Sus informes desglosan los resultados por ubicación y muestran el tiempo de respuesta frente al número de usuarios virtuales, que es donde se ve el salto descrito arriba (cómo leer los resultados en LoadFocus).

FAQ

¿Cuánto debe durar una prueba de carga? Lo suficiente para mantener la carga objetivo varios minutos después de la subida, de modo que los picos cortos no decidan el resultado. Mantener al menos 10 minutos es un buen punto de partida, y bastante más si buscas fugas de memoria o una degradación lenta.

¿Cuántos usuarios virtuales necesito? Calcúlalo a partir del tráfico real. Toma las peticiones por segundo de la hora de más tráfico, estima cuántas peticiones hace un recorrido y cuánto dura, y dimensiona los usuarios virtuales para que la prueba produzca ese ritmo con algo de margen.

¿Es seguro hacer pruebas de carga en producción? Puede serlo, con cuidado: prueba en un momento tranquilo, avisa a quien opera el sistema, fija condiciones de parada y empieza muy por debajo del pico esperado. Muchos equipos prefieren un entorno de staging del tamaño de producción, para que una prueba fallida no afecte a ningún cliente.

Lecturas relacionadas

• Criterios de aprobación en pruebas de carga: cómo fijarlos
• Pruebas de carga en GitHub Actions: guía práctica

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.