En el ámbito de las pruebas de rendimiento, es común observar un error fundamental: el uso repetitivo de los mismos parámetros en solicitudes concurrentes. Demasiadas veces, se utiliza JMeter como una herramienta avanzada para copiar y pegar, donde una solicitud HTTP se duplica decenas de veces, modificando manualmente IDs de usuario, números de pedido o marcas de tiempo. El resultado es engañoso: los registros del servidor se llenan de user\_id=1001 idénticos, la base de datos se satura con pedidos duplicados y las métricas de monitoreo muestran una línea plana, lejos de un comportamiento realista. Esto no es una prueba de carga efectiva; es una simulación deficiente.

Una prueba de carga verdaderamente útil no se mide por la cantidad de solicitudes enviadas, sino por la autenticidad de cada una. Los usuarios reales no envían simultáneamente el mismo ID de pedido. Durante un evento de ventas masivo, cientos de miles de usuarios navegan por diferentes productos, utilizan distintas direcciones de envío y aplican diversos códigos de descuento. En un sistema financiero, cada solicitud de apertura de cuenta debe llevar un número de identificación único, un número de teléfono válido y una tarjeta bancaria conforme a las reglas de validación. Las pasarelas de API exigen tokens generados individualmente, con su propia caducidad y firmas irrepetibles. ¿Podemos gestionar todo esto modificando parámetros manualmente? No solo con cincuenta solicitudes, incluso con solo cinco, es fácil omitir un campo, distorsionando gravemente los datos de la prueba y anulando cualquier conclusión.

La capacidad de "personalizar diferentes parámetros de solicitud" es más que una simple característica de JMeter; es la piedra angular de la credibilidad en las pruebas de rendimiento. Determina si estamos identificando cuellos de botella reales del sistema o aquellos que hemos fabricado nosotros mismos. Por ejemplo, si todas las solicitudes comparten el mismo ID de sesión, un balanceador de carga puede dirigir todo el tráfico a un solo servidor, generando una falsa alarma de punto único de falla. Si todas las solicitudes llevan la misma marca de tiempo, las estrategias de cacheo pueden fallar completamente, dando la impresión de que la caché no funciona, cuando en realidad el problema es que la clave de caché es siempre la misma debido a parámetros inalterados. He tropezado con estos obstáculos en proyectos de pruebas de carga en diversas industrias: servicios de autenticación colapsados en pruebas de venta flash por tokens de usuario no aislados; bloqueos por controles de fraude en pruebas de inicio de sesión de plataformas gubernamentales debido a números de teléfono duplicados; y picos de conexiones en brokers MQTT durante pruebas de reporte de dispositivos IoT por IDs de dispositivo no rotativos. En cada ocasión, la causa raíz fue la falta de "dinamismo" en los parámetros.

Por lo tanto, este artículo no abordará cómo añadir grupos de hilos ni cómo interpretar un informe de agregados. Se centrará en un único aspecto: cómo asegurar que cada solicitud concurrente se inicie con parámetros únicos, conformes a la lógica de negocio y autoconsistentes. Presentaremos un análisis detallado de cuatro estrategias, desde la configuración básica de CSV Data Set hasta la generación dinámica con JSR223 PreProcessor y las técnicas de combinación de funciones __Random. Para cada solución, exploraremos sus límites de aplicabilidad, su impacto en el rendimiento y experiencias reales. No es una simple lista de funcionalidades, sino una guía evolutiva para la dinamización de parámetros, organizada por complejidad de negocio. No es necesario dominar todas las opciones, pero es crucial saber cuándo elegir cada camino y por qué ciertas rutas deben evitarse.

2. Comparativa Práctica y Lógica de Selección entre Cuatro Estrategias de Dinamización

Para abordar la necesidad de "personalizar diferentes parámetros de solicitud", JMeter ofrece múltiples caminos. Sin embargo, muchos tutoriales solo mencionan "puedes usar A o B" sin explicar por qué la lectura de archivos CSV puede ralentizarse bajo alta concurrencia, por qué los scripts JSR223 pueden disparar el uso de CPU con 2000 hilos, o por qué la combinación de funciones __Random puede fallar en pruebas distribuidas. Estas no son preguntas teóricas; son las respuestas que necesitarás a las tres de la mañana cuando tu clúster de pruebas colapse. A continuación, presentamos cuatro estrategias ordenadas de menor a mayor complejidad y estabilidad en escenarios de pruebas reales, incluyendo sus restricciones, puntos de inflexión de rendimiento y datos de mis propias pruebas.

