k6 vs Locust: ¿scripts JavaScript o usuarios Python?

k6 y Locust son dos herramientas de código abierto que mantienen una prueba de carga como código en tu repositorio, y cualquiera de las dos prueba bien una API HTTP bajo carga. Elige Locust si tu equipo escribe Python y quiere la lógica de la prueba en Python puro. Elige k6 si escribes JavaScript, quieres umbrales de éxito integrados o necesitas una prueba que mantenga una tasa de llegada.

Los datos de esta comparación de k6 y Locust proceden de la documentación y del repositorio de cada proyecto, comprobados el 13 de octubre de 2026.

¿Cuál es la diferencia entre k6 y Locust?

La diferencia principal es el lenguaje en el que escribes las pruebas. k6 ejecuta JavaScript dentro de un programa de Go compilado, mientras que Locust ejecuta tu código Python y se apoya en gevent para muchos usuarios concurrentes.

k6 se instala como paquete o binario independiente, sin otro entorno de ejecución. También ejecuta archivos .ts, aunque su compatibilidad con TypeScript quita los tipos sin comprobarlos. Locust se instala con pip install locust, y su página What is Locust dice que las pruebas son Python corriente que guardas en control de versiones como cualquier otro código (comprobado el 13 de octubre de 2026).

¿Cómo se escribe la misma prueba en cada herramienta?

Las dos expresan la prueba como un programa corto. Aquí va una prueba con 50 usuarios durante cinco minutos que falla si el percentil 95 supera los 500 ms o si más del 1 % de las peticiones fallan.

En k6 los objetivos forman parte del script, como umbrales:

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

export const options = {
  vus: 50,
  duration: "5m",
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
  sleep(1);
}

En Locust el usuario es una clase, y los mismos objetivos van en un listener, siguiendo el patrón de la documentación del modo headless:

import logging
from locust import HttpUser, between, events, task


class ApiUser(HttpUser):
    wait_time = between(1, 2)

    @task
    def list_users(self):
        self.client.get("/api/users")


@events.quitting.add_listener
def _(environment, **kw):
    stats = environment.stats.total
    if stats.fail_ratio > 0.01:
        environment.process_exit_code = 1
    elif stats.get_response_time_percentile(0.95) > 500:
        environment.process_exit_code = 1

Se lanzan con k6 run script.js y locust -f locustfile.py --headless -u 50 -r 10 -t 5m --host https://staging.example.com (comprobado el 13 de octubre de 2026).

¿Cómo modelan la carga k6 y Locust?

k6 admite los dos modelos de carga, mientras que Locust describe la carga como un número fijo de usuarios. En k6 eliges el modelo con el ejecutor, y en Locust con el número de usuarios y el tiempo de espera.

k6 tiene seis ejecutores. Cuatro son cerrados: un usuario virtual empieza su siguiente iteración solo cuando termina la anterior. Los dos ejecutores arrival-rate siguen el modelo abierto, en el que las iteraciones empiezan con independencia de lo que tarden las anteriores. La guía del locustfile dice que el tiempo de espera solo puede limitar el rendimiento y no puede lanzar usuarios nuevos para alcanzar una tasa objetivo (comprobado el 13 de octubre de 2026).

Si tu objetivo es «300 peticiones llegan cada segundo, sea cual sea el tiempo de respuesta», k6 puede expresarlo directamente. Nuestra guía sobre el modelo de carga abierto y cerrado explica cuándo encaja cada uno.

¿Cómo deciden k6 y Locust si una prueba ha pasado?

k6 tiene los criterios de éxito como función central, y Locust deja la mayor parte a tu código. Un umbral de k6 incumplido termina la ejecución con un código de salida distinto de cero, y abortOnFail detiene la prueba en cuanto falla.

Locust termina con código 1 si alguna petición ha fallado. Para límites sobre la tasa de fallos, la media o el percentil 95, su documentación muestra un listener como el de arriba, que fija el código de salida por su cuenta (comprobado el 13 de octubre de 2026). Nuestra guía sobre los criterios de aprobación de una prueba de carga ayuda a elegir los límites.

¿Qué protocolos cubre cada herramienta?

k6 incluye cuatro protocolos y un módulo de navegador; Locust incluye HTTP y HTTPS y te deja envolver cualquier cliente de Python para el resto.

