Guía de usuariok6 · Workspaces · IA

2. Primeros pasos

k6 en tu equipo

• Windows (instalador habitual): la app suele incluir k6 listo para usar; no necesitas instalarlo por separado para ejecutar pruebas desde Performante.
• macOS y Linux: próximamente.

Cuenta y primer uso

• Inicio de sesión: introduce email y contraseña o el método que indique la pantalla (a veces también Google).
• Primera vez: se crea un workspace Default Workspace sin carpetas ni tests; los cambios se guardan solos mientras trabajas.

---

3. Workspaces y organización

• Workspaces: agrupan tus pruebas; puedes tener varios.
• Carpetas: dentro de un workspace, organiza tests en carpetas.
• Barra lateral: la puedes redimensionar; con doble clic en el separador la pliegas o despliegas.
• Multiselección: elige varios tests para acciones en lote.
• Exportar / importar: guarda workspaces completos o sueltos en JSON y vuelve a cargarlos.
• Importar colección Postman: arrastra un JSON de colección Postman en la app.
  • Se crea un workspace con una petición por ítem de Postman (los ejemplos no se importan).
  • Si hay nombres repetidos, se renombran como copy, copy 2, etc.
  • No se importan peticiones pensadas para el servicio de IA de Gemini.
• Importar cURL / API: pega cURL, gRPCurl, URLs o JSON de Performante/Postman según te indique el asistente en pantalla.

---

4. Constructor de pruebas

Cada petición se define en la parte central de la app: método y URL, parámetros de query, cuerpo (si aplica), cabeceras y validaciones. Los valores pueden incluir {{nombreDeVariable}}, que se sustituyen por el valor del entorno activo al generar o ejecutar el script.

Método HTTP y URL

