Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad

Cumplimiento normativo

Histórico de cambios

Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.

Introducción

La normativa que a continuación se detalla muestra la metodología a seguir para llevar a cabo las pruebas de carga del sistema sobre los diferentes aplicativos basados en los modelos de arquitectura tecnológica de referencia publicados en Confluence.

En la metodología se muestra el flujo genérico que se debe seguir para planificar y ejecutar correctamente las pruebas de carga del sistema desde el inicio del desarrollo hasta su validación.

De esta forma, se indican el conjunto de pruebas fundamentales necesarias para garantizar el correcto funcionamiento y rendimiento, previo a la entrada a producción, de una nueva aplicación o de una evolución de un producto existente. Consta de los siguientes elementos:

1. Prerrequisitos: Los elementos y herramientas necesarias para poder implementar las pruebas.
2. Pruebas de comunicación: Comprobación del entorno objetivo para las pruebas por parte del lanzador.
3. Línea base: Establecimiento del conjunto inicial de datos necesario para la restauración del punto inicial en cada prueba.
4. Pruebas de capacidad: Determinan los parámetros de concurrencia para el resto de las pruebas.
5. Pruebas de rendimiento: Determinan el correcto funcionamiento del aplicativo con la carga en los distintos niveles de concurrencia definidos.
6. Pruebas de estrés: Se ejecuta la prueba con concurrencia incremental hasta el punto de saturación del aplicativo o aplicativos con respecto al entorno objetivo. Se mide también la recuperación del sistema.
7. Pruebas sostenidas: Comprueba el correcto funcionamiento y la ausencia de degradación del aplicativo durante un período de tiempo prolongado.
8. Pruebas sostenidas con tolerancia a fallos: Comprueba el impacto sobre el funcionamiento del aplicativo o aplicativos con operativas sobre determinados componentes del entorno: caída de una instancia de base de datos, caída de una instancia del servidor de aplicaciones o réplica de la aplicación, etc.
9. Conclusiones: Conjunto de conclusiones obtenidas a partir de los resultados e interpretaciones de las pruebas realizadas.

Esta normativa se limita exclusivamente al proceso a seguir para la ejecución de pruebas de carga del sistema, no siendo responsabilidad de esta normativa el resto de flujos que intervienen en el proceso de creación de un nuevo software. Su propósito por tanto es que sirva de guía para el usuario que se encarga de gestionar o ejecutar las pruebas de carga del sistema, existiendo un documento adicional que hará de plantilla, siendo dicha plantilla el documento que realmente deberán entregar a la STIC los proveedores de los aplicativos con los resultados de las pruebas obtenidas.

Actores

A continuación, se indican los actores partícipes en la metodología y su etiqueta que determina el liderazgo en cada proceso de la metodología:

Flujo de trabajo

Es importante tener muy en cuenta las pruebas de carga de nuestros sistemas de información desde una fase temprana del desarrollo, estando seguros de los requisitos de rendimiento necesarios para la aceptación del producto por parte del SAS, y reservando el espacio de tiempo oportuno para poder llevar a cabo correctamente el conjunto de pruebas del sistema.

La responsabilidad de la coordinación del proceso de pruebas será labor de la OCA actuando como intermediario entre el proveedor de desarrollo, Sistemas y las diferentes áreas técnicas y de gestión de la STIC. 

En el siguiente diagrama se puede ver una foto global del procedimiento a seguir para la planificación y ejecución de pruebas de sistemas sobre un sistema de información:

Las actividades descritas en este flujo son:

• Nuevo desarrollo: Es el disparador del proceso, se refiere al momento, al inicio de un desarrollo, en el que surge la necesidad de realizar una estimación de un nuevo desarrollo. Ya desde el principio es muy importante tener en cuenta las pruebas de carga del sistema.
• Definición de requisitos de rendimiento/volumetría y casos de uso: Es responsabilidad del jefe de proyecto del sistema el acordar con los responsables funcionales así como con las distintas áreas técnicas de la STIC las necesidades y requerimientos de rendimiento que debe cumplir el sistema. Como resultado de este proceso, se obtendrán el apartado de métricas y los anexos I y II.
• Validación volumetría y casos de uso: El Área de Gobernanza validará la inclusión de requisitos de rendimiento/volumetría, su relevancia y que estos sean verificables con los casos de uso que se hayan incluido en el plan de pruebas.
• Estimación del desarrollo y pruebas de carga: El proveedor es el responsable de realizar la estimación que vea oportuna para el desarrollo del producto, incluyendo en dicha estimación el tiempo necesario para realizar las pruebas de carga aquí descritas.
• Estimación pruebas de alta disponibilidad: Sistemas realizará una estimación sobre el tiempo que necesita para hacer pruebas de alta disponibilidad. Esta planificación será añadida a la estimación global.
• Planificación pruebas de carga: La Oficina de Calidad realizará la coordinación entre las diferentes partes (Sistemas y el Proveedor) de la realización de las pruebas de carga.
• Preparación de entornos: Sistemas es el responsable de asegurar que el entorno de pruebas necesario estará correctamente configurado de acuerdo a las especificaciones indicadas en el DGT del producto. Igualmente, Sistemas deberá asegurar la integridad del entorno durante toda la fase de pruebas de carga.
• Validación de requisitos previos: Tanto el proveedor como Sistemas deberá revisar el conjunto de requisitos previos explicados en el presente documento con el fin de asegurar el correcto estado del entorno y poder así iniciar los ciclos de pruebas de carga del sistema.
• Ejecución de las pruebas de carga: Se refiere a la ejecución de forma ordenada de los diferentes tipos de pruebas de carga explicados en el presente documento.
• Análisis de resultados: El proveedor revisará y analizará los resultados de las pruebas de carga ejecutadas, transmitiendo al jefe de proyecto los resultados obtenidos de cara a decidir si continuar con el proceso de pruebas o abortar el ciclo. Es necesaria una explicación clara de lo que indica cada tabla / gráfica, tanto por parte del proveedor, como de CTI,  por lo que cada una de las tablas / gráficas, deberá venir personalizada incluyendo una explicación de los datos que se están arrojando.
• Ejecución línea base del entorno: Sistemas ejecutará el procedimiento necesario para restaurar el entorno a su punto inicial y poder así iniciar un nuevo ciclo de pruebas.
• Revisión informe de resultados: El Área de Gobernanza revisará el informe de resultados de las pruebas de carga realizadas.
• ¿Se aceptan los resultados?: Se refiere a la aprobación por parte del jefe de proyecto de las pruebas ejecutadas hasta el momento, debiendo decidir entre continuar con las pruebas de carga, dar por finalizada la fase de pruebas, ya sea por haber llegado al último ciclo o por no tener resultados satisfactorios.
• Optimización de la estructura: Se refiere al proceso de ajustes y optimización por parte de Sistemas de la infraestructura ofrecida con el fin de solucionar posibles problemas de rendimiento o funcionamiento encontrados durante las pruebas de carga.
• Optimización del software: Se refiere al proceso de ajustes y optimización del software por parte del proveedor con el fin de solucionar posibles problemas de rendimiento o funcionamiento encontrados durante las pruebas de carga.

