S09 - Evaluación de rendimiento

Contenido

CÓDIGO

S09

NOMBRE

Evaluación de rendimiento

OBJETIVO

Verificar el buen rendimiento del sistema de información ante situaciones de carga y estrés mediante la realización de diversos tipos de pruebas. Para evaluar el rendimiento y el adecuado consumo de recursos, se considerarán tanto los requisitos específicos del sistema como requisitos generales, además de los límites de consumo de recursos vigentes.
Cuando el sistema está en integración y despliegue continuo (CI/CD), siempre que sea viable estas evaluaciones se ejecutan como parte del pipeline definido, de forma completa o en parte.

ENTRADAS

1) Plan Específico de la Calidad del Sistema (PECS).
2) Plan de pruebas de rendimiento (opcional).
3) Scripts de pruebas de rendimiento, si existen (opcional)
4) Requisitos de rendimiento específicos del sistema (opcional).
5) Conjunto de datos de pruebas necesarios para la correcta ejecución del servicio (opcional).
6) Acceso al sistema de información desplegado en un entorno de pruebas similar al de producción aislado de actuaciones de terceros durante la ejecución de las pruebas.
7) Si las evaluaciones están automatizadas, acceso al pipeline en la plataforma CI/CD y al resto de herramientas en las que se sustenta la automatización.

SALIDAS

1) Informe del resultado con detalle de todas las pautas de evaluación realizadas, incluyendo recomendaciones.
2) Plan de pruebas de Rendimiento actualizado, si procede.
3) Scripts de pruebas de rendimiento actualizados, si procede.
4) Actualización del sistema en la herramienta HRC detallada en el Plan General de Calidad.
5) Defectos registrados en la herramienta correspondiente, si procede.

RESULTADO

- Un resultado Superado significa que se cumplen los requisitos generales mínimos recomendados (se detallan a continuación) y los requisitos específicos si los hubiera, en todas las pruebas contempladas en la evaluación del rendimiento del sistema detalladas en las pautas de evaluación.
- Un resultado Superado con reservas significa que, pese a que no se han seguido todas las directrices de acuerdo a los mínimos, sí se ha logrado para las más prioritarias.
- Un resultado No superado significa que no se han seguido las recomendaciones, al menos, en una de las consideradas prioritarias.

Requisitos generales mínimos recomendados:
- No existen operaciones SLOW (operaciones o transacciones que destaquen sobre el resto en cuanto a un pobre rendimiento se refiere. Es decir, mucho más lentas que la media).
- No hay degradación del sistema por problemas con la liberación de los recursos no utilizados, especialmente con la memoria (memory leak).
- No se observa lentitud significativa en las transacciones, aunque se pueda seguir trabajando con el sistema.
- El tiempo de respuesta, así como el tiempo de carga es el esperado según los estándares de sistemas análogos.
- El consumo de recursos como la CPU, la memoria y el espacio en disco es el esperado, según los estándares de sistemas análogos.
- No se identifican otros comportamientos, además de los previstos que, desaconsejen el uso del sistema.

CADUCIDAD

24 meses

PAUTAS DE EVALUACIÓN

ID.DESCRIPCIÓNSEVERIDADOBSERVACIONES

Según lo indicado en los requisitos de rendimiento específicos del sistema o siguiendo estándares de sistemas análogos en su defecto, las pruebas simulan diferentes escenarios, en los que se varían número de usuarios concurrentes, duración de la prueba y ritmo de incremento de usuarios concurrentes. A los que se añadirán, según el caso, otros parámetros como el tamaño de los ficheros o documentos intercambiados, el volumen de datos a manejar en las consultas y/o búsquedas, etc.


Durante estas pruebas se monitorizarán las siguientes características: funcionamiento ante un volumen de datos mínimo, rendimiento, estabilidad, pruebas con nivel de carga máximo, estrés (por capacidad o por sobrecarga) y consumo de recursos del sistema.


