Tu primer script de k6

Un script de k6 es un archivo JavaScript. Ese es todo el truco, y es por eso que un tester que ya escribe Cypress o Playwright puede volverse productivo con k6 en una tarde.

Lo que cambia no es el lenguaje. Lo que cambia es que k6 toma tu script y lo ejecuta una y otra vez, en muchas copias simultáneas, midiendo cada petición HTTP que hace en el camino.

El script más pequeño que hace algo

Crea un archivo en k6/first-test.js con este contenido:

import http from 'k6/http'
import { sleep } from 'k6'

export default function () {
  http.get('http://localhost:3000/products')
  sleep(1)
}

Esa es una prueba de rendimiento completa y válida. Tres cosas en ella merecen un nombre.

La función default

La función exportada como default es el cuerpo de tu prueba. k6 la llama una vez, después otra, y otra, durante todo el tiempo que la prueba esté configurada para correr. Una pasada por ella se llama iteración.

Ese es el mayor cambio mental viniendo de las pruebas funcionales. En Cypress, tu prueba corre una vez y se acabó. En k6, tu prueba es el cuerpo de un bucle que será ejecutado miles de veces por cientos de usuarios virtuales concurrentes, así que todo lo que pongas ahí ocurre miles de veces.

👨‍🏫 Por eso también un script de k6 no tiene bloques it() ni test(). No hay nada que nombrar, porque el mismo código corre una y otra vez. La unidad de organización en k6 es el escenario, no el caso de prueba.

`http.get()`

El módulo k6/http es cómo haces peticiones. http.get(url) envía un GET y devuelve un objeto de respuesta con los campos que esperarías:

const response = http.get('http://localhost:3000/products')

console.log(response.status)         // 200
console.log(response.timings.duration) // cuánto tardó, en milisegundos
console.log(response.json('total'))  // lee un campo del cuerpo JSON

Cada petición hecha a través de ese módulo se mide automáticamente y entra en las métricas que k6 imprime al final. No instrumentas nada por tu cuenta.

`sleep()`

sleep(1) pausa al usuario virtual durante un segundo antes de que empiece la siguiente iteración.

Es tentador borrarlo y "probar más fuerte". No lo hagas. Un usuario virtual sin sleep() no es un usuario, es un bucle apretado, y va a generar un patrón de peticiones que ninguna población real de humanos produciría. Trataremos esto en serio en la lección sobre recorridos reales de usuario, donde sleep() recibe su nombre verdadero: tiempo de reflexión (think time).

Ejecutándolo

k6 run k6/first-test.js

Por defecto, k6 corre un usuario virtual por una iteración y sale. Eso es deliberado: tu primera ejecución debe decirte si el script funciona, no qué tan rápida es la API.

Leyendo el resumen

Cuando la ejecución termina, k6 imprime un bloque de métricas. Recortado a lo que importa hoy:

     checks.........................: 0.00%  0 out of 0
     data_received..................: 12 kB  11 kB/s
     data_sent......................: 391 B  366 B/s
     http_req_duration..............: avg=8.42ms  min=8.42ms med=8.42ms max=8.42ms p(90)=8.42ms p(95)=8.42ms
     http_req_failed................: 0.00%  0 out of 1
     http_reqs......................: 1      0.93/s
     iteration_duration.............: avg=1.01s   min=1.01s  med=1.01s  max=1.01s  p(90)=1.01s  p(95)=1.01s
     iterations.....................: 1      0.93/s
     vus............................: 1      min=1        max=1

Cuatro de esas líneas cargan casi todo el significado:

http_req_duration es cuánto tardaron las peticiones. Ese es el número que la gente quiere decir cuando dice "tiempo de respuesta".
http_req_failed es la tasa de error. 0.00% aquí, y es lo primero que deberías mirar, porque una API rápida que devuelve errores no es rápida, está rota.
http_reqs es cuántas peticiones se hicieron, y la tasa por segundo al lado es tu throughput.
iterations es cuántas veces corrió tu función default.

Nota que avg, min, med, max y los percentiles son todos el mismo número. Con una sola petición hay una sola medición, así que toda estadística la describe. Eso cambia en el momento en que agregas un segundo usuario virtual, y leer esas columnas correctamente es justamente el tema completo de la lección Leyendo los resultados.

👨‍🏫 Nota también que iteration_duration es alrededor de un segundo mayor que http_req_duration. Ese es tu sleep(1). El tiempo de reflexión cuenta para la iteración, no para la petición.

Visión general de los comandos 📖

`k6 run`

Ejecuta un script de k6. Sin opciones, ejecuta una iteración con un usuario virtual.

Sintaxis:

k6 run <ruta-del-script>

Ejemplo:

k6 run k6/first-test.js

`k6 run --vus --duration`

Sobrescribe el número de usuarios virtuales y cuánto tiempo corre la prueba, directo desde la línea de comandos.

Sintaxis:

k6 run --vus <numero> --duration <tiempo> <ruta-del-script>

Ejemplo:

k6 run --vus 10 --duration 30s k6/first-test.js

Contenido sugerido 📚

Ejercicio 🎯

Escribe k6/first-test.js tú mismo, ejecútalo y luego cambia una cosa a la vez para ver qué hace cada cambio al resumen:

Ejecútalo tal como está, con la iteración única por defecto.
Ejecútalo de nuevo con --vus 5 --duration 10s y compara http_reqs e iterations.
Quita el sleep(1), ejecuta la versión de diez segundos de nuevo y mira qué pasó con http_reqs y con http_req_duration.
Vuelve a poner el sleep(1).

🙊 En el paso 3 deberías ver http_reqs saltar alrededor de un orden de magnitud, porque cinco usuarios virtuales sin tiempo de reflexión martillan la API tan rápido como esta puede responder. Observa http_req_duration subir al mismo tiempo: no hiciste la API más lenta, hiciste la carga más pesada. Esta es la primera vez que vas a causar un cambio de rendimiento a propósito, y vale la pena quedarse un minuto con eso.

La versión terminada de este script está en el directorio k6/ del repositorio del curso.

Muéstrale al mundo lo que aprendiste 🌎

Para mostrarle a tu red profesional lo que aprendiste en esta lección, publica lo siguiente en LinkedIn.

Estoy haciendo el curso "Pruebas de Rendimiento con k6" de @Walmyr Lima e Silva Filho en la @Talking About Testing School, donde escribí mi primer script de k6 y aprendí a leer las métricas de resumen que imprime: tiempo de respuesta, tasa de error, throughput e iteraciones. #TalkingAboutTesting #TATSchool #PerformanceTestingWithK6 #k6 #PerformanceTesting

👨‍🏫 Recuerda etiquetarme en tu publicación. Aquí está mi perfil de LinkedIn.