loadtest.appde LoadFocus

Comparativas

k6 vs Artillery: qué herramienta de pruebas de carga elegir

6 min de lectura

k6 y Artillery son herramientas de pruebas de carga open source en las que las pruebas se escriben como código, y cualquiera de las dos prueba bien una API HTTP bajo carga. Elige k6 si quieres un único binario, la lógica de prueba en JavaScript y umbrales de éxito integrados. Elige Artillery si tu equipo ya trabaja en Node.js, prefiere escenarios cortos en YAML o necesita pruebas de navegador con Playwright y ejecuciones distribuidas en AWS o Azure desde la línea de comandos.

Los datos de abajo salen de la documentación y del repositorio de cada proyecto, comprobados el 8 de octubre de 2026.

k6Artillery
LicenciaAGPL-3.0 (repositorio)MPL-2.0, algunos módulos de Azure con BSL (repositorio)
Entorno de ejecuciónUn binario de Go con un motor de JavaScript integradoNode.js, última versión LTS
Scripts de pruebaJavaScriptYAML, TypeScript o JavaScript
Protocolos principalesHTTP, WebSockets, gRPCHTTP, WebSocket, Socket.IO (gRPC y Kinesis con motores adicionales)
Pruebas de navegadorMódulo de navegador integradoPlaywright
Criterios de éxitoThresholdsPlugin ensure
Ejecución distribuidak6-operator en Kubernetes, o Grafana Cloud k6run-lambda o run-fargate en AWS, run-aci en Azure

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

Se diferencian sobre todo en el entorno de ejecución y en cómo describes la carga. k6 es una herramienta compilada en Go que ejecuta código de prueba en JavaScript, mientras que Artillery es una herramienta de Node.js que lee escenarios en YAML o JavaScript.

Esa diferencia se nota desde el primer día. Instalar k6 es instalar un paquete o un binario independiente, sin un entorno de ejecución que mantener. Artillery necesita Node.js y se instala con npm, algo natural en un proyecto de JavaScript y un entorno más que mantener al día en cualquier otro sitio.

En protocolos, lo que comparten cubre casi todo el trabajo web: ambos hablan HTTP y WebSockets de serie. k6 trae además gRPC, y Artillery, Socket.IO. Artillery consigue gRPC y Kinesis con motores adicionales que se instalan aparte (comprobado el 9 de octubre de 2026), y k6 llega más lejos con su ecosistema de extensiones.

¿Cómo se escribe una prueba en cada herramienta?

En k6 escribes un módulo de JavaScript con las opciones arriba y una función por defecto que ejecuta cada usuario virtual. En Artillery sueles escribir un archivo YAML con un bloque config para la carga y un bloque scenarios para lo que hace cada usuario virtual.

Una prueba de k6 que sube a 20 usuarios virtuales y falla si el percentil 95 del tiempo de respuesta pasa de 500 ms:

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

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

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

La misma idea en el formato YAML de Artillery, con diez usuarios virtuales nuevos por segundo durante un minuto:

config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 10
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 500
scenarios:
  - flow:
      - get:
          url: "/api/users"

Los dos ejemplos modelan la carga de forma distinta. El script de k6 fija un número de usuarios virtuales simultáneos, y el archivo de Artillery fija cuántos usuarios virtuales nuevos llegan cada segundo. k6 también puede controlar tasas de llegada con sus executors de escenarios, y Artillery puede limitar la concurrencia con maxVusers, así que elige el modelo que se parezca a cómo llega el tráfico real a tu sistema, no el que cada herramienta muestra primero.

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

Las dos convierten un objetivo de rendimiento en un código de salida, que es lo que necesita un pipeline de CI. Un objetivo incumplido termina la ejecución con un código de salida distinto de cero en las dos herramientas.

En k6 los objetivos son thresholds y van en las opciones del script, como en el ejemplo de arriba. En Artillery viven en el plugin ensure, que admite umbrales simples y condiciones que combinan varias métricas.

La diferencia práctica está en dónde viven los objetivos. Los thresholds de k6 están en el mismo archivo que la lógica de la prueba. Las comprobaciones de Artillery están en el bloque config, donde puede ajustarlas alguien que nunca toca los escenarios.

