La latencia se establece en el tiempo que lleva iniciar sesión.

Esta muestra le permite enviar una solicitud HTTP/HTTPS a un servidor web. También le permite controlar si JMeter analiza o no los archivos HTML en busca de imágenes y otros recursos incrustados y envía solicitudes HTTP para recuperarlos. Se recuperan los siguientes tipos de recursos incrustados:

• imágenes
• subprogramas
• hojas de estilo (CSS) y recursos a los que se hace referencia desde esos archivos
• guiones externos
• marcos, iframes
• imágenes de fondo (cuerpo, tabla, TD, TR)
• sonido de fondo

El analizador predeterminado es org.apache.jmeter.protocol.http.parser.LagartoBasedHtmlParser . Esto se puede cambiar utilizando la propiedad " htmlparser.className "; consulte jmeter.properties para obtener más información.

Si va a enviar varias solicitudes al mismo servidor web, considere usar un elemento de configuración de valores predeterminados de solicitud HTTP para que no tenga que ingresar la misma información para cada solicitud HTTP.

O bien, en lugar de agregar solicitudes HTTP manualmente, es posible que desee utilizar la grabadora de secuencias de comandos de prueba HTTP(S) de JMeter para crearlas. Esto puede ahorrarle tiempo si tiene muchas solicitudes HTTP o solicitudes con muchos parámetros.

Hay tres elementos de prueba diferentes que se utilizan para definir los muestreadores:

Muestreador AJP/1.3

usa el protocolo Tomcat mod_jk (permite probar Tomcat en modo AJP sin necesidad de Apache httpd) El AJP Sampler no admite la carga de múltiples archivos; sólo se utilizará el primer archivo.

Solicitud HTTP

Esto tiene un cuadro desplegable de implementación, que selecciona la implementación del protocolo HTTP que se va a usar:

Java

utiliza la implementación HTTP proporcionada por la JVM. Esto tiene algunas limitaciones en comparación con las implementaciones de HttpClient; consulte a continuación.

Cliente HTTP4

utiliza Apache HttpComponents HttpClient 4.x.

Valor en blanco

no establece la implementación en HTTP Samplers, por lo que se basa en los valores predeterminados de solicitud HTTP si están presentes o en la propiedad jmeter.httpsampler definida en jmeter.properties

Solicitud HTTP de GraphQL

Esta es una variación de la GUI de la solicitud HTTP para proporcionar elementos de la IU más convenientes para ver o editar la consulta GraphQL , las variables y el nombre de la operación , mientras los convierte en argumentos HTTP automáticamente bajo el capó usando la misma muestra. Esto oculta o personaliza los siguientes elementos de la interfaz de usuario, ya que son menos convenientes o irrelevantes para GraphQL a través de solicitudes HTTP/HTTPS:

• Método : solo los métodos POST y GET están disponibles conforme a la especificación GraphQL sobre HTTP. El método POST está seleccionado de forma predeterminada.
• Pestañas Parámetros y Cuerpo de la publicación : en su lugar, puede ver o editar el contenido de los parámetros a través de los elementos de la interfaz de usuario Consulta, Variables y Nombre de la operación.
• Pestaña Carga de archivo : irrelevante para las consultas de GraphQL.
• Recursos incrustados de la sección Archivos HTML en la pestaña Avanzado: irrelevante en las respuestas GraphQL JSON.

La implementación de Java HTTP tiene algunas limitaciones:

• No hay control sobre cómo se reutilizan las conexiones. Cuando JMeter libera una conexión, puede o no ser reutilizada por el mismo subproceso.
• La API se adapta mejor al uso de un solo subproceso: varias configuraciones se definen a través de las propiedades del sistema y, por lo tanto, se aplican a todas las conexiones.
• Sin soporte de autenticación Kerberos
• No es compatible con las pruebas de certificados basadas en clientes con Keystore Config.
• Mejor control del mecanismo de reintento
• No es compatible con hosts virtuales.
• Solo admite los siguientes métodos: GET , POST , HEAD , OPTIONS , PUT , DELETE y TRACE
• Mejor control sobre el almacenamiento en caché de DNS con DNS Cache Manager

Si la solicitud requiere autorización de inicio de sesión de servidor o proxy (es decir, cuando un navegador crearía un cuadro de diálogo emergente), también deberá agregar un elemento de configuración del administrador de autorización HTTP . Para los inicios de sesión normales (es decir, cuando el usuario ingresa la información de inicio de sesión en un formulario), deberá averiguar qué hace el botón de envío del formulario y crear una solicitud HTTP con el método apropiado (generalmente POST ) y los parámetros apropiados de la definición del formulario. . Si la página usa HTTP, puede usar JMeter Proxy para capturar la secuencia de inicio de sesión.

Se utiliza un contexto SSL independiente para cada subproceso. Si desea utilizar un solo contexto SSL (no el comportamiento estándar de los navegadores), configure la propiedad JMeter:

https.sessioncontext.shared=true

httpclient.reset_state_on_thread_group_iteration=true

https.predeterminado.protocolo=SSLv3

JMeter también permite habilitar protocolos adicionales, cambiando la propiedad https.socket.protocols .

Si la solicitud utiliza cookies, también necesitará un administrador de cookies HTTP . Puede agregar cualquiera de estos elementos al grupo de subprocesos o a la solicitud HTTP. Si tiene más de una solicitud HTTP que necesita autorizaciones o cookies, agregue los elementos al grupo de subprocesos. De esa forma, todos los controladores de solicitudes HTTP compartirán los mismos elementos del Administrador de autorización y el Administrador de cookies.

Si la solicitud utiliza una técnica llamada "Reescritura de URL" para mantener las sesiones, consulte la sección 6.1 Manejo de sesiones de usuario con reescritura de URL para conocer los pasos de configuración adicionales.

Esta muestra le permite enviar una solicitud JDBC (una consulta SQL) a una base de datos.

Antes de usar esto, debe configurar un elemento de configuración de configuración de conexión JDBC

Si se proporciona la lista de nombres de variables, para cada fila devuelta por una instrucción Select, las variables se configuran con el valor de la columna correspondiente (si se proporciona un nombre de variable) y también se configura el recuento de filas. Por ejemplo, si la instrucción Select devuelve 2 filas de 3 columnas y la lista de variables es A,,C , se configurarán las siguientes variables:

A_#=2 (número de filas)
A_1=columna 1, fila 1
A_2=columna 1, fila 2
C_#=2 (número de filas)
C_1=columna 3, fila 1
C_2=columna 3, fila 2

Si la instrucción Select devuelve cero filas, las variables A_# y C_# se establecerían en 0 y no se establecería ninguna otra variable.

Las variables antiguas se borran si es necesario; por ejemplo, si la primera selección recupera seis filas y una segunda selección devuelve solo tres filas, se eliminarán las variables adicionales para las filas cuatro, cinco y seis.

Esta muestra le permite controlar una clase Java que implementa la interfaz org.apache.jmeter.protocol.java.sampler.JavaSamplerClient . Al escribir su propia implementación de esta interfaz, puede usar JMeter para aprovechar múltiples subprocesos, controlar parámetros de entrada y recopilar datos.

El menú desplegable proporciona la lista de todas las implementaciones encontradas por JMeter en su classpath. Luego, los parámetros se pueden especificar en la tabla a continuación, según lo definido por su implementación. Se proporcionan dos ejemplos simples ( JavaTest y SleepTest ).

La muestra de ejemplo de JavaTest puede ser útil para comprobar los planes de prueba, ya que permite establecer valores en casi todos los campos. Estos pueden ser utilizados por Aserciones, etc. Los campos permiten el uso de variables, por lo que los valores de estos pueden verse fácilmente.

Si va a enviar varias solicitudes al mismo servidor LDAP, considere usar un elemento de configuración de valores predeterminados de solicitud LDAP para que no tenga que ingresar la misma información para cada solicitud LDAP.

Si va a enviar varias solicitudes al mismo servidor LDAP, considere usar un elemento de configuración predeterminado de solicitud extendida de LDAP para que no tenga que ingresar la misma información para cada solicitud LDAP.

AccessLogSampler fue diseñado para leer registros de acceso y generar solicitudes http. Para aquellos que no estén familiarizados con el registro de acceso, es el registro que el servidor web mantiene de cada solicitud que acepta. Esto significa cada imagen, archivo CSS, archivo JavaScript, archivo html,...

Tomcat usa el formato común para los registros de acceso. Esto significa que cualquier servidor web que use el formato de registro común puede usar AccessLogSampler. Los servidores que usan un formato de registro común incluyen: Tomcat, Resin, Weblogic y SunOne. El formato de registro común se ve así:

