Herramientas de pruebas de carga open source: seis opciones

Seis herramientas de pruebas de carga open source muy usadas hoy son Apache JMeter, k6, Gatling, Locust, Artillery y Vegeta. Elige según el lenguaje en el que tu equipo escribe las pruebas y según cómo necesites escalar: JMeter para la mayor cobertura de protocolos, k6 o Artillery para JavaScript, Gatling para la JVM, Locust para Python y Vegeta para comprobaciones HTTP rápidas a ritmo fijo.

Para este artículo no hemos comparado estas herramientas entre sí con benchmarks. Los datos salen del repositorio y la documentación de cada proyecto, comprobados el 8 de octubre de 2026, y las notas de «Ideal para» son nuestra opinión.

¿Sigue mereciendo la pena Apache JMeter?

Sí, sobre todo si necesitas protocolos más allá de HTTP. JMeter cubre el abanico más amplio de las seis y tiene detrás el mayor volumen de planes de prueba y conocimiento.

JMeter es una aplicación Java con licencia Apache 2.0. Su lista de protocolos incluye HTTP y HTTPS, servicios web SOAP y REST, FTP, bases de datos mediante JDBC, LDAP, mensajería JMS, correo y TCP sin más. Los planes de prueba se crean en una interfaz gráfica de escritorio, las pruebas reales se lanzan sin interfaz desde la línea de comandos y el modo remoto cliente-servidor reparte una prueba entre varias máquinas.

Ideal para sistemas con varios protocolos, equipos que ya tienen planes de JMeter y testers que prefieren construir las pruebas de forma visual. Elige otra cosa si tu equipo quiere pruebas como código puro, revisadas igual que la aplicación, porque los planes XML creados en una interfaz gráfica son difíciles de leer en una pull request.

¿Cuándo es k6 la opción adecuada?

Cuando tu equipo escribe JavaScript y quiere pruebas en código con umbrales de éxito integrados. Se distribuye como un único binario de Go, lo que simplifica su configuración en la CI.

k6 tiene licencia AGPL-3.0 y habla HTTP, WebSockets y gRPC, con un módulo de navegador para comprobaciones de front-end. Los thresholds convierten un objetivo, como un límite al percentil 95, en un código de salida distinto de cero para la CI. Para escalar, el k6-operator ejecuta pruebas distribuidas en Kubernetes, y Grafana vende un servicio alojado.

Ideal para desarrolladores que mantienen sus pruebas de API junto al código y para pipelines de CI. Elige otra cosa si tu equipo no quiere JavaScript o si la licencia AGPL no encaja con cómo integras o distribuyes la herramienta. La comparamos a fondo en k6 vs Artillery.

¿Para quién es Gatling?

Para equipos en la JVM que quieren pruebas como código y un informe HTML detallado sin añadir nada. También ofrece un SDK de JavaScript y TypeScript sobre el mismo motor.

Gatling ejecuta los usuarios virtuales sobre un motor no bloqueante construido con Netty, así que una sola máquina puede generar mucha carga. Las simulaciones se escriben en Java, Kotlin, Scala, JavaScript o TypeScript y se ejecutan con plugins de Maven, Gradle, sbt o npm. La edición comunitaria tiene licencia Apache 2.0 y cubre HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events y JMS, mientras que sus componentes de gRPC, MQTT y GraphQL usan la licencia enterprise de Gatling.

Ideal para equipos de Java y Scala, y para quien quiera informes completos sin herramientas extra. Elige otra cosa si necesitas repartir la carga entre máquinas solo con la edición open source: generar carga desde infraestructura gestionada o privada es la función de Gatling Enterprise, la edición comercial.

¿Es Locust una buena opción para equipos de Python?

Sí. Las pruebas de Locust son Python puro, así que bucles, condiciones y cualquier biblioteca de Python funcionan como en código normal.

Locust tiene licencia MIT y funciona por eventos con gevent, lo que permite a un solo proceso atender a muchos usuarios. Las pruebas se lanzan desde la línea de comandos o desde una interfaz web que muestra en directo el rendimiento, los tiempos de respuesta y los errores, y Locust reparte una prueba entre varias máquinas por sí mismo. HTTP viene integrado y otros protocolos se añaden escribiendo Python.

Ideal para equipos de Python, escenarios con lógica compleja y quien disfrute siguiendo una prueba en el navegador. Elige otra cosa si quieres pruebas declarativas al estilo de un archivo de configuración, o si un plugin listo para un protocolo poco común importa más que escribir uno propio.

¿Cuándo tiene sentido Artillery?

Cuando tu equipo vive en Node.js, le gustan los escenarios cortos en YAML o quiere pruebas de navegador con Playwright en la misma herramienta que sus pruebas de API.

