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 Performate.
• 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 requests (peticiones) y/o ejemplos guardados bajo un request con Ctrl (Windows/Linux) o Cmd (macOS) al hacer clic, o extiende la selección con Mayús + flechas en el árbol. Sirve para borrar o duplicar en lote y para ejecutar varias pruebas en paralelo (ver Ejecución en paralelo).
• 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 solo para el asistente de IA de la app.
• Importar cURL / API: pega cURL, gRPCurl, URLs o JSON de Performate/Postman según te indique el asistente en pantalla.

Biblioteca JS del workspace (código que comparten tus pruebas)

¿Qué es?

Es un cajón de archivos JavaScript propio de ese workspace: sirve para guardar trozos de código que varias peticiones o scripts k6 pueden usar sin copiar y pegar el mismo texto en cada sitio.
No sustituye el script principal de la prueba: es material de apoyo (por ejemplo una función que monta cabeceras, un mapa de URLs de prueba, validaciones repetidas, etc.).

¿Dónde la veo?

Con el workspace desplegado en la barra lateral, debajo del nombre verás el bloque JS library (o el nombre equivalente si cambias el idioma de la interfaz). Ahí se listan carpetas y archivos que solo existen en ese workspace y que gestionas desde la propia app (crear, editar, mover, borrar).

Qué puedes hacer (paso a paso)

1. Crear carpetas o archivos con los botones de la cabecera del bloque, o con clic derecho sobre la raíz o una carpeta. Los archivos nuevos deben llamarse con extensión .js o .mjs.
2. Traer archivos desde tu PC: arrastra .js / .mjs al bloque de la biblioteca. Si el archivo parece un script k6 completo (un test listo para ejecutar), la app puede rechazarlo aquí a propósito: ese tipo de archivo va en la importación o script del test, no en la biblioteca de apoyo.
3. Abrir y editar: clic (o doble clic) en un archivo abre una pestaña con el editor. Guarda con Ctrl+S cuando haya cambios, igual que en otras pestañas.
4. Ordenar: arrastra filas para mover archivos o carpetas. Puedes seleccionar varios con Ctrl/Cmd + clic o un rango con Mayús + flechas cuando el foco está en la librería. Suprimir o Retroceso con algo seleccionado puede pedirte borrar.
5. Copiar y pegar dentro de la biblioteca: con nodos seleccionados, Ctrl+C y Ctrl+V duplican o mueven partes del árbol dentro de la carpeta de destino que tengas activa (si solo seleccionas un archivo, el destino del pegado suele ser su carpeta contenedora). También puedes arrastrar archivos desde el escritorio al bloque.
6. Menú contextual (clic derecho): además de crear, renombrar o borrar, verás copiar ruta de importación: es la línea que debes pegar en tu script k6 para enlazar ese archivo (tiene forma de ./algo.js o ./carpeta/algo.js).

Cómo usarla desde tu script k6

En el editor de script de la petición (o en un ejemplo guardado), escribe una importación relativa usando exactamente la ruta que te dio la opción copiar ruta de importación, por ejemplo:

import { miFuncion } from './helpers/login.js';

Al ejecutar la prueba desde Performate, la app acompaña el script principal con los archivos de la biblioteca que hagan falta según esas rutas (y los que esos archivos importen a su vez). No tienes que subirlos a otro sitio: van dentro del mismo workspace que ya guardas con la app.

Si ejecutas fuera de la app (CI, terminal, otro ordenador)

Desde Performate todo queda enlazado. Si más adelante usas solo un script exportado o herramientas como npx performate run, puede que recibas un único archivo generado: en ese caso los archivos de la biblioteca no “viajan solos”; tendrás que copiarlos en tu proyecto o seguir las opciones que indique el Automation Hub (Pro+) para que el entorno de CI tenga la misma estructura de archivos.

Nota para usuarios avanzados

