3. Elementos de un plan de prueba

3.0 Plan de prueba ¶

El objeto Plan de prueba tiene una casilla de verificación llamada " Prueba funcional ". Si se selecciona, hará que JMeter registre los datos devueltos por el servidor para cada muestra. Si ha seleccionado un archivo en sus oyentes de prueba, estos datos se escribirán en el archivo. Esto puede ser útil si está haciendo una pequeña ejecución para asegurarse de que JMeter esté configurado correctamente y que su servidor arroje los resultados esperados. La consecuencia es que el archivo crecerá enormemente rápidamente y el rendimiento de JMeter se verá afectado. Esta opción debería estar desactivada si está realizando una prueba de estrés (está desactivada de forma predeterminada).

Si no está grabando los datos en un archivo, esta opción no hace ninguna diferencia.

También puede usar el botón Configuración en un oyente para decidir qué campos guardar.

3.1 Grupo de hilos ¶

Los elementos del grupo de subprocesos son los puntos iniciales de cualquier plan de prueba. Todos los controladores y muestreadores deben estar bajo un grupo de subprocesos. Otros elementos, por ejemplo, Listeners, pueden colocarse directamente bajo el plan de prueba, en cuyo caso se aplicarán a todos los grupos de subprocesos. Como su nombre lo indica, el elemento del grupo de subprocesos controla la cantidad de subprocesos que JMeter utilizará para ejecutar su prueba. Los controles para un grupo de subprocesos le permiten:

• Establecer el número de hilos
• Establecer el período de aceleración
• Establecer el número de veces para ejecutar la prueba

Cada subproceso ejecutará el plan de prueba en su totalidad y de forma completamente independiente de otros subprocesos de prueba. Se utilizan múltiples subprocesos para simular conexiones simultáneas a su aplicación de servidor.

El período de aumento le dice a JMeter cuánto tiempo debe tomar para "aumentar" el número total de subprocesos elegidos. Si se utilizan 10 subprocesos y el período de aceleración es de 100 segundos, entonces JMeter tardará 100 segundos en poner en funcionamiento los 10 subprocesos. Cada subproceso comenzará 10 (100/10) segundos después de que se inició el subproceso anterior. Si hay 30 subprocesos y un período de aceleración de 120 segundos, cada subproceso sucesivo se retrasará 4 segundos.

El aumento debe ser lo suficientemente largo para evitar una carga de trabajo demasiado grande al comienzo de una prueba, y lo suficientemente corto para que los últimos subprocesos comiencen a ejecutarse antes de que finalicen los primeros (a menos que uno quiera que eso suceda).

Comience con Ramp-up = número de subprocesos y ajuste hacia arriba o hacia abajo según sea necesario.

De forma predeterminada, el grupo de subprocesos está configurado para recorrer una vez sus elementos.

Thread Group también permite especificar la duración de Thread . Haga clic en la casilla de verificación en la parte inferior del panel Grupo de subprocesos para habilitar/deshabilitar campos adicionales en los que puede ingresar la duración de la prueba y el retraso de inicio. Puede configurar la Duración (segundos) y el Retraso de inicio (segundos) para controlar la duración de cada subproceso. grupo y después de cuántos segundos se inicia. Cuando se inicia la prueba, JMeter esperará el retraso de inicio (segundos) antes de iniciar los subprocesos del grupo de subprocesos y se ejecutará durante el tiempo de duración configurado (segundos) .

3.2 Controladores ¶

JMeter tiene dos tipos de Controladores: Samplers y Controladores Lógicos. Estos impulsan el procesamiento de una prueba.

Los muestreadores le dicen a JMeter que envíe solicitudes a un servidor. Por ejemplo, agregue una muestra de solicitud HTTP si desea que JMeter envíe una solicitud HTTP. También puede personalizar una solicitud agregando uno o más elementos de configuración a una muestra. Para obtener más información, consulte Muestras .

Los controladores lógicos le permiten personalizar la lógica que usa JMeter para decidir cuándo enviar solicitudes. Por ejemplo, puede agregar un controlador lógico intercalado para alternar entre dos muestras de solicitudes HTTP. Para obtener más información, consulte Controladores lógicos .

3.2.1 Muestreadores ¶

Los samplers le dicen a JMeter que envíe solicitudes a un servidor y espere una respuesta. Se procesan en el orden en que aparecen en el árbol. Los controladores se pueden utilizar para modificar el número de repeticiones de un muestreador.