127.0.0.1 - - [21/oct/2003:05:37:21 -0500] "GET /index.jsp?%2Findex.jsp= HTTP/1.1" 200 8343

Para el futuro, sería bueno filtrar las entradas que no tienen un código de respuesta de 200 . Extender la muestra debería ser bastante simple. Hay dos interfaces que tienes que implementar:

• org.apache.jmeter.protocol.http.util.accesslog.LogParser
• org.apache.jmeter.protocol.http.util.accesslog.Generator

La implementación actual de AccessLogSampler usa el generador para crear un nuevo HTTPSampler. AccessLogSampler establece el nombre del servidor, el puerto y las imágenes obtenidas. A continuación, se llama al analizador con el número entero 1 , diciéndole que analice una entrada. Después de eso, se llama a HTTPSampler.sample() para realizar la solicitud.

muestra = (HTTPSampler) GENERADOR.generateRequest();
muestra.setDomain(this.getDomain());
muestra.setPort(this.getPort());
muestra.setImageParser(this.isImageParser());
PARSER.parse(1);
res = muestra.muestra();
res.setSampleLabel(muestra.toString());

• setGenerator(Generador)
• analizar (int)

Las clases que implementan la interfaz de Generator deben proporcionar una implementación concreta para todos los métodos. Para ver un ejemplo de cómo implementar cualquiera de las interfaces, consulte StandardGenerator y TCLogParser .

Esta muestra le permite escribir una muestra utilizando el lenguaje de secuencias de comandos BeanShell.

Para obtener detalles completos sobre el uso de BeanShell, consulte el sitio web de BeanShell.

El elemento de prueba admite los métodos de interfaz ThreadListener y TestListener . Estos deben definirse en el archivo de inicialización. Consulte el archivo BeanShellListeners.bshrc para ver definiciones de ejemplo.

El muestreador BeanShell también es compatible con la interfaz interrumpible . El método interrupt() se puede definir en el script o en el archivo de inicio.

El muestreador JSR223 permite que se use el código de secuencia de comandos JSR223 para realizar una muestra o algún cálculo necesario para crear/actualizar variables.

MuestraResultado.setIgnorar();

Los elementos de prueba JSR223 tienen una función (compilación) que puede aumentar significativamente el rendimiento. Para beneficiarse de esta característica:

• Utilice archivos de secuencias de comandos en lugar de insertarlos. Esto hará que JMeter los compile si esta función está disponible en ScriptEngine y los almacene en caché.
• O Use Script Text y marque Cache compilated script si está disponible .
  Al usar esta función, asegúrese de que su código de secuencia de comandos no use variables de JMeter o llamadas a funciones de JMeter directamente en el código de secuencia de comandos, ya que el almacenamiento en caché solo almacenaría en caché el primer reemplazo. En su lugar, utilice parámetros de secuencia de comandos.
  Para beneficiarse del almacenamiento en caché y la compilación, el motor de lenguaje utilizado para las secuencias de comandos debe implementar la interfaz compilable JSR223 (Groovy es uno de estos, java, beanshell y javascript no lo son)
  Cuando utilice Groovy como lenguaje de secuencias de comandos y no verifique la secuencia de comandos compilada de Cache si está disponible (aunque se recomienda el almacenamiento en caché), debe establecer esta propiedad JVM -Dgroovy.use.classvalue=true debido a una fuga de Groovy Memory a partir de la versión 2.4.6, consulte:

  • MARAVILLOSO-7683
  • MARAVILLOSO-7591
  • JDK-8136353

jsr223.compiled_scripts_cache_size=100

TCP Sampler abre una conexión TCP/IP al servidor especificado. Luego envía el texto y espera una respuesta.

Si se selecciona " Reutilizar conexión ", las conexiones se comparten entre Samplers en el mismo subproceso, siempre que se utilicen exactamente la misma cadena de nombre de host y puerto. Diferentes combinaciones de hosts/puertos utilizarán diferentes conexiones, al igual que diferentes subprocesos. Si se seleccionan " Reutilizar conexión " y " Cerrar conexión ", el zócalo se cerrará después de ejecutar el muestreador. En la siguiente muestra, se creará otro zócalo. Es posible que desee cerrar un zócalo al final de cada bucle de hilo.

Si se detecta un error, o no se selecciona " Reutilizar conexión ", el socket se cierra. Se reabrirá otro socket en la siguiente muestra.

Las siguientes propiedades se pueden utilizar para controlar su funcionamiento:

tcp.estado.prefijo

texto que precede a un número de estado

tcp.status.sufijo

texto que sigue a un número de estado

tcp.estado.propiedades

nombre del archivo de propiedades para convertir códigos de estado en mensajes

controlador tcp

Nombre de la clase del controlador TCP (predeterminado TCPClientImpl ): solo se usa si no se especifica en la GUI

Los usuarios pueden proporcionar su propia implementación. La clase debe extender org.apache.jmeter.protocol.tcp.sampler.TCPClient .

Actualmente se proporcionan las siguientes implementaciones.

• TCPClientImpl
• BinaryTCPClientImpl
• LongitudPrefijadoBinarioTCPClientImpl

TCPClientImpl

Esta implementación es bastante básica. Al leer la respuesta, lee hasta el final del byte de línea, si esto se define configurando la propiedad tcp.eolByte , de lo contrario, hasta el final del flujo de entrada. Puede controlar la codificación del conjunto de caracteres configurando tcp.charset , que tendrá la codificación predeterminada de la plataforma.

BinaryTCPClientImpl

Esta implementación convierte la entrada de la GUI, que debe ser una cadena codificada en hexadecimal, en binaria y realiza lo contrario al leer la respuesta. Al leer la respuesta, lee hasta el final del byte del mensaje, si esto se define configurando la propiedad tcp.BinaryTCPClient.eomByte , de lo contrario, hasta el final del flujo de entrada.

LongitudPrefijadoBinarioTCPClientImpl

Esta implementación amplía BinaryTCPClientImpl prefijando los datos del mensaje binario con un byte de longitud binaria. El prefijo de longitud por defecto es de 2 bytes. Esto se puede cambiar configurando la propiedad tcp.binarylength.prefix.length .

Manejo de tiempos de espera

Si se establece el tiempo de espera, la lectura finalizará cuando expire. Entonces, si está utilizando un eolByte / eomByte , asegúrese de que el tiempo de espera sea lo suficientemente largo, de lo contrario, la lectura terminará antes de tiempo.

Manejo de respuestas

Si se define tcp.status.prefix , se busca en el mensaje de respuesta el texto que sigue hasta el sufijo. Si se encuentra algún texto de este tipo, se utiliza para establecer el código de respuesta. A continuación, el mensaje de respuesta se obtiene del archivo de propiedades (si se proporciona).

Uso de pre y sufijo ¶

Por ejemplo, si el prefijo = " [ " y el sufijo = " ] ", entonces la siguiente respuesta:

[J28] XI123,23, GBP, CR

tendría el código de respuesta J28 .

Los códigos de respuesta en el rango " 400 "-" 499 " y " 500 "-" 599 " actualmente se consideran fallas; todos los demás tienen éxito. [¡Esto debe hacerse configurable!]

JMS Publisher publicará mensajes en un destino determinado (tema/cola). Para aquellos que no están familiarizados con JMS, es la especificación J2EE para mensajería. Existen numerosos servidores JMS en el mercado y varias opciones de código abierto.

El suscriptor de JMS se suscribirá a los mensajes en un destino determinado (tema o cola). Para aquellos que no están familiarizados con JMS, es la especificación J2EE para mensajería. Existen numerosos servidores JMS en el mercado y varias opciones de código abierto.

Este muestreador envía y, opcionalmente, recibe mensajes JMS a través de conexiones punto a punto (colas). Es diferente de los mensajes de publicación/suscripción y generalmente se usa para manejar transacciones.

request_only normalmente se utilizará para poner carga en un sistema JMS.
request_reply se utilizará cuando desee probar el tiempo de respuesta de un servicio JMS que procesa los mensajes enviados a la cola de solicitudes, ya que este modo esperará la respuesta en la cola de respuestas enviada por este servicio.
examinar devuelve la profundidad actual de la cola, es decir, el número de mensajes en la cola.
read lee un mensaje de la cola (si lo hay).
clear borra la cola, es decir, elimina todos los mensajes de la cola.

JMeter usa las propiedades java.naming.security.[principal|credentials] , si están presentes, al crear la conexión de cola. Si no se desea este comportamiento, establezca la propiedad JMeter JMSSampler.useSecurity.properties=false