Los datos de la biblioteca se guardan junto al workspace (incluido en el JSON de workspaces que la app mantiene por perfil). En Electron, el menú contextual de la cabecera de la biblioteca puede ofrecer abrir la carpeta del workspace en el explorador si necesitas localizar ese archivo en disco.

Datasets (CSV de datos por perfil)

En la zona inferior del panel lateral aparece Datasets, separado del árbol de carpetas/tests. Ahí ves archivos CSV y subcarpetas que viven en disco, unificados por cuenta/perfil de datos (workspaceUserId, la misma lógica de carpeta que bajo Workspaces/…): no están duplicados por cada workspace de nombre en la lista.

• La ruta habitual en Windows coincide con algo como …\AppData\Roaming\Performate\data\<perfil>\datasets\ (ver también Datos en tu equipo).
• Plegado: la sección se despliega con la flecha; al abrirse, puede ceder más altura visual a esa zona y Test results sobre el divisor del árbol.
• Cabecera — acciones rápidas: nueva carpeta, nuevo CSV, abrir carpeta datasets en el explorador del sistema y refrescar la lista desde disco.
• Árbol vacío: hasta que no hay carpetas CSV listadas, la app muestra un texto guía para crear carpeta o CSV desde la cabecera.
• Mover elementos: puedes arrastrar archivos u otra carpeta sobre la carpeta de destino, o soltarlos en la raíz (zona donde se listan CSV de nivel superior). También tienes herramientas de menú contextual para renombrar.
• Abrir CSV: clic en un archivo abre pestaña central con editor de texto CSV; desde ahí aplican el guardado y el cierre de pestaña igual que otros borradores. Con un CSV abierto, la barra superior pasa al modo datos: no muestra controles HTTP ni Ejecutar (no es una petición k6 ejecutable hasta que hagas **open(...) desde un script guardado).
• Multiselección: Ctrl/Cmd + clic en varios archivos/carpetas. Copiar/pegar dentro de Datasets: con selección sobre datasets, Ctrl+C la guarda en un buffer interno de Performate para datasets (no reemplaza necesariamente un “copiar” del árbol de requests). Ctrl+V crea duplicados físicos en disco bajo la última carpeta establecida como destino por un clic normal en un archivo (carpeta padre) o en una carpeta; si no hay destino elegido así, suele usar la raíz de Datasets.
• Copiar ruta absoluta: menú contextual en archivo o carpeta → Copiar ruta. Útil para usar en open('…') en setup(), script principal o ejemplo guardado (k6 resuelve open() frente al directorio del script en ejecución; las rutas bajo temporales cambian cada run, por eso un camino absoluto al archivo bajo tu carpeta datasets suele ser lo más estable al ejecutar desde Performate).
• Eliminar: menú contextual o Suprimir / Retroceso con selección activa sobre datasets. Para confirmar, debes escribir exactamente la cadena indicada en el cuadro (la ruta relativa del objeto, o una frase fija cuando borras varios ítems a la vez).

Nota sobre snippets de CSV en Setup: los snippets tipo “CSV / SharedArray” que insertas en la pestaña Setup de un request están pensados inicialmente para el directorio data_files dentro de datos de usuario (la interfaz puede ofrecerte abrirlo). Las rutas ahí son distintas de la carpeta Datasets del lateral. Para datos que gestiones en Datasets, usa Copiar ruta o construye manualmente una ruta correcta hasta tu .csv.

---

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).

Pestaña «Validaciones» / «Validations»

En esa pestaña hay dos bloques (en este orden en la interfaz):

1. Umbrales k6 (thresholds) — reglas sobre métricas agregadas de la corrida (p. ej. http_req_duration con p(95), http_req_failed con rate). Cada fila tiene métrica, etiquetas opcionales (tags, p. ej. method:GET), estadístico (p(95), avg, rate, etc.; en métricas tipo gauge como vus solo aplica value), operador (<, >, <=, >=) y valor numérico. Se vuelcan en options.thresholds del script generado; si un umbral no se cumple, k6 marca la ejecución como fallida (código de salida distinto de cero). Sirven como puerta de calidad y son el requisito habitual para generar comandos completos en el Automation Hub (ver Sección 12 — Herramientas).

