Difference between revisions of "Generando scripts JMeter con GXtest"

Latest revision as of 12:42, 14 November 2016

JMeter

JMeter es una herramienta para realizar pruebas de Performance, de uso gratuito y código abierto. Actualmente JMeter es la herramienta más utilizada en el área de Performance ya que permite de manera sencilla ejecutar pruebas sobre el protocolo HTTP (o bien HTTPS) generando carga a un servidor simulando ser un navegador, pero sin serlo. Con GXtest serás capaz de construir scripts de JMeter con un solo clic pudiendo luego adaptar tu script de forma que el mismo realice las tareas que desees a través de validaciones, condiciones, parametrizaciones, etc.

JMeter te permite ejecutar diferentes escenarios definiendo una carga de usuarios reales e iteraciones que te ayuden a visualizar el comportamiento de tus ambientes ante simulaciones de escenarios reales. Te mostramos a continuación cómo luce un Plan de Pruebas en JMeter.

El proceso de generación de casos de prueba de JMeter se logra ejecutando el caso de prueba en un navegador, capturando las solicitudes HTTP que se hicieron de manera automática mediante un Proxy. Esto permite a testers que no tienen experiencia con JMeter generar primero un caso de prueba (crear un flujo con sus datos mediante datapools) en GXtest, y luego proveer de un script de JMeter a un experto de Performance que podrá modificarlo y dejarlo funcionando de manera correcta (agregando expresiones regulares y algunas parametrizaciones que sean de utilidad).

Sin este proceso, sería difícil identificar eventos e identificar qué tarea realiza cada solicitud HTTP en lo que tiene que ver con acciones funcionales o reglas de negocio. El script generado incluye timers que agregan realismo a tu script mediante el uso de Thinktimes. Crear un script de JMeter sin GXtest es una tarea tediosa difícil de terminar, especialmente cuando el código de la aplicación que estamos queriendo probar cambia continuamente, lo que significa que el script tenga que ser modificado o a veces reconstruido en cada unos de estos cambios. Además, hay que tener en cuenta que si tienes previsto ejecutar sus scripts de prueba utilizando el cifrado Ajax (habilitado de forma predeterminada en GeneXus), sería casi imposible hacerlo sin la generación de GXtest, debido al cifrado.

Consejos para proyectos de Performance

A priori, es muy difícil hacer scripts de pruebas de performance en GeneXus, ya que hay muchos parámetros que no controlarás sobre las solicitudes y las respuestas HTTP. Dicho esto, es casi una necesidad desactivar el Ajax Security para generar correctamente solicitudes parametrizadas y evitar códigos de estado 403 - Resultados no autorizados, en GeneXus. http://wiki.genexus.com/commwiki/servlet/wiki?17384,Javascript+Debug+Mode+property.

Le recomendamos considerar complementar los resultados de sus ejecuciones con las herramientas de monitoreo de GeneXus, como JMX o WMI.

Si desea simular un comportamiento real utilizando cifrado Ajax, es necesario utilizar GXtest versión 3.2 en adelante, para tener la posibilidad de cifrar automaticamente los pedidos Ajax en runtime así como otras parametrizaciones más comunes como AJAX_KEY, AJAX_SECURITY_TOKEN, GX_WEBSOCKET_ID, entre otras variables.

Generando scripts de JMeter con GXtest

GXtest puede generar scripts de JMeter a partir de una grabación de caso de prueba. Esto brinda muchas ventajas a los usuarios, como:

• Grabar casos de prueba con GXtest, lo cuál puede ser realizado por un tester funcional sin experiencia en automatización de scripts de performance. (Una vez generado el script JMeter, un tester de performance tendrá que trabajar sobre el mismo para dejarlo funcionando correctamente).
• Generación automática de la parte más tediosa del script sin perder tiempo ejecutando tareas repetitivas.
• No es necesario introducir manualmente validaciones, temporizadores o parametrizaciones básicas. Normalmente, esto se convierte en una tarea considerablemente larga y por lo general presenta problemas. GXtest introduce automáticamente todos estos elementos.
• Uso de banderas de debugging para capturar tiempos de procesamiento o mensajes de error.
• Soporte para autenticaciones de tipo NTLM.
• Manejo automático de redirecciones.

¿Cómo funciona el generador de scripts?

El script de performance es creado haciendo clic en GXtest Designer, sobre el botón denominado "Generate JMeter scripts".

Cuando se manda una solicitud de creación de un script JMeter, el caso de prueba comienza a ejecutarse de manera usual en la pantalla del usuario. Sin embargo, dicha ejecución desencadena acciones muy diferentes de manera interna al sistema en comparación con una ejecución de caso de prueba tradicional de GXtest. En el transcurso de la ejecución del caso de prueba, se crea un archivo de tipo xml con todos los comandos GXtest que están siendo usados en el caso de prueba, mientras que todos los pedidos HTTP realizados van siendo capturados y guardados en un archivo de tipo saz. Luego estos archivos quedan guardados dentro de una carpeta con el nombre del caso de prueba, donde está instalado el GXtest Designer, normalmente: Abstracta\GXtest Designer\Performance\ExecutionLog\.