Artillery tiene sobre todo licencia MPL-2.0, con algunos módulos de Azure bajo una licencia source-available. Trae de serie HTTP, WebSocket y Socket.IO, suma gRPC y Kinesis con motores adicionales, y sus comandos run-lambda y run-fargate reparten una prueba entre workers de tu propia cuenta de AWS. El comando run-aci hace lo mismo en Azure Container Instances, con una suscripción de pago a Artillery para algo más que una evaluación (comprobado el 9 de octubre de 2026).

Ideal para equipos de Node.js, pruebas mixtas de API y navegador, y empresas que ya usan AWS. Elige otra cosa si prefieres no instalar Node.js en tus generadores de carga o si las pruebas grandes tienen que correr fuera de AWS y Azure.

¿Para qué sirve Vegeta?

Para comprobaciones HTTP rápidas a ritmo constante desde la línea de comandos. Hace una sola cosa, enviar peticiones a un ritmo fijo, y la mantiene sencilla.

Vegeta es una herramienta de Go con licencia MIT que funciona como programa de línea de comandos o como biblioteca de Go, con una CLI pensada para combinarse con otras herramientas de Unix. Como mantiene constante el ritmo de peticiones en lugar de modelar usuarios, responde mejor a preguntas como «¿qué pasa a 500 peticiones por segundo?» que a reproducir recorridos de usuario.

Ideal para comprobar rápido un endpoint, hacer pruebas de capacidad a ritmo fijo y escribir scripts de shell. Elige otra cosa si necesitas recorridos de varios pasos, tiempo de reflexión o informes detallados.

¿Dónde encaja un servicio alojado como LoadFocus?

Ninguna de estas herramientas necesita un servicio alojado, pero generar una carga grande o repartida geográficamente desde tus propias máquinas da trabajo. Un servicio alojado se encarga de generar la carga y deja tus scripts como están.

LoadFocus, el editor de este sitio, es uno de esos servicios. Ejecuta tus planes de prueba de JMeter y tus scripts de k6 desde 25 regiones en la nube. No ejecuta pruebas de Gatling, Locust, Artillery ni Vegeta, así que para esas herramientas se aplican las opciones de escalado de arriba. Grafana Cloud k6 y Gatling Enterprise son las vías alojadas de los propios fabricantes para k6 y Gatling.

¿Cómo elegir entre ellas?

Parte del lenguaje que tu equipo ya escribe y de los protocolos que tienes que probar, y luego mira cómo escala cada herramienta. Eso suele reducir seis opciones a una o dos.

Después escribe la misma prueba corta con tus dos favoritas. Leerlas una al lado de la otra resuelve la mayoría de los debates más rápido que cualquier tabla de funciones, y nuestra guía Cómo hacer una prueba de carga acompaña esa primera prueba paso a paso.

FAQ

¿Qué herramienta de pruebas de carga open source es la más fácil para empezar? Para un solo endpoint HTTP, Vegeta o k6 te dan un resultado en minutos porque cada una es un único binario. Para recorridos de varios pasos, elige la herramienta cuyo lenguaje de pruebas ya escribe tu equipo.

¿Pueden las herramientas de pruebas de carga open source ejecutar pruebas distribuidas? Sí, por caminos distintos: JMeter tiene un modo remoto integrado, Locust se reparte entre máquinas de forma nativa, k6 usa el k6-operator en Kubernetes y Artillery usa AWS Lambda, Fargate o Azure Container Instances. En Gatling, generar carga desde infraestructura gestionada o privada forma parte de la edición comercial Enterprise.

¿Es JMeter mejor que k6? Ninguna es mejor en general. JMeter cubre más protocolos y encaja con el diseño de pruebas en interfaz gráfica, mientras que k6 encaja con desarrolladores que quieren pruebas como código JavaScript en la CI.

Lecturas relacionadas

• Herramientas de benchmark HTTP: wrk, hey, oha, ab y más
• Pruebas de carga con Locust: análisis de la herramienta
• Pruebas de carga con Gatling: la herramienta JVM a fondo
• Herramientas de pruebas de carga WebSocket: seis opciones
• k6 vs Artillery: qué herramienta de pruebas de carga elegir
• Cómo hacer una prueba de carga: guía paso a paso
• Azure Load Testing: análisis del servicio de Microsoft
• Pruebas de carga con Artillery: análisis de la herramienta
• Pruebas de carga con NBomber: análisis del framework .NET
• Pruebas de carga con Tsung: la herramienta Erlang a fondo
• pgbench: benchmark y pruebas de carga de PostgreSQL
• Cómo usar sysbench: benchmarks de CPU, disco y MySQL

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