Aproximación inicial a las Pruebas de Carga

Todo el ciclo de vida de desarrollo de una aplicación debe estar apoyado en el Testing. Y no sólo eso, las pruebas deben continuar una vez puesta en producción la aplicación. El hecho de que el trabajo de un tester NUNCA termina puede parecer frustrante. Pero es importante tener en mente que, con cada ciclo de pruebas, la aplicación va mejorando. Su calidad se va incrementando.

Una vez en producción, la caída de una aplicación debido a un exceso de carga puede deberse a dos razones fundamentalmente: o bien no se hicieron pruebas de carga durante el desarrollo, o, aún peor; se hicieron, pero no correctamente. Las pruebas de carga suelen ser diseñadas para poner de manifiesto cierto tipo de defectos. Sin la preparación adecuada, estos defectos pueden quedar ocultos y pasar a la fase de producción.

Entonces, ¿cómo nos preparamos para hacer las pruebas de carga?

¿Qué necesitas saber?

En primer lugar, es necesario determinar el conocimiento que queremos adquirir del sistema a través de estas pruebas. Cada tipo de test se ejecuta de manera diferente, y proporciona un enfoque de nuestra aplicación desde una perspectiva distinta. Así que necesitamos ejecutar diferentes tipos de tests basados en lo que esperamos encontrar.

Por ejemplo:

• Si quieres ver cómo se comporta tu aplicación con poca carga, con la intención de establecer el comportamiento básico de partida, ejecutaremos una prueba con un único usuario o “single user test”.
• Si quieres ver cómo se comporta tu aplicación bajo la carga normal esperada en producción, ejecutaremos una prueba de carga o “load test”.
• Si quieres determinar el punto a partir del cual tu aplicación deja de funcionar o responde tan lentamente que es prácticamente inutilizable, necesitaremos ejecutar una prueba de estrés o “stress test”.
• Si quieres saber si la aplicación tiene memory leaks ejecutaremos un test de resistencia o “endurance test”.

Existen otros tipos de pruebas, como pruebas de volumen (“volume test”) que pueden resultar útiles en determinados entornos, como aquellos en los que datos acumulados durante largos periodos de tiempo pueden ser significativos para la ejecución. De nuevo: es necesario determinar los tipos de pruebas adecuados a la aplicación en desarrollo, anticipando los escenarios de producción.

Decidir el número de usuarios virtuales

Bien, hemos decidido que nuestra aplicación necesita pruebas de carga, ¿cuántos usuarios virtuales necesitamos simular? Para responder a esta pregunta es necesario estimar cuantos usuarios concurrentes podrían utilizar la aplicación (por ejemplo, visitar el sitio web), y eso podría depender de fechas, husos horarios, etc. Muchos testers, simplemente, hacen una estimación. Pero mejor, habla con el arquitecto de la aplicación, habla con la gente de marketing, mira las especificaciones no funcionales referidas a rendimiento (si las hay), entrevista potenciales usuarios (si eso es posible),…

En estos casos suelen resultar muy útiles los datos históricos. Al menos inicialmente, tras la puesta en producción, cabe esperar una carga similar a la de las herramientas que los usuarios estuvieran utilizando anteriormente (si las había).

También puede ser que el número máximo de usuarios concurrentes esté limitado por diseño. Para esto resulta útil hablar con los ingenieros de desarrollo o el propietario del producto. En el plan de pruebas habrá que incluir estos datos, y posteriormente incrementarlos para asegurar la estabilidad de la aplicación frente a situaciones de sobrecarga extraordinarias.

Nota importante: si necesitas ejecutar un test de carga tras la puesta en producción, procura programarlo para una hora y día en que prácticamente no haya usuarios reales. Ten en cuenta los posibles efectos laterales de una caída del entorno de producción y prepara un plan de contingencia para el peor de los casos.

Análisis estadísticos

Es muy difícil hacer una estimación de los hábitos de uso de los clientes de la aplicación. Si las tienes, ¡utiliza las estadísticas! Es la única manera de entender quién, cómo y cuándo utiliza la aplicación.

De esta manera se pueden crear tests representativos de los usuarios reales, en oposición a tests de lo que en el departamento de desarrollo (o de pruebas) se cree que será el uso real de la aplicación, y que a veces dista mucho de la realidad. Las estadísticas de producción son una gran herramienta. Úsalas.

