Productos a generar como salida de la ejecución de un test con JMeter

RECU-0404 (Recurso Técnica)

Descripción

Cuando se utiliza JMeter para realizar pruebas sobre una aplicación objetivo, tanto de forma aislada como cuando se utiliza JMeter en combinación con otro software (por ejemplo Glassbox), se debería de capturar un conjunto de productos que se generan como salida de la ejecución de cada test (fichero .jmx), con JMeter, ó que se han utilizado como entrada para la ejecución de la prueba. Estos productos a capturar incluyen, pero no exclusivamente, el informe de rendimiento y el testplan de JMeter (fichero .jmx).

Tales productos, explicados en este documento, se mencionan aquí por el hecho de usar JMeter como una de las herramientas para realizar la prueba(s). Otras herramientas utilizadas en combinación con JMeter para la prueba(s), pueden requerir la captura de otros productos, que escapan al alcance de este documento, quizás algunos de ellos comunes a JMeter.

El objetivo de formalizar esta recopilación, es que como salida de una prueba en la que se ha usado JMeter, se capture información lo más precisa posible, que permita contrastar a posteriori, las condiciones en que se ha realizado la prueba, la validez de los resultados obtenidos, examinar los resultados con otras herramientas, ...

Uso en MADEJA

Los productos que se especifican a continuación se deberían de capturar cuando se ejecutan pruebas utilizando JMeter como herramienta de testing, bien de forma aislada o bien en combinación con otras herramientas.

Este documento ayuda a la aplicación de MADEJA formalizando la lista de productos que deben capturarse tras la ejecución de una prueba con JMeter.

En los subapartados que siguen se explica en qué consiste cada uno de estos productos:

  • Informe de Prueba de Rendimiento
    Según una plantilla específica. Algunos productos importantes a generar son apartados de este documento. En particular:
    • Nombre y version del software para la que se testea el rendimiento
    • Especificación del entorno de despliegue de la aplicación a testear
    • Especificación de la arquitectura de testing
    • Especificación del testplan
    • Métricas a calcular con su valores objetivos
  • Testplan de JMeter (fichero .jmx)
  • Especificación de las propiedades de configuración del testplan
  • Fichero(s) sample result
  • Fichero de log de JMeter
  • Ficheros de configuración de JMeter
  • Ficheros de datos utilizados para la ejecución de la prueba
  • Ficheros de respuesta de la aplicación (normalmente no se generan en pruebas de rendimiento)

Informe de Prueba de Rendimiento

Debe generarse según una plantilla específica.

Algunos de los productos importantes que deben generarse como resultado de la ejecución de una prueba son apartados de este documento:

  • Nombre y versión del software para el que se testea el rendimiento.
    Apartado Ficha del Proyecto del documento.
  • Especificación del entorno de despliegue en el que se ha instalado la aplicación a testear
    Consiste en la especificación de la arquitectura hardware y software del entorno de despliegue, arquitectura software de la aplicación, especificando las versiones concretas del software base que utiliza la aplicación (SGBD, Servidor de Aplicaciones, Servidor HTTP, Servidor de Correo, ...). Apdo. Especificación del Entorno Hardware / Software para las pruebas de rendimiento .
  • Especificación de la arquitectura de testing
    Consiste en la especificación de los productos software que se han utilizado para realizar la prueba de rendimeinto, incluidas las versiones de éstos, y la arquitectura de despliegue de los mismos en el entorno de test.
  • Especificación del testplan (del script .jmx)
    Un script .jmx es básicamente un conjunto de peticiones (http, FTP, … ) en un orden determinado, con cierta información adicional (p.e. aserciones). Por otra parte, los scripts .jmx no documentan a que elementos y acciones de la interfaz de usuario corresponden las peticiones del script. Esto hace que sin una especificación adicional, sea extremadamente difícil el mantenimineto de un script .jmx.
    Por otra parte, el testplan, que posteriormente el equipo de testing implementará como un sript .jmx, debe ser consensuado con el proyecto (proyecto = equipo del proyecto que ha desarrollado el software, director del proyecto, usuario, ...), es decir, con usuarios sin ningún conocimiento de JMeter.
    Por las dos razones anteriores se necesita un mecanismo de especificación del testplan, que permita especificar éste en un estadio anterior a la implementación en fichero .jmx, además, debe ser un mecanismo de especificación entendible por otros actores no especializados en JMeter.
    Existen básicamente dos mecnismos de especificación para este fin:
    • Lenguaje natural
    • Lenguaje UCML (User Comunity Modeling Language): http://www.perftestplus.com/articles/ucml.pdf
      Lo deseable, en la mayoría de los casos para generar la especificación de un testplan, es utilizar una combinación de ambos.
      NOTA:
      Sería deseable construir un profile de Enterprise Architect para especificar diagramas UCML con esta herramienta.
      Debería haber una especificación por cada script .jmx . Es decir, si la prueba de rendimiento tiene asociados varios scripts .jmx, debería haber varias especificaciones, una para cada uno de ellos.
  • Objetivo de la prueba (métrica(s) a calcular, comportamiento a estudiar, ...)