2.1 CSV Data Set Config: La "Zona Segura" para Escenarios Simples con un Límite Claro

Esta es la estrategia más básica que los principiantes encuentran primero: preparar un archivo usuarios.csv con el siguiente formato:

id_usuario,telefono,token,marca_tiempo
1001,34600138000,abc123xyz,1715678901234
1002,34600138001,def456uvw,1715678901235
1003,34600138002,ghi789rst,1715678901236
...

Luego, en las solicitudes HTTP, se utilizan las variables ${id\_usuario}, ${telefono}, etc. Los puntos clave de configuración son: Recycle on EOF = False, Stop thread on EOF = True, Sharing mode = All threads.

Las ventajas de esta solución son claras: coste de aprendizaje nulo, depuración intuitiva y resultados trazables. En el View Results Tree exportado, los parámetros de cada solicitud corresponden claramente a una fila del CSV, facilitando la investigación de problemas. He utilizado consistentemente el enfoque CSV para pruebas de sistemas internos, ya que los desarrolladores pueden mantener los datos de prueba y los testers con menos experiencia también pueden ejecutar pruebas con facilidad.

Sin embargo, tiene limitaciones físicas inevitables. El CSV Data Set Config es, esencialmente, una lectura secuencial de archivo en un solo hilo. Cuando el número de hilos supera los 500 y el número de filas del CSV es menor que los hilos, un gran número de hilos se bloqueará esperando leer la siguiente línea. En mis pruebas, con 1000 hilos y 10000 filas CSV en una máquina i7-10875H, la CPU se mantuvo en un 35%, pero el rendimiento (TPS) se estancó en aproximadamente 1200, muy por debajo del valor teórico. La razón es directa: el hilo principal de JMeter debe coordinar la lectura del mismo descriptor de archivo por parte de todos los hilos secundarios, lo que provoca una intensa contención de bloqueos. Más críticamente, si el número de filas del CSV es insuficiente, Stop thread on EOF = True hará que algunos hilos terminen prematuramente, lo que lleva a fluctuaciones en el número de usuarios concurrentes y picos notables en la curva de carga.

Consejo: La estrategia CSV solo se recomienda para tres tipos de escenarios: ① Pruebas de humo a nivel de API con concurrencia ≤ 300; ② Validaciones específicas que requieren un control estricto de combinaciones de parámetros (por ejemplo, 100 usuarios fijos interactuando con 10 productos); ③ Entornos de prueba con recursos limitados donde no es posible instalar el motor Groovy en pipelines CI antiguas.

2.2 Combinación de Funciones __Random y __RandomString: Generación Dinámica Ligera con Advertencia de "Pseudo-Aleatoriedad"

Cuando el coste de mantenimiento del CSV es demasiado alto (por ejemplo, si se necesitan generar 100.000 números de teléfono diarios), o cuando los parámetros requieren cálculo en tiempo real (como la marca de tiempo actual con un desfase de milisegundos), las funciones de JMeter se convierten en la opción preferida. Las funciones \_\_Random y \_\_RandomString integradas en JMeter tienen una sintaxis sencilla y no requieren dependencias adicionales:

• ${__Random(1000,9999,)} genera un número aleatorio de 4 dígitos.
• ${__RandomString(11,0123456789,)} genera una cadena numérica de 11 dígitos (smiulando un número de teléfono).
• ${__time(yyyy-MM-dd HH:mm:ss,)} obtiene la hora actual.

Su uso combinado puede cubrir la mayoría de las necesidades básicas:

"id_pedido": "PED-${__Random(100000,999999,)}${__time(yyyyMMddHHmmss,)}"
"id_dispositivo": "${__RandomString(16,abcdefghijklmnopqrstuvwxyz0123456789,)}"

Esta estrategia ofrece una ventaja de rendimiento muy destacada: las llamadas a funciones son operaciones en memoria, resultando en un uso de CPU inferior al 15% con 1000 hilos, y el TPS puede superar fácilmente los 5000. Durante la prueba de carga de una API de seguimiento logístico, utilicé este método para generar 2000 números de seguimiento únicos por segundo, funcionando de forma continua durante 2 horas sin incidencias.

