Difference between revisions of "GXtest2OpenSTA para pruebas de performance"

Latest revision as of 19:09, 24 January 2014

link= {{{3}}}

Introducción

GXtest2OpenSTA es una nueva feature que nos permite hacer pruebas de performance (stress testing, load testing, scalability testing, capacity testing) minimizando en aproximadamente un 80% el costo de automatización. Esto se logra ya que, si bien GXtest es una herramienta de testing funcional, una vez que tenemos los casos de prueba automatizados nos permite generar scripts de forma automática en una herramienta gratuita para pruebas de performance como es OpenSTA, dándole al tester numerosas ventajas que se verán más adelante.

En este artículo veremos una introducción a las pruebas de performance, luego veremos cómo éstas se suelen realizar con OpenSTA, para finalizar viendo cómo utilizar GXtest2OpenSTA y así entender los verdaderos beneficios que esta herramienta nos aporta para garantizar la calidad de los sistemas antes de ponerlos en producción.

Introducción al testing de performance

Un aspecto fundamental a tener en cuenta en los tests de performance es que, por varias razones, es imposible testear todas las funcionalidades de una aplicación. Teniendo presente esto, surge un nuevo problema: ¿Qué funcionalidades probar? ¿Qué casos de prueba seleccionamos para automatizar e incluir en una prueba de performance?

Para resolver ésto se puede recurrir por ejemplo a datos históricos tomados del sistema anterior (en caso de que el hubiera una versión anterior en funcionamiento) que nos den una pauta de los usuarios activos, número de veces que se utilizan las funcionalidades que nos interesan, etc. De no tener esta posibilidad, se puede recurrir al conocimiento de expertos (encargados del proyecto, desarrolladores, usuarios u otras personas que puedan realizar un estimativo de que funcionalidades serán las más adecuadas para incluir en las pruebas).

Luego de determinados los casos de prueba a ejecutar, se deben automatizar. Armar los scripts es generalmente la parte que lleva más tiempo del proyecto. Afortunadamente, con GXtest esta tarea se puede hacer con menor esfuerzo.

¿Cuándo realizar testing de performance?

Básicamente, existen dos estrategias para encarar las pruebas de performance. La más tradicional es comenzar con la automatización de los casos de prueba luego de finalizado el producto, por lo que no van a haber más cambios en el desarrollo. Esta estrategia tiene como ventaja que no se tendrá que invertir tiempo en mantenimiento de los casos de prueba automatizados, ya que se trabaja con una única versión del sistema. Sin embargo, tiene la principal contra de que se pueden encontrar de manera muy tardía problemas de diseño o de arquitectura que impliquen un retrabajo de construcción del sistema muy grande.

La otra manera de encarar un proyecto de performance es comenzar las pruebas de performance en paralelo con el desarrollo, a medida que se van liberando las funcionalidades principales. Este método tiene como ventaja que se pueden descubrir fallas más temprano y se pueden ir solucionando a medida que avanza el desarrollo, sin embargo, el costo de las pruebas de performance puede ser mayor ya que hay que ir adaptando los casos de prueba cuando se producen cambios en el desarrollo. En esta tarea de mantenimiento de los casos de prueba es fundamental el uso de GXtest como herramienta de automatización ya que nos va a permitir rápidamente adaptar los casos de prueba automatizados a los cambios del sistema.

OpenSTA

OpenSTA es una herramienta open source para hacer testing de performance. Se utiliza para automatizar los casos de prueba en scripts que contienen los pedidos http (o https) que realiza cada caso, y permite modificarlos para realizar distintas acciones (tales como ingresar validaciones, condiciones, parametrizaciones, etc.). En la siguiente figura podemos apreciar el formato de un script de OpenSTA.

Además, el OpenSTA permite montar escenarios de prueba donde se pueden configurar la cantidad de usuarios activos, cantidad de iteraciones, forma en que los usuarios virtuales ingresan al sistema y otras opciones que permiten que la prueba represente un escenario lo más realista posible. En la figura que sigue se muestra un ejemplo de un escenario.

En materia de performance, OpenSTA es una de las mejores herramientas, ya que:

• Permite ingresar un gran número de usuarios virtuales por máquina generadora.
• Permite distribuir la carga de manera sencilla.
• Presenta un modelo para armar la simulación del escenario muy bien orientado a aplicaciones web.
• Presenta gran cantidad de opciones para analizar los resultados tales como: numerosas gráficas, tablas, etc.
• La productividad en desarrollo es mucho mayor una vez que se tiene experiencia con la herramienta.

Por otro lado, una desventaja del OpenSTA es el grabado de casos de prueba. Al grabar los casos de prueba se obtiene un script con los pedidos http que se realizaron. Por lo tanto, a alguien que no conozca la aplicación le va a resultar muy difícil diferenciar cada paso, o identificar que es lo que se hace en cada pedido. Muchas veces, para dejar el script más claro, se ingresan durante la grabación comentarios entre los pasos, o timers que controlen el tiempo de cada paso. Si encima de esto, queremos agregar validaciones o parametrizar variables, vamos a concluir que realizar un script en OpenSTA es una tarea pesada, y puede que resulte engorroso en los proyectos en los que se esté cambiando constantemente el código de la aplicación, lo que hace que se tengan que regenerar los scripts seguido.