Plan de pruebas

Diseño

Uno de los aspectos más importante a la hora de plantear unas pruebas de carga del sistema es hacer un buen diseño de las pruebas a realizar, ya que estas deben ser representativas de la situación real del producto, esto es:

• Casos de Usos: Se deben identificar los casos de usos más representativos del sistema, aquellos usados con más frecuencia así como los casos de uso de nueva incorporación.
• Volumetría: Es imprescindible la definición de una volumetría semejante a la que se espera recibir en producción, ya que establecer una carga muy diferente (ya sea por encima o por debajo) no será representativo del estrés real que sufrirá la aplicación, haciendo que las pruebas realizadas no sean representativas.
• Diseño de lanzadores de pruebas: En la medida de lo posible, se debe añadir en las herramientas de pruebas aquellos controles necesarios para validar que el resultado obtenido en cada petición es el esperado (Por ejemplo, aserciones en jMeter).
• Pruebas conectadas o desconectadas: Un aspecto clave a la hora de diseñar un buen plan de pruebas de carga del sistema es decidir qué situación es más representativa con respecto a la situación real que vamos a encontrarnos en producción. En general, puede tener más sentido hacer pruebas de carga desconectadas (Donde la aplicación testeada no se conectará con terceras aplicaciones o lo hará mediante simuladores), pero la STIC junto al proveedor deberá decidir si tiene más sentido hacer pruebas de carga conectadas (Por ejemplo, cuando se está probando una aplicación en la que la mayor parte de sus funcionalidades hacen uso de servicios ofrecidos por terceras aplicaciones).

Planificación

Como un aspecto fundamental a la hora de diseñar un plan de pruebas de carga del sistema, debemos tener en cuenta los distintos tipos de pruebas necesarios para llevar a cabo el ciclo de pruebas completo. Por ello, en la siguiente captura se muestra una plantilla a modo de ejemplo con los ítems que deben ser recogidos en la planificación de cualquier producto que vaya a realizar pruebas de carga.

Para iniciar el proceso de lanzamiento de pruebas de carga del sistema será necesario enviar correo electrónico a l-pruebasderendimiento.stic.sspa@juntadeandalucia.es con la siguiente información:

• Planificación detallada por tipo de prueba a realizar (se puede hacer referencia al apartado planificación del PPS). Debe incluir las pruebas de alta disponibilidad (sostenidas con tolerancia a fallos).
• Horario en el que se realizarán las pruebas, es importante indicar la franja horaria en la que se realizan las pruebas para poder contar con el soporte de Sistemas y sobre todo sí estas se realizan fuera de horario laboral (por ejemplo las cargas sostenidas se suelen hacer los fines de semana).
• Nº de máquinas lanzadoras (controladora + agentes) necesarias para la realización de las pruebas.
• Usuario DMSAS-TEST que realizará las pruebas, se utilizará para conceder el acceso a las máquinas.
• Software y versión necesario para realizar la pruebas.
• Aplicaciones afectadas por las pruebas de carga de sistemas, es necesario indicar las integraciones con aplicaciones que se realizan durante las pruebas. 
• PPS, adjuntar en el correo el enlace al artículo Confluence del plan de pruebas de carga de sistemas actualizado.

El correo se debe enviar con al menos un mes de antelación a la fecha prevista de inicio de las pruebas.

Una vez el Área de Gobernanza reciba la solicitud de ejecución de pruebas de rendimiento y estudie su viabilidad, realizará petición CGES a CTI para la asignación de las máquinas lanzadoras a los proveedores para así ejercer el control de la asignación de éstas durante todo el periodo de pruebas. Esta asignación será por un periodo de tiempo determinado y de manera nominal (preferiblemente del usuario que vaya a realizar las pruebas) y será informado mediante correo electrónico al proveedor encargado de realizar las pruebas. (Calendario)

