modelado de pruebas de carga con apache jmeter · 2017-05-10 · de comandos o con la propia...

28
Modelado de pruebas de carga con Apache JMeter Referencia: ESPEC_PruebasCargaJMeter.doc Autor: Aragonesa de Servicios Telemáticos Fecha de creación: 07/03/2014 Última actualización: 07/01/2015 Versión: v1.4 Clasificación: Uso Público Especificaciones técnicas

Upload: others

Post on 17-Apr-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Modelado de pruebas de carga con Apache JMeter

Referencia: ESPEC_PruebasCargaJMeter.doc

Autor: Aragonesa de Servicios Telemáticos

Fecha de creación: 07/03/2014

Última actualización: 07/01/2015

Versión: v1.4

Clasificación: Uso Público

Especificaciones técnicas

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 3 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Contenido

1. INTRODUCCIÓN................................................................................................................................. 4

2. VERSIONES DE PRODUCTOS ......................................................................................................... 5

3. NOMENCLATURA DE LOS PLANES DE PRUEBA ............ ............................................................. 6

4. EJECUCIÓN DE LAS PRUEBAS........................ ............................................................................... 7

4.1. PARÁMETROS ............................................................................................................................. 7

4.1.1. Grupo de Hilos .......................................................................................................................... 7 4.1.2. CSV Data Set............................................................................................................................ 8

5. COMPONENTES .............................................................................................................................. 10

5.1. ÁMBITO Y ORDEN DE EJECUCIÓN ......................................................................................... 10 5.2. RECEPTORES (LISTENERS) .................................................................................................... 13

6. MODELADO DE PRUEBAS............................. ................................................................................ 14

6.1. NORMAS GENERALES ............................................................................................................. 14 6.2. USO DE PLANTILLAS DE TRABAJO ........................................................................................ 14

6.2.1. Aplicaciones Web.................................................................................................................... 14

6.2.1.1. Grupo de Hilos .................................................................................................................... 15 6.2.1.2. Valores por defecto para petición HTTP............................................................................. 16

6.2.2. Aplicaciones Web Avanzadas................................................................................................. 17

6.2.2.1. Variables definidas por el usuario....................................................................................... 18 6.2.2.2. Gestor de Cookies HTTP.................................................................................................... 19 6.2.2.3. Gestor de cabecera HTTP.................................................................................................. 19 6.2.2.4. Configuración del CSV Data Set ........................................................................................ 20 6.2.2.5. Grupo de Hilos .................................................................................................................... 20

a) Valores por defecto para petición HTTP ........................................................................ 21 b) Aserción de respuesta .................................................................................................... 21 c) Petición HTTP................................................................................................................. 22

Temporizador Aleatorio Gaussiano .................................................................................... 23 Aserción de respuesta ........................................................................................................ 23 Extractor de expresiones regulares .................................................................................... 24

6.2.3. Servicios Web ......................................................................................................................... 24

6.2.3.1. Variables definidas por el usuario....................................................................................... 25 6.2.3.2. Valores por defecto para petición HTTP............................................................................. 26 6.2.3.3. Grupo de Hilos .................................................................................................................... 26

a) Petición HTTP................................................................................................................. 27

Gestor de cabecera HTTP.................................................................................................. 28 Aserción de respuesta ........................................................................................................ 29

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 4 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

1. Introducción

La herramienta elegida en Aragonesa de Servicios Telemáticos para definir y ejecutar pruebas de carga es Apache JMeter. Se trata de una herramienta de testing cuyas funcionalidades se pueden resumir en tres:

� Diseñar un plan de pruebas, esto es, generar un fichero .jmx

� Ejecutar un plan de pruebas

� Ver de distintas formas los resultados de la ejecución de un plan de pruebas (a través de listeners)

Para diseñar un plan de pruebas, JMeter dispone de una interfaz GUI a modo de diseñador, en la que se pueden agregar componentes de manera visual, y ejecutar los componentes agregados, viendo el resultado. Una vez finalizado el diseño del plan de pruebas, la herramienta permite grabarlo como un fichero .jmx.