Es recomendable para un proyecto de performance que se complementen las mediciones del OpenSTA con herramientas de monitorización de GX, como por ejemplo JMX.

GXtest2OpenSTA

Como mencionábamos en la introducción, GXtest presenta una alternativa que permite superar esta problemática.

Gracias a su nueva funcionalidad, GXtest puede generar scripts de OpenSTA a partir de un caso de prueba previamente grabado. Esto le brinda al tester muchas ventajas, entre ellas:

• Grabar los casos de prueba en GXtest, que permite hacerlo de una forma mucho más práctica con posibilidad de agregar validaciones y otras opciones mencionadas en otros artículos.
• Realizar la parte más pesada del script automáticamente sin necesidad de perder tiempo en hacer tareas repetitivas.
• En caso de que haya un cambio en la aplicación, poder impactar los cambios en GXtest y luego regenerar los scripts de forma fácil, sin necesidad de grabar de nuevo en GXtest.
• No tener que ingresar manualmente validaciones, timers, ni parametrizaciones. Normalmente esto se vuelve una tarea bastante larga y muchas veces presenta problemas. GXtest ingresa todos estos elementos de forma automática.
• Tener los pedidos secundarios (css, gif, jpg, js, etc.) en archivos separados de los primarios. Esto permite tener un script más prolijo, lo que facilita el análisis.
• Tener una bandera de debug que condiciona los pedidos secundarios y mensajes de log.
• Soporta autenticación NTLM.
• Manejo de redirects automático.

¿Cómo funciona el generador?

La generación del script de performance se realiza ejecutando el caso de prueba desde el botón "Generate OpenSTA scripts"

Al ejecutar el pedido para crear un script de OpenSTA, el usuario verá en su pantalla el caso de prueba ejecutándose tal y como se hace normalmente. Sin embargo, internamente se realizan varias acciones distintas: a medida que se va ejecutando el caso de prueba, se crea un archivo xml con todos los comandos de GXtest que se van ejecutando en la prueba. Además, en paralelo se van grabando los pedidos http en un archivo de extensión saz. Estos archivos se dejan dentro de una carpeta con el nombre del caso de prueba, donde está instalado el GXtest Designer, normalmente en: Abstracta\GXtest Designer\Performance\ExecutionLog\.

El formato saz pertenece a la herramienta Fiddler, un proxy que graba el tráfico http(s) entre Internet y la PC para luego poder analizarlo, permitiendo insertar breakpoints, editar los pedidos a nivel de protocolo, etc.

A partir de estos dos archivos (xml y saz) se va generando el script de OpenSTA tomando los comandos de GXtest del xml y los pedidos http(s) del saz, por lo que, una vez finalizada la ejecución, el script tendrá cada comando ejecutado de GXtest asociado a los pedidos http(s) que se hacen en él con sus correspondientes timers y, en caso de que se hayan ingresado, sus correspondientes validaciones. Además, si en el caso de prueba de GXtest se toma algún valor de una variable desde un datapool, ésta quedará parametrizada en el script de OpenSTA. Estos archivos se crean en la carpeta Abstracta\GXtest Designer\Repository.

En general los scripts generados están listos para ejecutarse sin hacer ningún cambio, aunque dependiendo del sistema se le hacen modificaciones para agregar condiciones, variables, validaciones, etc. para que el script se comporte de la forma más real posible.

Instalar OpenSTA

Abstracta realizó correciones de bug sobre la última versión liberada de OpenSTA. Para poder aplicar esas correcciones, es necesario instalar la última versión liberada de OpenSTA con el fix desde aquí. Finalmente, aplicar el parche siguiendo las instrucciones del archivo readme incluido en los archivos descargados.

Cómo habilitar GXtest2OpenSTA

Para generar los archivos necesarios para las pruebas de performance utilizando OpenSTA, es necesario habilitar la generación en el menú Options -> Local Settings.

Allí se puede habilitar o deshabilitar la generación de los archivos, y además configurar la ubicación de las herramientas Fiddler y el OpenSTA Modeller.

Aquí pueden encontrar un post de nuestro blog en donde hay (entre otras cosas) un video de ejemplo.

Resumen

GXtest permite crear scripts para hacer pruebas de performance en la herramienta OpenSTA. Generar los scripts a partir de GXtest le permite al tester ahorrar mucho tiempo de trabajo repetitivo, permitiéndole dedicarse a otras tareas para mitigar la mayor cantidad de errores de performance, y así obtener un producto de mayor calidad.

Referencias

• Scott Barber; Performance Testing Guidance for Web Applications
• Scott Barber; User experience, not metrics
• Blog del CES