2. Chequeos sobre la respuesta — las validaciones descritas en la siguiente subsección (check por petición).

Validaciones / chequeos (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 Performate, 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 Performate: 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. 2026-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 en el árbol del workspace tienes más de un ítem seleccionado (dos o más peticiones y/o ejemplos guardados), el mismo botón inicia el modo ejecución en paralelo descrito en la siguiente subsecció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.

Ejecución en paralelo (multi-test run)

Cuando hay al menos dos ítems ejecutables en la multiselección del árbol (peticiones y/o ejemplos guardados), Performate lanza todas esas ejecuciones a la vez (en paralelo): cada una abre su terminal externa con k6 y usa el mismo entorno de variables activo en el panel inferior.

• Qué se ejecuta: por cada petición seleccionada se usa el script generado o el script personalizado de ese request; por cada ejemplo guardado seleccionado se usa su script (con sustitución de {{variables}} según la configuración del ejemplo). La lista del diálogo de confirmación muestra los nombres (hasta 40 visibles con desplazamiento si hace falta).
• Orden interno: primero se encolan las peticiones seleccionadas, después los ejemplos; dentro de cada grupo, el orden sigue el de la selección en el árbol.
• Dashboard embebido: si activas la opción de incluir dashboard y al menos uno de los seleccionados no es de tipo Monitoreo, cada prueba elegible obtiene su propio dashboard en vivo (cada proceso usa un puerto distinto para no chocar). En el panel inferior aparece un selector del estilo «Mostrar dashboard de…» para cambiar de una ejecución a otra mientras corren o al cargar informes.
• Solo terminal: los ítems de tipo Monitoreo en un lote paralelo no usan dashboard embebido para esa fila; verás la indicación de que esa ejecución fue solo en terminal. Si todo el lote es monitoreo, el flujo equivale a varias ejecuciones sin dashboard integrado en la app.
• Detener: Detener ejecución intenta parar todos los procesos k6 que la app haya iniciado en esa sesión, no solo uno.
• Resultados: cada run que use el flujo con informe puede generar sus propios HTML/JSON en la carpeta de resultados, con el patrón de nombres habitual.

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)

• En ejecución en paralelo, el resumen indica cuántos ítems van a ejecutarse, tipo «Paralelo», el workspace y un texto que explica el comportamiento; debajo, la lista de nombres (peticiones y ejemplos).
• 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 Performate 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). Con varias ejecuciones en paralelo, esta acción aplica a todas las instancias arrancadas desde Performate.
• Varias ejecuciones a la vez: si acabas de usar ejecución en paralelo, elige en el desplegable qué run quieres ver en el visor; las URL locales pueden usar puertos distintos por proceso. Las filas marcadas como solo terminal no muestran dashboard embebido para ese ítem.
• Dashboard en vivo: si todo va bien, se muestra la vista web del dashboard de k6 en una URL http://127.0.0.1 con un puerto que asigna la app (suelen usarse puertos libres a partir de 5665; con varios runs a la vez, cada proceso tiene el suyo) dentro de un visor embebido. Puedes usar Abrir en navegador para verlo en tu navegador externo (misma dirección que muestra el visor).
• 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 del perfil (habitualmente algo como …\Performate\data\<perfil>\test_results\ en Windows; véase Datos en tu equipo).

• 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

• 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).
• En el flujo de resumen puedes adjuntar o pegar capturas (formatos habituales de imagen, con límites de tamaño y número que indica la propia pantalla) para dar contexto visual a la IA.

---

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 la suscripción ha terminado (p. ej. Pro o Pro+ vencidos) o la cuenta quedó en estado expirado, 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 (Pro y Pro+)

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

Sesión en un solo dispositivo