Involucra al equipo

Debido a la relación que las pruebas de carga tienen con el futuro entorno de producción, normalmente es necesario involucrar en ellas a múltiples interesados (stakeholders). Identificarlos y hacer que se interesen por estas pruebas es una parte importante del load testing.

Por su naturaleza, las pruebas de carga pueden involucrar a: desarrolladores, ingenieros de redes, DBAs, jefes de pruebas, propietarios de la aplicación, futuros usuarios, etc. Todos ellos tienen su propio interés en que la aplicación funcione correctamente y cumpla sus expectativas, aunque cada uno de ellos tiene su propio punto de vista. En el caso de las pruebas de carga, normalmente, la aproximación correcta englobará la combinación de dos o más de estos diferentes puntos de vista. Asegúrate de que todos ellos puedan expresar su opinión y además:

• Monitoricen su área de conocimiento
• Den feedback
• Se comprometan con los resultados de estas pruebas, y, más concretamente, con el rendimiento de la aplicación

Plataformas (Navegadores)

La mejor estrategia es, sin duda, utilizar para pruebas el software más parecido a la experiencia real de usuario de la aplicación en desarrollo.

Para el caso práctico de una aplicación web sería necesario analizar datos como localizaciones, navegadores utilizados, etc. Los escenarios deberían poder ser reproducidos en cualquier navegador, por supuesto, pero es importante poder anticipar cuales serán los mayoritariamente utilizados por los usuarios, considerar los países desde donde se reciben las visitas y los hábitos de navegación y/o configuración.

La mejor manera de entender el SW que están utilizando los futuros usuarios es que tú mismo lo tengas instalado. En el caso de los navegadores es bastante sencillo. A partir de ahí, debes asegurarte de que tus pruebas reproducen lo más fielmente posible el comportamiento de los usuarios reales. Esto incluye:

• Procesamiento en paralelo de múltiples peticiones (threads)
• Think time
• Múltiples escenarios concurrentes; desarrollo/arquitectura determinará si existen exclusiones
• Escenarios complejos
• Parametrización de los escenarios
• Generación de carga desde múltiples agentes (y monitorización de los agentes)

Preparación para la ejecución de tu aplicación en Producción

Es indudable el valor de los tests en fase de desarrollo, en un entorno específico de pruebas. Pero, por múltiples razones, esto deja algunas lagunas que deben ser cubiertas antes de la salida a producción, y que solo pueden cubrirse con pruebas en un entorno que ha de ser lo más parecido posible (si no idéntico) al de producción:

• Los entornos de pruebas suelen NO ser duplicados exactos del de producción.
• Los entornos de pruebas suelen estar disponibles solamente desde dentro de la red local, desde la propia organización, obviando elementos como firewalls, etc., que pueden suponer un cuello de botella.
• Ojo con la carga que provoca la propia ejecución de los usuarios virtuales y cómo se distribuye. A veces esto es significativo. A veces los cuellos de botella están en las máquinas inyectoras de carga, incluso cuando están separadas de las máquinas en las que corre la aplicación bajo prueba.

Análisis de los resultados

Normalmente, la interpretación de los resultados de las pruebas de carga no es trivial (y esto no solo se debe al “state of the art” de las herramientas comerciales). No suelen ser tan sencillas como las funcionales, en las que, casi siempre, el resultado se reduce a “correcto” o “incorrecto”.

Es necesario reservar en la planificación suficiente tiempo para el análisis e interpretación de los resultados, involucrando de nuevo a los interesados mencionados anteriormente, stakeholders que pueden ayudar a determinar si un resultado entra dentro de los parámetros aceptables o no.

Identificados los escenarios NO aceptables, pasamos a la búsqueda de cuellos de botella, errores, debilidades, posibles fallos de seguridad, etc., apoyados siempre por personal de desarrollo y arquitectura, que son en última instancia quienes deben entender y solucionar los problemas identificados. Asegúrate de que el personal que crees que debe estar involucrado lo entiende y reserva tiempo en su planificación para estas tareas.

 

Más información:

Javier Fernández Caro – QA Specialist – Sogeti España

javier.fernandez-caro@sogeti.com