Sin embargo, oculta dos trampas profundas. La primera es la falta de seguridad de hilos: la función \_\_Random no es absolutamente independiente en entornos multihilo. En versiones anteriores a JMeter 5.4, múltiples hilos podían obtener la misma semilla aleatoria, lo que aumentaba la probabilidad de valores duplicados en cortos periodos. Esto me llevó a descubrir que el 0.3% de las solicitudes en una prueba de carga de devolución de pagos fallaban con "pedido ya existe", debido a una tasa de duplicación excesiva de \_\_Random(100000,999999) bajo alta concurrencia. La solución es actualizar a JMeter 5.5+ o usar \_\_RandomString (que internamente usa SecureRandom y es seguro para hilos).

La segunda es la ausencia de conformidad con la lógica de negocio: un número de teléfono puramente aleatorio como 12345678901 no cumple con las reglas de asignación de operadores; un número de identificación generado como 110101199001011234 puede tener un dígito de verificación incorrecto. Si estos parámetros son interceptados por la lógica de negocio del backend, la prueba de carga se convierte en una "tormenta de solicitudes inválidas". Mi experiencia es clara: para cualquier campo con validación estricta (números de teléfono, identificaciones, números de tarjetas bancarias, correos electrónicos), nunca se deben usar funciones puramente aleatorias; siempre se debe recurrir a la generación por script.

2.3 JSR223 PreProcessor (Groovy): El "Arma Definitiva" para la Generación de Parámetros a Nivel de Negocio, con un Coste de Rendimiento

Cuando la lógica de generación de parámetros se vuelve compleja – por ejemplo, calcular dinámicamente el valor de un cupón basado en el nivel del usuario, generar coordenadas de latitud/longitud según reglas de geolocalización, o invocar servicios de cifrado internos para generar firmas – las funciones auxiliares resultan insuficientes y es indispensable utilizar scripts. Groovy es el lenguaje de script recomendado oficialmente por JMeter para JSR223, con una sintaxis concisa, compatibilidad perfecta con el ecosistema Java y un rendimiento superior al de BeanShell.

Un script típico para la generación de parámetros para una prueba de carga de pedidos de comercio electrónico (colocado antes de la solicitud HTTP):

import java.text.SimpleDateFormat
import java.security.MessageDigest
import java.util.UUID

// 1. Generar un ID de usuario único (basado en el ID de hilo y el tiempo, para evitar duplicados)
//    Se utiliza UUID para mayor aleatoriedad global combinada con el ID del hilo.
def idUsuario = "${ctx.getThreadNum()}_${UUID.randomUUID().toString()}"

// 2. Generar un número de teléfono válido (simulando prefijos comunes, últimos 4 dígitos aleatorios)
def prefijosMovil = ['60', '61', '62', '63', '64', '65', '66', '67', '68', '69', '70', '71', '72', '73', '74', '75'][new Random().nextInt(16)] // Prefijos españoles simulados
def sufijoAleatorio = String.format('%07d', new Random().nextInt(10000000)) // 7 dígitos aleatorios
def numeroTelefono = "${prefijosMovil}${sufijoAleatorio}"

// 3. Generar un número de identificación simulado (ejemplo genérico con checksum simplificado)
//    Este es un ejemplo simplificado; la lógica real de DNI/NIF/NIE es más compleja y específica del país.
def identificadorBase = "X" + String.format('%08d', new Random().nextInt(100000000)) // 8 dígitos aleatorios
def letrasDNI = "TRWAGMYFPDXBNJZSQVHLCKE"
def digitoControl = letrasDNI.charAt(new Random().nextInt(23)) // Letra aleatoria para simplificación
def numeroIdentificacion = identificadorBase + digitoControl

// 4. Almacenar como variables de JMeter para su uso en solicitudes HTTP
vars.put("id_usuario", idUsuario)
vars.put("numero_telefono", numeroTelefono)
vars.put("numero_identificacion", numeroIdentificacion)
vars.put("marca_tiempo", System.currentTimeMillis().toString())

El valor central de esta estrategia radica en su control total sobre la lógica de generación, asegurando una conformidad del 100% con las reglas de negocio. Todos los parámetros se someten a una validación de reglas de negocio real, lo que significa que las solicitudes recibidas por el servicio backend son indistinguibles a nivel de datos de las solicitudes enviadas por usuarios en producción. Cuando realicé pruebas de carga para transferencias en una aplicación bancaria, utilicé este enfoque para generar números de tarjeta compatibles con las regulaciones (BIN + dígito de verificación) y códigos de autenticación dinámicos (TOTP) calculados en tiempo real. Los resultados de la prueba se alinearon estrechamente con los patrones de tráfico reales de eventos en vivo.