Las pruebas de rendimiento, en general, se deben realizar a partir de escenarios automatizados y para ello se elabora un Plan de Pruebas de Rendimiento que debe cubrir los circuitos funcionales más habituales, aquellas partes del sistema que serán más críticas y los puntos en los cuales se manejan mayor número de datos o transacciones. Este plan debe cumplir:

  • Ser configurable, de modo que permita simular todos los escenarios posibles, ajustando su configuración. 
  • Debe identificar las funcionalidades en diversos bloques, de modo que se pueda variar el alcance de las pruebas cuando sea necesario, activando y desactivando bloques.
  • Debe estar diseñado para que se puedan ejecutar n-veces. Ya sea incluyendo borrado de datos manipulados o siendo precedidos de la creación o consulta de datos válidos, que se usen posteriormente en el proceso completo.

En esta actividad se generarán, además del plan de pruebas, el conjunto de scripts necesarios para automatizar las pruebas.

C01

Prueba de Estrés:
Se realizan diferentes pruebas de carga, habitualmente de corta duración, con un aumento progresivo del número de sesiones de usuario que acceden simultáneamente al sistema. El objetivo es conocer el número máximo de sesiones de usuario simultáneas que admite el sistema, dentro de unas condiciones que previamente se habrán fijado, siempre que se pueda:

  • Un tiempo de respuesta determinado.
  • Un determinado porcentaje de error en las pruebas.

En función de estas condiciones se establecerán los siguientes casos en las pruebas de estrés:

  • Caso Óptimo: es el número máximo de sesiones de usuario en un período determinado para los que el sistema no presenta ningún contratiempo o problema en su rendimiento.
  • Caso Crítico: es el número aproximado de sesiones de usuario para los que el sistema sigue funcionando, pero el rendimiento se ve afectado.
  • Caso de Saturación: número de usuarios a partir del cual el sistema deja de funcionar.
ALTAEn caso de no disponer de un Plan de pruebas, puede solicitar el servicio de apoyo "Elaboración y Evolución de Planes de Prueba".
C02Prueba de Fiabilidad:
Consiste en una prueba de rendimiento cuya ejecución se mantiene durante un periodo de tiempo prolongado. El número de sesiones de usuarios utilizadas en la prueba es un dato que estará definido en los objetivos del sistema o bien puede utilizarse la cifra obtenida como "Caso Óptimo" al haber realizado previamente las pruebas de Estrés.
Es una prueba de especial interés para sistemas que van a dar servicio de manera continuada, con un nivel de carga que pueda considerarse más o menos constante.
ALTA
C03Prueba de Picos:
Consiste en el lanzamiento de una prueba de rendimiento con un número fijo de sesiones de usuario, e introduciendo de forma intercalada picos de carga durante el transcurso de la misma. Trata de observar el comportamiento del sistema variando la carga de forma puntual a partir de un número de usuarios base, tanto disminución como aumentos drásticos en la carga. La prueba debe comenzarse y finalizarse precisamente con este número fijo de sesiones.
La finalidad de la prueba es verificar que los cambios de carga a los que se sometería al Sistema en Producción no afectan al rendimiento verificado en las pruebas de Estrés, es decir, que una vez finalizadas las subidas y bajadas de carga, la respuesta del Sistema prácticamente no varía respecto al estado inicial.
ALTA
C04

Prueba de Escalabilidad:
En este caso, se realizan una serie de pruebas de rendimiento (normalmente, de estrés) atacando a una arquitectura variable del sistema. La forma de ejecutar esta prueba variará según las necesidades del proyecto y/o la respuesta de la infraestructura.
Mediante este tipo de pruebas, se pueden hacer 2 tipos de estudios:

  • Análisis del producto software, identificando defectos relacionados con el desarrollo, que podrán identificarse a nivel de base de datos, software, interfaces, etc.
  • Análisis de la infraestructura, verificando si ésta es la más adecuada para el propósito que se pretende con el sistema. Es decir, se podrá realizar la ejecución de distintos escenarios mediante los que se podrá determinar la escalabilidad vertical (se aumentarán los recursos hardware) o la horizontal (se aumentarán los nodos del servidor), en base al estudio continuo de la infraestructura durante las pruebas.
ALTA

FECHA ACTUALIZACIÓN

21/10/2024

Índice