La solicitud CGES contendrá la siguiente información:

• Motivo de la reserva.
• Usuario DMSAS-TEST que realizará las pruebas.
• Fecha inicio y fecha fin de la reserva.
• Número de máquinas.
• Nombre de las maquinas a reservar.
• Software y versión necesario para realizar la pruebas.

A continuación se muestra un diagrama con el flujo a seguir de dicha petición CGES:

Si por algún motivo justificado fuese necesaria una prórroga del tiempo establecido inicialmente en la petición CGES, el usuario encargado de realizar las pruebas y que tiene asignadas las máquinas lanzadoras deberá solicitar mediante un correo electrónico a "l-pruebasderendimiento.stic.sspa@juntadeandalucia.es" una ampliación del tiempo de asignación. Dicha solicitud de prórroga será tramitada por la OCA según el flujo anterior, informando al ejecutor de las pruebas sobre la resolución de la misma.

Una vez finalizado el periodo de asignación de las máquinas lanzadoras y tras confirmación por parte del proveedor que las pruebas han finalizado, la OCA devolverá la petición CGES a CTI para que proceda a la desasignación de las mismas:

• Se quitan los permisos al usuario DMSAS.
• Se elimina su perfil y se desinstala el software solicitado.

Todas las máquinas se encuentran alojadas en el entorno de preproducción.

El usuario que realiza las pruebas no tendrá en ningún momento permisos de administración sobre las máquinas lanzadoras.

En caso de ser necesario el reinicio de las máquinas lanzadoras, el proveedor generará una petición CGES la cual será asignada a CTI para que resuelva lo antes posible dicha petición y no produzca ninguna demora en la realización de las pruebas. Dicha petición CGES debe ser informada mediante correo electrónico a la lista l-pruebasderendimiento.stic.sspa@juntadeandalucia.es

Prerrequisitos

Los prerrequisitos son los elementos necesarios para una correcta ejecución de las pruebas. Es un proceso iterativo hasta que todos los actores acuerden los mismos y sean aceptados por la STIC.

Aunque no todo el conjunto de prerrequisitos dependen exclusivamente del proveedor, si será responsabilidad del proveedor las tareas de gestión necesarias para desbloquear los posibles impedimentos que pueda encontrarse al iniciar el proceso de pruebas del sistema.

En la siguiente tabla se muestra el conjunto de prerrequisitos que el proveedor deberá validar y marcar como revisado. En el caso de no poder validar algunos de los requisitos deberá contactar con el coordinador de las pruebas:

Validación de las comunicaciones

Las pruebas de comunicación son necesarias para que el PROVEEDOR pueda interactuar con el entorno y pueda probar las comunicaciones necesarias para las pruebas. Es un proceso iterativo hasta que el PROVEEDOR considere necesario.

Es importante no confundir con las comunicaciones entre aplicativos que los sistemas podrían realizar, estas pruebas se refieren SOLO a las pruebas que el proveedor necesita realizar para poder acceder a la herramienta y poder así hacer un seguimiento de las pruebas de carga realizadas.

La siguiente tabla muestra el listado de comprobaciones realizadas:

[Ejemplo. Reemplazar por tabla real]

Línea base del entorno

En este proceso se recogen las tareas necesarias para poder reproducir el entorno original antes de cualquier prueba de carga. El responsable de ejecutar las tareas de este proceso es Sistemas, pero será responsabilidad del PROVEEDOR el definir los pasos que necesita ejecutar para la restauración del entorno.

Las tareas son las siguientes:

[En caso de necesitar tareas adicionales, estas deben ser indicadas aquí

Ejemplo: Si la prueba va a generar cambios en otras aplicaciones, se debe hacer backup de esa otra aplicación para poder restaurarla en caso de ser necesario.]

Métricas y requisitos

Uno de los primeros pasos a realizar a la hora de abordar un conjunto de pruebas de carga de un sistema es identificar correctamente el conjunto de pruebas y métricas, de forma que sea lo suficientemente representativas para reflejar fielmente el funcionamiento del sistema ante una elevada carga de usuarios.

Por ello, uno de los requisitos obligatorios será que el nuevo desarrollo sea capaz de soportar la carga de usuarios a los que deberá dar servicio. Los umbrales a superar serán:

• En el caso de productos que ya están en producción o que reemplacen a alguno existente conservando, en su mayor parte, su funcionalidad, el desarrollo deberá soportar una carga de transacciones que sea un 25% superior a la carga máxima recibida en horario de trabajo indicada en el Anexo I. Como norma general, se considerará el periodo comprendido entre las 9:00 y las 14:00 de lunes a viernes como horario de trabajo o los 6 intervalos de 1 hora con mayor carga si estos no coinciden con el horario de trabajo habitual.
• Para los productos que no estén en producción también se establecerá un 25% superior a la estimación inicial realizada por el proveedor indicada en el Anexo I.

Se proponen dos conjuntos de posibles métricas a realizar dependiendo del tipo de prueba a realizar, definiendo en función del caso un conjunto de métricas básicas a medir.

Las métricas básicas se refieren al conjunto de métricas dirigidas a medir los tiempos de respuestas y buen funcionamiento del sistema. Estas métricas deben ser medidas en las diferentes tipos de pruebas que se proponen en el presente documento, debiéndose incluir en el informe final generado los resultados obtenidos en las mediciones de cada una de las pruebas.