Los muestreadores de JMeter incluyen:

• Solicitud FTP
• Solicitud HTTP (también se puede usar para el servicio web SOAP o REST)
• Solicitud JDBC
• Solicitud de objeto Java
• Solicitud JMS
• Solicitud de prueba JUnit
• Solicitud LDAP
• solicitud de correo
• Solicitud de proceso del sistema operativo
• Solicitud TCP

Si va a enviar varias solicitudes del mismo tipo (por ejemplo, solicitud HTTP) al mismo servidor, considere usar un elemento de configuración predeterminado. Cada controlador tiene uno o más elementos predeterminados (ver más abajo).

Recuerde agregar un Oyente a su plan de prueba para ver y/o almacenar los resultados de sus solicitudes en el disco.

Si está interesado en que JMeter realice una validación básica en la respuesta de su solicitud, agregue una afirmación a la muestra. Por ejemplo, en la prueba de estrés de una aplicación web, el servidor puede devolver un código de "Respuesta HTTP" correcto, pero la página puede tener errores o puede que le falten secciones. Puede agregar aserciones para verificar ciertas etiquetas HTML, cadenas de errores comunes, etc. JMeter le permite crear estas afirmaciones usando expresiones regulares.

Samplers integrados de JMeter

3.2.2 Controladores lógicos ¶

Los controladores lógicos le permiten personalizar la lógica que usa JMeter para decidir cuándo enviar solicitudes. Los controladores lógicos pueden cambiar el orden de las solicitudes que provienen de sus elementos secundarios. Pueden modificar las solicitudes por sí mismos, hacer que JMeter repita las solicitudes, etc.

Para comprender el efecto de los controladores lógicos en un plan de prueba, considere el siguiente árbol de prueba:

• Plan de prueba
• Grupo de hilos
• Controlador de una sola vez
• Solicitud de inicio de sesión (una solicitud HTTP )
• Cargar página de búsqueda (muestra HTTP)
• Controlador intercalado
• Buscar "A" (muestra HTTP)
• Búsqueda "B" (muestra HTTP)
• Solicitud predeterminada de HTTP (elemento de configuración)
• Solicitud predeterminada de HTTP (elemento de configuración)
• Administrador de cookies (elemento de configuración)

Lo primero de esta prueba es que la solicitud de inicio de sesión se ejecutará solo la primera vez. Las iteraciones posteriores lo omitirán. Esto se debe a los efectos de Once Only Controller .

Después del inicio de sesión, el siguiente Sampler carga la página de búsqueda (imagine una aplicación web donde el usuario inicia sesión y luego va a una página de búsqueda para realizar una búsqueda). Esta es solo una solicitud simple, no filtrada a través de ningún controlador lógico.

Después de cargar la página de búsqueda, queremos hacer una búsqueda. En realidad, queremos hacer dos búsquedas diferentes. Sin embargo, queremos volver a cargar la página de búsqueda entre cada búsqueda. Podríamos hacer esto al tener 4 elementos de solicitud HTTP simples (cargar búsqueda, buscar "A", cargar búsqueda, buscar "B"). En su lugar, usamos el controlador Interleave que transmite una solicitud de niño cada vez que se realiza la prueba. Mantiene el orden (es decir, no pasa uno al azar, sino que "recuerda" su lugar) de sus elementos secundarios. Intercalar 2 solicitudes de niños puede ser una exageración, pero fácilmente podría haber habido 8 o 20 solicitudes de niños.

Tenga en cuenta los valores predeterminados de solicitud HTTPque pertenece al Interleave Controller. Imagine que "Buscar A" y "Buscar B" comparten la misma información de RUTA (una especificación de solicitud HTTP incluye dominio, puerto, método, protocolo, ruta y argumentos, además de otros elementos opcionales). Esto tiene sentido: ambas son solicitudes de búsqueda, que llegan al mismo motor de búsqueda de back-end (un servlet o cgi-script, digamos). En lugar de configurar ambos HTTP Samplers con la misma información en su campo PATH, podemos abstraer esa información en un solo elemento de configuración. Cuando el Interleave Controller "transmite" las solicitudes de "Buscar A" o "Buscar B", llenará los espacios en blanco con valores del elemento de configuración de solicitud predeterminada de HTTP. Entonces, dejamos el campo PATH en blanco para esas solicitudes, y poner esa información en el elemento de configuración. En este caso, este es un beneficio menor en el mejor de los casos, pero demuestra la función.