• Si en tu proyecto de Supabase está activa la sesión única, solo puede haber una sesión iniciada por cuenta: si entras desde otro dispositivo, la sesión anterior se invalida y esa instancia de la app puede cerrar sesión sola al recuperar el foco. Detalle técnico: documentación Sesión única por usuario en el repositorio de la app.

Tu cuenta en Opciones

• En Opciones → Cuenta verás datos como el email, el plan (tier), el rol, el estado de la suscripción, si el trial está en uso y la fecha de vencimiento cuando aplique (Pro / Pro+); en Free suele no haber fecha de caducidad de cuenta.

---

10. Datos en tu equipo

• La app guarda tu trabajo en la carpeta de datos de usuario. Lo principal suele estar bajo Workspaces/<cuenta>/ (workspaces + variables JSON). CSV de Datasets e informes Test results suelen estar bajo data/<cuenta>/ en la misma raíz Roaming/local de Performate (datasets y test_results; ver diagrama siguiente).
• Los archivos principales son workspaces.json (workspaces, carpetas, tests, ejemplos y, si los usas, los archivos de la biblioteca JS de cada workspace —van embebidos en ese mismo JSON—) 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\Performate\
├── Workspaces\
│   └── parte_local_email\
│       ├── workspaces.json
│       └── variables.json
├── data\
│   └── parte_local_email\
│       ├── datasets\      ← CSV y subcarpetas del lateral «Datasets» (ver más arriba en la sección 3)
│       └── test_results\  ← informes HTML listados como «Test results» (ver sección 7)

Por ejemplo, si entras con ana.dev@empresa.com, una ruta plausible sería:

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

y tus Datasets CSV estarían paralelos en C:\Users\Ana\AppData\Roaming\Performate\data\ana.dev\datasets\.

• 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.
• Centro de automatización (Automation Hub): modal para llevar un request a CI/CD: plantillas GitHub Actions, Jenkins (Linux/Windows), Docker Compose con npx performate run, esqueleto k6 Operator, export de carpeta starter y guías. Para generar plantillas y comandos completos hacen falta entorno de variables seleccionado y umbrales definidos en el test (ver sección 4). Pro+, Dev y QA tienen acceso completo en modo nube; Free y Pro pueden abrir el hub pero el contenido sensible puede mostrarse difuminado hasta que actualices el plan. Más detalle en el repositorio de la app.

---

13. Preguntas frecuentes

Respuestas breves para quien llega al producto o a la landing; los detalles técnicos ampliados siguen en el resto de esta guía, en el centro de documentación y en el repositorio de la app.

¿Qué es Performate?

Performate es una aplicación de escritorio para diseñar y ejecutar pruebas de carga con un flujo parecido al de herramientas de API, pero orientado al rendimiento: defines peticiones, escenarios y datos, y el motor que ejecuta las pruebas es k6.

¿Por qué no usar solo la terminal con k6?

Puedes hacerlo sin problema. Performate sirve para ordenar el trabajo: carpetas, peticiones reutilizables, variables por entorno y un panel con resultados sin pelearte con cada comando ni perder el hilo entre archivos sueltos.

¿Tengo que instalar k6 por separado?

No. En builds habituales para Windows, k6 ya viene incluido (bundled) en la aplicación; no necesitas instalarlo aparte para empezar a ejecutar desde Performate.

¿Se pueden correr múltiples scripts en paralelo?

Sí. Puedes ejecutarlos en paralelo; cada ejecución genera un dashboard independiente y también puedes crear un reporte comparativo de las ejecuciones. Para cómo seleccionar varias peticiones o ejemplos y lanzarlas juntas, consulta Ejecución en paralelo (multi-test run).

¿Puedo importar lo que ya tengo en Postman?

Sí. Puedes importar colecciones Postman (arrastrando el JSON en la app) y evitar reescribir todo desde cero. Los matices de la importación se describen en la sección Workspaces y organización.

¿Puedo usar Performate sin conexión a internet?