Pero el coste también es real. La ejecución de scripts Groovy es una operación interna de la JVM, lo que significa que cada hilo, por cada solicitud, debe analizar, compilar y ejecutar el script. Cuando el número de hilos alcanza los 2000 y el script contiene múltiples bucles o llamadas externas, el uso de la CPU puede dispararse por encima del 80%, y el TPS puede incluso disminuir. Mis datos de prueba muestran que, con 2000 hilos, un script ligero con 3 operaciones de cadena tuvo un TPS de 3800; si se añadía un cálculo MessageDigest.getInstance("SHA-256"), el TPS caía drásticamente a 2100. Por lo tanto, el script debe adherirse al "principio de minimización": realizar solo los cálculos necesarios, evitar operaciones de I/O de red y prevenir la creación de objetos grandes.

2.4 Centro de Parámetros Distribuido (Redis): Solución de "Infraestructura" para Pruebas de Carga a Gran Escala

Cuando el objetivo de la prueba de carga es de decenas de millones de solicitudes por segundo (QPS), o si los parámetros deben coordinarse entre múltiples máquinas de prueba (por ejemplo, 10 máquinas JMeter consumiendo el mismo pool de usuarios), ni los archivos CSV ni los scripts locales son suficientes. En tales casos, es imprescindible introducir un centro de parámetros externo. Nuestro equipo, al realizar pruebas de carga para un evento masivo en una plataforma de videos cortos, adoptó Redis como el centro de distribución de parámetros, con resultados que superaron las expectativas.

La arquitectura es sencilla: una instancia de Redis, y un script de precalentamiento que carga 100 millones de datos de usuario (id_usuario, token, id_dispositivo) en una estructura Hash, con la clave pool\_usuarios. Cada vez que JMeter inicia una solicitud, primero ejecuta un JSR223 Sampler con un script Groovy que usa el cliente Jedis para interactuar con Redis para obtener de forma atómica un dato de usuario del Hash:

import redis.clients.jedis.Jedis
import java.util.Random

// Configuración de conexión a Redis
def hostRedis = "192.168.1.100"
def puertoRedis = 6379
def clavePoolUsuarios = "pool_usuarios"

Jedis clienteJedis = new Jedis(hostRedis, puertoRedis)
try {
   // Obtener todos los datos del pool de usuarios (considerar rendimiento para pools muy grandes)
   // Para pools extremadamente grandes, se podría usar un enfoque de "streaming" o consumir por lotes.
   def datosUsuario = clienteJedis.hgetAll(clavePoolUsuarios)

   if (datosUsuario && !datosUsuario.isEmpty()) {
       // Simular HPOP: seleccionar un campo aleatoriamente y eliminarlo
       // Esto garantiza que cada usuario sea consumido una sola vez.
       def clavesDisponibles = datosUsuario.keySet().toArray()
       def indiceAleatorio = new Random().nextInt(clavesDisponibles.length)
       def claveUsuario = (String) clavesDisponibles[indiceAleatorio]
       def valorToken = datosUsuario.get(claveUsuario)

       // Eliminar el usuario consumido del pool
       clienteJedis.hdel(clavePoolUsuarios, claveUsuario)

       // Almacenar los datos en variables de JMeter
       vars.put("id_usuario", claveUsuario)
       vars.put("token_acceso", valorToken)
       log.debug("Usuario '${claveUsuario}' y token obtenidos de Redis.")
   } else {
       log.warn("¡No quedan datos de usuario en el pool de Redis! Usando datos de respaldo.")
       vars.put("id_usuario", "fallback_user_" + System.currentTimeMillis())
       vars.put("token_acceso", "fallback_token_" + System.currentTimeMillis())
   }
} catch (Exception e) {
   log.error("Error al obtener parámetros de Redis: " + e.getMessage(), e)
   // En caso de error, proporcionar valores de respaldo para evitar fallos completos
   vars.put("id_usuario", "error_user_" + System.currentTimeMillis())
   vars.put("token_acceso", "error_token_" + System.currentTimeMillis())
} finally {
   if (clienteJedis != null) {
       clienteJedis.close()
   }
}

