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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