• en lugar de usar la interfaz de prueba de JMeter, escanea los archivos jar en busca de clases que extiendan la clase TestCase de JUnit . Eso incluye cualquier clase o subclase.
• Los archivos jar de prueba JUnit deben colocarse en jmeter/lib/junit en lugar del directorio /lib . También puede usar la propiedad " user.classpath " para especificar dónde buscar las clases de TestCase .
• JUnit sampler no usa pares de nombre/valor para la configuración como Java Request . El muestreador asume que setUp y tearDown configurarán la prueba correctamente.
• El muestreador mide el tiempo transcurrido solo para el método de prueba y no incluye configuración ni desmontaje .
• Cada vez que se llama al método de prueba, JMeter pasará el resultado a los oyentes.
• El soporte para oneTimeSetUp y oneTimeTearDown se realiza como un método. Dado que JMeter tiene subprocesos múltiples, no podemos llamar a oneTimeSetUp / oneTimeTearDown de la misma manera que lo hace Maven.
• El muestreador informa las excepciones inesperadas como errores. Existen algunas diferencias importantes entre los ejecutores de pruebas JUnit estándar y la implementación de JMeter. En lugar de crear una nueva instancia de la clase para cada prueba, JMeter crea 1 instancia por muestra y la reutiliza. Esto se puede cambiar con la casilla de verificación " Crear una nueva instancia por muestra ".

clase pública myTestCase {
  myTestCase público () {}
}

clase pública myTestCase {
  public myTestCase(Texto de cadena) {
    super(texto);
  }
}

Mail Reader Sampler puede leer (y opcionalmente borrar) mensajes de correo usando los protocolos POP3(S) o IMAP(S).

Este sampler también puede ser útil en conjunto con Transaction Controller, ya que permite incluir pausas sin necesidad de generar una muestra. Para demoras variables, establezca el tiempo de pausa en cero y agregue un temporizador como elemento secundario.

La acción " Detener " detiene el subproceso o la prueba después de completar las muestras que están en curso. La acción " Detener ahora " detiene la prueba sin esperar a que se completen las muestras; interrumpirá cualquier muestra activa. Si algunos subprocesos no se detienen dentro del límite de tiempo de 5 segundos, se mostrará un mensaje en el modo GUI. Puede intentar usar el comando Detener para ver si esto detendrá los subprocesos, pero si no, debe salir de JMeter. En el modo CLI, JMeter se cerrará si algunos subprocesos no se detienen dentro del límite de tiempo de 5 segundos.

SMTP Sampler puede enviar mensajes de correo utilizando el protocolo SMTP/SMTPS. Es posible establecer protocolos de seguridad para la conexión (SSL y TLS), así como autenticación de usuarios. Si se utiliza un protocolo de seguridad, se realizará una verificación en el certificado del servidor.
Hay dos alternativas disponibles para manejar esta verificación:

Confiar en todos los certificados

Esto ignorará la verificación de la cadena de certificados.

Usar un almacén de confianza local

Con esta opción, la cadena de certificados se validará con el archivo del almacén de confianza local.

OS Process Sampler es una muestra que se puede usar para ejecutar comandos en la máquina local.
Debería permitir la ejecución de cualquier comando que se pueda ejecutar desde la línea de comandos.
Se puede habilitar la validación del código de retorno y se puede especificar el código de retorno esperado.

Tenga en cuenta que los shells del sistema operativo generalmente proporcionan análisis de línea de comandos. Esto varía entre los sistemas operativos, pero generalmente el shell dividirá los parámetros en espacios en blanco. Algunos shells expanden los nombres de archivos comodín; algunos no. El mecanismo de cotización también varía entre los sistemas operativos. La muestra deliberadamente no realiza ningún análisis ni manejo de cotizaciones. El comando y sus parámetros deben proporcionarse en la forma esperada por el ejecutable. Esto significa que la configuración de la muestra no será transferible entre sistemas operativos.

Muchos sistemas operativos tienen algunos comandos integrados que no se proporcionan como ejecutables independientes. Por ejemplo, el comando DIR de Windows es parte del intérprete de comandos ( CMD.EXE ). Estos integrados no se pueden ejecutar como programas independientes, sino que se deben proporcionar como argumentos al intérprete de comandos adecuado.

Por ejemplo, la línea de comandos de Windows: DIR C:\TEMP debe especificarse de la siguiente manera:

Dominio:

CMD

Parámetro 1:

/C

Parámetro 2:

DIRECCIÓN

Parámetro 3:

C:\TEMP

Esta muestra le permite enviar una solicitud a un MongoDB.

Antes de usar esto, debe configurar un elemento de configuración de configuración de origen de MongoDB

Esta muestra le permite ejecutar consultas Cypher a través del protocolo Bolt.

Antes de usar esto, debe configurar una configuración de conexión de pernos

Cada solicitud utiliza una conexión adquirida del grupo y la devuelve al grupo cuando se completa la muestra. El tamaño del grupo de conexiones usa los valores predeterminados del controlador (~100) y no se puede configurar en este momento.

El tiempo de respuesta medido corresponde a la ejecución de la consulta "completa", incluido el tiempo para ejecutar la consulta cifrada Y el tiempo para consumir los resultados enviados por la base de datos.

El controlador lógico simple le permite organizar sus muestreadores y otros controladores lógicos. A diferencia de otros Logic Controllers, este controlador no ofrece más funciones que las de un dispositivo de almacenamiento.

Si agrega controladores generativos o lógicos a un controlador de bucle, JMeter los recorrerá una cierta cantidad de veces, además del valor de bucle que especificó para el grupo de subprocesos. Por ejemplo, si agrega una solicitud HTTP a un controlador de bucle con un recuento de bucles de dos y configura el recuento de bucles del grupo de subprocesos en tres, JMeter enviará un total de 2 * 3 = 6 solicitudes HTTP.

El controlador lógico de una sola vez le dice a JMeter que procese los controladores dentro de él solo una vez por subproceso, y pase por alto cualquier solicitud debajo de él durante las iteraciones posteriores a través del plan de prueba.

El controlador de una sola vez ahora se ejecutará siempre durante la primera iteración de cualquier controlador principal en bucle. Por lo tanto, si el controlador de solo una vez se coloca bajo un controlador de bucle especificado para repetir 5 veces, entonces el controlador de solo una vez se ejecutará solo en la primera iteración a través del controlador de bucle (es decir, cada 5 veces).

Tenga en cuenta que esto significa que el controlador de una sola vez seguirá comportándose como se esperaba anteriormente si se coloca en un grupo de subprocesos (se ejecuta solo una vez por prueba por subproceso), pero ahora el usuario tiene más flexibilidad en el uso del controlador de una sola vez.

Para las pruebas que requieren un inicio de sesión, considere colocar la solicitud de inicio de sesión en este controlador, ya que cada subproceso solo necesita iniciar sesión una vez para establecer una sesión.

Si agrega controladores generativos o lógicos a un controlador intercalado, JMeter alternará entre cada uno de los otros controladores para cada iteración de bucle.

El Controlador Lógico Aleatorio actúa de manera similar al Controlador Intercalado, excepto que en lugar de ir en orden a través de sus subcontroladores y muestreadores, elige uno al azar en cada pasada.

El controlador de orden aleatorio se parece mucho a un controlador simple en el sentido de que ejecutará cada elemento secundario como máximo una vez, pero el orden de ejecución de los nodos será aleatorio.

El controlador de rendimiento permite al usuario controlar la frecuencia con la que se ejecuta. Hay dos modos:

• porcentaje de ejecución
• ejecuciones totales

Porcentaje de ejecuciones

hace que el controlador ejecute un cierto porcentaje de las iteraciones a través del plan de prueba.

Ejecuciones totales

hace que el controlador deje de ejecutarse después de que haya ocurrido un cierto número de ejecuciones.

El controlador de tiempo de ejecución controla cuánto tiempo se ejecutarán sus hijos. El controlador ejecutará a sus hijos hasta que se excedan los tiempos de ejecución configurados.

El controlador If permite al usuario controlar si los elementos de prueba debajo de él (sus hijos) se ejecutan o no.

De forma predeterminada, la condición se evalúa solo una vez en la entrada inicial, pero tiene la opción de evaluarla para cada elemento ejecutable contenido en el controlador.

La mejor opción (la predeterminada) es marcar ¿Interpretar condición como expresión variable? , luego en el campo de condición tienes 2 opciones:

