Pruebas de rendimiento con ventanas emergentes y/o protocolo HTTPS

Introducción

Durante el diseño de las pruebas dinámicas existen varias alternativas de herramientas que se pueden utilizar para la grabación de las navegaciones. La herramienta que mejores prestaciones nos ofrece para realizar este tipo de tareas es Apache JMeter, aunque existen otras que pueden servir de complemento o que, dependiendo de las características de las pruebas, pueden sustituirla: Badboy, Selenium, The Grinder... Apache JMeter es una aplicación libre, diseñada para grabar las navegaciones, y que posteriormente puede simular la carga necesaria para las pruebas y hacer análisis sobre aplicaciones web, aunque también se ha extendido su uso como herramienta de pruebas unitarias para LDAP, conexiones de bases de datos, FTP, Servicios Web, HTTP, etc. Se pueden consultar más detalles sobre Apache JMeter en el siguiente enlace.

Uso de JMeter para testear aplicaciones web con protocolo HTTPS

El componente HTTP Proxy Server de JMeter permite capturar las navegaciones por una aplicación web, facilitando así la implementación de un testplan (fichero .jmx.). Para ello, el HTTP Proxy Server captura las peticiones HTTP que el navegador realiza a la aplicación, y las agrega al testplan mientras se está construyendo éste.

Hasta la versión 2.3 inclusive, JMeter no tenía la posibilidad de capturar peticiones HTTPS. El motivo es simple: al estar encriptadas las peticiones HTTPS y las respuestas que se intercambian entre navegador y aplicación, el servidor proxy era incapaz de entender el texto que se intercambiaba entre ambos.

En este caso, una posible solución consiste en grabar con Badboy las navegaciones y exportar a JMeter estas grabaciones para su posterior lanzamiento durante las pruebas de rendimiento. Sin embargo esta solución no es válida en el caso que exista código JavaScript. Tambien pueden darse otras circunstancias que impidan esta solución tan sencilla, como por ejemplo si además de HTTPS se utilizan ventanas emergentes, en cuyo caso se debe seguir los pasos del punto anterior.

A partir de la versión 2.4 esto ha cambiado, siendo posible para el HTTP Proxy Server capturar las peticiones HTTPS. Para ello, este componente utiliza un certificado, que deberá ser aceptado por el navegador, aunque éste detecte que no es válido.

Uso de JMeter con aplicaciones a base de ventanas emergentes

Las ventanas emergentes pueden ser o no ser un problema para JMeter, en función de qué es lo que se quiere testear en la aplicación.

Si lo que se quiere testear con JMeter es el rendimiento de la aplicación, las ventanas emergentes no son un problema. La explicación es que para la aplicación, la cuestión de si una petición HTTP se la hace una ventana emergente o la ventana principal del navegador, es irrelevante. El problema podría estar en el momento de construir el testplan de JMeter, porque se necesite capturar con expresiones regulares campos ocultos de los forms HTML, para que la ejecución llegue al punto de mostrar la ventana emergente sin detectar un error. Más sobre esto en la referencia http://wiki.apache.org/myfaces/PerformanceTestingWithJMeter.

Si lo que se quiere es testear que se muestra la ventana emergente, tenemos un problema con JMeter, porque JMeter no puede ejecutar el código JavaScript embebido en la respuesta de la aplicación a las peticiones HTTP, ni entender el árbol DOM de las páginas HTML/XML que responde el servidor. Por tanto, con JMeter no es posible comprobar si en el lado del cliente se muestra una ventana emergente. Si este es el tipo de test que se quiere realizar sobre la aplicación, lo recomendable es utilizar otra herramienta.

En cualquier caso, la implementación de un testplan con tecnologías como AJAX y JSF, o incluso sin estas tecnologías, cuando los forms de la aplicación envían campos ocultos que la aplicación cambia de valor de una respuesta a otra, suele tener cierta dificultad. Normalmente por el hecho de que las peticiones HTTP / HTTPS arrastran valores de estos campos ocultos, que hay que detectar y extraer de las respuestas a las peticiones, para enviarlos en las peticiones siguientes. Muchas veces además, este tipo de comportamiento se da en aplicaciones basadas en tecnologías como JSF y AJAX, con las que suele hacerse un profuso uso de las ventanas emergentes, lo que provoca que a veces también se identifique el problema con el hecho de que la aplicación muestra ventanas emergentes que "no pueden ser capturadas con JMeter", cuando en realidad el problema suele estar en que es necesario capturar estos campos ocultos para que el script de JMeter haga correctamente la petición HTTP que en otro caso haría el navegador vía una ventana emergente.

