---
title: "Gestionar entornos y variables en k6 para pruebas más seguras"
description: "Usa __ENV, flags CLI y options modulares para separar configs dev/stage/prod sin filtrar secretos—alineado con el modelo de runtime de k6."
publishDate: "2026-05-29"
draft: false
keyword: "gestionar entornos variables k6"
intent: "MOFU"
cta: "Usa Performate para gestionar entornos y cambios de variables sin duplicar scripts."
tags: ["k6", "entornos", "variables", "testing"]
translationOf: managing-environments-variables-k6
---

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](https://k6.io/docs/using-k6/environment-variables/), [options](https://k6.io/docs/using-k6/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](/es/blog/postman-a-k6-paso-a-paso) cuando las colecciones ya tienen entornos con nombre, y con [pruebas de carga en CI/CD](/es/blog/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](/es/blog/k6-oauth2-api-key-concurrencia)).

## Patrón 1: `__ENV` para endpoints y secretos

Lee valores al inicio; nunca commits secretos.

```javascript
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:

```bash
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`:

```javascript
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](/es/blog/pruebas-carga-microservicios-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:

```javascript
// 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

| Variable | Típicamente | Evita hardcodear |
|:---|:---|:---|
| `BASE_URL` | Por entorno | Sí |
| `API_TOKEN` / OAuth | Secretos CI | Sí |
| `TEST_PROFILE` | smoke / nightly | Perfil en repo |
| `V1_RPS` / mix de tráfico | Analytics | Sí, para [versionado API](/es/blog/pruebas-carga-versionado-api) |
| Rutas y checks de negocio | Repo | No—son contrato del test |

**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

| Variable | Ejemplo | Quién la provee |
|:---|:---|:---|
| `BASE_URL` | `https://api.staging.example.com` | Pipeline / dev local |
| `API_TOKEN` | (secreto) | Vault CI, nunca git |
| `TEST_PROFILE` | `smoke` \| `nightly` | Job de CI vs cron |
| `TENANT_ID` | `tenant-sandbox-01` | Plataforma multi-tenant |
| `GIT_SHA` | inyectado en CI | Para baselines en export JSON |

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](/es/blog/pruebas-carga-versionado-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](/es/blog/pruebas-de-carga-apis-con-llm). Falla en `setup()` si falta key de test.
- **Mocks:** `DEP_TRACK=mock|sandbox`—ver [mocks vs dependencias reales](/es/blog/mock-services-vs-dependencias-reales-pruebas-carga).

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](https://performate.app) | [Book a demo](/demo) | [k6 options reference](https://k6.io/docs/using-k6/options/)