Esta estrategia desacopla completamente la generación de parámetros de la ejecución de la prueba. Diez máquinas JMeter comparten el mismo pool de usuarios, garantizando la unicidad global de los parámetros; el alto rendimiento de Redis (100.000 QPS en una sola instancia) asegura que la obtención de parámetros no sea un cuello de botella. Más importante aún, el ciclo de vida de los parámetros es controlable: se pueden añadir nuevos datos a Redis en cualquier momento, o restablecer el pool, sin necesidad de reiniciar ningún proceso de JMeter. Durante una prueba, descubrimos un problema con la política de caducidad de tokens; en 5 minutos, el pool de parámetros se actualizó, y la prueba continuó sin interrupciones.

Sin embargo, requiere que el equipo tenga capacidades básicas de operación de middleware. Un único punto de falla en Redis bloquearía todas las máquinas de prueba, por lo que es esencial desplegar Sentinel o un clúster. La latencia de red puede aumentar el tiempo de respuesta por solicitud, por lo que se debe monitorear el "tiempo de obtención de parámetros" por separado en las métricas de Response Time. Además, no es adecuada para pruebas a pequeña escala; el coste operativo de configurar un sistema Redis para 100 usuarios concurrentes supera con creces los beneficios.

3. Los "Tres Minutos Fatales" de la Dinamización de Parámetros: Rastreo Completo de la Causa Raíz a partir de los Registros de Errores

Incluso la solución más perfecta probablemente fallará en algún momento durante una prueba de carga en producción. Una de las fallas más típicas que experimenté ocurrió durante la última prueba de carga de extremo a extremo antes de una gran campaña de ventas en línea: después de iniciar 2000 hilos, los primeros dos minutos transcurrieron sin problemas. A partir del tercer minuto, el View Results Tree comenzó a mostrar un gran número de solicitudes con 401 Unauthorized, el informe de agregados indicaba que la tasa de error se disparó del 0% al 35%, mientras que el gráfico de Active Threads mostraba un número estable de 2000 hilos. Todos en la sala miraban la pantalla, sin saber dónde estaba el problema, porque la solicitud HTTP en sí no reportaba un error, sino que el backend la rechazaba.

En los siguientes 18 minutos, realicé una localización de fallas estándar en la dinamización de parámetros. Este proceso ilustra mejor que cualquier tutorial por qué la dinamización de parámetros no es solo "configurar un CSV y listo", sino un problema de ingeniería que requiere una investigación sistemática.

3.1 Primer Minuto: Identificando la "Huella de Parámetros" de las Solicitudes Anómalas

En lugar de mirar los registros de errores primero, abrí el View Results Tree, seleccioné aleatoriamente una solicitud que devolvía 401 y, en la pestaña Request, examiné cuidadosamente el cuerpo de la solicitud original. El foco no estaba en la URL o las cabeceras, sino en todos los valores de los parámetros encerrados en ${}. Copié rápidamente algunos campos clave:

• id_usuario: 1001
• token: abc123xyz
• marca_tiempo: 1715678901234

Luego, cambié a una solicitud normal (respuesta 200) y copié los parámetros de la misma manera:

• id_usuario: 1001
• token: abc123xyz
• marca_tiempo: 1715678901234

¡Todos los parámetros eran exactamente iguales! Esto significaba que: no era que los parámetros de un hilo estuvieran mal, sino que todos los hilos estaban usando el mismo conjunto de parámetros. El problema se centró inmediatamente en el alcance de los parámetros: ¿por qué 2000 hilos no estaban obteniendo valores diferentes?

3.2 Segundo Minuto: Verificando la Efectividad del "Modo de Compartición" en CSV Data Set Config

Volví a la interfaz de JMeter, hice doble clic en el elemento CSV Data Set Config y verifiqué la configuración de Sharing mode. Sorprendentemente, decía Current thread group. Este era el culpable. Current thread group significa que el archivo CSV es compartido por todos los hilos dentro de ese grupo de hilos, pero cada hilo lo lee secuencialmente: el hilo 1 lee la fila 1, el hilo 2 lee la fila 2... Cuando el número de hilos excede el número de filas del CSV, los hilos subsiguientes comenzarán a leer desde el principio, lo que provoca que un gran número de hilos obtengan los datos de la primera fila (es decir, id\_usuario=1001, token=abc123xyz). Como nuestro CSV solo tenía 1000 filas, 2000 hilos inevitablemente llevarían a que al menos 1000 hilos reutilizaran las primeras 1000 filas, siendo la primera fila la más reutilizada.

