Pruebas de performance

¿Qué son las pruebas de rendimiento?

De manera sencilla podemos definir las pruebas de rendimiento como un conjunto de pruebas que son realizadas a una aplicación para determinar el comportamiento del performance de la misma, identificar puntos potenciales de mejora o garantizar los niveles de servicios esperados por los clientes del sistema.  Actualmente este tipo de pruebas son realizadas en la mayoría de los proyectos de tecnología únicamente a aquellas aplicaciones de ejecución crítica que puedan afectar la operación del negocio, aunque cada vez más se evidencia la necesidad de realizar este tipo de pruebas para los diferentes aspectos del código producido y consecuentemente los proyectos de tecnología hacen cada vez un mayor uso de pruebas de stress y de carga en un mayor número de compontes de sus sistemas.   

Cabe recordar que las pruebas de rendimiento pueden realizarse en diferentes niveles del desarrollo, pueden planearse y ejecutarse mucho antes de que se haya finalizado el desarrollo en su totalidad, por ejemplo, podríamos realizar pruebas de rendimiento a cada uno de los componentes que integran el desarrollo en conjunto con las pruebas unitarias de los mismos y a medida que se vayan integrando podríamos realizar otras pruebas de integración entre componentes que aseguren que no existan problemas de rendimiento en la forma en la cual interactúan a partir del diseño del sistema.  Realizar pruebas de rendimiento de manera temprana es una buena forma de establecer garantías parciales en el mediano plazo que nos permitan avanzar hacia los objetivos de performance definidos con una incertidumbre menor.

¿Por qué son necesarias?

Podría pensarse que las pruebas de rendimiento pueden ser ejecutadas de manera posterior al despliegue de nuestras aplicaciones, sin embargo, debemos tener claro que las pruebas de rendimiento tienen como objetivo fundamental anticipar los problemas de performance que puedan ocurrir una vez la aplicación esté en producción.  Una vez que se haya llevado a cabo la entrega de un desarrollo, será mucho más difícil encontrar formas de sobrellevar problemas de desempeño detectados en la operación ya que en esta etapa contaremos con un menor control sobre las características que podremos cambiar para cumplir los nuevos objetivos.

Las pruebas de rendimiento adicionalmente nos ayudan a visualizar tiempos muertos de las aplicaciones que de otra manera no hubieran podido detectarse, redundando en un mayor conocimiento las tareas que consumen mayor tiempo, de los límites del código producido y adicionalmente en la identificación de los puntos más frágiles de la aplicación.  Cada uno de estos aspectos es de vital importancia si deseamos descubrir mejores formas de realizar las operaciones pertinentes. 

¿Cómo pueden ayudarnos?

Las pruebas de rendimiento pueden hacernos la vida más fácil o más difícil dependiendo de la forma en la que se gestione la ejecución de dichas pruebas, si no se tienen claros temas del proyecto relacionados con costos, tiempos de entrega y parámetros específicos de las pruebas realizadas podemos entrar en un ciclo infinito de pruebas rechazadas. 

Es importante entender los conceptos o las características que se están midiendo y como se alinearán dichas mediciones con los objetivos del proyecto antes de iniciar un plan de pruebas que probablemente arrojen resultados de poco valor que no nos permitan mejorar nuestros productos. 

Otra forma en la que las pruebas de performance pueden ayudarnos está relacionada con la capacidad de predecir comportamientos a partir de los volúmenes de datos u operaciones de manera tal que podamos ser capaces de entregar guidelines o documentación clara sobre el rendimiento que debe ser esperado por parte de los usuarios del sistema, por ejemplo, si hemos construido una aplicación para construir pantallas de captura de datos en la web y entregamos una documentación que establezca que el tiempo promedio de procesamiento para un control en una página tiene un tiempo promedio de 1 ms bajo ciertas condiciones, con seguridad podremos establecer los requisitos de hardware mínimos para que dicha premisa se cumpla y adicionalmente podremos evitar mediante políticas de desarrollo que los usuarios del sistema intenten construir páginas con 3000 controles que demorarían en promedio 3 segundos en cargar lo que podría ocasionar otro tipo de problemas en el desempeño general de la aplicación.

Etapas generales de una prueba

Una prueba de rendimiento por lo general se encuentra divida en tres fases.  A continuación se presenta una breve descripción de cada una de ellas.

Construcción: En esta etapa de la prueba se identifican los casos que serán susceptibles de ser probados, se define la manera en la cual se realizará la prueba y se construyen scripts o artefactos que permitirán su ejecución. 