Testplan de JMeter (fichero .jmx)

Uno o varios ficheros de JMeter.

Especificación de las propiedades de configuración del testplan

Uno de los requisitos que debe cumplir un testplan de JMeter (fichero .jmx) es ser configurable. Por ejemplo, datos como

  • El hostname o dirección IP del servidor(es) contra el que se ejecuta el testplan
  • Creedenciales (nombre de usuario y password) de los usuarios virtuales
  • Strings / expresiones regulares que se comprueban en las aserciones
  • Datos de configuración de los thread groups (número de threads, ramp-up period, número de iteraciones o tiempo de la ejecución, ...) deberían de ser configurables, para asegurar que el testplan se pueda ejecutar en varios entornos de pruebas solo modificando la configuración.

La forma más simple de hacer esto es mediante un fichero de propiedades que se pasa a JMeter con el modificador -q en el momento de ejecutar éste.

Si la prueba de rendimiento consiste en un solo fichero .jmx, convenimos en que debería existir un único fichero .properties con el mismo nombre que el .jmx, pero con extensión .properties. Si la prueba de rendimiento consiste en varios .jmx, es opcional el utilizar un único fichero de propiedades para todos los .jmx o bien uno para cada .jmx. Si este último es el caso, con el mismo nombre que el fichero .jmx .

Requisitos que debe cumplir un fichero de propiedades:

  • Ser autodocumentado: además de las propiedades y sus valores, debe contener la especificación de qué es lo que significa cada propiedad y como son los valores que puede tomar
  • Si un mismo fichero .properties se utiliza para varios .jmx, debe quedar claro que propiedadeas aplican y cuales no aplican a cada .jmx
  • Número de version del fichero y fecha de última modificación. Si el fichero se está bajo control de Subversion, deben usarse los SVN keywords $Id$ y $HeadURL$ para especificar estas informaciones.

Fichero(s) de sample result

Para cada ejecución de un script .jmx como parte de una prueba de rendimiento, debería de generarse un fichero de sample result correspondiente a la ejecución del testplan.

El nombre del fichero de sample result debe ser el nombre del fichero .jmx más la fecha y hora de la ejecución.

El formato del fichero puede ser CVS o JTL, a elección del tester, en cada caso con la extensión .csv ó .jtl repectívamente

Por ejemplo, si el testplan se llama testplan.jmx, el fichero de sample result en formato JTL se llamará testplan_20101129133044.jtl . Este fichero se especifica en la línea de comando de JMeter con los modificadores -Jjmeter.save.saveservice.output_format (valores csv ó xml, en minúsculas) y -l

Notas:

  1. Si el formato de fichero que se especifica es JTL, las propiedades de JMeter deben configurarse (fichero jmeter.properties) para que las respuestas de la aplicación a las peticiones del testplan NO se guarden en el fichero JTL, pues esto penaliza la ejecución del testplan. Los fichero de result samples en formato CSV no tienen la posibilidad de guardar las respuestas.
  2. Es más optimo generar los ficheros de result samples en formato CSV para las pruebas de rendimiento, debido a que la generación de un fichero JTL penaliza más la ejecución del testplan que la generación de un fichero CSV, por contener aquel más texto que este. Sin embargo, hay algunos listeners que no saben mostrar correctamente la información almacenada en un fichero CSV.
  3. Si el fichero de result sample se genera en formato CSV, debe especificarse en la configuración de JMeter que se genere con cabeceras, o de otra forma no se podrá cargar en listeneres. Para ello especificar -Jjmeter.save.saveservice.print_field_names=true en la línea de comando.

Fichero de log de JMeter

Es el fichero de log que genera JMeter en cada una de sus ejecuciones. Recoge las posibles excepciones de JMeter y los mensajes que el testplan haya decidido escribir en este log.

Para cada ejecución de un fichero .jmx debe generarse un fichero de log, con el mismo nombre que éste mas la fecha y hora de la ejecución, pero con extensión .log . Por ejemplo, si el fichero de testplan se llama testplan.jmx, el fichero de log de una de sus ejecuciones se llamará testplan_20101129133044.log