El archivo de tipo saz es creado mediante una herramienta llamada Fiddler. Fiddler es un proxy que captura todos los pedidos HTTP (o HTTPS) entre una pc e internet que luego pueden ser analizados agregando breakpoints, o bien editarse los pedidos a nivel de protocolo, entre otros. Este archivo es muy importante para el tester de performance porque será el archivo que tome como base para comparar los pedidos generados y para entender cómo deben ser parametrizados los pedidos luego en el script JMeter.

El plan de pruebas de JMeter es generado usando los comandos de GXtest tomados del archivo xml y los pedidos que quedaron capturados en la sesión de fiddler. Una vez que se completa la ejecución el script creado cuenta con cada comando GXtest tal como es esperado, asociado con las solicitudes HTTP que estén involucradas en cada acción, así como con los temporizadores correspondientes y las validaciones siempre y cuando hayan sido agregadas. El script creado es agregado en la carpeta Abstracta\GXtest Designer\JMeter.

El script generado puede quedar pronto para utilizar sin necesidad de cambios, pero generalmente es recomendable que un experto en JMeter trabaje sobre el script para agregar las parametrizaciones y modificaciones pertinentes, especialmente cuando en el sistema se usa cifrado Ajax. Los cambios que se suelen realizar en los scripts una vez generados, son los siguientes: manejo de condiciones, parametrización de variables, manejo de validaciones, etc, de manera de que tu script simule lo mejor posible la realidad.

Características de GXtest para la creación de scripts de JMeter

Como fue dicho, GXtest genera un script de JMeter de manera automática y ayudando en gran parte con el trabajo del tester en lo que tiene que ver con la creación del script y es un hecho que las pruebas de performances deben hacerse en GeneXus. Las principales características son:

• Legibilidad del script:
  • El script generado es legible y modular.
  • Trazabilidad entre las acciones del usuario (comandos GXtest) y las solicitudes HTTP (o HTTPS)
  • Parametrización automática de variables como: webServer, port, webapp, entre otras.
  • Introducción de Thinktimes entre cada acción de usuario.
• Manejo de redirecciones:
  • JMeter realiza de manera automática las redirecciones en aquellos pedidos con código de respuesta 302.
  • Todos los pedidos secundarios son eliminados para que el manejo de estos pedidos los realice JMeter con la opción “Retrieve all embedded resources”.
• Error debugging:
  • Todas las solicitudes y todas las respuestas son escritas en un archivo de log facilitando el debugging.
  • DEBUG FLAG: habilita y deshabilita la opción de Thinktimes.
• Análisis de resultados:
  • Todas las acciones de usuarios son agrupadas de modo de mejorar el entendimiento de los tiempos de respuesta.
  • Parametrizaciones automáticas:
  • Variables GX y datos de pruebas utilizados por los Datapools (cuando los datos usados son mayores a 3 caracteres).
  • Variables de cifrado Ajax (GX_AJAX_KEY, AJAX_SECURITY_TOKEN)
  • Variables frecuentes como GX_WEBSOCKET_ID
  • Generación de Beanshell para el cifrado automático de los parámetros de URLs en pedidos Ajax. (Para esto dentro de libs hay q poner las clases de Util/encryption de GeneXus que se encuentra en la carpeta de instalación de GXtest\Jmeter en GXtest Professional Edition)
• Buenas prácticas:
  • Eliminación de cookies anterior a la generación.
  • Uso de manejador de cookies en JMeter.

Elementos no soportados actualmente

Existen algunos elementos que sería de utilidad incluir en próximas versiones de GXtest que actualmente no se están generando:

• Carga de binarios (imágenes, etc.) Debido a una limitación en Jmeter .
• Parametrización de otras variables GeneXus.
• Agregar más variables de usuarios.

¿Cómo importar el archivo generado en JMeter?

Después de ejecutar el caso de prueba desde GXtest Designer, el plan de prueba JMeter generado quedará disponible en la carpeta de instalación de GXtest Abstracta\GXtest Designer\JMeter..

El archivo generado tendrá la extensión .jmx y puede ser abierto desde el menú de JMeter: Archivo -> Abrir.

Instalar JMeter

JMeter se puede descargar e instalar de manera gratuita desde su sitio web

Resumen

GeneXus oculta toda la complejidad a los desarrolladores, así como GXtest permite crear scripts Jmeter y hacer pruebas de performance sobre aplicaciones GeneXus. Generar scripts JMeter utilizando la herramienta le ahorrará mucho tiempo y dolores de cabeza al manejar de manera automática las solicitudes de GeneXus.

Además, si mantiene habilitada la opción AJAX SECURITY (default), GXtest será probablemente la única opción para manejar tal complejidad en sus scripts.