El siguiente elemento en el árbol es otra solicitud predeterminada de HTTP, esta vez agregada al grupo de subprocesos. El grupo de subprocesos tiene un controlador lógico incorporado y, por lo tanto, utiliza este elemento de configuración exactamente como se describe anteriormente. Rellena los espacios en blanco de cualquier Solicitud que pase. Es extremadamente útil en las pruebas web dejar el campo DOMAIN en blanco en todos los elementos de HTTP Sampler y, en su lugar, colocar esa información en un elemento de solicitud predeterminado de HTTP, agregado al Thread Group. Al hacerlo, puede probar su aplicación en un servidor diferente simplemente cambiando un campo en su Plan de prueba. De lo contrario, tendría que editar todos y cada uno de los Sampler.

El último elemento es un administrador de cookies HTTP . Se debe agregar un administrador de cookies a todas las pruebas web; de lo contrario, JMeter ignorará las cookies. Al agregarlo en el nivel de grupo de subprocesos, nos aseguramos de que todas las solicitudes HTTP compartan las mismas cookies.

Los controladores lógicos se pueden combinar para lograr varios resultados. Consulte la lista de controladores lógicos integrados .

3.2.3 Fragmentos de prueba ¶

El elemento Test Fragment es un tipo especial de controlador que existe en el árbol del Plan de prueba al mismo nivel que el elemento Thread Group. Se distingue de un grupo de subprocesos en que no se ejecuta a menos que esté referenciado por un controlador de módulo o un controlador de inclusión .

Este elemento es puramente para la reutilización de código dentro de los planes de prueba.

3.3 Oyentes ¶

Los oyentes brindan acceso a la información que recopila JMeter sobre los casos de prueba mientras se ejecuta JMeter. El oyente Graph Results traza los tiempos de respuesta en un gráfico. El oyente "Ver árbol de resultados" muestra detalles de solicitudes y respuestas de muestras, y puede mostrar representaciones HTML y XML básicas de la respuesta. Otros oyentes proporcionan información de resumen o agregación.

Además, los oyentes pueden dirigir los datos a un archivo para su uso posterior. Cada oyente en JMeter proporciona un campo para indicar el archivo para almacenar datos. También hay un botón de Configuración que se puede usar para elegir qué campos guardar y si usar el formato CSV o XML.

Los oyentes se pueden agregar en cualquier parte de la prueba, incluso directamente bajo el plan de prueba. Recopilarán datos solo de elementos en o por debajo de su nivel.

Hay varios oyentes que vienen con JMeter.

3.4 Temporizadores ¶

De forma predeterminada, un subproceso JMeter ejecuta muestras en secuencia sin pausas. Le recomendamos que especifique un retraso agregando uno de los temporizadores disponibles a su grupo de subprocesos. Si no agrega un retraso, JMeter podría sobrecargar su servidor al realizar demasiadas solicitudes en muy poco tiempo.

Un temporizador hará que JMeter retrase una cierta cantidad de tiempo antes de cada muestra que esté en su alcance .

Si elige agregar más de un temporizador a un grupo de subprocesos, JMeter toma la suma de los temporizadores y se detiene durante esa cantidad de tiempo antes de ejecutar las muestras a las que se aplican los temporizadores. Los temporizadores se pueden agregar como hijos de muestreadores o controladores para restringir los muestreadores a los que se aplican.

Para proporcionar una pausa en un solo lugar en un plan de prueba, se puede usar el Muestreador de acciones de control de flujo .

3.5 Afirmaciones ¶

Las aserciones le permiten afirmar hechos sobre las respuestas recibidas del servidor que se está probando. Usando una aserción, esencialmente puede "probar" que su aplicación está devolviendo los resultados que espera.

Por ejemplo, puede afirmar que la respuesta a una consulta contendrá algún texto en particular. El texto que especifique puede ser una expresión regular de estilo Perl y puede indicar que la respuesta debe contener el texto o que debe coincidir con la respuesta completa.

Puede agregar una aserción a cualquier Sampler. Por ejemplo, puede agregar una aserción a una solicitud HTTP que verifique el texto, " </HTML> ". JMeter luego verificará que el texto esté presente en la respuesta HTTP. Si JMeter no puede encontrar el texto, lo marcará como una solicitud fallida.

