Diagrama

1. Introducción y alta tarea en JIRA

La Tareas QA para las "pruebas de carga y estabilidad" de una aplicación se compone de dos tareas principales:

• Realización de pruebas de carga en local: Diseño de las pruebas de carga, ejecución en local y validación de los test realizados. Para ello se deberán adjuntar las evidencias  generadas, que deberán ser validadas por un revisor de MNCS.
• Realización de pruebas de carga con el equipo de sistemas: Una que un revisor de MNCS haya validado las pruebas en el entorno local se podrá realizar esta tarea, que consiste en el lanzamiento de los test en el entorno de preproducción (Test) para lo cual hay que concertar una cita con personal de sistemas y base de datos.

Su objetivo es asegurar que cuando nuestro proyecto esté desplegado en producción no habrá problemas de rendimiento derivados del uso del mismo por parte de los usuarios y/o servicios que necesiten acceder a él para realizar las diferentes gestiones que provea.

En este punto, el Responsable técnico principal o los responsables técnicos del proyecto deberán crear una Tarea QA  dentro de la Release en la que se está trabajando, para asegurar que todos los hitos QA relacionados con las "pruebas de carga y estabilidad" se han cumplido, y que el equipo encargado de supervisar y verificar las Tareas QA dé el visto bueno a los resultados aportados.

Dentro de esta tarea se deberá crear una Subtarea Test para el diseño del test de carga y pruebas en local y otra para las pruebas en el entorno de preproducción con el equipo de sistemas .

• Antes de realizar el test de carga, el miembro del equipo de desarrollo que vaya a realizar el test, deberá solicitar al equipo de telemática en sistemas que el usuario con el que realizará el test no requiera doble factor de autenticación. Para ello pondrá un Jira a DJ-AT-Telemática

• Cuando el miembro del equipo de desarrollo termine la subtarea correspondiente a las pruebas en el entorno local,  creará una petición de servicio a DJ-AT-MNCS con dicha subtarea enlazada para su validación.

• Cuando MNCS valide las pruebas en el entorno local, el miembro del equipo de desarrollo responsable creará una petición de servicio a DJ-AT-SIST-MIDDLE para realizar las pruebas con el equipo de sistemas:

Una vez realizadas todas las pruebas el miembro del equipo de desarrollo encargado de realizar la Tarea QA cerrará dicha tarea, y creará una subtarea externa que será una petición de servicio a DJ-AT-MNCS, para verificar que la recogida de evidencias ha sido correcta:

2. Diseño de los test de carga

A la hora de diseñar un test de carga debemos intentar hacer un recorrido representativo de la aplicación, no obstante este recorrido en ocasiones puede requerir inserciones y/o actualizaciones. Como regla general, las aplicaciones tienen muchas más lecturas que escrituras, y las escrituras suelen tener poca concurrencia si el número de usuarios que pueden escribir es bajo. Por lo que tenemos que estudiar cada caso y diseñar el test que más convenga.

Por cómo están estructuradas las aplicaciones en ATICA a nivel de base de datos, tenemos dos tipos aplicaciones, las que sólo insertan en una base de datos, y aplicaciones que insertan en varias bases de datos. Por tanto debemos ser conscientes del coste que podría suponer si hay que "deshacer" los cambios de un test de carga con inserciones.

En base a todo lo anterior, las aplicaciones deben realizar test de carga que mayoritariamente hagan lecturas y/o actualizaciones, evitando las inserciones. No obstante existen aplicaciones o escenarios en los que es necesario realizar las inserciones.

  Para saber qué tipo de test realizar, se debe contactar con el equipo de sistemas para acordar con ellos las características del mismo y asegurar que la prueba abarca el mayor escenario posible.

3. Realización de pruebas de carga en local

Para garantizar la correcta ejecución  y análisis de los test, las pruebas de carga deberán hacerse utilizando la versión de JMeter empaquetada por MNCS: Descarga de JMeter

El objetivo de las pruebas de carga en local es eliminar cualquier defecto en el test o en la aplicación antes de realizarlo con el equipo de sistemas. En esta prueba el miembro del equipo de desarrollo encargado diseñará y ejecutará un test contra su máquina local que, una vez terminado, MNCS validará para confirmar que la aplicación funciona correctamente. Para tal fin, el Responsable técnico creará una Subtarea Test donde se registrará este trabajo y se adjuntarán todas las evidencias recabadas con el formato indicado, en caso contrario se tendrá que repetir el test.

Para saber cómo empezar y abordar un test de carga, los miembros del equipo de desarrollo encargados de realizar las tareas deberán leer la guía "1. Cómo abordar un test de carga", donde se indican las herramientas necesarias a utilizar y las evidencias que hay que anexar a Jira para que se pueda proceder a la validación de las diferentes pruebas.

En dicho test se tendrá en cuenta: un uso estable y acotado de la memoria, unos tiempos de respuesta inferiores a 3 segundos y que no se produzcan errores en la aplicación durante su ejecución. Si alguno de los parámetros no se cumple, se tendrá que estudiar el código fuente de la aplicación para detectar y solventar los posibles problemas de funcionalidad y/o rendimiento. 

4. Realización de pruebas de carga con el equipo de sistemas

Una vez tengamos todos los parámetros de las pruebas de carga en local aceptados, se podrá proceder a realizar el test con el equipo de sistemas y bases de datos . Estos test diferirán con los anteriores en que ahora, en vez de simular una carga sin tope máximo, se establecerá un caudal constante de peticiones (JMeter Temporizador de rendimiento constante) según las indicaciones que nos de el equipo de sistemas. Este caudal está basado en datos estadísticos de años anteriores (podemos verlo en https://informesweb.atica.um.es) por lo que simularía una situación real en base a los datos que se tienen.

A la hora de establecer el número de peticiones por minuto que nos indiquen desde el equipo de sistemas, tendremos que asegurarnos que en JMeter confirmamos este caudal para todos los hilos (por defecto está sólo en el hilo actual).

En esta tarea, la información relativa al rendimiento en los servidores en el entorno de test la suministrará el equipo de sistemas. El miembro del equipo de desarrollo deberá registrar la información facilitada por JMeter en la subtarea destinada a tal fin, y asegurar que la tarea puesta al equipo de sistemas está enlazada y contiene los datos de uso de los servidores.

5. Registro de resultados de las pruebas de carga

La Tarea QA creada estará incluida dentro del espacio de Confluence del PÓRTICO, en la Release correspondiente a las fechas en las que se realizó la tarea. Toda la información sobre esta tarea y su validación deberá quedar registrada en la propia Tarea QA o en las Subtarea Test que pueda tener. En este caso serían las evidencias de las pruebas tanto en test como en local que deberán recoger las subtareas.