Ejecución:  El objetivo en esta fase es el de utilizar los artefactos construidos para la ejecución de la prueba con el fin de obtener información sobre las métricas, los casos y/o características definidas durante la construcción.

Análisis: Una vez que se haya recolectado la información que se ha obtenido durante las ejecuciones de las pruebas de rendimiento se deberá proceder a analizar la información según para poder tomar acciones los resultados encontrados.

A pesar de que puede parecer sencillo, la obtención de los datos de una prueba con un nivel de confianza relativamente bueno puede suponer algunos retos a la hora de poner en marcha el plan.  Temas como el aislamiento de los ambientes, el estados de los recursos, temas de configuración de la aplicación y los errores humanos pueden repercutir en la invalidez de las pruebas realizadas, derivando en la necesidad de repetir la prueba una y otra vez hasta que se logue la confianza suficiente en los datos y los procedimientos utilizados.

Validez de pruebas

Como se mencionó anteriormente las pruebas pueden invalidarse por un gran número de razones de diferente naturaleza, por esta razón sería una buena idea tener claros los escenarios más comunes que puedan presentarse para que una prueba pierda su validez.  En esta sección presentaremos algunos de estos escenarios e intentaremos detallar ejemplos asociados con los mismos.

Aislamiento del ambiente de pruebas

Un caso común en las áreas de tecnología de las empresas hoy en día corresponde al reúso de recursos para los ambientes de IT, ser reutiliza la infraestructura con el objetivo de reducir costos, por esta razón, encontramos ambientes virtualizados que comparten hardware entre sí con el fin de optimizar las operaciones, estas situaciones pueden representar un riesgo al momento de realizar pruebas de rendimiento, ya que si el ambiente que ha sido destinado para pruebas también se utiliza en otro tipo de tareas como por ejemplo como ambiente de desarrollo, los resultados de nuestras pruebas podrían no ser del todo confiables. 

Teniendo como base el planteamiento anterior podemos inferir que para que la validez de nuestras pruebas no se vean afectadas por operaciones sobre el ambiente externas a los escenarios probados es fundamental que el ambiente de pruebas esté físicamente aislado de otros ambientes.  Esto no quiere decir que el ambiente deba estar totalmente desconectado, por ejemplo, de la red de nuestra compañía o que deba ser privado de cualquier servicio de comunicación con otros elementos de la infraestructura, lo que realmente nos dice es que los recursos destinados para pruebas deben estar lo suficientemente disponibles para garantizar que la aplicación probada no presentará pérdidas de rendimiento debido a elementos externos a la misma prueba y a las condiciones naturales de la plataforma sobre la que opera. 

 

Disponibilidad de recursos suficientes

Aún cuando el ambiente se encuentre físicamente aislado durante la realización de las pruebas de rendimiento, es posible que existan elementos locales dentro de las máquinas utilizadas, por ejemplo, componentes ajenos a la prueba que puedan consumir intensivamente recursos computacionales como podrían ser instalaciones imprevistas de aplicativos, ejecución de análisis de antivirus o condiciones específicas del sistema operativo pueden provocar una disminución en los tiempos obtenidos en la prueba de manera, hecho que podría confundirse con mejoras o disminución del rendimiento al ser comparados con pruebas que hayan sido realizadas en ausencia de la ejecución de dichos componentes.  Entonces podemos decir que se debe verificar que los recursos locales no están siendo afectados de manera intensiva por aplicaciones externas a la prueba.  De igual manera otras tareas en ejecución como la descarga de grandes volúmenes de información de internet durante el tiempo de la prueba puede afectar  recursos utilizados por la aplicación probada como el acceso a la red.

Invariabilidad del hardware y software

Una vez que se ha garantizado que las condiciones físicas y locales del ambiente de pruebas se perciben como estables podemos comenzar a realizar nuestras pruebas, pero en caso de utilizar diferentes ambientes para realizar las mismas debemos garantizar que las mediciones de tiempos se realicen utilizando recursos de hardware equivalentes, es decir, asegurar que a pesar de que las pruebas se hayan realizado en diferentes máquinas, las especificaciones del hardware utilizado sean exactamente iguales o muy similares, en caso de ser diferentes las pruebas son incomparables a menos que los resultados de las pruebas se evalúen en términos relativos, como porcentaje del tiempo consumido. 