• Opción 1: Usar una variable que contenga verdadero o falso
  Si desea probar si la última muestra fue exitosa, puede usar ${JMeterThread.last_sample_ok}

  
• Opción 2: use una función ( se recomienda ${__jexl3()} ) para evaluar una expresión que debe devolver verdadero o falso

  

"${miVar}" == "\${miVar}"

"${miVar}" != "\${miVar}"

El controlador while ejecuta a sus hijos hasta que la condición es " falsa ".

Posibles valores de condición:

• en blanco: sale del ciclo cuando falla la última muestra en el ciclo
• LAST : sale del bucle cuando falla la última muestra del bucle. Si la última muestra justo antes del ciclo falló, no ingrese el ciclo.
• De lo contrario, salga (o no ingrese) del bucle cuando la condición sea igual a la cadena " falso "

• ${VAR} - donde VAR se establece en falso por algún otro elemento de prueba
• ${__jexl3(${C}==10)}
• ${__jexl3("${VAR2}"=="abcd")}
• ${_P(propiedad)} - donde la propiedad se establece en " falso " en otro lugar

El Switch Controller actúa como el Interleave Controller en el sentido de que ejecuta uno de los elementos subordinados en cada iteración, pero en lugar de ejecutarlos en secuencia, el controlador ejecuta el elemento definido por el valor del switch.

Si el valor del interruptor está fuera de rango, ejecutará el elemento cero, que por lo tanto actúa como valor predeterminado para el caso numérico. También ejecuta el elemento cero si el valor es la cadena vacía.

Si el valor no es numérico (y no está vacío), Switch Controller busca el elemento con el mismo nombre (las mayúsculas y minúsculas son significativas). Si ninguno de los nombres coincide, se selecciona el elemento denominado " predeterminado " (mayúsculas y minúsculas no significativas). Si no hay un valor predeterminado, entonces no se selecciona ningún elemento y el controlador no ejecutará nada.

Un controlador ForEach recorre los valores de un conjunto de variables relacionadas. Cuando agrega muestras (o controladores) a un controlador ForEach, cada muestra (o controlador) se ejecuta una o más veces, donde durante cada ciclo la variable tiene un nuevo valor. La entrada debe constar de varias variables, cada una extendida con un guión bajo y un número. Cada una de estas variables debe tener un valor. Entonces, por ejemplo, cuando la variable de entrada tiene el nombre inputVar , se deberían haber definido las siguientes variables:

• entradaVar_1 = Wendy
• inputVar_2 = charles
• inputVar_3 = pedro
• inputVar_4 = juan

Nota: el separador " _ " ahora es opcional.

Cuando la variable de retorno se proporciona como " returnVar ", la colección de muestreadores y controladores bajo el controlador ForEach se ejecutará 4 veces consecutivas, y la variable de retorno tendrá los valores anteriores respectivos, que luego se pueden usar en los muestreadores.

Es especialmente adecuado para ejecutarse con el posprocesador de expresiones regulares. Esto puede "crear" las variables de entrada necesarias a partir de los datos de resultado de una solicitud anterior. Al omitir el separador " _ ", el controlador ForEach se puede usar para recorrer los grupos usando la variable de entrada refName_g , y también puede recorrer todos los grupos en todas las coincidencias usando una variable de entrada de la forma refName_${C }_g , donde C es una variable de contador.

El controlador del módulo proporciona un mecanismo para sustituir fragmentos del plan de prueba en el plan de prueba actual en tiempo de ejecución.

Un fragmento de plan de prueba consta de un controlador y todos los elementos de prueba (muestras, etc.) que contiene. El fragmento se puede ubicar en cualquier grupo de subprocesos. Si el fragmento está ubicado en un grupo de subprocesos, su controlador se puede desactivar para evitar que el fragmento se ejecute excepto por el controlador del módulo. O puede almacenar los fragmentos en un grupo de subprocesos ficticio y deshabilitar todo el grupo de subprocesos.

Puede haber múltiples fragmentos, cada uno con una serie diferente de muestras debajo de ellos. El controlador del módulo se puede usar para cambiar fácilmente entre estos múltiples casos de prueba simplemente eligiendo el controlador apropiado en su cuadro desplegable. Esto proporciona comodidad para ejecutar muchos planes de prueba alternativos de forma rápida y sencilla.

Un nombre de fragmento se compone del nombre del controlador y todos sus nombres principales. Por ejemplo:

Plan de prueba/Protocolo: JDBC/Control/Controlador intercalado (Módulo 1)

Cualquier fragmento utilizado por el controlador del módulo debe tener un nombre único , ya que el nombre se utiliza para encontrar el controlador de destino cuando se vuelve a cargar un plan de prueba. Por esta razón, es mejor asegurarse de que el nombre del controlador se cambie del predeterminado, como se muestra en el ejemplo anterior; de lo contrario, se puede crear un duplicado accidentalmente cuando se agregan nuevos elementos al plan de prueba.

El controlador de inclusión está diseñado para utilizar un archivo JMX externo. Para usarlo, cree un Fragmento de prueba debajo del Plan de prueba y agregue los muestreadores, controladores, etc. que desee debajo. Luego guarde el plan de prueba. El archivo ahora está listo para incluirse como parte de otros planes de prueba.

Para mayor comodidad, también se puede agregar un grupo de subprocesos en el archivo JMX externo para fines de depuración. Se puede utilizar un controlador de módulo para hacer referencia al fragmento de prueba. El grupo de subprocesos se ignorará durante el proceso de inclusión.

Si la prueba utiliza un administrador de cookies o variables definidas por el usuario, estas deben colocarse en el plan de prueba de nivel superior, no en el archivo incluido; de lo contrario, no se garantiza que funcionen.

Si el archivo no se puede encontrar en la ubicación proporcionada por prefijo + nombre de archivo , el controlador intenta abrir el nombre de archivo relativo al directorio de inicio de JMX.

Transaction Controller genera una muestra adicional que mide el tiempo total necesario para realizar los elementos de prueba anidados.

Hay dos modos de funcionamiento:

• se agrega una muestra adicional después de las muestras anidadas
• se agrega una muestra adicional como padre de las muestras anidadas

El tiempo de muestra generado incluye todos los tiempos para los muestreadores anidados, excluyendo de forma predeterminada (desde 2.11) los temporizadores y el tiempo de procesamiento de los pre/postprocesadores, a menos que se marque la casilla de verificación " Incluir la duración del cronómetro y los pre-postprocesadores en la muestra generada ". Dependiendo de la resolución del reloj, puede ser un poco más largo que la suma de los muestreadores individuales más los temporizadores. El reloj puede funcionar después de que el controlador registró la hora de inicio, pero antes de que comience la primera muestra. Del mismo modo al final.

La muestra generada solo se considera correcta si todas sus submuestras lo son.

En el modo principal, las muestras individuales todavía se pueden ver en el Oyente de vista de árbol, pero ya no aparecen como entradas separadas en otros Oyentes. Además, las submuestras no aparecen en los archivos de registro CSV, pero se pueden guardar en archivos XML.

El controlador de grabación es un marcador de posición que indica dónde debe grabar las muestras el servidor proxy. Durante la ejecución de prueba, no tiene ningún efecto, similar al controlador simple. Sin embargo, durante la grabación con HTTP(S) Test Script Recorder , todas las muestras grabadas se guardarán de forma predeterminada en el controlador de grabación.

El controlador de sección crítica garantiza que sus elementos secundarios (muestreadores/controladores, etc.) serán ejecutados por un solo subproceso, ya que se tomará un bloqueo con nombre antes de ejecutar los elementos secundarios del controlador.

Los oyentes se pueden configurar para guardar diferentes elementos en los archivos de registro de resultados (JTL) utilizando la ventana emergente de configuración como se muestra a continuación. Los valores predeterminados se definen como se describe en la documentación de configuración predeterminada de escucha . Los elementos con ( CSV ) después del nombre solo se aplican al formato CSV; los elementos con ( XML ) solo se aplican al formato XML. Actualmente, el formato CSV no se puede utilizar para guardar elementos que incluyan saltos de línea.

Tenga en cuenta que las cookies, el método y la cadena de consulta se guardan como parte de la opción " Datos de muestra".

El oyente Graph Results genera un gráfico simple que traza todos los tiempos de muestra. En la parte inferior del gráfico, la muestra actual (negro), el promedio actual de todas las muestras (azul), la desviación estándar actual (rojo) y la tasa de rendimiento actual (verde) se muestran en milisegundos.

