Twitter
RSS

Load & Performance Testing

0
Gracias a herramientas como Watir o Selenium donde podemos automatizar tareas repetitivas podes hacer pruebas de regresión en corto tiempo y de forma muy sencilla, pero estas herramientas no son útiles para pruebas de carga o performance de servers.

Una herramienta sencilla de utilizar y que es Open Source, es JMeter, esta herramienta permite ejecutar pedidos al server de forma paralela, a través de threads, cada uno pudiéndole pedir diferente tipo de pedidos, esta potencial herramienta ademas permite realizar pruebas de forma distribuidas, donde múltiples equipos simulan múltiples usuarios.

La herramienta se la puede conseguir aquí: http://jakarta.apache.org/jmeter/.

Una vez descargado, se debe ejecutar: jmeter.bat (windows) o jmeter (GNU/Linux); al principio su interfaz parece ser poco intuitiva, pero es sencilla, JMeter tiene un arbol de elementos que se pueden cargar o agregar segun corresponda el caso, se divide en dos, el Plan de Pruebas y el Banco de Trabajo, dentro del Plan de Pruebas se deben agregar todos elementos pertenecientes a nuestros casos que iremos armando durante la utilización de JMeter, y el Banco de Trabajo, permite utilizar elementos temporarios para emplear con nuestro Plan.
En la imagen se puede observar la pantalla con la que nos encontramos al ejecutar JMeter. En este caso vamos a realizar pruebas sencillas contra servers publicos, y vamos a generar el plan de forma casi automatica.

Lo primero que debemos hacer es agregar un Grupo de Hilos, seleccionamos nuestro Plan, hacemos click con el boton derecho del mouse, Añadir->Grupo de Hilos; el grupo de hilos nos permite definir cuantos hilos (simula la cantidad de usuarios) se deben ejecutar, el periodo de subida es cada cuanto tiempo debe ejecutarse un nuevo hilo, y el contador de bucle define cuantas repeticiones se deben hacer antes de finalizar la ejecución.
Una vez agregado el Grupo de Hilos debemos agregar un nuevo elemento llamado "Valores por Defecto para Petición HTTP", seleccionamos el Grupo de Hilos, y hacemos click derecho, Añadir->Elemento de Configuración->Valores por Defecto para Petición HTTP.
Este elemento nos permite definir parámetros del server, como la dirección, puerto, timeouts, protocolo (http, https), encoding, path y agregar parámetros que se enviaran al server al comenzar.

El resultado debe quedar de la siguiente forma, usaremos a yahoo.com como server de prueba:


Una vez configurado nuestro server, para facilitarnos la tarea de agregar las peticiones manualmente usaremos un proxy HTTP que incluye JMeter, este no funciona contra servers HTTPS, por lo que conviene guardar las peticiones usando una conexion no segura y despues si utilizar la conexion segura para ejecutarlas.
Para ello seleccionamos nuestro banco de trabajo, y hacemos click con el boton derecho, Añadir->Elemento de No Prueba->Servidor Proxy HTTP; aquí debemos configurar los parametros para nuestro proxy, el cual debemos agregar a nuestro navegador, como la mayoria de las veces en ambientes de desarrollo los puertos 80 y 8080 se encuentran ocupados, utilizaremos otro puerto, en nuestro ejemplo 9090; en esta pantalla se pueden definir diferente opciones, pero las requeridas son el puerto y el tipo de peticion, se recomienda seleccionar el controlador objetivo, en nuestro caso: Plan de Pruebas -> Grupo de Hilos.

 La configuración debe ser como la siguiente pantalla: 



Ademas se pueden definir que tipo de archivos pueden omitirse o cuales incluirse.

Ahora configuramos las opciones del proxy de nuestro navegador, con la configuración de JMeter:



Con el proxy configurado solamente nos resta arrancar el proxy de JMeter, lo arrancamos y luego en nuestro navegador ingresamos al sitio web, una vez arrancado el proxy e ingresado al sitio web, JMeter capturara los pedidos GET y/o POST que se le realicen al server, en este caso quedo asi:




Siendo los nuevos elementos de nuestro plan, las peticiones al servidor; volviendo a la configuración inicial de el grupo de hilos, cambiamos el parametro de numero de hilos, y seleccionamos el valor 5, para simular 5 usuarios, y el periodo de subida en 60 (1 cada 60 segundos), grabamos nuestro plan de pruebas, y solo nos resta ejecutar.