IMPORTANTE: Es especialmente importante destacar la necesidad de diseñar indicadores de negocio específicos de cada aplicación y que serán de utilidad para conocer el buen funcionamiento del sistema y la validez de las pruebas (Por ejemplo, si estamos probando un sistema en el que sabemos que en producción se crean 1000 episodios por hora, y nuestro indicativo de "Episodios creados por hora" nos da un resultado de 100 episodios, sabemos que los resultados no son correctos, puesto que no está simulando una situación real.

Métricas básicas: API de Servicios

Las pruebas de carga del sistema orientadas a testear herramientas que principalmente ofrecen servicios web mediante API (Como por ejemplo es Maco, Estructura o BDU) deben ir dirigidas a testear cada servicio web que se ofrece.

Este tipo de servicios se caracterizan por ser rápidos, ágiles y concretos, dedicándose a un conjunto reducido de funcionalidades específicas y obteniendo tiempos de respuesta reducidos, por lo que las exigencias en cuanto a requisitos de respuesta son mayores que el caso de aplicaciones web.

Para este tipo de aplicaciones se propone medir las siguientes métricas básicas:

Para REST:

Para Soap:

(*): Es importante tener en cuenta que los valores marcados en la presente tabla como valores objetivos se refiere al conjunto de peticiones REST o Soap de operaciones sobre datos "típicas". Si la aplicación a testear cuenta con alguna funcionalidad específica de la que se espere un tiempo de respuesta mayor, debe indicarse en la siguiente tabla, aportando en cada caso una justificación de porqué se espera un tiempo de respuesta mayor al indicado como referencia en este documento:

Métricas básicas: Aplicaciones Web

Las aplicaciones web se suelen caracterizar por contar con una división entre la capa visual y otras capas que gestionan el negocio de la aplicación. Los frameworks de desarrollo web ofrecen un conjunto de funcionalidades (gestión de la sesión, páginas cacheadas en servidor, etc.) que hacen que los tiempos de respuestas en peticiones web suelan ser superiores a las aplicaciones que ofrecen API de servicios.

En el caso de aplicaciones web, las peticiones al servidor suelen dar como resultado respuestas de mayor tamaño que las API de servicios, puesto que en la misma respuesta se debe ofrecer toda la información necesaria para representar visualmente el contenido (HTML).

Para este tipo de aplicaciones se propone medir las siguientes métricas básicas:

(*): Es importante tener en cuenta que los valores marcados en la presente tabla como valores objetivos se refiere al conjunto de peticiones de navegación típicas de cualquier aplicación web. Si la aplicación a testear cuenta con alguna funcionalidad específica de la que se espere un tiempo de respuesta mayor, debe indicarse en la siguiente tabla, aportando en cada caso una justificación de porqué se espera un tiempo de respuesta mayor al indicado como referencia en este documento:

Métricas detalladas

Este conjunto de métricas van destinadas a profundizar en el comportamiento del sistema desde un punto de vista de sistemas, donde se pretende analizar que los diferentes componentes internos que forman parte de la arquitectura del sistema (Servidor, bases de datos, conexiones, etc.) funcionan correctamente.

El resultado de las mediciones obtenidas debe analizarse en las diferentes pruebas, debiéndose incluir en este informe las anomalías que se encuentren en dicho análisis. Igualmente, el proveedor podrá incluir en cualquiera de las pruebas el resultado de una o varias de estas métricas si lo considera necesario para comprender el informe generado.

Las métricas establecidas para esta prueba son:

Pruebas de capacidad

Se trata de la ejecución de casos de uso conjuntos y con concurrencia escalable de usuarios y con incremento paulatino de forma iterativa en un escenario de duración determinada a petición del PROVEEDOR. Si se dispone de datos de carga (Volumetría) de un sistema preexistente, se recomienda que la duración del lanzamiento sea la misma para facilitar la comparación de los resultados obtenidos. Por ejemplo, si los datos de volumetría de los que se dispone vienen agrupados en periodos de una hora (accesos por hora), la duración de la ejecución debiera ser de una hora.

El objetivo de estas pruebas es buscar los parámetros de configuración adecuados para los lanzadores de pruebas (jMeter), realizándose una carga progresiva sobre los sistemas a probar en busca del punto de carga máximo sin degradar el servicio, es decir, sin dejar de cumplir los requisitos particulares del sistema y las métricas establecidas. De nuevo, para facilitar la comparación de los datos obtenidos, si los datos de volumetría de los que se dispone vienen expresados en base a una métrica (p. ej.: peticiones por segundo), los datos del punto de carga máximo deberían expresarse en la misma métrica. Con el objetivo de armonizar los resultados y, teniendo en cuenta la información que recopila JMeter en sus informes, se propone la Productividad (Transacciones/s) como métrica para la volumetría y el punto de carga máximo.

Debido a que los niveles de concurrencia encontrados en estas pruebas serán la base para las siguientes pruebas, una vez encontrado el punto máximo de carga sobre un sistema, es necesario ejecutar el plan de pruebas una segunda vez para confirmar que los datos observados son correctos.

La iteración del proceso dependerá de la autorización de la STIC, los problemas encontrados que necesiten algún ajuste, o que el PROVEEDOR no haya encontrado aún los niveles de concurrencia.

Resultados obtenidos

[El presente apartado se muestra únicamente a modo de ejemplo, debiendo ser cumplimentado al COMPLETO por el PROVEEDOR con los resultados, tanto de métricas básicas como de métricas detalladas, obtenidos en sus pruebas de carga.]

La aplicación X tiene como requisito el tener que soportar una carga máxima de 200 usuarios concurrentes, por ello se ha configurado la herramienta lanzadora para generar 100 hilos por cada uno de los 2 casos de usos programados para ser lanzado.

Es necesaria una explicación clara de lo que indica cada tabla / gráfica, tanto por parte del proveedor, como de CTI,  por lo que cada una de las tablas / gráficas, deberá venir customizada incluyendo una explicación de los datos que se están arrojando.

Tras la ejecución de la lanzadera durante 30 minutos, se ha obtenido un resultado estable de tiempos de respuestas que puede visualizarse en las siguientes gráficas (ordenada por tiempo medio de respuesta de mayor a menor):

Tras el lanzamiento de estas pruebas se realizan las siguientes comprobaciones:

• No se observan errores en el log de la aplicación

• El funcionamiento de la base de datos ha sido correcto, no detectándose cargas elevadas en CPU y Memoria.

• En los servidores de aplicaciones no se detectan cargas significativas.

Dados los datos obtenidos, se dan por válidas las pruebas de capacidad, pudiendo afrontar las siguientes pruebas definidas en el presente documento.

Pruebas de rendimiento

Se trata de la ejecución de casos de uso conjuntos y con concurrencia de hilos determinada por el PROVEEDOR de forma iterativa en un escenario de duración determinada por las pruebas de capacidad. El objetivo es observar el comportamiento del producto con diferentes niveles de concurrencia. Las pruebas de rendimiento son fundamentales.

La iteración del proceso dependerá de la autorización de la STIC y los problemas encontrados que necesiten algún ajuste y/u optimización del aplicativo o aplicativos.

Previo acuerdo con el PROVEEDOR y autorización de la STIC, los niveles de concurrencia recomendables serían los obtenidos por la prueba de capacidad. Lo habitual es que la prueba consista en tres iteraciones: una con el nivel de concurrencia máximo, otra con el nivel de concurrencia óptimo y una última con un nivel bajo.

En la siguiente tabla puede verse el conjunto de pruebas a realizar:

Resultados obtenidos

[El presente apartado se muestra únicamente a modo de ejemplo, debiendo ser cumplimentado al COMPLETO por el PROVEEDOR con los resultados, tanto de métricas básicas como de métricas detalladas, obtenidos en sus pruebas de carga.]

Es necesaria una explicación clara de lo que indica cada tabla / gráfica, tanto por parte del proveedor, como de CTI,  por lo que cada una de las tablas / gráficas, deberá venir customizada incluyendo una explicación de los datos que se están arrojando.

Partiendo de los niveles de concurrencia definidos en las pruebas de capacidad (200 hilos concurrentes), se definen las siguientes pruebas de rendimiento a realizar:

Obteniendo los siguientes resultados:

Concurrencia alta (160 hilos):

Concurrencia media (120 hilos):

Concurrencia baja (80 hilos):

Se aprecia una bajada importante de los tiempos de respuesta entre la concurrencia alta y la concurrencia media, lo cual nos hace ver que la concurrencia alta definida en las pruebas de capacidad está muy cerca del límite de los servidores actuales. Se recomienda asignar mayor cantidad de RAM a los servidores de weblogic, ya que el gráfico de carga muestra que se llegan a picos del 100%.

Pruebas de estrés

Se trata de la ejecución de casos de uso conjuntos y con concurrencia de hilos determinada por el PROVEEDOR y con máximos y mínimos locales determinados por el PROVEEDOR de forma iterativa en un escenario de duración determinada por el PROVEEDOR. La finalidad de estas pruebas es determinar la capacidad de recuperación del entorno frente a un período de carga superior a la máxima admitida.

La iteración del proceso dependerá de la autorización de la STIC y los problemas encontrados que necesiten algún ajuste y/u optimización del aplicativo o aplicativos.

Las pruebas deben ejecutarse de forma incremental, de forma que cada una de las pruebas que se muestran a continuación se deben lanzar sobre la anterior (Por ejemplo, se lanza el proceso inicial y se inicia la monitorización. A los 10 minutos se incrementa la carga, a los 20 se vuelve a incrementar, etc.):

Desde un punto de vista teórico, al sobrepasar el límite admitido por el servidor, algunas peticiones deberían comenzar a fallar, obteniendo respuestas erróneas durante el periodo de carga superior al máximo obtenido. El objetivo de estas pruebas es observar cómo, después de haber estado durante un periodo de tiempo por encima del límite, la aplicación vuelve a su estado normal y las nuevas peticiones enviadas siguen funcionando correctamente.

Por ello, como resultado de este proceso se debe observar los resultados obtenidos ANTES y DESPUÉS de la ejecución de estas pruebas, para lo cual existen varias alternativas:

• Incremento paulatino: Programar en la aplicación lanzadora un número elevado de hilos a lanzar y hacer que el incremento se realice durante un periodo de subida muy largo
  • Por ejemplo, si el límite de nuestra máquina está en 200 hilos, se puede programar una prueba que lance 300 hilos y que tenga un periodo de subida de 30 minutos.
• Programar diferentes lanzaderas: Programar una lanzadera inicial que ejecute el 80% de la capacidad máxima y posteriormente se van lanzando otras lanzaderas en las que cada una de ellas van aumentando la carga en un 20%. De esta forma se pueden ir parando manualmente cuando se vea necesario para volver a la carga inicial.

Resultados obtenidos

[El presente apartado se muestra únicamente a modo de ejemplo, debiendo ser cumplimentado al COMPLETO por el PROVEEDOR con los resultados, tanto de métricas básicas como de métricas detalladas, obtenidos en sus pruebas de carga.]

Es necesaria una explicación clara de lo que indica cada tabla / gráfica, tanto por parte del proveedor, como de CTI,  por lo que cada una de las tablas / gráficas, deberá venir customizada incluyendo una explicación de los datos que se están arrojando.

Para la realización de estas pruebas se ha partido de la concurrencia definida en las pruebas de capacidad, realizándose las siguientes pruebas:

[(*): A modo de ejemplo se ha lanzado el test durante solo 10 minutos. Se recomienda que en un caso real se ejecute al menos 1 hora y se vayan realizando incrementos de concurrencia cada 10 o 20 minutos]

Ejecutadas las pruebas, se observa que a partir del primer incremento los tiempos de respuesta ya se elevan a valores no admisibles.

Esto nos lleva a pensar que, como se había mencionado anteriormente, la máquina ya estaba cerca de su límite máximo.

En la siguiente gráfica se muestra como se deterioran las peticiones con cada incremento de concurrencia:

En este caso concreto, el problema se debe a una limitación de la máquina en la que está desplegada Weblogic, ya que se está quedando sin memoria con demasiada facilidad:

Pruebas sostenidas

Se trata de la ejecución de casos de uso conjuntos y con concurrencia de usuarios determinada por el PROVEEDOR, normalmente medio/bajo, de forma iterativa en un escenario de larga duración determinada por el PROVEEDOR. Estas pruebas determinan la degradación del servicio y el ciclo de vida de las instancias de WebLogic/réplicas del servicio y las instancias de bases de datos.

La iteración del proceso dependerá de la autorización de la STIC y los problemas encontrados que necesiten algún ajuste y/u optimización del aplicativo o aplicativos.

A modo general, se propone lanzar estas pruebas con un 40% del nivel de concurrencia máximo determinado en las pruebas de capacidad durante al menos 48 horas (siendo el PROVEEDOR quien determine el periodo exacto que ve más apropiado).

Resultados obtenidos

[El presente apartado se muestra únicamente a modo de ejemplo, debiendo ser cumplimentado al COMPLETO por el PROVEEDOR con los resultados, tanto de métricas básicas como de métricas detalladas, obtenidos en sus pruebas de carga.]

Es necesaria una explicación clara de lo que indica cada tabla / gráfica, tanto por parte del proveedor, como de CTI,  por lo que cada una de las tablas / gráficas, deberá venir customizada incluyendo una explicación de los datos que se están arrojando.

Tras ejecutar todos los casos de pruebas durante 48 horas con un nivel de concurrencia definido durante las pruebas de capacidad (200 hilos) se obtienen los siguientes resultados:

Prueba ejecutada entre el 26/12/2017 08:00 y el 28/12/2017 08:00

Pruebas sostenidas con tolerancia a fallos

Se trata de pruebas sostenidas pero dirigidas por Sistemas y con soporte del PROVEEDOR en el lanzamiento. La idea subyacente es la de realizar operativas sobre las instancias de WebLogic/réplicas del servicio e instancias de bases de datos correspondiente al entorno objetivo, ya sean administrativas o no, y estudiar el comportamiento de los casos de uso e indicadores de negocio.

La duración de la prueba estará acotada por lo acordado con la STIC y el tiempo disponible al tratarse de las pruebas realizadas en último lugar.

La iteración del proceso dependerá de la autorización de la STIC y los problemas encontrados que necesiten algún ajuste y/u optimización del aplicativo o aplicativos.

El diseño de las pruebas se muestra en la siguiente tabla:

Conclusiones

En el presente apartado se hace un resumen de los resultados obtenidos, su interpretación y si los resultados obtenidos cubren las necesidades definidas en los requisitos. Los resultados deben satisfacer las necesidades definidas, por lo que la información que se refleje en las conclusiones Capacidad máxima, Margen actual y Nodos recomendados deberá mostrar de forma clara que la aplicación, junto con los recursos hardware recomendados, será capaz de cubrir la carga definida en los requisitos a partir de las necesidades detectadas en Volumetría . Por ello, será necesario que los resultados obtenidos en los análisis y las necesidades definidas sean comparables. Idealmente, el caso de uso que se haya utilizado como fuente de información para la Volumetría debería formar parte de los Casos de Uso del plan de pruebas o que este contenga algún caso de uso lo más similar posible (Número de peticiones, peticiones de complejidad similar, similar proporción de peticiones a servicios externos, etc.)

Aunque la cumplimentación de este apartado es responsabilidad del PROVEEDOR, los datos aquí expuestos deben ser acordados con los diferentes grupos de la STIC dependiendo del caso (Sistemas, Arquitectura, Interoperabilidad, etc.).

En estas conclusiones se deben aportar al menos los siguientes datos, teniendo en cuenta que se refieren en cada momento a la infraestructura actual existente:

[A partir de este punto la información mostrada es únicamente a modo de ejemplo, debiendo ser cumplimentado al completo por el PROVEEDOR con los resultados obtenidos durante sus pruebas]

Dados los resultados de las pruebas realizadas, podemos aportar la siguiente información:

• Capacidad máxima: Una vez analizadas las pruebas de estrés, a partir de 300 usuarios concurrentes por nodo los tiempos de respuestas son demasiado elevados (1,8 segundos). Por lo que se considera que 300 es el máximo de usuarios por nodos que soporta la aplicación.
• Margen actual: Dado que 200 usuarios (Pruebas de capacidad) ya supera aproximadamente un 25% el número de usuarios en picos de trabajo, aún hay un margen de 100 usuarios por nodo.
• Nodos recomendados: Dado que la previsión es contar con 500 usuarios concurrentes en momentos de máximo trabajo, creemos que la arquitectura actual (3 nodos) es suficiente.

Adicionalmente, se desea destacar las siguientes conclusiones extraídas de los resultados obtenidos:

• Memoria RAM: La memoria actualmente asignada a Weblogic (1GB) puede considerarse demasiado justa para el sistema. Se recomienda aumentar la memoria asignada a 1.5GB.
• Lentitud de peticiones: Se detecta un tiempo medio de respuesta de más de 2 segundos en la acción de logar. Se analizará para futuras versiones cómo optimizar este proceso para reducir el tiempo de respuesta.

Finalmente, con la información recogida a lo largo del proceso de pruebas de carga del sistema, junto a la experiencia del proveedor como conocedor del producto a nivel técnico, el PROVEEDOR establece que las pruebas han sido:

El documento debe finalizar con las conclusiones globales por parte del proveedor y CTI, indicando si del resultado de las pruebas realizadas se desprende que la aplicación es apta o no para su puesta en producción. 

Posteriormente el Área de Gobernanza revisará toda la información entregada emitiendo también sus conlusiones.

Entregables tras las pruebas   

Una vez finalizadas las pruebas se entregará tanto el plan de pruebas con los resultados obtenidos, como cualquier información, documentación y artefactos que se haya utilizado en la realización de las mismas. El Área de Gobernanza revisará y dará como FAVORABLE o planteará una serie de objeciones al plan de pruebas una vez  se le informe de la disponibilidad del informe del plan de pruebas.

Documentación

Con respecto al plan de pruebas, se entregará en Confluence y deberá contener toda la información de las pruebas realizadas y resultados obtenidos siguiendo las indicaciones que aparecen en el Anexo III: Plantilla PPS de este documento.

En el apartado Entregables del PPS deberán adjuntarse la exportación de los informes HTML (https://jmeter.apache.org/usermanual/generating-dashboard.html) obtenidos en las pruebas:

1. 1. 1. 1. Confirmación de las pruebas de capacidad
         2. Pruebas de rendimiento en concurrencia alta
         3. Pruebas de estrés
         4. Pruebas sostenidas

Archivos

Los archivos relacionados con las pruebas de carga del sistema se entregarán a través de Git, siguiendo un versionado específico y organizanándose de acuerdo a los siguientes criterios:

• HELM: Los archivos se ubicarán dentro del proyecto HELM, en el directorio denominado "pruebasdecarga".
  • Versionado:  Este directorio seguirá el versionado del proyecto HELM, existiendo un único directorio asociado a cada versión/etiqueta del repositorio helm.

• Aplicación/componente (sin componente HELM): Se creará un directorio al mismo nivel que los componentes existentes, con el nombre <CALM>-pruebasdecarga, donde CALM corresponde al código ALM de la aplicación.
  • Versionado: Se creará una rama a partir de develop con el contenido necesario para las pruebas de carga de la versión a lanzar. Posteriormente, se mergeará esta rama en develop y se versionará/etiquetará desde develop con la misma versión que la aplicación padre

• El resto, en el directorio "pruebasdecarga".
  • Versionado: Dentro del directorio de pruebas de carga se entregará una capeta por cada versión del producto sobre la que se realizan pruebas de carga siguiendo la nomenclatura de 3 dígitos o 4 cuando sea necesario por motivos de reentrega.

Estos directorios se creará en el repositorio del proyecto no siendo necesaria su entrega previa a la versión.

Contenido, se entregará:

• • Archivos de JMeter utilizados para las pruebas (archivo *.jmx).
  • Scripts para la preparación de datos siguiendo la normativa (si aplica).
  • Archivo Readme.md que contendrá, entre otros apartados, un enlace al plan de pruebas de Confluence, así como las características técnicas que sean necesarias para la ejecución de las pruebas. La plantilla está disponible en Git: Plantilla del Readme.md para las pruebas de carga del sistema. 

Anexos

Anexo I: Volumetría

El objetivo de las pruebas de carga del sistema es garantizar el comportamiento de la aplicación en su puesta en producción evitando caídas del sistema, lentitud, etc. Por ello, resulta necesario establecer la carga del sistema en producción y simular el comportamiento de la aplicación en dichas circunstancias. En sistemas que ya se encuentren en producción, preferentemente se utilizará el pico de carga del sistema del que se conserven registros. En caso de que el sistema no se encuentre en producción o no se conserven registros, se deberá establecer una estimación razonada de la carga que deberá soportar el sistema.

Como norma general, el caso de uso que origine el pico de carga identificado en Volumetría debe formar parte de los Casos de Uso del plan de pruebas. En su defecto, el plan de pruebas deberá contener algún caso de uso lo más similar posible (Número de peticiones, peticiones de complejidad similar, similar proporción de peticiones a servicios externos, etc.)

Preferentemente, las métricas a utilizar en Volumetría vendrán expresadas en términos que permitan una correspondencia con los resultados que proporciona la herramienta utilizada (JMeter) en sus informes. Con caracter general, se recomienda utilizar Productividad (Transacciones/s) como unidad de medida realizando la conversion de la información de carga máxima de la que se disponga a esta unidad de medida.

Anexo II: Casos de Uso

El conjunto de casos de usos debe ser acordado entre el proveedor y la STIC a través de los responsables funcionales de la aplicación.

A continuación se muestra un ejemplo de casos de uso a probar:

En la descripción se incluirá la serie de actividades/pasos a realizar para llevar a cabo el proceso. Normalmente, cada actividad/paso coincidirá con alguna de las peticiones que proporciona la funcionalidad propia de la aplicación.

Anexo III: Plantilla PPS 

Siguiendo la estrategia de migración a Confluence adoptada por la STIC, se ha creado una plantilla en dicha herramienta con el fin de abandonar el documento que se utilizaba hasta ahora.

El informe se ubicará en el espacio del proyecto correspondiente, en el apartado "versiones", dentro de la versión sobre la que se hayan ejecutado las pruebas.

Una vez situados en el lugar en el que queremos generar el informe, sólo tenemos que crearlo utilizando la plantilla llamada "Plan de pruebas de carga del sistema".

Si surgiese alguna cuestión al respecto, la Oficina de Calidad está siempre dispuesta a resolver cualquier duda que surja.

Anexo IV: Lista de revisión de documentación

A continuación se presentan los puntos de revisión que se aplicarán al documento PPS entregado:

Anexo V: Hot Deployment

Requisitos y recomendaciones para afrontar con garantías un hot deployment en Oracle Weblogic:

1. Aplicación del workaround relativo a los conflictos de clases. Nos hemos encontrado 3 tipos de conflictos en los entornos del SAS:

• Duplicidad en clases aportadas en el desplegable del proveedor y el software base de WebLogic. En el war/ear/jar tenemos las clases que tiene Weblogic en el software base existe con una versión distinta. En este caso podemos tratarlo con informes de conflicto de clases desde WebLogic (informes CAT).
• Duplicidad en clases aportadas en el desplegable. En el mismo war/ear/jar hay clases duplicadas  con distintas versiones. El informe CAT no detecta estos casos, luego tendrá que realizarse mediante una herramienta de auditoría de código. En este caso hemos acordado que el aplicativo esté Mavenizado y compruebe que no haya "clases" en las librerías duplicadas (ojo, librerías con distinto nombre pueden tener clases repetidas con distintas versiones, luego no es sólo comprobar que haya librerías con distinto nombre).
• Duplicidad en clases aportadas por librerías copiadas manualmente en el rutas accesibles (CLASSPATH) como si fuera software base (por ejemplo $DOMAIN/lib). Este caso tampoco es comprobable con el informe CAT. Se ha acordado que el aplicativo candidato a despliegue caliente no puede tener más allá del software base de weblogic en el directorio de Middlware. Cualquier clase distinta al software base debe estar en el war/ear/jar e indicada la preferencia para weblogic en el descriptor de despliegue weblogic.xml.

2. No se deben incluir a nivel de máquina virtual de java parametrización que pueda provocar un comportamiento irregular del servidor de WebLogic. Por ejemplo, en el caso del "nodo mudo" se indica un parser a nivel de JVM distinto al utilizado por defecto en weblogic, cuando se debe utilizar como recursos dentro de los paquetes EAR. El ejemplo está documentado por Oracle en el siguiente enlace: https://docs.oracle.com/cd/E23943_01/web.1111/e13724/appscope.htm#XMLPG224 para WebLogic 10.3.6. En él se ejemplifica el cómo cambiar el Parser desde el EAR y no a nivel de JVM.

3. El cambio a desplegar debe ser pilotable en BBDD y otros elementos compartidos como JMS, JTA, EJB, etc¿ Es decir, si el desplegable conlleva un cambio en base de datos y hay que parar para ese cambio, no se puede desplegar en caliente. Si el aplicativo necesita un reinicio un timeout excesivo en JTA, parar JMS, cambio en paramétricas en base de datos, etc¿ Puede ser contraproducente el despliegue en caliente y que dos versiones estén simultáneamente en ejecución.

4. Redimensionamiento de los pooles de java relacionados con la carga de clases: PermGen en java 7 y MetaSpace en java 8. 
En Java 8 se suele indicar un máximo, aunque sea memoria nativa, suele estar restringido el máximo al igual que con Java 7 y el PermGen. Se debe, al menos, tener el doble para que no estamos ante excepciones de tipo OutOfMemory en los despliegues en caliente.

Todos estos requisitos son añadidos a las recomendaciones indicadas por Oracle en la documentación oficial:

https://docs.oracle.com/cd/E13222_01/wls/docs100/deployment/redeploy.html (apartado "Requirements and Restrictions for Production Redeployment")

Los requisitos aquí indicados son los mínimos, pero evidentemente hay que probarlo por cada plataforma y de forma exhaustiva ya que el modo de programación es ajeno a sistemas. 

Para porder comprobar que se ha realizado correctamente el despliegue en caliente, proponemos realizar la una prueba de una versión (la ya desplegada) a otra (la que queremos desplegar en caliente) con una carga sostenida, lo que significa tener preparado dos versiones (versión A y B) con cambios en uno o varios casos de uso que se estén probando en dicha carga:

1. Despliegue versión A con versionado y reinicio/limpieza de entorno.
2. Lanzamiento de prueba sostenida.
3. Redespliegue online de versión B en la mitad de la prueba sostenida con un retire timeout de 5 minutos (el tiempo de expiración de sesión se consensuará entre las partes interesadas).
4. Espera a final de prueba sostenida de al menos 48 horas.