Alternativas estudiadas para resolver este problema

Combinación de las herramientas JMeter y Badboy

Badboy es una aplicación que facilita el testeo y desarrollo de webs capturando la navegación para ejecutarla posteriormente de forma automática. Sin embargo, BadBoy no permite simular carga en las aplicaciones y por esta razón se suele combinar con JMeter, para las pruebas de rendimiento, ya que ofrece la posibilidad de exportar las navegaciones grabadas a formato .jmx, compatible con JMeter.

En el diseño de pruebas con ventanas emergentes, si se graba un pop-up con Badboy y posteriormente se exporta dicha navegación a .jmx, obtenemos la siguiente advertencia:

Advertencia

Si aún así importamos la navegación en JMeter, podremos comprobar que efectivamente no obtenemos el resultado deseado. Por tanto esta solución no resulta válida para resolver el diseño de pruebas de rendimiento con ventanas emergentes.

Combinación de las herramientas JMeter, Selenium y JUnit

Es posible realizar una grabación de las pruebas utilizando Selenium y JUnit y posteriormente ejecutarlas desde JMeter, a través del muestreador JUnit Request, seleccionando la clase y el método que se desea ejecutar:

Sin embargo, el muestreador solo detecta clases que hereden directamente de la clase JUnit, y los test JUnit, al apoyarse directamente en las grabaciones de Selenium, heredan de la clase SeleneseTestCase que extiende de JUnit, por lo que no son detectadas por el muestreador y no se podrán lanzar lanzarlas desde JMeter.

Por tanto esta solución no es válida para resolver el diseño de pruebas con ventanas emergentes.

Utilización de The Grinder en lugar de JMeter

The Grinder es una herramienta de generación de pruebas de estrés diseñada principalmente para pruebas de carga de aplicaciones web, aunque ofrece la posibilidad de crear scripts Jython que extiendan esta funcionalidad a otros protocolos, así como diseñar desde cero las pruebas. Consta de una herramienta de captura, una interfaz de control y un agente que ejecuta el proceso que genera la carga.

La principal diferencia que ofrece respecto a JMeter, es que The Grinder está orientado al desarrollo de scripts en Jython o Python, por lo que JMeter será mucho más amigable para testeadores que no sean desarrolladores. Además, JMeter también ofrece un módulo de informes de resultados más completo que The Grinder.

Aunque The Grinder puede parecer una buena alternativa para JMeter, no puede manejar código en el lado del cliente, como Javascript, con lo que esta solución tampoco es válida para resolver el diseño de pruebas con ventanas emergentes.

Solución recomendada

En este caso habrá que estudiar cada aplicación para encontrar la alternativa que mejor se adapte. La solución más práctica suele ser crear en el testplan de JMeter los componentes necesarios para que éste se ejecute sin errores, independientemente de que las peticiones del testplan se hayan capturado con la herramienta BadBoy o el componente HTTP Proxy Server de JMeter.

Los pasos a seguir serían:

• Realizar la grabación de la navegación con BadBoy ó HTTP Proxy Server. Si la grabación se realiza con Badboy, hay que exportar el script a JMeter (que no es posible en el caso de JavaScript).
• Identificar los parámetros intercambiados.
• Configurar manualmente en JMeter los parámetros que se le deben pasar a la aplicación en la Request, utilizando por ejemplo el componente Regular Expression Extractor, y especificando en las siguientes peticiones la variable en la que se han extraído los elementos necesarios.
• Configurar manualmente en JMeter para que la navegación funcione en los casos en los que se haya necesitado exportar de BadBoy fuentes de datos, incrementos o aserciones.

En la siguiente imagen aparece la interfaz de la herramienta Apache Jmeter. En la parte izquierda podemos visualizar las diferentes Request de la aplicación, y en la parte derecha, los parámetros de la Request que se encuentra seleccionada.

Request de Jmeter

Esta técnica se puede utilizar con éxito para la grabación de navegaciones en las que se utilizan un parámetro cuyo valor cambia en hilos distintos, siendo su valor aleatorio y siempre distinto.

Esta técnica se explica en la referencia Testing a JSF Application with JMeter para aplicaciones JSF, pero es válida también para construir el testplan de otras aplicaciones que no se basan en JSF, como Redmine.