La propia herramienta permite ejecutar un fichero .jmx previamente generado, a través de línea de comandos o con la propia interfaz GUI. La ejecución de un fichero .jmx realiza peticiones contra la aplicación objetivo a testear; estas peticiones son del tipo que se hayan especificado al generar el fichero .jmx. JMeter permite generar diversos tipos de peticiones: HTTP, FTP, LDAP, ...). Para cada petición ejecutada, JMeter recopila ciertos datos. Además, en el fichero .jmx se puede especificar qué número de usuarios de cada tipo ejecuta las peticiones contra la aplicación, es decir, el .jmx simula una o mas comunidades de usuarios (roles) trabajando contra la aplicación objetivo.

Los datos generados por la herramienta para cada petición se procesan o bien con un tipo de componente que proporciona la interfaz GUI llamados listeners, o bien con herramientas externas. Los listeners permiten ver los resultados de una o más ejecuciones de múltiples maneras (cada listener los muestra de una manera).

Este manual explica los conceptos necesarios para entregar planes de pruebas (ficheros .jmx) configurables y mantenibles con JMeter de acuerdo a las especificaciones técnicas establecidas por AST. En particular, se explica el concepto de componente y tipo de componente de un plan de pruebas, el orden en que éstos se asocian a los samplers, el ámbito de los diferentes tipos de componentes y cómo construir planes de pruebas configurables y mantenibles mediante el uso de variables.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 5 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

2. Versiones de productos

Los planes de pruebas se diseñarán y ejecutarán con las siguientes versiones de productos:

� Apache JMeter 2.11

� JRE 1.7.0_51

Estos productos podrán actualizarse conforme se publiquen nuevas versiones, de modo que se recomienda siempre consultar las versiones exactas antes de comenzar a preparar un plan de pruebas.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 6 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

3. Nomenclatura de los planes de prueba

El nombre del fichero .jmx que se envía debe comenzar por el código de aplicación al que se refieren las pruebas de carga. Por ejemplo, para la aplicación cuyo código identificador es GPZ, un nombre válido de plan de pruebas es:

� PWT_PruebasCarga.jmx

Si son necesarios varios ficheros .jmx, cada uno de ellos deberá tener un nombre representativo de la parte del sistema que se ve implicada en las pruebas, por ejemplo, para definir planes de prueba distintos sobre la parte pública y privada de la aplicación:

� PWT_Publico.jmx

� PWT_Privado.jmx

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 7 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

4. Ejecución de las pruebas

Hay dos formas de ejecutar JMeter, según se quiera mostrar o no la interfaz GUI:

� Desde línea de comando SIN mostrar la interfaz GUI (especificar la opción -n en la línea de comando).

� Mostrando la interfaz GUI: no especificar la opción -n al arrancar JMeter.

La ejecución de los planes de prueba se realizará siempre en modo no gráfico con los siguientes parámetros:

jmeter -n -t <PlanPrueba>.jmx -l <Resultado>.jtl –j <Resultado>.log

donde:

� <PlanPrueba>.jmx: prueba de carga a realizar

� <Resultado>.jtl: fichero de resultados

� <Resultado>.log: log generado en la ejecución de la prueba de carga

Al ejecutar las pruebas con el parámetro –l se pueden eliminar TODOS los receptores del plan de pruebas.

4.1. Parámetros

4.1.1. Grupo de Hilos

Todos los planes de carga vendrán parametrizados con las siguientes variables a nivel de grupo de hilos:

� Número de hilos: ${__P(nHilos,10)}

� Periodo de subida (en segundos): ${__P(pSubida,1)}

� Contador del bucle: ${__P(nIteraciones,10)}

Esto define el parámetro con un valor por defecto.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 8 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Configuración Grupo de Hilos

Se debe tener claro el significado de la propiedad “Periodo de subida”. Con esta propiedad se indica a JMeter cuánto debe esperarse para lanzar cada hilo, es decir si por ejemplo tenemos programada una ejecución de 5 hilos e indicamos un periodo de subida de 5 segundos, esto quiere decir que transcurridos los 5 segundos, Jmeter habrá lanzado todos los hilos, es decir que el tiempo de espera entre hilos será de 1 segundo.

4.1.2. CSV Data Set

Siempre que sea necesario (usuarios y contraseñas, parámetros de búsqueda, etc.) se proporcionará un juego de datos en formato CSV, lo que permite utlizar diferentes valores en las pruebas de carga, por ejemplo, no hacer siempre login con el mismo usuario o búsquedas con los mismos parámetros. Generar estos valores en tiempo de ejecución es muy costoso tanto en CPU como en memoria, por lo que deberán generarse previamente y entregarse en formato CSV.

