Testing Publianuncios

Como sucede con todo el software desarrollado profesionalmente, también es necesario hacer pruebas de las aplicaciones web. Independientemente de las pruebas de la lógica de la aplicación, en desarrollo web interesan dos tipos de pruebas especialmente: las pruebas funcionales y las de rendimiento o performance.

Pruebas funcionales

Las pruebas funcionales se realizan con Selenium, una herramienta diseñada para la captura de eventos sobre el navegador y su almacenamiento en forma de scripts. Posteriormente, estos scripts pueden ser reejecutados para realizar pruebas de regresión o pueden exportarse en varios lenguajes para modificarlos.

Se van a planificar pruebas de varios escenarios: Login, logout, registro, carga de ubicaciones, chat y creación de anuncios con contenido multimedia incluido. Además, se realizarán tests funcionales del Broker.

Los archivos implementados se encuentran tanto en src/test como en la carpeta Testing del repositorio.

Broker

El Broker es el agente que gestionará las conexiones necesarias con la BBDD. Incluye un Pool de conexiones. Por tanto, sus pruebas consisten, principalmente, en asegurar el funcionamiento de la apertura de conexiones con el Pool, la selección y la inserción en la BBDD.

El primer test, AperturaConexiones, abrirá conexiones tanto de seleccion como de inserción, hasta un máximo predefinido en el Pool de conexiones. Si ha abierto la cantidad exacta del máximo, el test es satisfactorio.

Los siguientes tests del Broker son los de Inserción y Selección. El test de inserción probará a insertar cadenas aleatorias en una tabla de la BBDD, el de selección leerá de la BBDD las cadenas introducidas anteriormente. En ambos se medirá el tiempo invertido en la tarea.

Login

Es momento de realizar las pruebas sobre la aplicación. El primer escenario a grabar con Selenium es el de Login. Tras hacer la grabación se repetirá el test con la propia herramienta:

Si es satisfactorio se exportará para poder modificarlo y hacer pruebas con JUnit.

Hay que añadir pequeños periodos de tiempo entre ciertas instrucciones para que al hacer los tests no intente, por ejemplo, pulsar un botón antes de que haya cargado la página. Además, se deben insertar asserts para comprobar que lo que se espera y lo que efectivamente sucede es lo mismo.

En este caso, el test prueba que, en caso de hacer un login que debe ser correcto, la alerta lo anuncia como tal; y en caso contrario, muestra el error. También se ha parametrizado la clase para poder probar varios grupos de valores.

Se ha implementado otro test de Logout para comprobar que el usuario es capaz de cerrar sesión. Es similar al de login, pero en esta ocasión, de un login que debe resultar correcto, el usuario debe poder tener acceso al menú "logout", mientras que un usuario mal identificado no lo puede hacer.

Registro

El segundo escenario es el de Registro. Si el usuario consigue registrarse, el alert debe ser satisfactorio. En caso contrario, advertir del error.

Para facilitar la repetición de los tests, el propio test borrará de la BBDD el usuario que acaba de crear.

Chat

El escenario del Chat se ha probado haciendo dos conexiones, en diferentes pestañas de un explorador. En cada una de ellas se ha identificado un usuario. El test es satisfactorio si al escribir un mensaje desde una de las pestañas, en la otra pestaña el otro usuario puede leer el mensaje.

Carga de Ubicaciones

La carga de ubicaciones debe funcionar a la perfección pues se necesita para filtrar anuncios en en índice y para registrar a un usuario. Por ello se ha hecho testing para comprobar su correcto funcionamiento. Se han hecho 3 tests:

• Test de carga de CCAA. Se ha comprobado que la caja de CCAA tiene todas las comunidades.
• Test de carga de Provincias. Se ha comprobado que al seleccionar una CCAA se cargan todas sus provincias.
• Test de carga de Municipios. Se ha comprobado que al seleccionar una provincia se cargan todos sus municipios.

Crear Anuncio

Por último, se ha realizado el test para crear un anuncio. El anuncio, además, incluye contenido multimedia. Si el usuario está identificado y se consigue crear un anuncio con su precio, descripción, su categoría, y el contenido multimedia asociado y además al volver a la página principal se encuentra insertado, el test resultará satisfactorio.

Para facilitar la repetición de los tests, el anuncio se creará con una cadena aleatoria como descripción.

#Pruebas de rendimiento

Las pruebas de rendimiento se realizan con la herramienta JMeter. El objetivo será definir un Test Plan o Plan de Pruebas que contendrá grupos de hilos donde se establece el número de hilos (usuarios virtuales) que ejecutarán las tareas, así como el tiempo total y el número de veces que se ejecutarán.

El primer paso será crear un HTTP Test Script Recorder para grabar las tareas, en este caso de login, utilizando un proxy por el puerto 9000 para capturarlas. Los archivos resultantes de las pruebas con JMeter se encuentran en la carpeta Testing del repositorio.

Luego se creará un grupo de hilos donde se añadirán las tareas que se han grabado, se configurará para que ejecute, de momento 20 usuarios en dos segundos. Los resultados obtenidos han sido:

Se puede ver cómo no se han encontrado errores y se han hecho 20 peticiones a varios recursos, entre ellos al CentroDePublicidad (con labels CentroDePublicidad/enviarAnuncio.jsp y /250/150/xxx/n), que es el que sirve a la página para colocar anuncios en los laterales. Esos anuncios contienen imágenes, por lo que la tarea no es simple. Como resumen:

• Las peticiones al centro de anuncios, que contienen imágenes que están alojadas en una página web externa, son las más pesadas, por lo que la media es mayor (entre 98 y 211 milisegundos).

• En cuanto al resto de peticiones, las que han necesitado más tiempo han sido la que identifica al usuario, las cargas de las ubicaciones, y con menos tiempo, los formularios.

Se ha probado el mismo test con un mayor número de usuarios, 100. Cuando se alcanza la cifra de 150 los errores empiezan a aparecer y hay que parar el grupo de hilos.

El segundo escenario que se puede probar es el de crear un anuncio. En éste, el usuario debe añadir una foto al anuncio, por lo que se estima que requiere más tiempo.

Al igual que en el caso de prueba anterior, se ha probado con 20 usuarios agregando anuncios al mismo tiempo, obteniendo como resultado:

El porcentaje de error es casi nulo y no proviene de peticiones a la página a probar. Con una media de 177 milisegundos, la petición de subir el anuncio es la que más tiempo necesita (exceptuando las peticiones antes mencionadas a las fotos de la web externa).

Si se ejecuta el grupo de hilos con 100 usuarios se notan algunos cambios, como que existe, aunque pequeño, un porcentaje de errores, al intentar identificar.

A pesar de esos pequeños fallos, se han podido agregar la mayoría de los anuncios correctamente. En esta ocasión, la tarea que requiere más tiempo es la de subir el anuncio, superando a la de subir la foto en el tiempo medio, pero no en el máximo, donde se supone que la tarea de subir foto se hace más ardua proporcionalmente al aumento de usuarios.

Para realizar el tercer escenario, registrarse, se ha creado sólo un grupo de hilos de 20 usuarios, ya que con 100 usuarios el porcentaje de errores es muy alto. Incluso en este caso el porcentaje de errores es más alto que en los anteriores escenarios, ya que no se han conseguido mostrar algunas imágenes de la publicidad externa. A pesar de ello, la tarea principal se ha llevado a cabo sin problemas.

Con una media de 2856 milisegundos, la tarea del envio de la petición del registro es la que más tiempo necesita de todos los escenarios.

Volver al índice