En el uso estándar necesitas conexión para iniciar sesión, validar la cuenta con Supabase y, si tienes Pro/Pro+, para sincronizar con la nube. No está pensado un modo “offline prolongado” para producción. Solo en builds de desarrollo con modo local (localMode, sin Supabase configurado) la app puede permitir uso sin esa cadena; eso no aplica a los instaladores habituales de usuario final.

¿Dónde están mis datos y scripts?

Los scripts se suben cifrados al almacenamiento (storage) de Supabase; el diseño del producto trata de mantener tus archivos seguros en ese flujo. En disco, el JSON del workspace (Workspaces/<perfil>/workspaces.json) incluye peticiones, scripts y la biblioteca JS (código compartido del workspace, ver sección 3); los datasets CSV y los informes HTML tienen rutas típicas bajo Performate/data/<perfil>/ (datasets y test results — véanse las secciones 3 y 10 de esta guía). Además, puedes ver archivos locales desde la app cuando el explorador aparece desde acciones contextual (workspaces.json, rutas CSV, carpetas dedicadas).

¿Para qué sistemas operativos está disponible?

Por ahora solo Windows. La intención del proyecto es ampliar la compatibilidad a otros sistemas operativos más adelante.

¿Puedo escribir mi propio script k6?

Sí. Puedes usar scripts personalizados cuando el flujo visual no basta o quieres control total del guion k6.

¿Qué es la «biblioteca JS» que sale en el lateral?

Es un cajón de archivos JavaScript (.js / .mjs) por workspace: ahí guardas funciones o trozos de código que varias pruebas pueden reutilizar sin duplicarlos. No es el script principal del test; sirve como apoyo que enlazas con import desde el editor k6. Pasos concretos (crear, arrastrar archivos, copiar ruta de importación, ejecutar fuera de la app) están en Sección 3 — Biblioteca JS del workspace.

¿La IA ejecuta el test por mí?

No. La IA no sustituye que tú definas la carga ni que k6 sea quien ejecute. Suele ayudarte a entender resultados o resumir qué ocurrió durante la prueba.

¿Sirve si recién empiezo con pruebas de carga?

Sí. El constructor visual facilita el arranque. Si ya conoces k6, sigues teniendo el mismo motor debajo y las mismas ideas de siempre.

¿Qué son el workspace y los entornos?

El workspace es tu proyecto: carpetas, peticiones, todo organizado en un mismo espacio. Los entornos permiten cambiar URL, tokens y demás sin duplicar el mismo test para desarrollo, staging o producción.

¿Cuáles son los límites de la prueba gratuita?

Los límites dependen de la versión del producto y de la política en Supabase. En la app, el plan Free suele mostrar cupos del orden de 5 generaciones de informe con IA y 5 solicitudes al asistente IA para scripts k6 por mes (ventana mensual en servidor); Pro y Pro+ usan límites mensuales por tokens distintos entre sí. Para cifras y migraciones al día, consulta la documentación en el repositorio de la app.

¿Puedo usar Performate en CI/CD (por ejemplo GitHub Actions o Jenkins)?

Sí. El Automation Hub está pensado para eso. El acceso completo a plantillas y comandos (sin restricción de tier en la nube) corresponde a Pro+ y a cuentas internas Dev/QA. Free y Pro pueden explorar el modal, pero parte del contenido puede estar restringida hasta actualizar. Detalle en el repositorio de la app y en SUBSCRIPTION.md.

¿Qué veo mientras corre el test?

Un tablero integrado en la aplicación con métricas habituales de k6 (carga, tiempos, errores, etc.), sin depender solo del texto de la consola.

---

14. Más información

Si necesitas más detalle (archivos locales, cuenta, IA o integraciones), puedes seguir por aquí:

• La sección 13 — Preguntas frecuentes de esta guía.
• El centro de documentación del sitio, la sección Cuenta y suscripción y los precios con políticas actualizadas.
• Documentación técnica ampliada del producto en el repositorio performate-app bajo documentation/ (p. ej. SETUP, SUBSCRIPTION, AUTOMATION-HUB, WORKSPACE-STORAGE).

---

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