El número de rendimiento representa el número real de solicitudes por minuto que manejó el servidor. Este cálculo incluye cualquier retraso que haya agregado a su prueba y el propio tiempo de procesamiento interno de JMeter. La ventaja de hacer el cálculo de esta manera es que este número representa algo real: su servidor, de hecho, manejó esa cantidad de solicitudes por minuto, y puede aumentar la cantidad de subprocesos y/o disminuir las demoras para descubrir el rendimiento máximo de su servidor. Mientras que si realizó cálculos que excluyeron los retrasos y el procesamiento de JMeter, no estaría claro qué podría concluir a partir de ese número.

El visualizador de resultados de aserción muestra la etiqueta de cada muestra tomada. También informa fallas de cualquier aserción que sea parte del plan de prueba.

Hay varias formas de ver la respuesta, que se pueden seleccionar mediante un cuadro desplegable en la parte inferior del panel izquierdo.

Recuento de coincidencias: 74
Coincidencia[1]=#funciones
Partido[2]=#qué_puede_hacer
Partido[3]=#dónde
Partido[4]=#cómo
Partido[5]=#función_ayudante
Coincidencia[6]=#funciones
Coincidencia[7]=#__regexFunción
Coincidencia[8]=#__regexFunction_parms
Partido[9]=#__contador
… y así …

Número de partidos: 26
Partido[1][0]=JMeter - Apache JMeter</título>
Partido[1][1]=JMeter
Coincidencia[2][0]=JMeter" title="JMeter" border="0"/></a>
Partido[2][1]=JMetro
Match[3][0]=JMeterCommitters">Contribuidores</a>
Partido[3][1]=JMeterCommitters
… y así …

imagen/
audio/
video/

Desplazarse automáticamente? opción de permiso para mostrar el último nodo en la selección de árbol

Con la opción Buscar , la mayoría de las vistas también permiten buscar los datos mostrados; el resultado de la búsqueda se resaltará en la pantalla de arriba. Por ejemplo, la siguiente captura de pantalla del panel de control muestra un resultado de la búsqueda de " Java ". Tenga en cuenta que la búsqueda opera en el texto visible, por lo que puede obtener resultados diferentes al buscar en las vistas Texto y HTML.
Nota: La expresión regular utiliza el motor Java (no el motor ORO como la vista Regular Expression Extractor o Regexp Tester).

Si no se proporciona ningún tipo de contenido , el contenido no se mostrará en ninguno de los paneles de Datos de respuesta. Puede usar Guardar respuestas en un archivo para guardar los datos en este caso. Tenga en cuenta que los datos de respuesta seguirán estando disponibles en el resultado de la muestra, por lo que aún se puede acceder a ellos mediante posprocesadores.

Si los datos de respuesta superan los 200 000, no se mostrarán. Para cambiar este límite, establezca la propiedad de JMeter view.results.tree.max_size . También puede guardar la respuesta completa en un archivo usando Guardar respuestas en un archivo .

Se pueden crear renderizadores adicionales. La clase debe implementar la interfaz org.apache.jmeter.visualizers.ResultRenderer y/o extender la clase abstracta org.apache.jmeter.visualizers.SamplerResultTab , y el código compilado debe estar disponible para JMeter (por ejemplo, agregándolo a lib/ directorio externo ).

El rendimiento se calcula desde el punto de vista del objetivo del muestreador (por ejemplo, el servidor remoto en el caso de muestras HTTP). JMeter tiene en cuenta el tiempo total durante el cual se han generado las solicitudes. Si hay otros muestreadores y temporizadores en el mismo subproceso, aumentarán el tiempo total y, por lo tanto, reducirán el valor de rendimiento. Por lo tanto, dos muestreadores idénticos con nombres diferentes tendrán la mitad del rendimiento de dos muestreadores con el mismo nombre. Es importante elegir correctamente los nombres de las muestras para obtener los mejores resultados del informe agregado.

El cálculo de los valores de la mediana y la línea del 90 % (percentil 90 ) ^requiere memoria adicional. JMeter ahora combina muestras con el mismo tiempo transcurrido, por lo que se utiliza mucha menos memoria. Sin embargo, para las muestras que toman más de unos pocos segundos, la probabilidad es que menos muestras tengan tiempos idénticos, en cuyo caso se necesitará más memoria. Tenga en cuenta que puede usar este oyente después para volver a cargar un archivo de resultados CSV o XML, que es la forma recomendada de evitar impactos en el rendimiento. Consulte el Informe resumido para ver un Listener similar que no almacena muestras individuales y, por lo tanto, necesita una memoria constante.

• Etiqueta - La etiqueta de la muestra. Si se selecciona "¿ Incluir el nombre del grupo en la etiqueta? ", el nombre del grupo de subprocesos se agrega como prefijo. Esto permite clasificar etiquetas idénticas de diferentes grupos de hilos por separado si es necesario.
• # Samples - El número de muestras con la misma etiqueta
• Promedio : el tiempo promedio de un conjunto de resultados
• Mediana : la mediana es el tiempo en medio de un conjunto de resultados. El 50 % de las muestras no tomó más de este tiempo; el resto tomó al menos el mismo tiempo.
• Línea del 90 %: el 90 % de las muestras no tomó más de este tiempo. Las muestras restantes tomaron al menos tanto tiempo como este. ( ^percentil 90 )
• Línea del 95 %: el 95 % de las muestras no tomó más de este tiempo. Las muestras restantes tardaron al menos tanto como esto. ( ^percentil 95 )
• Línea del 99 %: el 99 % de las muestras no tomó más de este tiempo. Las muestras restantes tardaron al menos tanto como esto. ( ^percentil 99 )
• Min - El tiempo más corto para las muestras con la misma etiqueta
• Max: el tiempo más largo para las muestras con la misma etiqueta
• Error % - Porcentaje de solicitudes con errores
• Rendimiento : el rendimiento se mide en solicitudes por segundo/minuto/hora. La unidad de tiempo se elige de modo que la tasa mostrada sea al menos 1,0. Cuando el rendimiento se guarda en un archivo CSV, se expresa en solicitudes/segundo, es decir, 30,0 solicitudes/minuto se guardan como 0,5.
• KB/s recibidos : el rendimiento medido en kilobytes recibidos por segundo
• KB/s enviados : el rendimiento medido en kilobytes enviados por segundo

Los tiempos están en milisegundos.

De forma predeterminada, solo muestra las muestras principales (principales); no muestra las submuestras (muestras secundarias). JMeter tiene una casilla de verificación " ¿Muestras secundarias? ". Si se selecciona, se muestran las submuestras en lugar de las muestras principales.

El visualizador de correo se puede configurar para enviar correo electrónico si una ejecución de prueba recibe demasiadas respuestas fallidas del servidor.

BeanShell Listener permite el uso de BeanShell para procesar muestras para guardar, etc.

Para obtener detalles completos sobre el uso de BeanShell, consulte el sitio web de BeanShell.

El elemento de prueba admite los métodos ThreadListener y TestListener . Estos deben definirse en el archivo de inicialización. Consulte el archivo BeanShellListeners.bshrc para ver definiciones de ejemplo.

El rendimiento se calcula desde el punto de vista del objetivo del muestreador (por ejemplo, el servidor remoto en el caso de muestras HTTP). JMeter tiene en cuenta el tiempo total durante el cual se han generado las solicitudes. Si hay otros muestreadores y temporizadores en el mismo subproceso, aumentarán el tiempo total y, por lo tanto, reducirán el valor de rendimiento. Por lo tanto, dos muestreadores idénticos con nombres diferentes tendrán la mitad del rendimiento de dos muestreadores con el mismo nombre. Es importante elegir correctamente las etiquetas de muestra para obtener los mejores resultados del Informe.

• Etiqueta - La etiqueta de la muestra. Si se selecciona "¿ Incluir el nombre del grupo en la etiqueta? ", el nombre del grupo de subprocesos se agrega como prefijo. Esto permite clasificar etiquetas idénticas de diferentes grupos de hilos por separado si es necesario.
• # Samples - El número de muestras con la misma etiqueta
• Promedio : el tiempo promedio transcurrido de un conjunto de resultados
• Min : el tiempo transcurrido más bajo para las muestras con la misma etiqueta
• Max : el tiempo transcurrido más largo para las muestras con la misma etiqueta
• estándar desarrollo - la desviación estándar del tiempo transcurrido de la muestra
• Error % - Porcentaje de solicitudes con errores
• Rendimiento : el rendimiento se mide en solicitudes por segundo/minuto/hora. La unidad de tiempo se elige de modo que la tasa mostrada sea al menos 1.0 . Cuando el rendimiento se guarda en un archivo CSV, se expresa en solicitudes/segundo, es decir, 30,0 solicitudes/minuto se guardan como 0,5 .
• KB/s recibidos : el rendimiento medido en kilobytes por segundo
• KB/s enviados : el rendimiento medido en kilobytes por segundo
• Promedio Bytes : tamaño promedio de la respuesta de la muestra en bytes.