Inmediatamente cambié Sharing mode a All threads y activé Recycle on EOF = False y Stop thread on EOF = True. Pero el problema no se resolvió, porque Stop thread on EOF = True haría que los últimos 1000 hilos terminaran inmediatamente después de iniciar, y el gráfico Active Threads se desplomaría desde 2000, lo que no coincidía con el monitoreo.

3.3 Tercer Minuto: Confirmando la Doble Trampa de "Terminación de Hilos" y "Reutilización de Parámetros"

Creé un nuevo Debug Sampler y añadí un JSR223 PostProcessor con el siguiente script:

log.info("El hilo ${ctx.getThreadNum()} está usando el id_usuario: ${vars.get('id_usuario')}")

Reinicié la prueba de carga y revisé jmeter.log. Los registros mostraban claramente: los hilos 0 a 999 imprimían id\_usuario: 1001, los hilos 1000 a 1999 imprimían id\_usuario: 1001... Todos los hilos estaban utilizando el primer valor. Esto confirmó la reutilización global causada por Sharing mode = Current thread group.

Pero, ¿por qué Active Threads no disminuía? Revisé la configuración del grupo de hilos: Number of Threads = 2000, Ramp-up = 60, Loop Count = Forever, y la opción Delay thread creation until needed estaba marcada. La clave estaba aquí: JMeter, por defecto, crea hilos gradualmente durante el Ramp-up, pero una vez creados, incluso si el CSV llega al EOF, los hilos no se destruyen automáticamente, sino que continúan enviando los parámetros leídos por última vez (es decir, id\_usuario=1001) hasta que se detienen manualmente. Esta fue la verdad detrás de los "tres minutos fatales": la reutilización de parámetros provocó fallos de autenticación, y los hilos, al no morir, continuaron generando errores.

La solución final consistió en tres pasos: ① Expandir el CSV a 2000 filas; ② Configurar Sharing mode a All threads; ③ Establecer Stop thread on EOF a True y asegurar que Loop Count fuera 1 (para evitar la reutilización en bucle). Después de estas modificaciones, la tasa de error se redujo a cero.

Nota: Este caso revela un error común: muchas personas confunden "número de hilos" con "concurrencia", ignorando el impacto decisivo del alcance de los parámetros en la calidad real de la concurrencia. La dinamización de parámetros no es un lujo, sino la base de las pruebas de carga. Cualquier prueba que omita la validación de parámetros debe ser cuestionada.

4. De "Funcionando" a "Resultados Precisos": 7 Consejos Cruciales para Evitar Problemas en la Dinamización de Parámetros

La dinamización de parámetros parece sencilla, pero en la práctica, el 90% de los fallos se deben a detalles fácilmente ignorados. Estas experiencias, que son el resultado de 37 incidentes en pruebas de carga, son consejos directos y prácticos.

4.1 La codificación del archivo CSV debe ser UTF-8 sin BOM, de lo contrario los campos con caracteres especiales se corromperán

Esta es la trampa más común para los principiantes. El Bloc de Notas de Windows guarda por defecto en ANSI o UTF-8 con BOM. Cuando JMeter lo lee, interpreta la cabecera BOM (EF BB BF) como el primer carácter del archivo, lo que añade  al principio del nombre de la primera columna, haciendo que la referencia a la variable ${nombre\_usuario} siempre esté vacía. Solo hay dos soluciones: ① Abrir el CSV con Notepad++ y convertirlo a UTF-8 (sin BOM); ② Abrir con VS Code, hacer clic en la codificación en la esquina inferior derecha y seleccionar "Guardar con codificación" → "UTF-8". No confíes en que "parece que funciona"; siempre usa el comando xxd o un editor hexadecimal para confirmar que el archivo no empieza con los bytes EF BB BF.

4.2 El parámetro de marca de tiempo debe usar la función \_\_time(), deshabilitando la codificación fija de System.currentTimeMillis()

He visto casos absurdos: alguien escribiendo vars.put("ts", System.currentTimeMillis().toString()) en un JSR223 PreProcessor, solo para descubrir durante la prueba que el valor ts era idéntico en todas las solicitudes. ¿La razón? JMeter, durante el ciclo de ejecución de un único sampler, cachea el resultado del PreProcessor. System.currentTimeMillis() se ejecuta una vez cuando el script se interpreta, y todas las solicitudes subsiguientes reutilizan este valor. La forma correcta es vars.put("ts", "${\_\_time(,)}"), lo que permite a JMeter reemplazarlo dinámicamente antes de cada solicitud. Alternativamente, si es imprescindible usar Groovy, se puede escribir vars.put("ts", System.currentTimeMillis().toString()), pero asegurándose de que el script esté ubicado antes de cada solicitud HTTP y de no marcar la opción "Cache compiled script".