¿Cómo se ejecuta una prueba más grande de lo que puede generar una máquina?

Las dos herramientas pueden repartir una prueba entre muchas máquinas, por caminos muy distintos. k6 se apoya en Kubernetes o en el servicio alojado de Grafana, y Artillery en tu propia cuenta de AWS o Azure.

Para k6, el k6-operator reparte una prueba entre pods de un clúster de Kubernetes, y Grafana Cloud k6 ejecuta los mismos scripts como servicio alojado. Para Artillery, los comandos run-lambda y run-fargate lanzan workers en tu cuenta de AWS tras una configuración IAM única con una pila de CloudFormation. En Azure, run-aci hace lo mismo con Azure Container Instances, pero exige una suscripción de pago a Artillery para algo más que una evaluación (comprobado el 9 de octubre de 2026). Si ya usas Kubernetes, el camino del operator te resultará familiar. Si prefieres no operar nada, el camino serverless de Artillery tiene menos piezas móviles, siempre que la prueba pueda vivir en AWS o Azure.

Hay un tercer camino para los scripts de k6. LoadFocus ejecuta scripts de k6 en su propia infraestructura en la nube desde 25 regiones, así que el script que lanzas en tu portátil se convierte en una prueba distribuida sin clúster ni cuenta de AWS. LoadFocus no ejecuta scripts de Artillery, de modo que para Artillery sus propios comandos de AWS y Azure siguen siendo la forma de escalar.

¿Adónde van los resultados?

Las dos herramientas muestran un resumen al final de cada ejecución y pueden enviar métricas a otros sistemas para paneles y alertas.

Según su repositorio, k6 ofrece estadísticas resumidas o métricas detalladas exportadas al servicio que elijas. Artillery enumera en su repositorio más de 20 integraciones de monitorización, observabilidad y CI/CD. Las dos pueden alimentar los paneles que ya tienes. Antes de decidirte, comprueba que la salida concreta que necesitas está en la lista, porque ambas listas cambian entre versiones.

¿Cuál deberías elegir?

Elige k6 si quieres un único binario en la CI, lógica de prueba en JavaScript con control de flujo real y thresholds en el mismo archivo que la prueba. También encaja con equipos que ya usan Grafana, porque la herramienta open source y el servicio alojado comparten la misma API de scripts.

Elige Artillery si tu equipo escribe Node.js a diario, si un archivo YAML corto es más fácil de revisar para el resto del equipo que un script, o si necesitas pruebas de navegador con Playwright y Socket.IO en la misma herramienta. Su escalado serverless también es el camino más corto si tu infraestructura ya vive en AWS y Kubernetes no forma parte de ella.

Si aún dudas, escribe la misma prueba de humo en las dos. Veinte líneas bastan para ver cuál le resulta más fácil de leer a tu equipo en una revisión de código.

FAQ

¿k6 es gratis? Sí. k6 es open source con licencia AGPL-3.0 y funciona gratis en tus propias máquinas. Grafana Cloud k6 es un servicio alojado aparte, con sus propios precios.

¿Artillery es gratis? En su mayor parte. Casi todo Artillery tiene licencia MPL-2.0, pero algunos módulos específicos de Azure usan una licencia source-available que exige una licencia comercial para uso en producción en Azure, según el repositorio del proyecto (comprobado el 8 de octubre de 2026).

¿LoadFocus puede ejecutar pruebas de Artillery? No. LoadFocus ejecuta scripts de k6 y JMeter. Para escalar una prueba de Artillery más allá de una máquina, usa los comandos de Artillery para AWS Lambda, Fargate o Azure Container Instances en tu propia cuenta en la nube.

¿Qué herramienta consume menos recursos en el generador de carga? No lo hemos medido nosotros, así que no nombramos un ganador. El proyecto k6 dice que incluso máquinas modestas pueden simular mucho tráfico, y la comparación justa es ejecutar el mismo escenario con las dos herramientas en tu propio hardware.

Lecturas relacionadas

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

LoadFocus team
Escrito por el equipo de LoadFocus, las personas detrás de un servicio de pruebas de carga en la nube.