Los tiempos están en milisegundos.

Este elemento de prueba se puede colocar en cualquier parte del plan de prueba. Para cada muestra en su ámbito, creará un archivo de los Datos de respuesta. El uso principal para esto es en la creación de pruebas funcionales, pero también puede ser útil cuando la respuesta es demasiado grande para mostrarse en Ver resultados del árbol de escucha. El nombre del archivo se crea a partir del prefijo especificado, más un número (a menos que esté deshabilitado, consulte a continuación). La extensión del archivo se crea a partir del tipo de documento, si se conoce. Si no se conoce, la extensión del archivo se establece en ' desconocido'. Si la numeración está deshabilitada y la adición de un sufijo está deshabilitada, el prefijo del archivo se toma como el nombre completo del archivo. Esto permite generar un nombre de archivo fijo si es necesario. El nombre del archivo generado se almacena en la respuesta de muestra y se puede guardar en el archivo de salida del registro de prueba si es necesario.

La muestra actual se guarda primero, seguida de cualquier submuestra (muestras secundarias). Si se proporciona un nombre de variable, los nombres de los archivos se guardan en el orden en que aparecen las submuestras. Vea abajo.

El JSR223 Listener permite que el código de script JSR223 se aplique a los resultados de la muestra.

# Defina la siguiente propiedad para iniciar automáticamente un resúmen con ese nombre
# (se aplica solo al modo CLI)
#resumen.name=resumen
#
# intervalo entre resúmenes (en segundos) por defecto 3 minutos
#resumen.intervalo=30
#
# Escribir mensajes en el archivo de registro
#resumen.log=true
#
# Escribir mensajes en System.out
#resumen.out=true

etiqueta + 16 en 0:00:12 = 1,3/s Promedio: 1608 Min: 1163 Max: 2009 Err: 0 (0,00%) Activo: 5 Iniciado: 5 Finalizado: 0
etiqueta + 82 en 0:00:30 = 2,7/s Promedio: 1518 Min: 1003 Max: 2020 Err: 0 (0,00%) Activo: 5 Iniciado: 5 Finalizado: 0
etiqueta = 98 en 0:00:42 = 2,3/s Promedio: 1533 Min: 1003 Max: 2020 Err: 0 (0,00 %)
etiqueta + 85 en 0:00:30 = 2,8/s Promedio: 1505 Min: 1008 Max: 2005 Err: 0 (0,00%) Activo: 5 Iniciado: 5 Finalizado: 0
etiqueta = 183 en 0:01:13 = 2,5/s Promedio: 1520 Min: 1003 Max: 2020 Err: 0 (0,00 %)
etiqueta + 79 en 0:00:30 = 2,7/s Promedio: 1578 Min: 1089 Max: 2012 Err: 0 (0,00%) Activo: 5 Iniciado: 5 Finalizado: 0
etiqueta = 262 en 0:01:43 = 2,6/s Promedio: 1538 Min: 1003 Max: 2020 Err: 0 (0,00 %)
etiqueta + 80 en 0:00:30 = 2,7/s Promedio: 1531 Min: 1013 Max: 2014 Err: 0 (0,00%) Activo: 5 Iniciado: 5 Finalizado: 0
etiqueta = 342 en 0:02:12 = 2,6/s Promedio: 1536 Min: 1003 Max: 2020 Err: 0 (0,00 %)
etiqueta + 83 en 0:00:31 = 2,7/s Promedio: 1512 Min: 1003 Max: 1982 Err: 0 (0,00%) Activo: 5 Iniciado: 5 Finalizado: 0
etiqueta = 425 en 0:02:43 = 2,6/s Promedio: 1531 Min: 1003 Max: 2020 Err: 0 (0,00 %)
etiqueta + 83 en 0:00:29 = 2,8/s Promedio: 1487 Min: 1023 Max: 2013 Err: 0 (0,00%) Activo: 5 Iniciado: 5 Finalizado: 0
etiqueta = 508 en 0:03:12 = 2,6/s Promedio: 1524 Min: 1003 Max: 2020 Err: 0 (0,00 %)
etiqueta + 78 en 0:00:30 = 2,6/s Promedio: 1594 Min: 1013 Max: 2016 Err: 0 (0,00%) Activo: 5 Iniciado: 5 Finalizado: 0
etiqueta = 586 en 0:03:43 = 2,6/s Promedio: 1533 Min: 1003 Max: 2020 Err: 0 (0,00 %)
etiqueta + 80 en 0:00:30 = 2,7/s Promedio: 1516 Min: 1013 Max: 2005 Err: 0 (0,00%) Activo: 5 Iniciado: 5 Finalizado: 0
etiqueta = 666 en 0:04:12 = 2,6/s Promedio: 1531 Min: 1003 Max: 2020 Err: 0 (0,00 %)
etiqueta + 86 en 0:00:30 = 2,9/s Promedio: 1449 Min: 1004 Max: 2017 Err: 0 (0,00%) Activo: 5 Iniciado: 5 Finalizado: 0
etiqueta = 752 en 0:04:43 = 2,7/s Promedio: 1522 Min: 1003 Max: 2020 Err: 0 (0,00 %)
etiqueta + 65 en 0:00:24 = 2,7/s Promedio: 1579 Min: 1007 Max: 2003 Err: 0 (0,00%) Activo: 0 Iniciado: 5 Finalizado: 5
etiqueta = 817 en 0:05:07 = 2,7/s Promedio: 1526 Min: 1003 Max: 2020 Err: 0 (0,00 %)

La etiqueta se utiliza para agrupar los resultados de las muestras. Entonces, si tiene varios grupos de subprocesos y desea resumirlos todos, use la misma etiqueta o agregue el resumen al plan de prueba (para que todos los grupos de subprocesos estén dentro del alcance). Se pueden implementar diferentes agrupaciones de resumen utilizando etiquetas adecuadas y agregando los resúmenes a las partes apropiadas del plan de prueba.

CSV Data Set Config se usa para leer líneas de un archivo y dividirlas en variables. Es más fácil de usar que las funciones __CSVRead() y __StringFromFile() . Es muy adecuado para manejar un gran número de variables y también es útil para probar con valores "aleatorios" y únicos.

La generación de valores aleatorios únicos en tiempo de ejecución es costosa en términos de CPU y memoria, por lo tanto, cree los datos antes de la prueba. Si es necesario, los datos "aleatorios" del archivo se pueden usar junto con un parámetro de tiempo de ejecución para crear diferentes conjuntos de valores de cada ejecución, por ejemplo, usando concatenación, que es mucho más económico que generar todo en tiempo de ejecución.

JMeter permite cotizar valores; esto permite que el valor contenga un delimitador. Si " permitir datos entrecomillados " está habilitado, un valor puede estar entre comillas dobles. Estos se eliminan. Para incluir comillas dobles dentro de un campo entre comillas, utilice dos comillas dobles. Por ejemplo:

1,"2,3","4""5" =>
1
2,3
4"5

JMeter admite archivos CSV que tienen una línea de encabezado que define los nombres de las columnas. Para habilitar esto, deje el campo " Nombres de variables " vacío. Se debe proporcionar el delimitador correcto.

JMeter admite archivos CSV con datos entrecomillados que incluyen líneas nuevas.

De forma predeterminada, el archivo solo se abre una vez y cada subproceso utilizará una línea diferente del archivo. Sin embargo, el orden en que se pasan las líneas a los subprocesos depende del orden en que se ejecutan, que puede variar entre iteraciones. Las líneas se leen al comienzo de cada iteración de prueba. El nombre de archivo y el modo se resuelven en la primera iteración.

Consulte la descripción del modo Compartir a continuación para obtener opciones adicionales. Si desea que cada subproceso tenga su propio conjunto de valores, deberá crear un conjunto de archivos, uno para cada subproceso. Por ejemplo test1.csv , test2.csv , ..., test n .csv . Use el nombre de archivo test${__threadNum}.csv y establezca el " Modo de compartir " en " Subproceso actual ".

Como caso especial, la cadena " \t " (sin comillas) en el campo delimitador se trata como una tabulación.

Cuando se alcanza el final del archivo ( EOF ), y la opción de reciclaje es verdadera , la lectura comienza nuevamente con la primera línea del archivo.