Para ver los resultados de la aserción, agregue un oyente de aserción al grupo de subprocesos. Las aserciones fallidas también aparecerán en la vista de árbol y en los oyentes de tabla, y contarán para el porcentaje de error, por ejemplo, en los informes agregados y resumidos.

3.6 Elementos de configuración ¶

Un elemento de configuración trabaja en estrecha colaboración con un Sampler. Aunque no envía solicitudes (excepto HTTP(S) Test Script Recorder ), puede agregar o modificar solicitudes.

Se puede acceder a un elemento de configuración solo desde dentro de la rama del árbol donde coloca el elemento. Por ejemplo, si coloca un administrador de cookies HTTP dentro de un controlador lógico simple, el administrador de cookies solo será accesible para los controladores de solicitud HTTP que coloque dentro del controlador lógico simple (consulte la figura 1). El Administrador de cookies es accesible para las solicitudes HTTP "Página web 1" y "Página web 2", pero no para "Página web 3".

Además, un elemento de configuración dentro de una rama de árbol tiene mayor prioridad que el mismo elemento en una rama "principal". Por ejemplo, definimos dos elementos predeterminados de solicitud HTTP, "Valores predeterminados web 1" y "Valores predeterminados web 2". Dado que colocamos "Web Defaults 1" dentro de un Loop Controller, solo "Web Page 2" puede acceder a él. Las otras solicitudes HTTP usarán "Web Defaults 2", ya que lo colocamos en el Grupo de subprocesos (el "principal" de todas las demás ramas).

3.7 Elementos del preprocesador ¶

Un preprocesador ejecuta alguna acción antes de que se realice una solicitud de muestra. Si se adjunta un preprocesador a un elemento de muestra, se ejecutará justo antes de que se ejecute ese elemento de muestra. Un preprocesador se usa con mayor frecuencia para modificar la configuración de una solicitud de muestra justo antes de que se ejecute, o para actualizar variables que no se extraen del texto de respuesta. Consulte las reglas de alcance para obtener más detalles sobre cuándo se ejecutan los preprocesadores.

3.8 Elementos de posprocesador ¶

Un posprocesador ejecuta alguna acción después de que se haya realizado una solicitud de muestra. Si se adjunta un posprocesador a un elemento de muestra, se ejecutará justo después de que se ejecute ese elemento de muestra. Un posprocesador se usa con mayor frecuencia para procesar los datos de respuesta, a menudo para extraer valores de ellos. Consulte las reglas de alcance para obtener más detalles sobre cuándo se ejecutan los posprocesadores.

3.9 Orden de ejecución ¶

0. Elementos de configuración
1. Preprocesadores
2. Temporizadores
3. Dechado
4. Post-procesadores (a menos que SampleResult sea nulo )
5. Aserciones (a menos que SampleResult sea nulo )
6. Oyentes (a menos que SampleResult sea nulo )

Por ejemplo, en el siguiente plan de prueba:

• Controlador
• Postprocesador 1
• Muestreador 1
• Muestreador 2
• Temporizador 1
• Afirmación 1
• Preprocesador 1
• Temporizador 2
• Postprocesador 2

Preprocesador 1
Temporizador 1
Temporizador 2
Muestreador 1
Postprocesador 1
Postprocesador 2
Afirmación 1

Preprocesador 1
Temporizador 1
Temporizador 2
Muestreador 2
Postprocesador 1
Postprocesador 2
Afirmación 1

3.10 Reglas de Alcance ¶

El árbol de prueba de JMeter contiene elementos que son tanto jerárquicos como ordenados. Algunos elementos en los árboles de prueba son estrictamente jerárquicos (Oyentes, Elementos de configuración, Post-procesadores, Pre-procesadores, Aserciones, Temporizadores), y algunos están principalmente ordenados (controladores, muestreadores). Cuando cree su plan de prueba, creará una lista ordenada de solicitudes de muestras (a través de Samplers) que representan un conjunto de pasos a ejecutar. Estas solicitudes a menudo se organizan dentro de los controladores que también se ordenan. Dado el siguiente árbol de pruebas:

El orden de las solicitudes será Uno, Dos, Tres, Cuatro.

Algunos controladores afectan el orden de sus subelementos, y puede leer sobre estos controladores específicos en la referencia del componente .