• Métodos disponibles: GET, POST, PUT, PATCH y DELETE. Eliges el método en el desplegable junto a la barra de URL.
• URL: escribe la dirección completa del endpoint (por ejemplo https://api.ejemplo.com/v1/recurso). También admite variables {{...}} en la URL.
• Aunque los parámetros de query se suelen asociar a GET, la tabla Params añade pares clave–valor a la query string según la configuración de la petición; el método lo eliges tú según lo que exija la API.

Params (parámetros de query)

• Tabla de clave, valor y notas (texto libre para documentar).
• Cada fila se puede activar o desactivar sin borrarla.
• Los valores pueden llevar {{variable}}. Lo que escribas aquí se concatena a la URL como query string (por ejemplo ?page=1&limit=10).

Body (cuerpo de la petición)

El tipo de cuerpo se elige en un desplegable. Opciones:

Subtipos de “raw”

Si eliges raw, puedes indicar el formato del contenido para el resaltado y el comportamiento del editor:

• JSON — objetos y arrays; la app puede formatear (embellecer) el JSON cuando lo solicites.
• Text — texto plano sin estructura JSON.
• XML — documentos XML.
• HTML — marcado HTML.

En el editor de cuerpo también puedes usar {{variable}} dentro del texto cuando corresponda.

Headers (cabeceras)

• Tabla de cabeceras con nombre, valor y casilla para activar o desactivar cada fila.
• Puedes usar {{variable}} en los valores (por ejemplo Bearer {{token}}).
• La app puede sugerir valores habituales (por tipos de contenido o cabeceras frecuentes) para ir más rápido.
• Las cabeceras que pongas aquí son las que k6 enviará con la petición (junto con las que añada el runtime según el tipo de body).

Validaciones (aserciones)

Las validaciones son comprobaciones sobre la respuesta. Si alguna falla, el test se considera fallido a nivel k6 (check). Puedes tener varias filas y desactivar las que no quieras sin borrarlas.

Tipos de validación:

1. Status code (código de estado)
   Comprueba el código HTTP de la respuesta. Operadores:

   • equals — un código concreto (ej. 200).
   • in — lista de códigos permitidos separados por comas (ej. 200,201).
   • range — rango (ej. 200-299).

2. Response body (cuerpo de la respuesta)
   Inspecciona el cuerpo como texto. Operadores:

   • contains — debe contener un fragmento de texto.
   • equals — coincidencia exacta con el cuerpo (uso más estricto).
   • regex — debe coincidir con una expresión regular.

3. JSONPath
   Sobre respuestas JSON, apunta a un valor con una expresión JSONPath (ej. $.data.id). Operadores:

   • exists — el nodo debe existir.
   • equals — el valor en esa ruta debe ser igual al esperado.
   • greater_than — comparación numérica “mayor que” en esa ruta.

4. Header (cabecera de respuesta)
   Indicas el nombre de la cabecera de respuesta y el valor esperado (por ejemplo comprobar Content-Type o cabeceras custom).

5. Response time (tiempo de respuesta)
   Comprueba la duración de la petición en milisegundos. Operadores: menor que, mayor que o igual al umbral que definas.

---

5. Tipos de carga y modelos

En cada test configuras qué escenario quieres simular (tipo de prueba) y, salvo en monitoreo, cómo quieres expresar la carga (modelo: usuarios virtuales o peticiones por segundo). El gráfico de perfil muestra la forma de la carga en el tiempo; la vista previa de opciones k6 traduce eso a lo que ejecutará k6.

Formas de modelar la carga (VU y RPS)

Disponibles en todos los tipos de prueba excepto Monitoreo (en monitoreo no aplica este selector).

• Usuarios virtuales (VU — Virtual Users)

  • Simulas cuántos usuarios concurrentes golpean el sistema a la vez.
  • Es la forma natural de pensar en “50 usuarios en la web” o “200 sesiones abiertas”.
  • La app genera un perfil donde subes, mantienes o bajas el número de VU en fases (subida, meseta, bajada, etc., según el tipo de test).

• Peticiones por segundo (RPS — Requests per Second)

  • Fijas un objetivo de caudal: cuántas peticiones por segundo quieres que se intenten en total (no cuántos usuarios hay detrás).
  • Sirve cuando te interesa más el volumen de tráfico que el paralelismo humano (APIs, microservicios, colas).
  • k6 reparte las llegadas para acercarse a esa tasa; en Performante, en modo RPS, la app puede pedirte una estimación del tiempo de respuesta medio (en milisegundos) en algunos tipos, porque ayuda a ajustar cómo se programa la tasa objetivo.

Cómo elegir: usa VU si piensas en concurrencia real de usuarios; usa RPS si tienes un objetivo de throughput (“debe aguantar X peticiones por segundo”) o quieres comparar escenarios por caudal fijo.

---

Load (carga)

• Para qué sirve: reproducir una carga esperada “normal” o de referencia: tráfico estable durante un tiempo, sin buscar el límite del sistema.
• Idea: subes de un nivel inicial a un objetivo (VU o RPS), lo mantienes un rato y luego bajas de forma controlada.
• Cuándo usarlo: validar que el servicio cumple con el uso típico, antes de pruebas más agresivas, o como línea base para comparar versiones.

Stress (estrés)

• Para qué sirve: subir la carga de forma progresiva hasta un pico alto y mantenerlo, para ver cómo se comporta el sistema bajo presión sostenida.
• Idea: rampa de subida → meseta en el máximo configurado → rampa de bajada.
• Cuándo usarlo: comprobar degradación, colas, timeouts o errores cuando el tráfico supera lo habitual pero de forma gradual, no en un golpe único.

Spike (pico)

• Para qué sirve: simular picos bruscos de tráfico: de repente mucha más carga, luego vuelta a la calma (y puedes repetir varios picos).
• Idea: partes de una línea base, subes rápido a un pico, lo mantienes un tiempo, recuperas a la base; el número de picos es configurable.
• Cuándo usarlo: lanzamientos, campañas, noticias virales, finales de evento, o cualquier caso donde el tráfico no sube despacio sino en saltos.

Endurance (resistencia / soak)

• Para qué sirve: dejar el sistema mucho tiempo bajo carga moderada y estable para detectar fugas de memoria, degradación lenta, errores que solo aparecen al cabo de horas o problemas acumulativos (discos, logs).
• Idea: subida controlada → tramo largo a carga sostenida → bajada.
• Cuándo usarlo: cuando necesitas confianza en estabilidad en el tiempo, no solo en un pico corto, antes de confiar en producción prolongada.

Breakpoint (punto de ruptura)

• Para qué sirve: incrementar la carga por escalones (más VU o más RPS en cada paso) hasta acercarte al punto en que el sistema deja de cumplir (errores, latencias inaceptables o saturación).
• Idea: en cada paso mantienes la carga un tiempo fijo y luego subes otro escalón, hasta un máximo que definas.
• Cuándo usarlo: estimar el techo de capacidad, dimensionar infraestructura o comparar optimizaciones entre versiones.

Monitoring (monitoreo)

• Para qué sirve: comprobar de forma periódica que un endpoint responde (disponibilidad, smoke checks), no para generar una carga masiva de estrés.
• Idea: defines un intervalo entre peticiones y una duración total; el test ejecuta llamadas repetidas en ese ritmo.
• En Performante: este tipo no usa el selector VU/RPS; las ejecuciones de monitoreo no abren el dashboard k6 embebido como en otras pruebas, acorde a un uso más ligero.

---

Resumen rápido

---

6. Entornos, variables, Setup Scripts y vista k6

Entornos (estilo Postman)

• Elige el entorno activo en el desplegable; puedes crear (+), renombrar, borrar y exportar.
• Los nombres de entorno tienen un máximo de 15 caracteres (igual que carpetas y tests en la app).

Variables

• En cada entorno puedes definir variables tipo texto, número, sí/no y JSON.
• Úsalas en las peticiones como {{nombre}}.

Importar entorno Postman

• Arrastra un JSON de entorno Postman para crear un entorno nuevo.

Setup Scripts (pestaña Setup)

En la pestaña Setup del test (la que en la interfaz puede mostrarse como “Setup” / script de configuración) concentras todo lo que ocurre una vez antes de la ejecución del escenario k6 y opciones que alteran cómo se registra la petición o qué cookies se envían.

Editor setup() de k6

• Es un editor de código (JavaScript al estilo k6) dedicado a la función setup(): k6 la ejecuta una sola vez al inicio; lo que devuelvas (return { ... }) queda disponible para las VU como datos de contexto (tokens, IDs, cabeceras preparadas, etc.).
• Snippets: menú Snippets con plantillas agrupadas por categoría. Al elegir una, se inserta el código en el cursor (o al final del script). Si el fragmento trae import que ya existen en tu script, la app evita duplicarlos.
  • Categorías típicas: Authentication (token Bearer, OAuth2 client credentials, Basic Auth), Data (datos aleatorios, carga de CSV con SharedArray, obtener IDs desde una API), Setup Utilities (crear usuario de prueba, sembrar datos, validar variables de entorno __ENV y devolver URLs o cabeceras listas).
• Clear: vacía el editor del setup() por completo.
• El editor tiene números de línea, resaltado y plegado de bloques para scripts largos.

Helpers de registro automático (logging)

• Bloque titulado en la app como ayuda para elegir qué se escribe en consola durante la ejecución del script generado (request/response).
• Request: casillas para registrar URL, método, cuerpo y cabeceras de la petición.
  • La casilla Body de la petición no está disponible si el método del test es GET (no tiene sentido en ese caso).
• Response: casillas para código de estado, cuerpo, cabeceras y cookies de la respuesta.
• Útil para depurar sin editar a mano el script k6; ten en cuenta que loguear cuerpos enteros puede llenar la consola o exponer datos sensibles en entornos compartidos.

Cookies de la petición (Request cookies)

• Tabla para definir cookies que k6 enviará con la petición del test, usando el jar de cookies de k6 (http.cookieJar() en el script generado).
• Por cada cookie puedes indicar:
  • Name y Value
  • Path (ruta, p. ej. /)
  • Domain (dominio, p. ej. api.ejemplo.com)
  • Secure — solo envío por HTTPS
  • Max age — vida en segundos
  • Expires — fecha de caducidad (texto que acepte el runtime, p. ej. 2025-12-31)
  • HttpOnly — cookie no accesible desde JavaScript en el navegador (relevante según cómo simule el cliente)
• Botón para añadir filas y eliminar cookies que no necesites.

---

Vista previa del script k6

Es otra pestaña del test (p. ej. Preview / vista del script k6), distinta de Setup:

• Ves el script k6 generado a partir del constructor (URL, método, body, headers, validaciones, tipo de carga, setup(), cookies, logging).
• Edit Script / Editar: pasa a modo script personalizado: dejas de depender del generador para ese test y editas el texto completo del script. La app muestra un aviso de que estás en modo personalizado.
• Discard / Descartar: vuelves al script generado automáticamente y pierdes los cambios manuales de ese modo.
• Save as Test / Guardar como test: guarda el contenido actual como un ejemplo reutilizable ligado a esa petición (mismo tipo de carga y opciones que tenías al guardar, salvo que indiques lo contrario en el flujo de la app). Sirve para versiones del escenario (distintos scripts o configuraciones) sin duplicar la petición en el árbol.
• Copiar el script al portapapeles y autocompletado en el editor (API típica de k6 como http.get, check, etc.) cuando editas a mano.

---

7. Ejecutar pruebas y resultados

Cómo se inicia una ejecución

• Pulsas Ejecutar test en la barra superior cuando tienes seleccionada una petición o un ejemplo guardado (test example) de esa petición.
• Si tu cuenta no tiene permiso para ejecutar (por ejemplo suscripción no activa), la app puede mostrar primero un diálogo de actualización de plan en lugar del flujo normal.

Confirmación antes de ejecutar

Se abre el diálogo Confirmación de ejecución con dos bloques principales:

1. Resumen del test (Test Summary)

• Endpoint: para una petición normal es MÉTODO + URL (incluye la query si es GET y tienes params). Si ejecutas un ejemplo guardado, el resumen puede mostrar el nombre del ejemplo como referencia.
• Workspace: aparece el nombre del workspace en el que estás trabajando. No es lo mismo que el “entorno” de variables del panel inferior (Postman-style); sirve para verificar que estás en el proyecto correcto.
• Carga / VUs: un valor asociado al pico o configuración de carga (la etiqueta en inglés puede decir “Max Virtual Users” aunque en modo RPS el número represente el planteamiento de carga que resume la app).
• Tipo de test y duración (cuando aplica; en monitoreo la duración puede no mostrarse igual).
• Campos adicionales según el tipo: por ejemplo número de picos y tasas en Spike, tiempos de rampa o meseta en Stress, etc.
• Si en la URL o en los textos hay {{variables}}, el resumen puede resaltarlas; al pasar el ratón por una URL truncada suele mostrarse el texto completo en un tooltip.

2. Lista pre-ejecución (checklist)
Ocho ítems agrupados en cuatro bloques; debes marcarlos todos (o usar Marcar todos) para habilitar el botón de ejecutar:

• Pie del diálogo: advertencia de que la prueba puede generar mucho tráfico y afectar al sistema de destino.
• Cancelar cierra sin ejecutar. Clic fuera o Escape también suelen cerrar el diálogo.

Qué ocurre al ejecutar (terminal y archivos)

• La app escribe el script en una carpeta temporal y lanza k6 en una ventana de terminal externa (en Windows suele abrirse una consola con un .bat que puedes revisar; el comando y mensajes de Performante aparecen en esa ventana). Así ves logs en vivo y el proceso no queda oculto dentro solo de la interfaz.
• Con informe web de k6 (caso habitual): para tipos de prueba distintos de Monitoreo, la app arranca k6 con el dashboard web integrado de k6 (K6_WEB_DASHBOARD), sin abrir el navegador sola al inicio, y define una exportación de informe HTML (y datos de resumen en JSON) en la carpeta de resultados del usuario. El nombre del archivo suele seguir un patrón como:
  NombreDelTest_TipoDeTest_AAAA-MM-DD_HH-MM.html
• Solo terminal (sin dashboard embebido en la app): para Monitoreo la ejecución es como k6 run clásico: no se activa el flujo del dashboard web en la app; sigues viendo la salida en la terminal.

Panel inferior: Dashboard durante y después del run

En la pestaña dashboard del panel inferior:

• Mientras arranca: mensaje tipo “Iniciando servidor del dashboard…” o “Ejecutando…”. Aparece Detener ejecución para enviar una señal de parada a los procesos k6 que la app haya lanzado (útil si el test se queda colgado o quieres cortar antes de tiempo).
• Dashboard en vivo: si todo va bien, se muestra la vista web del dashboard de k6 en http://127.0.0.1:5665 dentro de un visor embebido. Puedes usar Abrir en navegador para verlo en tu navegador externo (misma URL local).
• Paso al informe HTML: al terminar la prueba, k6 puede exportar el HTML a tu carpeta de resultados; la app detecta el archivo, deja de mostrar solo el dashboard en vivo y carga el informe estático (file://…) cuando está listo. Puede mostrarse un mensaje del estilo “Cerrando dashboard… el informe se cargará cuando esté listo”.
• Limpiar: cuando el informe ya es un archivo local o ha fallado el live dashboard, suele habilitarse la acción de limpiar la vista del panel para empezar de cero.
• Si hay error al lanzar k6 o al dashboard, el panel puede mostrar el mensaje de error en lugar de la URL.

Tras una ejecución con informe, la lista Test results en la barra lateral se actualiza para incluir el nuevo HTML.

Carpeta de resultados (barra lateral)

La sección Test results (resultados de test) lista informes HTML guardados bajo la carpeta de datos de la app (por defecto algo como …/Performante/test_results/ en Windows).

• Expandir / plegar la sección para ver la lista. Botón para abrir la carpeta en el explorador de archivos y otro para refrescar la lista.
• Doble clic en un archivo → abre el informe con la aplicación predeterminada del sistema.
• Clic simple selecciona; Ctrl/Cmd + clic permite selección múltiple.
• Arrastrar y soltar archivos sobre la raíz de resultados o sobre una carpeta para moverlos (también hay diálogo “Mover a carpeta” en el menú contextual).
• Clic derecho en un archivo: Resumen IA (un archivo) o Comparar informes (varios seleccionados), Mostrar en el explorador, Renombrar, Mover a carpeta (si hay carpetas o el archivo está en subcarpeta), Eliminar. Con varios seleccionados, eliminar actúa sobre todos.
• Clic derecho en la cabecera de “Test results” → Nueva carpeta para organizar informes. Clic derecho en una carpeta de resultados → Eliminar carpeta.
• Con archivos de resultados seleccionados, Suprimir / Backspace puede abrir el borrado (si el foco no está en un campo de texto).

La app también puede aceptar que arrastres un informe HTML al área de la aplicación para abrirlo o tratarlo según el flujo configurado (importación/visualización de resultado).

---

8. Resúmenes con IA (Gemini)

• Un informe: clic derecho sobre un resultado → opción para generar un resumen con IA.
• Varios informes: selecciona al menos dos resultados y usa la opción de comparar; obtienes un texto en formato markdown.
• Exportar el resumen: PDF o Word (.docx).

---

9. Cuenta y suscripción

Entrar o registrarte

• Usa email y contraseña y, si la app lo ofrece, Google.
• Es la misma pantalla para entrar y para darte de alta: si el email no estaba registrado, se crea la cuenta en ese momento.

Planes

• Si el periodo de prueba o la suscripción han terminado, puede aparecer una pantalla que te invita a ampliar plan o cerrar sesión.
• Sin una suscripción activa, la app puede limitar acciones como ejecutar pruebas, usar resúmenes IA, crear workspaces o exportar informes, y mostrar un mensaje para actualizar el plan.

Sincronización en la nube (plan Pro)

• El plan Pro puede sincronizar de forma cifrada tus workspaces y variables con el servicio en la nube de Performante.
• Al entrar, la app recupera lo que tengas guardado online si existe; también envía cambios de forma periódica y al cerrar.

Tu cuenta en Opciones

• En Opciones → Cuenta verás datos como el email, el plan, el estado de la suscripción, si ya usaste el periodo de prueba y la fecha de vencimiento cuando aplique.

---

10. Datos en tu equipo

• La app guarda tu trabajo en la carpeta de datos de usuario, dentro de Workspaces/ y una subcarpeta asociada a tu cuenta (suele derivarse de tu email, adaptando caracteres no válidos en nombres de archivo).
• Los archivos principales son workspaces.json (workspaces, carpetas, tests y ejemplos) y variables.json (entornos y cuál está seleccionado).

Ejemplo en Windows (sustituye TuUsuario por tu usuario de Windows y parte_local_email por la parte de tu correo antes de @, tal como la normaliza la app):

C:\Users\TuUsuario\AppData\Roaming\Performante\
├── Workspaces\
│   └── parte_local_email\
│       ├── workspaces.json
│       └── variables.json
└── test_results\          ← informes HTML de las ejecuciones (ver sección 7)

Por ejemplo, si tu usuario de Windows es Lucas y entras con lucas.dev@empresa.com, una ruta plausible sería:

C:\Users\Ana\AppData\Roaming\Performante\Workspaces\ana.dev\workspaces.json

• Autoguardado: los cambios se guardan al editar; al cerrar la aplicación se asegura de volcar todo a disco.

---

11. Interfaz e idioma

• Panel inferior: lo puedes redimensionar; incluye pestañas como Variables, Dashboard e IA, según el contexto.
• Doble clic en los separadores del panel o de la barra lateral para plegar o expandir.
• Ayudas breves en campos de configuración cuando pasas el cursor o enfocas la opción.
• Idioma de la interfaz: español e inglés (según el selector de la app).

---

12. Herramientas

• Desde el menú de herramientas suele haber una guía sobre la versión de k6 recomendada, un enlace a la documentación oficial de k6 y una acción para comprobar qué versión de k6 usa la app en tu equipo.

---

Si tu organización usa una versión personalizada, siguen las instrucciones que te hayan dado ellos.