Gestionar entornos y variables en k6 para pruebas más seguras

Un script con URL de producción hardcodeada y un token de staging en el portapapeles del autor causó incidentes reales: la prueba golpeó datos equivocados, o peor, datos reales con credenciales de test. k6 no «adivina» el entorno—tú suministras configuración en runtime, y el proceso alrededor decide si eso es seguro.

Gestionar entornos y variables en k6 trata de separar dev, staging y prod sin tres copias del script que derivan en dos sprints, y sin secretos en git. En esta guía verás patrones con __ENV, perfiles de escenario, setup() y CI—alineados al modelo oficial de k6 (variables de entorno, options).

Por qué la configuración es datos, no código duplicado

k6 lee __ENV y flags -e en cada corrida. Eso habilita:

• El mismo script en laptop, CI y campaña de release con distintos endpoints y tasas.
• Fallas tempranas cuando falta una variable obligatoria—antes de un soak de 45 minutos.
• Auditoría clara: el pipeline inyecta secretos; el repo solo documenta nombres.

Sin disciplina, los equipos fork scripts por entorno, mezclan URLs de staging con tokens de prod, o loguean tokens en artefactos de CI. Combina esto con Postman a k6 paso a paso cuando las colecciones ya tienen entornos con nombre, y con pruebas de carga en CI/CD para inyección de secretos.

Cuando «funciona en mi máquina» rompe el pipeline

Diferencias de TZ, DNS o resolución OAuth entre laptop y runner de CI producen umbrales que flappean sin cambio de código. Documenta variables obligatorias y valida el runner—especialmente en flujos móviles con refresh de token (OAuth y concurrencia).

Patrón 1: __ENV para endpoints y secretos

Lee valores al inicio; nunca commits secretos.

const baseUrl = __ENV.BASE_URL || 'https://staging.example.com';
const token = __ENV.API_TOKEN;

export function setup() {
  if (!token) throw new Error('Define API_TOKEN en runtime');
  return { token };
}

Ejecución local y CI:

k6 run -e BASE_URL=https://staging.example.com -e API_TOKEN="$TOKEN" script.js

Qué demuestra: configuración explícita; falla fuerte sin token.

Patrón 2: Perfiles de escenario por entorno

Mantén definiciones de escenario estables; varía duración, RPS y umbrales vía perfil parseado en options:

const PROFILE = __ENV.TEST_PROFILE || 'smoke';

const profiles = {
  smoke: { duration: '45s', rate: 5, vus: 10 },
  nightly: { duration: '8m', rate: 25, vus: 80 },
};

const cfg = profiles[PROFILE] || profiles.smoke;

export const options = {
  scenarios: {
    api: {
      executor: 'constant-arrival-rate',
      rate: cfg.rate,
      timeUnit: '1s',
      duration: cfg.duration,
      preAllocatedVUs: cfg.vus,
      maxVUs: cfg.vus * 4,
      exec: 'default',
    },
  },
};

Evita checkout-staging.js y checkout-prod.js que divergen silenciosamente.

Patrón 3: Docker, Kubernetes y runners en la nube

Los jobs de CI mapean secretos del vault a variables de entorno igual que en shell. Verifica:

• Resolución DNS del hostname de ingress (no solo ClusterIP interno si el test simula clientes reales—Kubernetes).
• Reloj y TZ para OAuth con ventanas cortas.
• Mismas variables documentadas en README del repo de performance.

Patrón 4: Defaults compartidos y overrides

Documenta al inicio del script:

// Obligatorias: BASE_URL, API_TOKEN, TEST_PROFILE (smoke|nightly)
// Opcionales: VUS_OVERRIDE, TENANT_ID

Lista obligatorias en PR checklist y en plantillas de pipeline. Usa setup() para validar combinaciones prohibidas (p. ej. BASE_URL contiene prod sin flag ALLOW_PROD_LOAD=1).

Anti-patrones que siguen apareciendo en 2026

• URL de prod «temporal» en el script—nunca temporal.
• Tres archivos casi iguales por entorno en lugar de parámetros.
• Loguear headers Authorization al depurar—scrub artefactos de CI.
• Variables sin nombre estándar entre squads (API_URL vs BASE_URL)—rompe comparación de baselines.

Marco de decisión: qué parametrizar

Usa perfiles __ENV si el mismo script alimenta CI y campañas largas.

Usa validación en setup() si el costo de una corrida contra el entorno equivocado es alto.

Usa entornos Postman/Performate si QA ya mantiene matrices dev/stage—exporta a k6 con los mismos nombres.

Checklist de seguridad de entornos

• ¿Cero secretos en git (incluidos .env commiteados por error)?
• ¿README lista variables obligatorias y ejemplo de comando?
• ¿CI usa secret store, no variables en YAML público?
• ¿Guardas explícitas contra prod sin aprobación?
• ¿Artefactos de log scrubean tokens?

Matriz de variables recomendada para equipos API

Convención: mismos nombres en Postman, Performate y k6 exportado. Si QA llama apiKey y el script espera API_TOKEN, cada handoff genera una corrida roja «misteriosa».

Integración con perfiles de carga versionada y LLM

• Versionado: V1_RPS, V2_RPS como en pruebas de carga y versionado de API—analytics cambia pesos sin editar lógica de requests.
• LLM: LLM_TEST_KEY, SHORT_RPS, LONG_RPS, MAX_TOKENS—ver pruebas de carga de APIs con LLM. Falla en setup() si falta key de test.
• Mocks: DEP_TRACK=mock|sandbox—ver mocks vs dependencias reales.

Un solo archivo options.js compartido puede parsear estas variables y exportar options por perfil—evita copiar bloques de thresholds entre scripts.

Cómo Performate reduce duplicación de scripts

Centralizar imports y alternancias supera mantener tres copias de la misma lógica. Abajo hay un ejemplo concreto de flujo para la API de checkout que usa este artículo.

Ejemplo: perfil staging vs load sin forks de script

1. Importa una colección Postman con variables de entorno para baseUrl y apiToken. Problema resuelto: entornos QA se convierten en entornos de performance sin reingreso.
2. Define perfiles de entorno en Performate—Dev, Staging, Load—con presets de duración y arrival rate que coincidan con ENV_PROFILE de arriba. Problema resuelto: ingenieros cambian targets en UI en vez de editar bloques de executor.
3. Mapea variables de colección a campos de escenario una vez; reutiliza en escenarios smoke y soak. Problema resuelto: payloads y headers de auth permanecen sincronizados.
4. Corre perfil Staging para gates pre-release; cambia a perfil Load para regresión programada—mismos requests, forma distinta. Problema resuelto: sin drift checkout-staging.js / checkout-load.js.
5. Exporta script k6 con placeholders __ENV para inyección de secretos en CI. Problema resuelto: tuning en escritorio y ejecución en pipeline comparten un artefacto.
6. Comparte reportes filtrados por tag de entorno para que incidentes comparen la misma baseline de perfil. Problema resuelto: on-call lee env:stage, no corridas misteriosas de laptop.

Ese flujo conecta directamente con el cta de este post: gestionar entornos y conmutación de variables sin duplicar scripts.

Cierre

k6 ya trae el mecanismo correcto: configuración en runtime. La práctica madura es un script, muchos perfiles, secretos fuera del repo y validación temprana en setup().

Antes de la próxima corrida larga, borra cualquier URL de prod del script, documenta tres variables obligatorias en el README, y haz fallar el job en CI si falta API_TOKEN—eso cuesta segundos y evita horas de incidente.

Try Performate free | Book a demo | k6 options reference