Si una aplicación se prueba dos veces en ambientes con especificaciones de software diferentes, como por ejemplo, máquinas con sistemas operativos diferentes o con diferencias en parches instalados del sistema, es posible que las operaciones realizadas en ambas pruebas no se realicen de la misma manera, por lo cual nuevamente las pruebas no son comparables entre sí.  Lo más cómodo en términos generales al momento de ejecutar un conjunto de pruebas es seleccionar un único ambiente, aislado y controlado para ejecutar todas las pruebas pertinentes, de esta manera no deberemos preocuparnos por las diferencias de hardware o software pues el ambiente será igual para todas las muestras recolectadas haciendo que los resultados entre pruebas puedan se comparables entre si y tengamos una mayor confianza en los datos obtenidos.

Representatividad del tamaño de muestras

Aún cuando el ambiente esté aislado, las condiciones locales del sistema sean uniformes y no existan diferencias de hardware o software entre las pruebas realizadas, debemos entender que el estado de las máquinas en la que se hospedan nuestras aplicaciones está sujeto a variaciones no predecibles, como por ejemplo el uso de la memoria virtual, caídas repentinas de la disponibilidad de ciertos servicios como la red o tecnologías asociadas con la reducción del consumo energético de los equipos y procesadores. 

Por el motivo anteriormente expresado, es necesario tener un tamaño de muestreo representativo, con el fin de descartar los casos atípicos y poder establecer un comportamiento promedio o general de las características que deseamos cuantificar.  Mientras mayor sea el número de muestras recolectadas tendremos una visión más completa del comportamiento medido.  Determinar el número de pruebas a realizar para obtener un nivel de confianza aceptable puede llevarnos a un análisis más formal y estadístico, aunque usualmente este tipo de métodos no son utilizados con frecuencia por lo que se trata de realizar las pruebas con el mayor número posible de iteraciones o usuarios, por ejemplo por encima del número promedio real.  Tener un número muy bajo de pruebas puede invalidar los resultados obtenidos a partir de las mismas.

Repetitividad o repetibilidad de Casos

Otro factor que suele ser determinante para identificar la validez de una prueba puede estar relacionado con la capacidad que tiene la prueba de ser "repetible", para exponer la importancia de este concepto, plantearemos un escenario en el cual una aplicaciones realiza un conjunto de tareas diferentes de manera aleatoria, si realizamos las pruebas de dicha aplicación ¿cómo podemos asegurar que todas las pruebas miden los mismos aspectos?, de hecho, no lo hacen, por lo que se evidencia la necesidad de que los casos probados sean perfectamente reproducibles de modo que podamos establecer comparaciones sobre los resultados obtenidos.  En algunas ocasiones la repetibilidad puede estar asociada a los diferentes caminos lógicos que una aplicación puede tomar durante su ejecución y en otras ocasiones dichos cambios dependerán de los datos suministrados como entrada de los algoritmos implementados. 

Algunas veces es casi imposible lograr que el número de llamados a todas las funciones sean exactamente igual entre pruebas, sobre todo si lo que intentamos comparar está relacionado con mejoras debido a modificaciones sobre los algoritmos codificados.  En estos casos es posible realizar las comparaciones normalizando los datos, por ejemplo  si una aplicación ejecutó diez veces el método A() en la prueba 1 y 30 veces el mismo método en la prueba 2 podremos comparar los resultados dividiendo el tiempo T1(A) entre 10 lo que nos dará el tiempo promedio de A durante la prueba 1 y podemos hacer lo mismo para la prueba número 2 obteniendo el tiempo promedio de A durante la prueba 2 al restar T2(A) - T1(A) podremos establecer la diferencia entre los tiempos promedio aún cuando las dos pruebas no coincidan en el número de llamados. 

Analizar tiempos de funcionalidades entre pruebas con diferente número de llamados y sin normalizar los tiempos puede ser un factor para invalidar las conclusiones obtenidas en las pruebas realizadas.

Confiabilidad de herramientas y mediciones

Bueno, como último aspecto a considerar para evitar que nuestra prueba sea confiable tenemos la confiabilidad de las herramientas que son utilizadas para realizar las mediciones de las características que deseamos evaluar.  Obtener datos a partir de herramientas que puedan retrasar en demasía los tiempos de la aplicación a probar puede llevarnos a conclusiones erróneas sobre el comportamiento de la misma.  En los posible las herramientas utilizadas deben estar certificadas o ser reconocidas como herramientas que arrojan resultados confiables y que tienen el menor efecto posible en la prueba.