4.3 En pruebas de carga distribuidas, está absolutamente prohibido usar la función \_\_Random para generar IDs únicos

En una prueba de carga en una sola máquina, \_\_Random(1000,9999) podría funcionar a duras penas. Sin embargo, en un clúster de 10 máquinas JMeter, la semilla aleatoria inicial de cada máquina es la misma (basada en la hora del sistema), lo que hace que todas las máquinas generen números aleatorios idénticos en el mismo milisegundo. En una ocasión, esto provocó que en una prueba de carga distribuida, 10 máquinas insertaran simultáneamente id\_pedido=5678 en la base de datos, desencadenando conflictos de índice único y una tasa de error del 100%. Las únicas soluciones son: ① Usar \_\_RandomString(8,abcdefghijklmnopqrstuvwxyz0123456789), que en su base utiliza SecureRandom y mezcla automáticamente la entropía del sistema; ② En un script Groovy, concatenar valores como "${ctx.getThreadNum()}\_${System.nanoTime()}" para asegurar la unicidad global.

4.4 En los scripts de generación de parámetros, deshabilitar println y log.info, usando log.debug en su lugar

println en los scripts Groovy se imprimirá en la consola de JMeter, pero bajo alta concurrencia, una gran cantidad de println ralentizará severamente la ejecución del script (bloqueo de I/O). Mis pruebas mostraron que un script que contenía println("debug") reducía el TPS en un 18% con 2000 hilos. La práctica correcta es usar el objeto log de JMeter: log.debug("id\_usuario generado: " + idUsuario), y configurar log\_level.jmeter=DEBUG en jmeter.properties. De esta manera, los registros solo se imprimen durante la depuración y se desactivan automáticamente en las pruebas de carga.

4.5 La ruta del archivo CSV debe ser relativa, y las rutas deben ser idénticas en todas las máquinas JMeter

En pruebas de carga distribuidas, la máquina controladora (Master) distribuye el plan de prueba (.jmx) a las máquinas esclavas (Slave), pero no sincroniza el archivo CSV. Si en el Master se configura la ruta CSV como C:\\data\\users.csv, la máquina esclava no encontrará esa ruta y fallará silenciosamente, dejando todos los parámetros vacíos. Soluciones: ① Colocar el archivo CSV en el directorio bin de JMeter y especificar la ruta como users.csv (ruta relativa); ② O colocar el archivo previamente en la misma ruta en todas las máquinas esclavas (por ejemplo, /opt/jmeter/data/users.csv). Recuerda: la ruta debe ser idéntica, incluyendo mayúsculas y minúsculas (Linux es sensible).

4.6 Parámetros complejos (como JWT Token) deben separarse en generación y uso, prohibiendo la "generación única y reutilización global"

Algunos usuarios, para simplificar, colocan un JSR223 Sampler en la parte superior del Test Plan para generar un Token y lo almacenan en props, luego todas las solicitudes referencian este Token con ${\_\_P(token)}. Esto hace que todas las solicitudes compartan el mismo Token, con la misma caducidad, firma y payload. La práctica correcta es: colocar la lógica de generación del Token en un PreProcessor antes de cada solicitud HTTP que lo necesite, asegurando que cada solicitud tenga un ciclo de vida independiente. Si la generación del Token es costosa (por ejemplo, al invocar un servicio de claves), se puede combinar con caché de Redis, pero la clave de caché debe incluir el identificador del usuario (como token:${id\_usuario}), en lugar de una clave global.

4.7 Antes de la prueba de carga, es imprescindible realizar una "verificación de salud de los parámetros", no solo observar el TPS

Me he impuesto una regla de oro: antes de iniciar cada prueba de carga, debo muestrear 100 solicitudes para verificar tres aspectos de los parámetros: ① Unicidad (el número de id\_usuario únicos = 100); ② Conformidad (la tasa de coincidencia de expresiones regulares para números de teléfono, la tasa de corrección del dígito de verificación de identificaciones = 100%); ③ Actualidad (el valor máximo de marca\_tiempo - valor mínimo < 5 segundos). La herramienta es simple: exportar View Results in Table como CSV desde View Results Tree, y usar un script de Python con pandas.read\_csv().nunique() y validación de expresiones regulares. Esta verificación de 3 minutos puede prevenir el 80% de los incidentes de "prueba de carga efectiva, resultados inválidos".