k6 enumera HTTP/1.1, HTTP/2, WebSockets y gRPC como protocolos integrados, con más mediante extensiones xk6, y un módulo de navegador que maneja un navegador basado en Chromium. La página de Locust sobre otros sistemas dice que solo trae soporte integrado para HTTP/HTTPS, pero que se puede extender para probar casi cualquier sistema, envolviendo una biblioteca de protocolo e informando de cada llamada como una petición. La biblioteca debe cooperar con gevent (comprobado el 13 de octubre de 2026).

¿Cómo se ejecuta una prueba mayor de lo que genera una máquina?

Locust escala con un master y workers, y k6 con un operador de Kubernetes o un servicio alojado. Ambos pueden repartir una prueba entre muchas máquinas.

La documentación del modo distribuido de Locust dice que un proceso puede hacer más de mil peticiones por segundo con un plan de prueba sencillo, así que las pruebas mayores usan un worker por núcleo de procesador en tantas máquinas como haga falta. El k6-operator reparte una prueba entre varias instancias de k6 en un clúster de Kubernetes, y Grafana Cloud k6 es la vía alojada (comprobado el 13 de octubre de 2026).

Hay una tercera vía para los scripts de k6. LoadFocus, que publica este sitio, ejecuta scripts de k6 desde 25 regiones en la nube, con los usuarios y la duración tomados de los ajustes de la prueba. Su validador de scripts avisa de que los escenarios arrival-rate se ejecutan allí con un número fijo de usuarios, de modo que un script de modelo abierto no mantiene su tasa de llegada en LoadFocus. LoadFocus no ejecuta Locust: solo ejecuta scripts de k6 y planes de prueba de JMeter.

¿Qué informes se obtienen?

k6 imprime un resumen al final de la prueba y puede exportar un informe HTML desde su panel web. Locust muestra gráficos en vivo en su interfaz web y escribe archivos si se lo pides.

El resumen de fin de prueba de k6 sale por la terminal, y su panel web exporta un informe HTML autónomo cuando defines K6_WEB_DASHBOARD_EXPORT. Locust ofrece una interfaz web en el puerto 8089 con gráficos en vivo, y su referencia de configuración lista las salidas --csv, --html y --json (comprobado el 13 de octubre de 2026).

¿Cuál deberías elegir?

Locust encaja con equipos de Python, y k6 con equipos que quieren umbrales integrados y un modelo de carga abierto. Los protocolos y el escalado deciden la mayoría de los demás casos.

Elige Locust en lugar de k6 si tu equipo escribe Python y quiere bucles, ramas, datos generados y su propio cliente de API en Python puro, si quieres reutilizar bibliotecas de Python para un protocolo, o si quieres una interfaz web con gráficos en vivo para explorar un sistema. Elige k6 en lugar de Locust si tu equipo escribe JavaScript o TypeScript, si los umbrales deben hacer fallar una compilación de CI y detener pronto una mala ejecución, si necesitas una tasa de llegada constante, o si quieres gRPC y pruebas de navegador en la misma herramienta.

Para una visión más amplia, consulta nuestra reseña de las pruebas de carga con Locust.

FAQ

¿Es Locust más rápido que k6? No lo hemos medido nosotros, así que no nombramos un ganador. La prueba justa es el mismo escenario con ambas herramientas en tu propio hardware.

¿Puede Locust ejecutar scripts de k6? No según la documentación de Locust, que describe las pruebas como código Python en un locustfile. Un script de k6 es JavaScript, así que hay que reescribirlo como una clase de usuario de Python, y los umbrales pasan a ser un listener.

¿Puede LoadFocus ejecutar pruebas de Locust? No. LoadFocus ejecuta scripts de k6 y planes de prueba de JMeter. Para escalar una prueba de Locust, usa su modo master y workers, el operador de Kubernetes o Azure Load Testing.

Lecturas relacionadas

• Pruebas de carga con Locust: la herramienta de Python a fondo
• Locust vs JMeter: ¿scripts de Python o planes de prueba de JMeter?
• Gatling vs k6: ¿simulaciones JVM o un binario de Go?
• k6 vs Artillery: qué herramienta de pruebas de carga elegir
• Modelo de carga abierto vs cerrado: ¿cuál usar?
• Azure Load Testing: análisis del servicio de Microsoft

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