Si su API funciona bien para un usuario pero falla bajo tráfico, necesita pruebas de carga, y k6 es una de las formas más limpias de hacerlo. Esta guía cubre qué es k6, cómo instalarlo, cómo escribir su primer script y cómo leer los resultados, para que pueda tratar las pruebas de carga como parte de su rutina normal de pruebas de rendimiento de API. También veremos cómo k6 encaja junto con las pruebas funcionales en CI, basándonos en la documentación oficial de k6 donde los detalles importan.
¿Qué es k6?
k6 es una herramienta de pruebas de carga de código abierto, ahora mantenida por Grafana. Usted escribe su prueba como un archivo JavaScript, k6 lo ejecuta con un rápido motor Go, y bombardea sus endpoints con tráfico simulado. La división es deliberada: usted autoriza las pruebas en un lenguaje que la mayoría de los desarrolladores ya conocen, pero el generador de carga en sí se ejecuta como Go compilado, por lo que una sola máquina puede manejar una gran cantidad de usuarios virtuales sin saturarse.
k6 está construido para un solo trabajo y lo hace bien: generar carga sostenida y repetible y medir cómo responde su sistema. Informa percentiles de latencia, tasas de solicitud, tasas de error y le permite establecer reglas de aprobación/fallo sobre esos números. Ese enfoque es el punto. k6 no es un cliente API, una herramienta de documentación o un framework de pruebas funcionales. Es un motor de carga.
Algunos términos que encontrará constantemente:
- Usuario virtual (VU): un usuario simulado que ejecuta su script en un bucle. Más VUs significa más carga concurrente.
- Iteración: un paso completo a través de su función de prueba. Un VU ejecuta iteraciones consecutivamente.
- Etapa (Stage): un paso en un perfil de carga, utilizado para aumentar o disminuir los VUs con el tiempo.
- Umbral (Threshold): una regla de aprobación/fallo en una métrica, como "el percentil 95 de latencia debe mantenerse por debajo de 500ms".
- Verificación (Check): una aserción no fatal sobre una respuesta, como "el estado fue 200". Las verificaciones fallidas se cuentan, pero la prueba continúa ejecutándose.
Instalación de k6
k6 se distribuye como un único binario, por lo que la instalación es breve. En macOS con Homebrew:
brew install k6
En Windows con Chocolatey:
choco install k6
En Debian o Ubuntu, añada el repositorio apt de Grafana e instale:
sudo gpg -k
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg \
--keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" \
| sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6
Confirme que funciona:
k6 version
También está disponible una imagen de Docker si prefiere no instalar nada localmente. Consulte la página de instalación en la documentación para ver los comandos actuales, ya que los detalles del paquete cambian con el tiempo.
Su primer script k6
Una prueba k6 es un módulo JavaScript con una función predeterminada. k6 llama a esa función una vez por iteración, por VU. Aquí tiene un script mínimo que accede a un endpoint y verifica la respuesta:
import http from 'k6/http';
import { check, sleep } from 'k6';
export default function () {
const res = http.get('https://test-api.example.com/users');
check(res, {
'status is 200': (r) => r.status === 200,
'body is not empty': (r) => r.body.length > 0,
});
sleep(1);
}
Guárdelo como script.js y ejecútelo:
k6 run script.js
Por defecto, k6 ejecuta un VU para una iteración. Ese sleep(1) añade una pausa de un segundo entre iteraciones, lo que imita a un usuario real haciendo una pausa entre acciones. Sin la pausa, cada VU se repite tan rápido como la red lo permite, lo cual es útil para pruebas de rendimiento bruto pero poco realista para la simulación del comportamiento del usuario.
Las llamadas a check() son aserciones "suaves". Una verificación fallida aparece en el resumen pero no detiene la ejecución. Eso es intencional. Bajo carga pesada, se esperan algunos fallos, y se desea que la prueba siga midiendo para que pueda ver lo mal que se pone.
VUs, etapas y umbrales
El primer script ejecuta un solo usuario una vez. Las pruebas de carga reales consisten en controlar cuántos usuarios acceden a su API y durante cuánto tiempo. Esto se configura con un objeto options exportado.
La forma más sencilla establece un número fijo de VUs y una duración:
export const options = {
vus: 50,
duration: '30s',
};
Eso ejecuta 50 usuarios virtuales durante 30 segundos. Más útil es un perfil de escalada (ramping) construido a partir de etapas, que le permite simular el tráfico aumentando, manteniéndose y disminuyendo:
export const options = {
stages: [
{ duration: '1m', target: 100 }, // escalar hasta 100 VUs
{ duration: '3m', target: 100 }, // mantener en 100 VUs
{ duration: '1m', target: 0 }, // escalar hacia abajo a 0
],
thresholds: {
http_req_duration: ['p(95)<500'], // 95% de las solicitudes en menos de 500ms
http_req_failed: ['rate<0.01'], // menos del 1% de errores
},
};
Los umbrales (thresholds) son donde k6 se gana su lugar en CI. Si un umbral falla, k6 sale con un código distinto de cero. Eso significa que un paso de pipeline puede hacer que la compilación falle cuando la latencia o las tasas de error superen una línea que usted establece. Está codificando un presupuesto de rendimiento como código, de la misma manera que codificaría una aserción funcional.
Un mapa rápido de los perfiles de carga comunes y la pregunta que cada uno responde:
| Perfil | Objetivo | Lo que le dice |
|---|---|---|
| Humo (Smoke) | Carga mínima, verificar que el script se ejecuta | Que la prueba en sí es correcta |
| Carga (Load) | Tráfico normal esperado | Si la API aguanta el día a día |
| Estrés (Stress) | Superar el pico esperado | Dónde empieza a fallar |
| Pico (Spike) | Salto brusco y repentino en VUs | Si puede sobrevivir a un pico de tráfico |
| Saturación (Soak) | Carga moderada durante horas | Fugas de memoria, degradación lenta |
No necesita los cinco. Empiece con las pruebas de humo y carga. Añada las de estrés y pico una vez que conozca sus números normales. Para una visión más amplia de los enfoques y las métricas detrás de ellos, los fundamentos de las pruebas de rendimiento se mantienen en todas las herramientas, no solo en k6.
Lectura de los resultados de k6
Cuando una ejecución finaliza, k6 imprime un resumen en la terminal. Las líneas que más importan:
- http_req_duration: tiempo total de solicitud, mostrado como promedio, min, max, mediana, p90 y p95. Los percentiles p95 y p99 le indican lo que experimentan sus usuarios más lentos. Los promedios ocultan el dolor; los percentiles lo revelan.
- http_req_failed: la proporción de solicitudes que fallaron. Observe cómo se mueve esto a medida que aumentan los VUs.
- http_reqs: solicitudes totales y solicitudes por segundo. Este es su rendimiento (throughput).
- iterations: cuántas pasadas completas se realizaron y la tasa.
- vus y vus_max: usuarios virtuales activos y pico.
- checks: la tasa de éxito de sus aserciones
check().
Lea los percentiles, no los promedios. Un tiempo de respuesta promedio de 200ms suena bien hasta que ve un p99 de 4 segundos, lo que significa que uno de cada cien usuarios espera cuatro segundos. Esa cola es donde los usuarios abandonan.
Para cualquier cosa más allá de observar la terminal, k6 puede transmitir resultados a salidas externas. Escribe JSON o CSV, y se integra con los paneles de Grafana y Prometheus para un análisis visual en vivo durante una ejecución. Esa combinación, k6 más Grafana, es la razón por la que a menudo verá la herramienta llamada "grafana k6". Para una prueba única, el resumen de la terminal es suficiente; para el monitoreo continuo, envíe las métricas a algún lugar donde pueda graficarlas.
Dónde encaja k6 y dónde encaja Apidog
k6 es un motor de carga. Responde a la pregunta "¿cómo se comporta mi sistema bajo tráfico sostenido?". No verifica si su API devuelve los datos correctos, coincide con su contrato o maneja la autenticación correctamente en cada endpoint. Esas son preguntas de pruebas funcionales y de contrato, y necesitan una herramienta diferente.
Esta es la división que vale la pena mantener clara. Usted desea ambos tipos de pruebas en su pipeline, y no compiten:
| Preocupación | Mejor manejado por | Qué responde |
|---|---|---|
| Carga pesada sostenida, percentiles a escala | k6 | ¿Se mantiene rápido bajo tráfico? |
| Corrección funcional, contrato, autenticación | Apidog | ¿Devuelve lo correcto? |
| Regresión en CI en cada commit | Apidog (apidog run) |
¿Este cambio rompió un endpoint? |
| Presupuestos de rendimiento en CI | Umbrales de k6 | ¿La latencia o los errores cruzaron un límite? |
Apidog se encarga de la parte de la corrección. Usted diseña o importa su API, construye escenarios de prueba con aserciones visuales, y los ejecuta en CI con apidog run, de la misma manera que ejecutaría un script k6. La guía CLI de Apidog le muestra cómo integrar esas pruebas funcionales en un pipeline. Apidog también incluye características más ligeras de pruebas de rendimiento para verificaciones rápidas, cubiertas en el tutorial de pruebas de rendimiento de API en Apidog, pero no es un generador de carga de la clase de k6 y no intenta serlo.
Un flujo de trabajo práctico se ve así. En cada commit, Apidog ejecuta sus pruebas funcionales y de contrato para confirmar que la API sigue haciendo lo que debe. Según un horario o antes de una publicación, k6 ejecuta un perfil de carga contra un entorno de staging para confirmar que la API se mantiene rápida bajo tráfico. Puerta de corrección y puerta de rendimiento, cada una con la herramienta construida para ello.
Si está comparando motores antes de comprometerse, k6 se sitúa junto a JMeter, Gatling y Locust. El resumen de herramientas de pruebas de carga y esta comparación de alternativas a Locust exponen las ventajas y desventajas si el lenguaje de scripting o la escala cambian su elección.
Preguntas frecuentes
¿Es k6 gratuito?
Sí. k6 es de código abierto bajo la licencia AGPL, y el binario es gratuito para ejecutar localmente sin límite de usuarios virtuales más allá de su propio hardware. Grafana también ofrece k6 Cloud, un servicio de pago para ejecutar grandes pruebas distribuidas y almacenar resultados, pero nunca tiene que usarlo. La herramienta principal cubre a la mayoría de los equipos. Si desea explorar otras opciones gratuitas primero, la descripción general de herramientas de pruebas de carga enumera lo que ofrece cada una.
¿Necesito saber JavaScript para usar k6?
Necesita JavaScript básico, no una gran experiencia. La mayoría de los scripts de k6 son una función predeterminada, algunas llamadas http.get o http.post, algunas verificaciones y un objeto de opciones. Si puede leer los ejemplos de esta guía, puede escribir una prueba que funcione. No hay un paso de compilación ni un framework que aprender, solo la API de k6.
¿Cuál es la diferencia entre k6 y Apidog para las pruebas de rendimiento?
k6 es un generador de carga dedicado, construido para impulsar un tráfico pesado sostenido e informar percentiles a escala. Apidog es una plataforma API centrada en el diseño, las pruebas funcionales y las pruebas de contrato, con características más ligeras de pruebas de rendimiento para verificaciones rápidas. Use k6 cuando necesite carga real y presupuestos de rendimiento para CI. Use Apidog para la corrección, la validación de contratos y la ejecución de pruebas funcionales en cada commit. Resuelven problemas diferentes y funcionan bien juntos.
¿Puedo ejecutar k6 en CI/CD?
Sí, y es una configuración común. k6 sale con un código distinto de cero cuando un umbral falla, por lo que cualquier sistema de CI puede fallar la compilación ante una regresión de rendimiento. Ejecute k6 run script.js como un paso del pipeline, apúntelo a un entorno de staging y establezca umbrales para la latencia p95 y la tasa de error. Combínelo con pruebas funcionales de apidog run para que cada commit obtenga tanto una verificación de corrección como una verificación de carga.
Conclusión
k6 le ofrece una forma limpia y programable de someter su API a una carga real y medir lo que sucede. Instale el binario, escriba un archivo JavaScript corto, configure VUs y etapas, añada umbrales y lea los percentiles. Ese es todo el ciclo. Mantenga las pruebas de carga separadas de las pruebas funcionales, ya que cada una responde a una pregunta diferente, y ejecute ambas en CI para que nada se escape.
Para la parte de la corrección de esa división, Apidog le permite diseñar, probar, simular y documentar su API en un solo lugar, y luego ejecutar pruebas funcionales en CI con apidog run. Descargue Apidog para combinar la confianza a nivel de contrato con sus ejecuciones de carga de k6.
botón