Para el tratamiento de estos ficheros se utilizará el elemento de configuración ‘CSV Data Set’. Cada uno de estos ficheros de entrada tendrá que estar parametrizado con su correspondiente variable ${__P(entrada)}:

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 9 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Configuración CSV Data Set

Utilizaremos tantos elementos de configuración ‘CSV Data Set’ como entradas de datos diferentes vayamos a tener: usuarios, búsqueda 1, búsqueda 2, etc.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 10 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

5. Componentes

Un plan de pruebas (fichero .jmx) es una jerarquía de componentes en forma de árbol. Puede verse abriendo un fichero .jmx en la interfaz GUI, en el frame de la izquierda.

Cada nodo del árbol es un componente. A su vez, un componente es una instancia de un tipo de componente en la que se pueden haber configurado algunas de sus propiedades (en el panel de control de la derecha).

En la tabla siguiente se explica para qué sirve cada uno de los tipos de componentes que existen en JMeter:

Tipo de componente Uso

Plan de pruebas Es el tipo de componente que representa la raíz del árbol. En todo plan de pruebas existe uno y sólo un componente de este tipo

Thread Group Representa un grupo de usuarios. En JMeter cada thread es un usuario virtual. Este tipo de componente permite representar grupos de usuarios. Cada grupo de usuarios del plan de pruebas representa un rol o perfil. Todos los threads de un mismo thread group (i.e. todos los usuarios de un grupo) realizan la misma secuencia de acciones, representada por los samplers que agrupa el thread group.

Controllers: Sampler, Logic Controler

Son los únicos componentes del plan de pruebas que hacen algo: los samplers realizan peticiones contra la aplicación, y los logic controlers establecen el orden en que se ejecutan los samplers que agrupan. El resto de componentes (Config Element, Assertion, ...) "matizan" la forma en que se ejecutan los samplers, pero no varían sustancialmente su comportamiento

Config Element Establecen propiedades de configuración que se aplican a los samplers a los que afectan

Assertion Comprueban condiciones que aplican a las peticiones que los samplers a los que afectan realizan contra la aplicación

Listener Recopilan datos de las peticiones que realizan los samplers a los que afectan

Timer Añaden tiempo extra a la ejecución de las peticiones que realizan contra la aplicación los samplers a los que afectan

Pre-Processor element

Realizan acciones o establecen configuraciones previa a la ejecución de los samplers a los que afectan

Post-Processor element

Realizan acciones o establecen configuraciones posteriormente a la ejecución de los samplers a los que afectan

5.1. Ámbito y orden de ejecución

Cada componente, según su tipo, es un elemento de Orden (O = Ordered) o Jerárquico (H = Hierarchy).

Los tipos de componentes son (entre paréntesis se indica si es un elemento de orden o jerárquico):

� Plan de pruebas

� Thread Group

� Controllers: Sampler, Logic Controler (O)

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 11 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

� Config Element (H)

� Assertion (H)

� Listener (H)

� Timer (H)

� Pre-Processor element (H)

� Post-Processor element (H)

El ámbito establece a qué elementos de tipo O (samplers y logic controlers) afecta un elemento de tipo H.

El orden de ejecución establece en qué orden se ejecutan los elementos de un test plan según su tipo y ciertas reglas de asociación entre ellos.

Reglas de ámbito y orden de ejecución:

� Los componentes de tipo Sampler y Logic Controler son de tipo Orden (O), por lo que se ejecutan en la secuencia en que aparecen en el plan de pruebas (de arriba a abajo).

� Algunos componentes Logic Controler pueden cambiar el orden en que se ejecutan sus componentes anidados.

� El resto de elementos son de tipo Jerarquico (H), lo que significa que aplican sólo a los componentes Samplers descendientes (todos ellos: hermanos, hijos, nietos, etc.) de su padre.

� Cuando varios componentes Jerárquicos (H) aplican a un sampler, hay un orden de ejecución que establece en qué orden se le aplican:

Configuration elements

Pre-Processors

Timers

Sampler

Post-Processors

Assertions

Listeners

� Si a un Sampler le aplican dos elementos con el mismo orden (según la regla anterior, por ejemplo dos Listeners), se le aplican en el orden en que aparecen en el plan de pruebas: de arriba a abajo.