Si la opción de reciclaje es falsa y stopThread es falso , todas las variables se establecen en <EOF> cuando se alcanza el final del archivo. Este valor se puede cambiar configurando la propiedad JMeter csvdataset.eofstring .

Si la opción Reciclar es falsa y Detener subproceso es verdadero , al llegar a EOF se detendrá el subproceso.

El elemento DNS Cache Manager permite probar aplicaciones que tienen varios servidores detrás de balanceadores de carga (CDN, etc.), cuando el usuario recibe contenido de diferentes IP. De forma predeterminada, JMeter utiliza la caché de DNS de JVM. Es por eso que solo un servidor del clúster recibe carga. DNS Cache Manager resuelve los nombres de cada subproceso por separado en cada iteración y guarda los resultados de la resolución en su DNS Cache interno, que es independiente de las cachés DNS de JVM y OS.

Se puede usar una asignación para hosts estáticos para simular algo como el archivo /etc/hosts . Estas entradas tendrán preferencia sobre la resolución personalizada. El uso de resolución de DNS personalizado debe estar habilitado si desea utilizar esta asignación.

El Administrador de autorización le permite especificar uno o más inicios de sesión de usuario para páginas web que están restringidas mediante la autenticación del servidor. Ve este tipo de autenticación cuando usa su navegador para acceder a una página restringida, y su navegador muestra un cuadro de diálogo de inicio de sesión. JMeter transmite la información de inicio de sesión cuando encuentra este tipo de página.

Es posible que los encabezados de autorización no se muestren en la pestaña " Solicitud " del oyente de vista de árbol . La implementación de Java realiza una autenticación preventiva, pero no devuelve el encabezado de autorización cuando JMeter obtiene los encabezados. La implementación de HttpComponents (HC 4.5.X) por defecto es preventiva desde 3.2 y se mostrará el encabezado. Para deshabilitar esto, configure los valores como se muestra a continuación, en cuyo caso la autenticación solo se realizará en respuesta a un desafío.

En el archivo jmeter.properties establezca httpclient4.auth.preemptive=false

El Administrador de caché HTTP se utiliza para agregar la funcionalidad de almacenamiento en caché a las solicitudes HTTP dentro de su alcance para simular la función de caché del navegador. Cada subproceso de usuario virtual tiene su propio caché. De forma predeterminada, Cache Manager almacenará hasta 5000 elementos en caché por subproceso de usuario virtual, utilizando el algoritmo LRU. Utilice la propiedad " maxSize " para modificar este valor. Tenga en cuenta que cuanto más aumente este valor, más memoria consumirá HTTP Cache Manager, así que asegúrese de adaptar la opción -Xmx JVM en consecuencia.

Si una muestra tiene éxito (es decir, tiene el código de respuesta 2xx ), los valores de Última modificación y Etag (y Expirado , si corresponde) se guardan para la URL. Antes de ejecutar la siguiente muestra, el muestreador verifica si hay una entrada en el caché y, de ser así, se establecen los encabezados condicionales If-Last-Modified y If-None-Match para la solicitud.

Además, si se selecciona la opción " Usar encabezado Cache-Control/Expires ", el valor de Cache-Control / Expires se compara con la hora actual. Si la solicitud es una solicitud GET y la marca de tiempo es futura, la muestra regresa inmediatamente, sin solicitar la URL del servidor remoto. Esto está destinado a emular el comportamiento del navegador. Tenga en cuenta que si el encabezado Cache-Control es " no-cache ", la respuesta se almacenará en caché como precaducada, por lo que generará una solicitud GET condicional. Si Cache-Control tiene cualquier otro valor, el " max-age" La opción de caducidad se procesa para calcular la duración de la entrada; si falta, se usará el encabezado de caducidad; si también falta la entrada, se almacenará en caché como se especifica en RFC 2616, sección 13.2.4, usando la hora de última modificación y la fecha de respuesta.

El elemento Administrador de cookies tiene dos funciones:
primero, almacena y envía cookies como un navegador web. Si tiene una solicitud HTTP y la respuesta contiene una cookie, el Administrador de cookies almacena automáticamente esa cookie y la utilizará para todas las solicitudes futuras a ese sitio web en particular. Cada subproceso de JMeter tiene su propia "área de almacenamiento de cookies". Entonces, si está probando un sitio web que usa una cookie para almacenar información de sesión, cada subproceso de JMeter tendrá su propia sesión. Tenga en cuenta que dichas cookies no aparecen en la pantalla del Administrador de cookies, pero se pueden ver mediante el Escuchador del árbol de resultados de vista .

JMeter verifica que las cookies recibidas sean válidas para la URL. Esto significa que las cookies de dominio cruzado no se almacenan. Si tiene un comportamiento defectuoso o desea que se utilicen cookies de dominio cruzado, defina la propiedad de JMeter " CookieManager.check.cookies=false ".

Las cookies recibidas se pueden almacenar como variables de subprocesos de JMeter. Para guardar cookies como variables, defina la propiedad " CookieManager.save.cookies=true ". Además, los nombres de las cookies tienen el prefijo " COOKIE_ " antes de almacenarse (esto evita la corrupción accidental de las variables locales). Para volver al comportamiento original, defina la propiedad " CookieManager.name.prefix= " (uno o más espacios). Si está habilitado, el valor de una cookie con el nombre TEST se puede denominar ${COOKIE_TEST} .

En segundo lugar, puede agregar manualmente una cookie al Administrador de cookies. Sin embargo, si hace esto, la cookie será compartida por todos los subprocesos de JMeter.

Tenga en cuenta que dichas cookies se crean con un tiempo de caducidad lejano en el futuro

Las cookies con valores nulos se ignoran de forma predeterminada. Esto se puede cambiar configurando la propiedad JMeter: CookieManager.delete_null_cookies=false . Tenga en cuenta que esto también se aplica a las cookies definidas manualmente; dichas cookies se eliminarán de la pantalla cuando se actualice. Tenga en cuenta también que el nombre de la cookie debe ser único: si se define una segunda cookie con el mismo nombre, reemplazará a la primera.

Este elemento le permite establecer valores predeterminados que utilizan sus controladores de solicitud HTTP. Por ejemplo, si está creando un plan de prueba con 25 controladores de solicitud HTTP y todas las solicitudes se envían al mismo servidor, puede agregar un solo elemento de valores predeterminados de solicitud HTTP con el campo " Nombre del servidor o IP " completado. Luego , cuando agregue los 25 controladores de solicitud HTTP, deje el campo " Nombre del servidor o IP " vacío. Los controladores heredarán este valor de campo del elemento Valores predeterminados de solicitud HTTP.

El Administrador de encabezados le permite agregar o anular encabezados de solicitud HTTP.

JMeter ahora admite múltiples administradores de encabezado . Las entradas del encabezado se fusionan para formar la lista de la muestra. Si una entrada que se fusionará coincide con un nombre de encabezado existente, reemplaza la entrada anterior. Esto permite configurar un conjunto predeterminado de encabezados y aplicar ajustes a muestras particulares. Tenga en cuenta que un valor vacío para un encabezado no elimina un encabezado existente, simplemente reemplaza su valor.

El componente Java Request Defaults le permite establecer valores predeterminados para las pruebas de Java. Consulte la solicitud de Java .

El elemento de configuración del almacén de claves le permite configurar cómo se cargará el almacén de claves y qué claves utilizará. Este componente generalmente se usa en escenarios de HTTPS en los que no desea tener en cuenta la inicialización del almacén de claves en el tiempo de respuesta.

Para usar este elemento, primero debe configurar un Java Key Store con los certificados de cliente que desea probar, para hacer eso:

1. Cree sus certificados con la utilidad Java keytool o a través de su PKI
2. Si fue creado por PKI, importe sus claves en Java Key Store convirtiéndolas a un formato aceptable por JKS
3. Luego haga referencia al archivo de almacén de claves a través de las dos propiedades de JVM (o agréguelas en system.properties ):
   • -Djavax.net.ssl.keyStore=ruta_al_almacén de claves
   • -Djavax.net.ssl.keyStorePassword=contraseña_del_almacén de claves

Para usar PKCS11 como fuente de la tienda, debe establecer javax.net.ssl.keyStoreType en PKCS11 y javax.net.ssl.keyStore en NONE .

El elemento de configuración de inicio de sesión le permite agregar o anular la configuración de nombre de usuario y contraseña en los muestreadores que usan nombre de usuario y contraseña como parte de su configuración.

El componente Valores predeterminados de solicitud de LDAP le permite establecer valores predeterminados para las pruebas de LDAP. Consulte la Solicitud LDAP .

