Desde hace unos años venimos utilizando una metodología propia para llevar adelante proyectos de pruebas de performance que nos ha dado muy buenos resultados.

Hemos tenido el agrado de escribir varias publicaciones al respecto y presentarlas en diferentes eventos (Expo QA 2008SEPGLA 2008)  recibiendo un muy buen feedback.

La metodología es lo suficientemente amplia para abarcar varios tipos de proyectos pero a su vez da una guía muy útil a la hora de abordar estos temas.

En este post me gustaría comentar brevemente las diferentes estapas de la metodología y cuál es el objetivo de cada una.

Etapas de pruebas de performance

Etapa inicial

Se busca entender el contexto en el cual surge el proyecto y los objetivos que se persiguen. Se busca también, dimensionar el proyecto de testing de performance, acotando su alcance. Se requieren en general pruebas de concepto para analizar que herramientas se adecuan mejor al contexto y al sistema que se tiene que probar. Al finalizar esta etapa tenemos que tener una idea clara del esfuerzo necesario para llevar adelante el proyecto,  perfiles de gente se a involucrar, los recursos  materiales se van a necesitar, etc.

Etapa de Relevamiento

Es una de las etapas fundamentales del proyecto. Se busca definir un modelo que simule de la manera más adecuada posible la realidad a la cual se va a enfrentar el sistema. En esta etapa debemos integrar personas con distintos perfiles (usuarios, analistas funcionales, desarrolladores, administradores, etc.) para definir qué transacciones se incluirán, cuántos usuarios virtuales se ejecutarán, cada cuánto tiempo, cómo se simularan otros sistemas, etc. Se deben tener en cuenta todos estos factores para reproducir las condiciones bajo las cuales se quiere estudiar el sistema.

También se deben detallar otros aspectos importantes como ser: la infraestructura que se utilizará para las pruebas, como se monitorizará la misma, los datos a utilizar en las pruebas, etc.

Etapa de Automatización

En general en las pruebas de performance debemos programar para simular el modelo definido en la etapa anterior. Este modelo en general incluye la necesidad de ejecutar funcionalidades con alta concurrencia. Para poder lograr esto, en general, las herramientas trabajan a nivel de protocolo. Para protocolos abiertos y ampliamente difundidos como HTTP existe una variedad importante de herramientas gratuitas y pagas, pero para protocolos propietarios es más complicado encontrar herramientas gratuitas (tal como comentamos en un post anterior).

Al finalizar esta etapa se contará con todos los artefactos de prueba necesarios para recrear el modelo definido.

Etapa de Armado de la Infraestructura definitiva

Luego que se ha dedicado mucho esfuerzo definiendo y programando la automatización, es hora de dejar el ambiente de pruebas listo para comenzar las ejecuciones. Esta etapa en general ocurre luego de la etapa de automatización debido a que por lo general los servidores a utilizar en las pruebas tienen un costo alto y se intenta minimizar el uso de los mismos. Las etapas anteriores se pueden realizar con un ambiente similar al que se va a utilizar en las pruebas.

Al finalizar esta etapa se tiene toda la infraestructura lista para la ejecución, eso incluye la monitorización (tanto de los servidores como de las generadoras de carga), procesos de backup/restore en caso de que sean necesarios, etc.

Etapa de Ejecución

En esta etapa se comienza a obtener los resultados. Generalmente las ejecuciones las comenzamos con las llamadas líneas bases (baselines) las cuales consisten en ejecutar cada transacción sin concurrencia ninguna (con la totalidad de los recursos disponibles) para obtener el mejor tiempo posible de cada una. Estos tiempos nos servirán luego como puntos de comparación. Al comenzar las pruebas se recomienda asignar un porcentaje de carga bajo (por ejemplo un 20% de la carga que se desea soportar), si todo funciona según lo esperado subir al 40%, y así hasta llegar al 100% o 200% si se desea. La razón fundamental para tomar esta estrategia es encontrar con un nivel de complejidad menor los problemas más gruesos, atacarlos y luego pasar al siguiente escalón. Si se ejecutaría de primera el escenario objetivo puede pasar que ocurran varios problemas al mismo tiempo, agregando complejidad  al análisis de los mismos.

Luego de varias iteraciones de ejecución, reportes y correcciones (lógica, configuración, re-diseño, etc.) se llega a una versión del sistema que cumple con los desafíos planteados, o no se llega y se aprende sobre los puntos en los cuáles se debe mejorar.

Es muy importante tener en cuenta que durante esta etapa el objetivo es mejorar el sistema y por este motivo se deben involucrar tanto los testers como los desarrolladores, los expertos en el DBMS, en el sistema operativo, en el balanceador de carga, en el servidor web, en el storage, etc, etc.

Etapa de Finalización

Luego que se terminan las ejecuciones es aconsejable hacer un informe final en el cual se cuente  el desarrollo del proyecto, qué mejoras se hicieron qué sugerencias quedan por implementar para mejorar la performance, etc. También es aconsejable hacer una evaluación postmortem en la cual se vean los puntos a mejorar y ajustar para el próximo proyecto.

Esperamos les sea útil esta información y pueda contribuir en la mejora de la performance de sus sistemas.

Matías Reina