Otros elementos son jerárquicos. Una afirmación, por ejemplo, es jerárquica en el árbol de prueba. Si su padre es una solicitud, entonces se aplica a esa solicitud. Si su padre es un controlador, entonces afecta a todas las solicitudes que son descendientes de ese controlador. En el siguiente árbol de prueba:

La afirmación n.° 1 se aplica solo a la solicitud uno, mientras que la afirmación n.° 2 se aplica a las solicitudes dos y tres.

Otro ejemplo, esta vez usando Timers:

En este ejemplo, las solicitudes se nombran para reflejar el orden en que se ejecutarán. El temporizador n.º 1 se aplicará a las solicitudes dos, tres y cuatro (observe cómo el orden es irrelevante para los elementos jerárquicos). La Afirmación #1 se aplicará solo a la Solicitud Tres. El temporizador #2 afectará a todas las solicitudes.

Esperemos que estos ejemplos aclaren cómo se aplican los elementos de configuración (jerárquicos). Si imagina que cada Solicitud se pasa por las ramas del árbol, a su padre, luego al padre de su padre, etc., y cada vez que recopila todos los elementos de configuración de ese padre, entonces verá cómo funciona.

3.11 Propiedades y Variables ¶

Las propiedades de JMeter se definen en jmeter.properties (consulte Primeros pasos: configuración de JMeter para obtener más detalles).
Las propiedades son globales para jmeter y se utilizan principalmente para definir algunos de los usos predeterminados de JMeter. Por ejemplo, la propiedad remote_hosts define los servidores que JMeter intentará ejecutar de forma remota. Se puede hacer referencia a las propiedades en los planes de prueba; consulte Funciones, lea una propiedad , pero no se pueden usar para valores específicos de subprocesos.

Las variables de JMeter son locales para cada subproceso. Los valores pueden ser los mismos para cada subproceso o pueden ser diferentes.
Si un subproceso actualiza una variable, solo se cambia la copia del subproceso de la variable. Por ejemplo, el posprocesador del extractor de expresiones regulares establecerá sus variables de acuerdo con la muestra que haya leído su subproceso, y estas pueden ser utilizadas más tarde por el mismo subproceso. Para obtener detalles sobre cómo hacer referencia a variables y funciones, consulte Funciones y variables

Tenga en cuenta que los valores definidos por el Plan de prueba y el elemento de configuración Variables definidas por el usuario están disponibles para todo el plan de prueba al inicio. Si la misma variable está definida por varios elementos UDV, el último entra en vigor. Una vez que se ha iniciado un subproceso, el conjunto inicial de variables se copia en cada subproceso. Se pueden utilizar otros elementos, como el preprocesador de parámetros de usuario o el posprocesador del extractor de expresiones regulares , para redefinir las mismas variables (o crear otras nuevas). Estas redefiniciones solo se aplican al hilo actual.

La función setProperty se puede utilizar para definir una propiedad JMeter. Estos son globales para el plan de prueba, por lo que se pueden usar para pasar información entre subprocesos, en caso de que sea necesario.

3.12 Uso de variables para parametrizar pruebas ¶

Las variables no tienen que variar: se pueden definir una vez y, si no se modifican, no cambiarán de valor. Por lo tanto, puede usarlos como abreviatura de expresiones que aparecen con frecuencia en un plan de prueba. O para artículos que son constantes durante una ejecución, pero que pueden variar entre ejecuciones. Por ejemplo, el nombre de un host o la cantidad de subprocesos en un grupo de subprocesos.

Al decidir cómo estructurar un plan de prueba, tome nota de qué elementos son constantes para la ejecución, pero cuáles pueden cambiar entre ejecuciones. Decida algunos nombres de variables para estos; tal vez use una convención de nomenclatura como prefijarlos con C_ o K_ o usar mayúsculas solo para distinguirlos de las variables que deben cambiar durante la prueba. Considere también qué elementos deben ser locales para un subproceso, por ejemplo, contadores o valores extraídos con el posprocesador de expresiones regulares. Es posible que desee utilizar una convención de nomenclatura diferente para estos.

Por ejemplo, puede definir lo siguiente en el plan de prueba:

HOST www.ejemplo.com
HILOS 10
BUCLES 20

HOST ${__P(host,www.ejemplo.com)}
HILOS ${__P(hilos,10)}
BUCLES ${__P(bucles,20)}

jmeter … -Jhost=www3.ejemplo.org -Jloops=13