Pruebas de prestaciones, ajustando escenarios.

En mi anterior post comentaba la importancia de ajustar la carga introducida en el sistema (los famosos usuarios virtuales) para realizar una prueba de prestaciones válida. Bueno, en esta ocasión me gustaría ofreceros una serie consejos a la hora de generar los escenarios de prueba, dependiendo del objetivo que persigamos.

En primer lugar, debemos tener en cuenta una serie de aspectos de la configuración que harán que los resultados de nuestra ejecución varíen sustancialmente:

• Rampa de entrada: Periodo en el que se introduce la carga total de usuarios. Ajustando el tiempo total de entrada, la frecuencia y el número de usuarios virtuales podemos cambiar completamente el comportamiento de la ejecución.
• Punto de saturación: Momento en la ejecución en el que el aumento de usuarios virtuales provoca un aumento continuado en los tiempos de respuesta. Este punto nos es muy útil a la hora de diseñar nuevos escenarios.
• Tiempos de espera (thinktimes): Tiempo que el hilo de ejecución permanece detenido entre peticiones, ajustando una mayor o menor duración del mismo el nivel de carga inyectado en el sistema varía, pudiendo generar un mayor ritmo de peticiones a la aplicación cuanto menor sea este.

Teniendo en cuenta estos conceptos, y algunos más sencillos, podemos generar una amplia variedad de pruebas. Vamos a ver algunos ejemplos dependiendo del tipo de escenario que queremos ejecutar:

• Prueba de escalabilidad: En este tipo de prueba, el objetivo es determinar el punto de saturación del sistema. Para ello, nuestra rampa de entrada no debe ser muy pronunciada y dilatarse bastante en el tiempo. De este modo, la persona encargada de la ejecución puede determinar en tiempo real el punto en el que los tiempos comienzan a degradarse. En ese momento, si es posible, la inyección de carga debería pausarse para comprobar si la respuesta sigue aumentando o si se estabiliza. Con estos resultados podemos buscar posibles cuellos de botella y determinar la cantidad de hilos que podemos utilizar en otros escenarios.
• Prueba de estabilidad: Si lo que queremos comprobar es cómo el sistema responde en periodos de uso continuados, este es el tipo de prueba a configurar. Utilizando como carga máxima entorno al 80 – 90% de la que obtuvimos en la prueba de escalabilidad, configuramos la duración del escenario para que se alargue durante varias horas una vez finalizada la rampa de entrada. Con este tipo de ejecución podemos detectar errores tipo memory leaks, dimensionamiento de sesiones en base de datos y problemas similares que no serían detectables con una ejecución más corta.
• Prueba de estrés: Este es el tipo de prueba a utilizar en aplicaciones que tienen grandes “picos” de uso; por ejemplo, webs de compra online en el famoso “Black Friday”. En esta configuración es cuando es importante ajustar los tiempos de espera entre transacciones de los scripts y la rampa de entrada de los usuarios virtuales. Una prueba de estrés bien configurada debería contener, al menos, una rampa de entrada corta con una carga de usuarios como poco igual a la determinada por la prueba de escalabilidad. Una vez introducida toda la carga, aguantaremos el nivel durante un corto intervalo, disminuyéndola después rápidamente hasta un 50%. De esta forma podemos comprobar cómo se recupera el sistema tras estos momentos de máximo uso.

Además de estos tipos de pruebas, podríamos añadir muchas más variantes. Entre ellas me gustaría destacar la regresión de prestaciones. Los más versados en QA os preguntaréis seguramente: ¿pero la regresión no es propia de pruebas funcionales? La respuesta es sí, también. Podemos generar un escenario base con una carga estable que, tras varias ejecuciones, nos proporcione una línea base de tiempos de respuesta y transacciones/hora. Con este mismo escenario, sin alterar la carga ni los scripts, podemos determinar si un cambio en la aplicación provoca una desviación en el rendimiento habitual del sistema.

Como podéis ver, es posible generar un sinfín de escenarios que se ajusten a las necesidades, solo es cuestión de determinar de forma clara los objetivos y, ya que somos nosotros los expertos, proporcionar a cada cliente la solución que más se ajuste a su situación.

Jorge Moya

Senior Test Engineer | Digital Assurance & Testing | SOGETI España