Seleccionamos el menu  Lanzar, y seleccionamos la opción Arrancar, y con esto ejecutamos nuestro plan de pruebas, arriba a la derecha se encendera un recuadro verde que se apagara cuando ya no queden hilos ejecutandose.

Para obtener resultados de las ejecuciones, se suele agregar Listeners (escuchadores), de los cuales los mas comunes son Summary Report y Reporte Agregado, ambos retornan los valores de respuesta del server con respecto a la ejecución de las pruebas cuanto mayor los valores, peor es la performance en la llamada que el listener muestre, en un próximo post detallare como leer un listener y obtener información util.

Watir Add-ons

0
Aunque Watir es una herramienta que constantemente madura, carece de algunas funcionalidades extra, que provocan que el proceso de testing se estanque, por ejemplo uno de los principales inconvenientes que me surgieron al automatizar con esta herramienta fueron los cuadros de dialogo simples, que muestran mensajes de información o advertencias, y hasta incluso confirman las acciones.

El atajo que use en estos casos, fue el mismo que implemento en mis Frameworks de testing, y se basa principalmente en extender la clase de Watir para añadir las nuevas funcionalidades, el "parche" (por ponerle un nombre) es sencillo de implementar, y se puede hacer incluyendolo dentro de otro script ruby, y añadirlo luego de agregar a watir al script.

El parche sin modificar la clase de Watir, pero injectando funcionalidad al objeto browser:


###############################################################
# watirAddOn #
# #
# add functionalities to watir #
###############################################################

def watirAddOn()

browser.instance_eval %{ #modifying the Watir::Browser object!

###############################################################
# Accept all dialogs #
###############################################################

def accept_dialogs
# Accept dialogs
# this method must be send before to handle a JScript Window...
str = "var win_all = getWindows();"
js_eval(str)
str = "var target_win = win_all[win_all.length-1];"
js_eval(str)
str = "target_win.content.confirm = function() {return true}"
js_eval(str)
end

###############################################################
# Cancel all dialogs #
###############################################################

def cancel_dialogs
# Cancel dialogs
# this method must be send before to handle a JScript Window...

str = "var win_all = getWindows();"
js_eval(str)
str = "var target_win = win_all[win_all.length-1];"
js_eval(str)
str = "var ex_con = target_win.content.confirm;"
js_eval(str)
str = "target_win.content.confirm = function() {return false}"
js_eval(str)

end

###############################################################
# Restores the browser status #
###############################################################

def restore_browser_dialogs
# Restore Dialogs
# this method fix up the dialog windows
str = "var win_all = getWindows();"
js_eval(str)
str = "var target_win = win_all[win_all.length-1];"
js_eval(str)
str = "target_win.content.confirm = ex_con;"
js_eval(str)

end

}

end
###############################################################

Con este simple método incluimos funcionalidades para aceptar o cancelar diálogos en Firefox o IE. El uso es sencillo, se debe llamar a "accept_dialog" o "cancel_dialog" antes de que estos se ejecuten, y luego de la ejecución se debe llamar a restore_browser_dialogs para restaurar la configuración del browser. La solución es sencilla pero muy útil.

Ej de uso:

###############################################################
require "watir"
require "watir_addon"


#... Inicialización de Browser ...
watirAddOn
# más instrucciones
accept_dialogs
restore_browser_dialogs
# más instrucciones

# fin de script
###############################################################

Ese sería el ejemplo en pseudo código, recordar que Watir Add On hace referencia a la variable browser, próximamente publicaré la modificación de la clase para que no dependa de la variable browser.

Watir / Selenium

2
Muchas de las inquietudes que existen alrededor de el area de QC es que herramientas son las ideales para poder automatizar las tareas diarias. Aunque existen una cantidad importante de herramientas, entre ellas pagas y otras open source; por mi parte prefiero optar por las herramientas que son libres para la comunidad, entre ellas destaco: Watir y Selenium.

Aunque a Selenium no la utilice en Java, si utilizo la gema para Ruby con la cual estoy diseñando un framework ideado para automatizar de forma sencilla.
Watir solamente se encuentra en Ruby por lo que su potencial solo puede apreciarse en este lenguaje.

De por si Ruby es sencillo de utilizar, simple sintaxis y abierto a cualquier cambio, sencillo para realizar scripts con metaprogramación.

Aquí voy a proponer soluciones simples basandome en ambas herramientas, por ejemplo con un set de datos leido desde un archivo excel, yaml, etc.; y cada script sera codificado para ambos drivers.