� Los elementos jerárquicos que se asocian a los samplers sólo se ejecutan si se ejecuta el sampler. Si por ejemplo el sampler está en un logic controler que hace que no se ejecute, no se ejecutan los elementos asociados.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 12 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Veamos un ejemplo para ilustrar estos conceptos:

Ejemplo de plan de pruebas

Este ejemplo es un plan de pruebas con un sólo Thread Group. Hay cinco samplers (de nombres One, Two, Three, Four y Five). Hay dos logic controlers, de tipo Simple Controler, con este mismo nombre. Los controlers de este tipo sólo agrupan, no alteran el orden de ejecución, por lo que el orden en que se ejecutan los samplers es de arriba a abajo: One, Two, Three, Four y Five.

Hay tres elementos jerárquicos: Timer #1, Assertion #1 y Timer #2. Además, por el tipo de estos elementos, se ejecutan después de los samplers a los que afectan.

El elemento Timer #2 cuelga directamente del Thread Group, por lo que afecta a todos los samplers que cuelgan (directa o indirectamente) de este elemento, es decir, a todos los samplers.

El elemento Timer #1 cuelga del controller Simple Controller, por lo que afecta a todos los samplers que cuelgan de este mismo controllers directa o indirectamente, esto es, a Two, Three y Four.

El elemento Assertion #1 cuelga del sampler Three, por lo que sólo afecta a este.

Con lo anterior, el orden en que se ejecuta el plan de pruebas es (recordemos que si dos componentes jerárquicos del mismo tipo afectan a un mismo sampler, se aplican en el orden en que aparecen en el plan de pruebas de arriba a bajo):

One Timer#2

Two Timer#1 Timer#2

Three

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 13 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Assertion#1 Timer#1 Timer#2

Four Timer#1 Timer#2

Five Timer#2

5.2. Receptores (Listeners)

Dedicamos especial atención a la utilización de receptores (listeners). Son necesarios en el modelado de las pruebas de carga, para ir viendo los resultados obtenidos y poder validar y depurar los posibles errores. Sin embargo, la mayoría de ellos consume muchos recursos tanto de memoria como de CPU en tiempo de ejecución, por lo que nunca deberán entregarse habilitados en el plan de pruebas a ejecutar.

La relación de receptores que no deben entregarse es la siguiente:

� Gráfico de resultados

� Visualizador Spline

� Resultados de la aserción

� Ver Árbol de Resultados

� Gráfico de distribución (alfa)

Se recomienda utilizar el menor número de receptores posibles. Al realizarse la ejecución de las pruebas con el parámetro –l, no serían necesarios, por lo que los receptores entregados se eliminarán o deshabilitarán.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 14 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

6. Modelado de pruebas

6.1. Normas generales

� Los planes de prueba (ficheros .jmx) deben ser configurables lo máximo posible, al menos deben contener los parámetros indicados anteriormente. De esta forma, los planes no son específicos de los entornos en los que se despliegan las aplicaciones que testean.

� No usar listeners innecesarios en el plan de pruebas. El tiempo extra que los listeners emplean en procesar cada petición a la que afecta el listener, se contabiliza como parte del tiempo de ejecución de la petición. Esto influye negativamente en scripts .jmx que testean el rendimiento. En particular, a la hora de entregar los planes no debe haber ningún listener activado.

� Se debe documentar la secuencia de interacciones que realiza un plan de pruebas en un documento externo. De otra forma es muy difícil que el script sea modificable por alguien distinto a quien lo ha generado. Esto cobra más importancia cuanto más complejas sean las interacciones que el script realiza con la aplicación.

� Los ficheros .jmx no contendrán grupos de hilos funcionalmente independientes, es decir, que deban lanzarse de manera separada o con distinta parametrización; para ello se entregarán ficheros .jmx distintos. Por ejemplo, las pruebas de carga sobre un portal que contiene parte pública y parte privada deberán entregarse en ficheros independientes, uno para la parte pública y otro para la privada.

Para la ejecución de pruebas de carga en AST no se habilitarán o deshabilitarán elementos, ni modificarán valores almacenados dentro de ficheros .jmx. Todo lo que deba tener distinto valor para las pruebas deberá estar parametrizado en el plan

6.2. Uso de plantillas de trabajo