El componente Valores predeterminados de solicitud extendida de LDAP le permite establecer valores predeterminados para pruebas de LDAP extendidas. Consulte la solicitud ampliada de LDAP .

TCP Sampler Config proporciona datos predeterminados para TCP Sampler

El elemento Variables definidas por el usuario le permite definir un conjunto inicial de variables , al igual que en el Plan de prueba .

Los UDV no deben usarse con funciones que generan resultados diferentes cada vez que se llaman. Solo el resultado de la primera llamada de función se guardará en la variable. Sin embargo, los UDV se pueden usar con funciones como __P() , por ejemplo:

ANFITRIÓN ${__P(anfitrión, host local)}

que definiría la variable " HOST " para tener el valor de la propiedad JMeter " host ", por defecto a " localhost " si no está definido.

Para definir variables durante una ejecución de prueba, consulte Parámetros de usuario . Los UDV se procesan en el orden en que aparecen en el Plan, de arriba a abajo.

Para simplificar, se sugiere que los UDV se coloquen solo al comienzo de un grupo de subprocesos (o tal vez debajo del plan de prueba).

Una vez que se han procesado el plan de prueba y todos los UDV, el conjunto de variables resultante se copia en cada subproceso para proporcionar el conjunto de variables inicial.

Si un elemento de tiempo de ejecución, como un preprocesador de parámetros de usuario o un extractor de expresiones regulares, define una variable con el mismo nombre que una de las variables de UDV, esto reemplazará el valor inicial y todos los demás elementos de prueba en el subproceso verán el valor actualizado. valor.

El elemento de configuración de variable aleatoria se utiliza para generar cadenas numéricas aleatorias y almacenarlas en variable para su uso posterior. Es más simple que usar Variables definidas por el usuario junto con la función __Random() .

La variable de salida se construye usando el generador de números aleatorios y luego el número resultante se formatea usando la cadena de formato. El número se calcula usando la fórmula mínimo+Aleatorio.nextInt(máximo-mínimo+1) . Random.nextInt() requiere un entero positivo. Esto significa que máximo-mínimo , es decir, el rango, debe ser inferior a 2147483647 ; sin embargo, los valores mínimo y máximo pueden ser valores largos siempre que el rango sea correcto.

Permite al usuario crear un contador al que se puede hacer referencia en cualquier parte del grupo de subprocesos. La configuración del contador permite al usuario configurar un punto de partida, un máximo y el incremento. El contador realizará un ciclo desde el inicio hasta el máximo, y luego comenzará de nuevo con el inicio, continuando así hasta que finalice la prueba.

El contador usa un largo para almacenar el valor, por lo que el rango es de -2^63 a 2^63-1 .

El elemento de configuración simple le permite agregar o anular valores arbitrarios en muestras. Puede elegir el nombre del valor y el valor en sí. Aunque algunos usuarios aventureros pueden encontrar un uso para este elemento, está aquí principalmente para desarrolladores como una GUI básica que pueden usar mientras desarrollan nuevos componentes de JMeter.

Luego puede acceder al objeto com.mongodb.DB en Beanshell o JSR223 Test Elements a través del elemento MongoDBHolder usando este código

importar com.mongodb.DB;
importar org.apache.jmeter.protocol.mongodb.config.MongoDBHolder;
DB db = MongoDBHolder.getDBFromSource("valor de la propiedad MongoDB Source",
            "valor de la propiedad Nombre de la base de datos");
…
    

El panel de control de aserción de respuesta le permite agregar cadenas de patrones para compararlas con varios campos de la solicitud o respuesta. Las cadenas de patrón son:

• Contiene , coincide con: expresiones regulares de estilo Perl5
• Equals , Substring : texto sin formato, distingue entre mayúsculas y minúsculas

Puede encontrar un resumen de los caracteres de coincidencia de patrones en Expresiones regulares de ORO Perl5.

También puede elegir si se espera que las cadenas coincidan con la respuesta completa o si se espera que la respuesta solo contenga el patrón. Puede adjuntar múltiples aserciones a cualquier controlador para mayor flexibilidad.

Tenga en cuenta que la cadena de patrón no debe incluir los delimitadores adjuntos, es decir, use Price: \d+ no /Price: \d+/ .

De forma predeterminada, el patrón está en modo multilínea, lo que significa que el metacarácter " . " no coincide con la nueva línea. En el modo de varias líneas, " ^ " y " $ " coinciden con el inicio o el final de cualquier línea en cualquier parte de la cadena, no solo con el inicio y el final de toda la cadena. Tenga en cuenta que \s coincide con la nueva línea. El caso también es significativo. Para anular esta configuración, se puede usar la sintaxis de expresión regular extendida . Por ejemplo:

(?i)

ignorar caso

(?s)

tratar el destino como una sola línea, es decir, " . " coincide con la nueva línea

(?es)

tanto lo anterior

(?i)Pastel de manzana(?-i)

Coincide con " Apple Pie ", pero no con " Apple Pie " .

(?s)Manzana.+?Pastel

coincide con Apple seguido de Pie , que puede estar en una línea posterior.

Manzana(?s).+?Pastel

Lo mismo que arriba, pero probablemente sea más claro usar (?s) al principio.

La afirmación de duración prueba que cada respuesta se recibió dentro de un período de tiempo determinado. Cualquier respuesta que tarde más que el número dado de milisegundos (especificado por el usuario) se marca como una respuesta fallida.

La afirmación de tamaño prueba que cada respuesta contiene el número correcto de bytes. Puede especificar que el tamaño sea igual, mayor que, menor que o no igual a un número determinado de bytes.

La aserción XML prueba que los datos de respuesta consisten en un documento XML formalmente correcto. No valida el XML basado en un DTD o esquema ni realiza ninguna otra validación.

La aserción BeanShell permite al usuario realizar una verificación de aserciones utilizando un script BeanShell.

Para obtener detalles completos sobre el uso de BeanShell, consulte el sitio web de BeanShell.

Tenga en cuenta que se utiliza un intérprete diferente para cada aparición independiente de la aserción en cada subproceso en un script de prueba, pero se utiliza el mismo intérprete para invocaciones posteriores. Esto significa que las variables persisten en las llamadas a la aserción.

Todas las afirmaciones se llaman desde el mismo subproceso que la muestra.

Si se define la propiedad " beanshell.assertion.init ", se pasa al intérprete como el nombre de un archivo fuente. Esto se puede utilizar para definir métodos y variables comunes. Hay un archivo de inicio de muestra en el directorio bin : BeanShellAssertion.bshrc

El elemento de prueba admite los métodos ThreadListener y TestListener . Estos deben definirse en el archivo de inicialización. Consulte el archivo BeanShellListeners.bshrc para ver definiciones de ejemplo.

La afirmación MD5Hex permite al usuario verificar el hash MD5 de los datos de respuesta.

La aserción HTML permite al usuario verificar la sintaxis HTML de los datos de respuesta utilizando JTidy.

La aserción XPath prueba un documento para ver si está bien formado, tiene la opción de validar contra un DTD o pasar el documento a través de JTidy y probar un XPath. Si ese XPath existe, la afirmación es verdadera. El uso de " / " coincidirá con cualquier documento bien formado y es la expresión XPath predeterminada. La aserción también admite expresiones booleanas, como " count(//*error)=2 ". Consulte http://www.w3.org/TR/xpath para obtener más información sobre XPath.

• //title[text()='Text to match'] - coincide con <title>Text to match</title> en cualquier parte de la respuesta
• /title[text()='Text to match'] - coincide con <title>Text to match</title> en el nivel raíz de la respuesta

La aserción XPath2 comprueba la buena formación de un documento. El uso de " / " coincidirá con cualquier documento bien formado y es la expresión XPath2 predeterminada. La aserción también admite expresiones booleanas, como " count(//*error)=2 ".

• //title[text()='Text to match'] - coincide con <title>Text to match</title> en cualquier parte de la respuesta
• /title[text()='Text to match'] - coincide con <title>Text to match</title> en el nivel raíz de la respuesta

La aserción de esquema XML permite al usuario validar una respuesta contra un esquema XML.

La aserción JSR223 permite utilizar el código de secuencia de comandos JSR223 para comprobar el estado de la muestra anterior.

• bcmail-xxx.jar (Castillo hinchable SMIME/CMS)
• bcprov-xxx.jar (Proveedor de castillo hinchable)

Si usa Mail Reader Sampler , asegúrese de seleccionar " Almacenar el mensaje usando MIME (sin formato) ", de lo contrario, la afirmación no podrá procesar el mensaje correctamente.