5. Más Allá de los Parámetros: Construyendo un Sistema de Gestión de Parámetros de Pruebas Sostenible

La dinamización de parámetros no es una acción técnica única, sino un sistema que requiere una gestión continua. Cuando fui responsable de la construcción de la plataforma de pruebas de carga de la empresa, impulsé la implementación de un mecanismo de gestión de parámetros que transformó al equipo de "caótico en cada prueba de carga al configurar parámetros" a un modelo de "Parámetro como Servicio (Parameter as a Service)". Este mecanismo no depende de ninguna herramienta comercial, sino que se basa íntegramente en las capacidades nativas de JMeter más scripts ligeros, y ha estado funcionando de forma estable en 3 líneas de negocio durante 18 meses.

5.1 Biblioteca de Plantillas de Parámetros: Usando JSON Schema para Restringir las Reglas de Generación

Ya no mantenemos archivos CSV dispersos, sino que definimos un esquema JSON de plantilla de parámetros unificado:

{
 "type": "object",
 "properties": {
   "usuario": {
     "type": "object",
     "properties": {
       "id": {"type": "string", "pattern": "^U[0-9]{8}$"},
       "telefono": {"type": "string", "pattern": "^\\+?[1-9]\\d{9,14}$"},
       "nivel": {"type": "integer", "minimum": 1, "maximum": 10}
     },
     "required": ["id", "telefono", "nivel"]
   },
   "pedido": {
     "type": "object",
     "properties": {
       "monto": {"type": "number", "multipleOf": 0.01, "minimum": 0.01},
       "articulos": {"type": "array", "maxItems": 5, "minItems": 1, "items": {"type": "string"}}
     },
     "required": ["monto", "articulos"]
   }
 },
 "required": ["usuario", "pedido"]
}

Luego desarrollamos un script de Python que, al recibir el esquema y la cantidad (por ejemplo, 10000), genera automáticamente un CSV conforme. Las ventajas son: ① Desarrolladores, testers y equipo de pruebas de carga llegan a un consenso sobre las reglas de los parámetros; ② Añadir un nuevo campo (como estado\_vip) solo requiere actualizar el esquema, y el script se adapta automáticamente; ③ Se evitan errores de formato manual (como escribir un número de teléfono como 138-0013-8000).

5.2 Versionado de Parámetros: Gestión con Git + Versiones Semánticas

Todos los archivos de plantilla de parámetros (.json) y los scripts de generación (.py) se gestionan en un repositorio Git. La estrategia de ramas es: main para versiones estables, develop para versiones pre-producción, y cada etiqueta utiliza un número de versión semántico (como v2.1.0-datos-usuario). Durante las pruebas de carga, JMeter carga dinámicamente el CSV correspondiente mediante ${\_\_BeanShell("${props.get('param\_version') == 'v2.1.0' ? 'usuarios\_v2.1.0.csv' : 'usuarios\_default.csv'}")}. De esta manera, los parámetros de una prueba de carga pueden rastrearse con precisión, y los resultados de diferentes versiones de pruebas de carga pueden compararse de forma cruzada.

5.3 Panel de Control de Parámetros: Seguimiento en Tiempo Real de la Calidad de los Parámetros

En nuestro panel de control de pruebas de carga (Grafana), añadimos un panel de "Salud de Parámetros" que recopila tres métricas: ① tasa\_unicidad\_param (tasa de unicidad de id\_usuario en el último minuto); ② tasa\_conformidad\_param (tasa de conformidad de campos como números de teléfono/identificaciones); ③ conteo\_parametros\_obsoletos (número de solicitudes con marca\_tiempo con más de 5 minutos de antigüedad). Cuando tasa\_unicidad\_param < 0.99, se activa una alerta automática para revisar la configuración del CSV. Después de implementar este panel, el tiempo promedio de localización de fallos relacionados con parámetros se redujo de 15 a 2 minutos.

La esencia de este sistema es elevar los parámetros de ser un "accesorio de las pruebas de carga" a ser un "activo central de las pruebas de carga". No busca ser vistoso, solo resuelve un problema fundamental: que cada prueba de carga sea una medición honesta de la capacidad real del sistema. Cuando ya no te preocupes por si los parámetros están "activos", podrás concentrarte verdaderamente en la pregunta definitiva: ¿cuántos usuarios reales puede soportar el sistema?