Diagrama
1. Introducción y alta tarea en JIRA
Las Tareas QA pruebas de carga y estabilidad sobre nuestras aplicaciones se componen 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 MNCS.
- Realización de pruebas de carga con el departamento de sistemas : Una vez validadas, por parte de MNCS, las pruebas en el entorno local se podrá realizar esta tarea, que consiste en el lanzamiento de los test en los entornos de preproducción 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 el código fuente se han cumplido y que el equipo encargado de supervisar y verificar las Tareas QA de el visto bueno a los resultados aportados.
Alta tarea JIRA: "NOMBRE_APLICACION: Pruebas de carga" | |||
---|---|---|---|
Tipo de tarea: | "Tarea QA" / "Subtarea Test" | Pórtico: | Asociado al Proyecto |
Disciplina: | "P9. Gestión de la calidad del software" | Proceso: | "Realizar pruebas de carga" |
Etiqueta: | sdaym_test_carga | Versión correctora: | Versión correspondiente a la Release en la que estamos. |
Fecha vencimiento | Fecha prevista puesta en producción |
Dentro de esta tarea se deberá crear una Subtarea Test para el diseño del test de carga y para las pruebas en el entorno de preproducción con el departamento de sistemas .
- Antes de realizar el test de carga el miembro del equipo de desarrollo que vaya a realizar el test deberá solicitar a telemática 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
Alta tarea JIRA: "Revisión QA: NOMBRE_APLICACION Pruebas de carga" | |||
---|---|---|---|
Proyecto | DJ-AT-SIST-Telemática (TLMS) | ||
Tipo de tarea: | "Petición de servicio" | ||
Descripción: | Permitir login sin 2FA para el/los usuarios: xxxxxxx |
- 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.
Alta tarea JIRA: "Revisión QA: NOMBRE_APLICACION Pruebas de carga" | |||
---|---|---|---|
Proyecto | DJ-AT-MNCS | ||
Tipo de tarea: | "Petición de servicio" | ||
Descripción: | Revisión de pruebas de carga |
- 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 departamento de sistemas
Alta tarea JIRA: "Revisión QA: NOMBRE_APLICACION Realización de pruebas de carga" | |||
---|---|---|---|
Proyecto | DJ-AT-SIS-MIDDLE | ||
Tipo de tarea: | "Petición de servicio" | ||
Descripción: | Realización de pruebas de carga en entorno de test |
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. El contenido del Jira a crear es el
Alta tarea JIRA: "Revisión QA: NOMBRE_APLICACION Validación pruebas de carga" | |||
---|---|---|---|
Proyecto | DJ-AT-MNCS | ||
Tipo de tarea: | "Petición de servicio" | ||
Descripción: | Validación de las pruebas de carga |
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 éste 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 que sólo insertan en una base de datos, aplicaciones que insertan en varias bases de datos. Por tanto debemos ser conscientes del coste que podría "deshacer" los cambios de un test de carga con inserciones.
En base a todo lo anterior, las aplicaciones deben realizar test que mayoritariamente hagan lecturas y/o actualizaciones, evitando las inserciones. No obstante existen aplicaciones o escenarios en los que es necesario realizar las inserciones, en esos casos deberán realizarse.
Para saber qué tipo de test realizar, se debe contactar con el departamento 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 el de eliminar cualquier defecto en el test o en la aplicación antes de realizarlo con el departamento 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 en esta guía 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 departamento 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 departamento 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 departamento 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 departamento 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 departamento 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 departamento 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á reflejada 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