El fichero de log de JMeter se especifica en la línea de comando con el modificador -j .

Convenimos en que la fecha y hora que se especifique como parte del nombre en el fichero de
result sample y fichero de log de una ejecución, han de ser la misma, para que se pueda
identificar cada par de ficheros correspondiente a una ejecución. Esto implica que la línea de
comando de JMeter debería ejecutarse con un script del shell o alguna otra herramienta que lance
el comando con estos requisitos

Ficheros de configuración de JMeter

Otra información que debería de capturarse como parte de la ejecución de una prueba de rendimiento es la configuración de JMeter utilizada para ejecutar la prueba. Esto permitirá reproducir la prueba en las mismas condiciones si es necesario.

JMeter guarda la configuración en ficheros de propiedades. Suponiendo que con ${JMETER_HOME} nos referimos al directorio raiz de la instalación de JMeter (p.e. /usr/local/jakarta-jmeter-2.4), los nombres por defecto de los ficheros de propiedades son:

  • ${JMETER_HOME}/bin/jmeter.properties
  • ${JMETER_HOME}/bin/jmeter.system
  • ${JMETER_HOME}/bin/jmeter.user

Estos ficheros de configuración deberían capturarse y empaquetarse como parte del material resultante de ejecutar una prueba de rendimiento, con objeto de que la configuración de JMeter se pueda reproducir en otra ejecución.

Los nombres por defecto de los ficheros de propiedades son los que se especifican más arriba, ahora bien, estos nombres pueden ser cambiados:

  • jmeter.properties especificando el modificador -p en la línea de comando.
  • Los otros dos alterando las propiedades user.properties y system.properties de jmeter.properties (o como se llame este)

Por otra parte, las propiedades de estos ficheros pueden especificarse desde la línea de comando con el modificador -J. Si esta es la forma en que se ha previsto que se ejecute el script .jmx, esto debería quedar documentado en algún sitio (p.e. LEAME.txt), o ser parte del código de un script de automatización con el que lanzar JMeter.

Nota:

Hay otros ficheros de propiedades que lee JMeter, pero no aportan gran cosa en la configuración de una ejecución

Ficheros de datos utilizados para la ejecución de la prueba

Es muy frecuente el uso de un fichero de datos, normalmente en formato CSV, para guardar datos que el fichero .jmx lee en el momento de ser ejecutado.

Si se utilizan ficheros de este tipo, también deben empaquetarse como parte del material resultante de la prueba de rendimiento.

Ficheros de respuesta de la aplicación

No es normal que en una prueba de rendimiento se diseñe el script .jmx para que capture como ficheros las respuestas de la aplicación a las peticiones del script, porque esto añade mucho tiempo extra a las peticiones que ejecuta el testplan.

No obstante, puede ser válido en algunos contextos. Si se hace, los ficheros de respuesta generados por cada .jmx en su ejecución, deben ser empaquetados al final de la prueba, de forma separada de los ficheros de respuesta generados por otro .jmx .

Línea de comando

Con los requisitos anteriores, la linea de comando para ejecutar un script de JMeter es (con \ indicamos continuación de la misma línea de comando):

  • Si el script se ejecuta desde linea de comando generando el fichero de sample results en formato CSV:
$ ${JMETER_HOME}/bin/jmeter -n -t testplan.jmx -Jjmeter.save.saveservice.output_format=csv \
       -Jjmeter.save.saveservice.print_field_names=true -l testplan_20101129133044.csv \
       -j testplan_20101129133044.log -q testplan.properties
  • Si el script se ejecuta desde la interfaz GUI genarando el fichero de sample result en formato JTL:
$ ${JMETER_HOME}/bin/jmeter -n -t testplan.jmx -Jjmeter.save.saveservice.output_format=xml \
       -l testplan_20101129133044.csv -j testplan_20101129133044.log -q testplan.properties
  • Si el script se ejecuta desde la línea de comando en un entorno de testing distribuido:
$ ${JMETER_HOME}/bin/jmeter -n -t testplan.jmx -Jjmeter.save.saveservice.output_format=xml \
       -l testplan_20101129133044.csv -j testplan_20101129133044.log -q testplan.properties -r \
       -Jremote_hosts=192.168.10.25,192.168.10.26

Para más información sobre las opciones de línea de comando de JMeter ver http://jakarta.apache.org/jmeter/usermanual/get-started.html#options

Se debería de utilizar una herramienta para automatizar estas ejecuciones, por ejemplo con Maven, Ant o un script Perl o de otro tipo.

Contenidos relacionados