Se recomienda utilizar las siguientes plantillas de trabajo en función de los escenarios para los que se deseen generar los planes de pruebas.

6.2.1. Aplicaciones Web

Se compone de los siguientes elementos:

� Grupo de hilos

Valores por defecto para petición HTTP

Peticiones HTTP (recogidas durante la grabación)

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 15 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Plan de pruebas para aplicaciones Web sencillas

6.2.1.1. Grupo de Hilos

En el grupo de hilos debemos parametrizar:

� Número de hilos: ${__P(nHilos,10)}

� Periodo de subida (en segundos): ${__P(pSubida,1)}

� Contador del bucle: ${__P(nIteraciones,10)}

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 16 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Parametrización grupo de hilos

6.2.1.2. Valores por defecto para petición HTTP

En los valores por defecto para petición HTTP debemos parametrizar:

� Nombre del servidor o IP: ${__P(nServidor)}

� Puerto: ${__P(nPuerto)}

� Protocolo: ${__P(protocolo)}

Parametrización valores por defecto para petición HTTP

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 17 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

6.2.2. Aplicaciones Web Avanzadas

Se compone de los siguientes elementos:

� Variables definidas por el usuario

� Gestor de cookies HTTP

� Gestor de cabecera HTTP

� Configuración del CSV Data Set

� Grupo de Hilos

Valores por defecto para petición HTTP

Aserción de respuesta

Petición HTTP

a) Temporizador Aleatorio Gaussiano

b) Aserción de respuesta

c) Extractor de expresiones regulares

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 18 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Plantilla aplicaciones Web Avanzadas

6.2.2.1. Variables definidas por el usuario

En este apartado definiremos todas las variables necesarias para la ejecución de nuestro plan de pruebas: expediente_finalizado, expediente_solo_lectura, etc.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 19 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Variables definidas por el usuario

6.2.2.2. Gestor de Cookies HTTP

El gestor de cookies tiene dos funcionalidades:

� Almacenar y enviar cookies como si se tratase de un navegador. Si estamos utilizando peticiones HTTP y la respuesta contiene una cookie, el gestor la almacena de forma automática y la utiliza en peticiones futuras. Cada thread cuenta con su propia zona de cookies, por lo que cada uno de ellos tendrá su sesión propia.

� Añadir cookies de forma manual. Las cookies añadidas de esta forma se comparten entre todos los threads.

Gestor de cookies HTTP

6.2.2.3. Gestor de cabecera HTTP

Este componente permite sobrescribir las cabeceras de las peticiones HTTP. Un ejemplo muy típico del uso de este componente es sobrescribir el ‘User-Agent’ por defecto para utilizar la versión de navegador que interese.

Gestor de cabecera HTTP

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 20 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

6.2.2.4. Configuración del CSV Data Set

Siempre que sea necesario (usuarios y contraseñas, parámetros de búsqueda, etc.) se proporcionará un juego de datos en formato CSV, lo que permite utlizar diferentes valores en las pruebas de carga, por ejemplo, no hacer siempre login con el mismo usuario o búsquedas con los mismos parámetros. Generar estos valores en tiempo de ejecución es muy costoso tanto en CPU como en memoria, por lo que deberán generarse previamente y entregarse en formato CSV.

Para el tratamiento de estos ficheros utilizaremos el elemento de configuración ‘CSV Data Set’. Cada uno de estos ficheros de entrada tendrá que estar parametrizado con su correspondiente variable ${__P(entrada)}:

Configuración CSV Data Set

6.2.2.5. Grupo de Hilos

En el grupo de hilos debemos parametrizar:

� Número de hilos: ${__P(nHilos,10)}

� Periodo de subida (en segundos): ${__P(pSubida,1)}

� Contador del bucle: ${__P(nIteraciones,10)}

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 21 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Parametrización Grupo de Hilos

a) Valores por defecto para petición HTTP

Con este elemento se definen los valores por defecto para todas nuestras peticiones HTTP. Por ejemplo, si se define un plan de pruebas que tiene 25 peticiones HTTP y todas se realizan contra el mismo servidor, lo lógico sería añadir el elemento de configuración “Valores por defecto para petición HTTP”, configurar el servidor en dicho componente y dejarlo en blanco en las peticiones HTTP, ya que heredarán dicho valor.

En los valores por defecto para petición HTTP debemos parametrizar:

� Nombre del servidor o IP: ${__P(nServidor)}

� Puerto: ${__P(nPuerto)}

� Protocolo: ${__P(protocolo)}

Valores por defecto para petición HTTP

b) Aserción de respuesta

Las aserciones de respuesta a este nivel permiten verificar el contenido de las respuestas para todas las muestras ‘hijo’ del Grupo de Hilos.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 22 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Aserción de Respuesta

c) Petición HTTP

Contendrá las muestras recogidas durante la grabación de la prueba.

Petición HTTP

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 23 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Temporizador Aleatorio Gaussiano

El temporizador pausa la petición de cada thread un tiempo aleatorio. El tiempo total de delay que se aplica resulta de la suma de la desviación indicada (milisegundos) más el desplazamiento (milisegundos).

Será necesario parametrizar desviación y desplazamiento, con variables tal y como se indica a continuación. Con esto se puede ajustar la carga en una navegación continuada (prueba sostenida).

� ${__P(desvRetardo)}

� ${__P(despRetardo,0)}

Temporizador aleatorio Gaussiano

Aserción de respuesta

Con las aserciones incluidas a este nivel se valida que las páginas de respuesta contienen determinados valores.

Aserción de respuesta

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 24 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Extractor de expresiones regulares

Permite extraer valores de respuesta del servidor utilizando expresiones regulares de tipo Perl.

Este elemento se ejecuta después de cada petición: aplica la expresión regular, extrae los valores solicitados, genera la cadena de la plantilla, y almacena el resultado en la variable proporcionada.

Extractor de expresiones regulares

6.2.3. Servicios Web

Se compone de los siguientes elementos:

� Variables definidas por el usuario

� Valores por defecto para petición HTTP

� Grupo de Hilos

Petición HTTP

1. Gestor de cabecera HTTP

2. Aserción de respuesta

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 25 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Plantilla plan de pruebas Servicios Web

6.2.3.1. Variables definidas por el usuario

En este apartado se definen todas las variables necesarias para la ejecución del plan de pruebas: expediente_solo_lectura, expediente_finalizado, etc.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 26 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Variables definidas por el usuario

6.2.3.2. Valores por defecto para petición HTTP

Con este elemento se definen los valores por defecto para todas las peticiones HTTP. Por ejemplo, si se define un plan de pruebas que tiene 25 peticiones HTTP y todas se realizan contra el mismo servidor, lo lógico sería añadir el elemento de configuración “Valores por defecto para petición HTTP”, configurar el servidor en dicho componente y dejarlo en blanco en las peticiones HTTP, ya que heredarán dicho valor.

En los valores por defecto para petición HTTP debemos parametrizar:

� Nombre del servidor o IP: ${__P(nServidor)}

� Puerto: ${__P(nPuerto)}

� Protocolo: ${__P(protocolo)}

Valores por defecto para petición HTTP

6.2.3.3. Grupo de Hilos

En el grupo de hilos debemos parametrizar:

� Número de hilos: ${__P(nHilos,10)}

� Periodo de subida (en segundos): ${__P(pSubida,1)}

� Contador del bucle: ${__P(nIteraciones,10)}

Revisar las acciones a realizar en caso de error en una muestra en función de la lógica de la prueba programada.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 27 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Parametrización grupo de hilos

a) Petición HTTP

Dado que el componente WebService(SOAP) Request está deprecado, para las pruebas de carga de servicios web se utilizará el componente “Petición HTTP” indicando en el apartado ‘Body Data’ la petición SOAP a enviar al servicio Web a testear (Método POST).

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 28 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Petición HTTP en las pruebas de carga de Servicios Web

Gestor de cabecera HTTP

Este componente permite sobrescribir las cabeceras de las peticiones HTTP. Un ejemplo muy típico del uso de este componente es sobrescribir el ‘User-Agent’ por defecto para utilizar la versión de navegador que interese.

Modelado de pruebas de carga con Apache JMeter

Clasificación: Uso Público

Ref.: ESPEC_PruebasCargaJMeter.doc Fecha: 07.01.2015 Versión: v1.4 Pág. 29 de 29

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Gestor de cabecera HTTP

Aserción de respuesta

Las aserciones de respuesta permiten verificar el contenido de las respuestas.

Aserción de respuesta