Pruebas de prestaciones, usuarios “virtuales” vs. usuarios “reales”

Durante mi carrera en QA me he encontrado en múltiples ocasiones en la tesitura de explicar a mi cliente por qué los “usuarios” que aparecen en los informes de pruebas de rendimiento no se corresponden con usuarios “reales”. A lo largo de este artículo voy a intentar explicar la diferencia entre ellos, así como la mayor importancia y utilidad de otras métricas.

Para comenzar vamos a tomar como ejemplo una aplicación típica de imputación horaria. La mayor parte de sus usuarios están familiarizados con su funcionamiento por lo que no debería llevarles más de 5 ó 10 minutos tener un parte de actividad cumplimentado y enviado. Vamos a llamar a este grupo “usuarios expertos”. Por otro lado, hay nuevas incorporaciones en la plantilla que aún no dominan la aplicación, “usuarios novatos”, que pueden tardar entre 20 y 25 minutos en realizar las transacciones de introducción y envío. Además, podemos agregar un tercer tipo de “usuarios remolones” que pueden tardar una hora en finalizar la operativa ya que aprovechan ese rato para ir a tomar un café o estirar un poco las piernas entre imputación e imputación. Estos tres grupos conformarían un conjunto típico de usuarios “reales”, ¿no os parece?

Bien, antes de continuar voy a recordaros que una prueba de rendimiento consiste, de forma muy resumida, en inyectar carga sobre un sistema para comprobar una serie de métricas, encontrar posibles cuellos de botella y verificar el correcto funcionamiento de toda la arquitectura.

Con esta pequeña definición en mente, ¿cuál de nuestros tres tipos de usuario genera, a priori, mayor carga en el sistema? La respuesta más obvia sería el grupo de “usuarios expertos”, realizan las mismas operaciones que el resto de grupos en menor tiempo. Sería una respuesta válida pero, ¿y si os dijese que los “usuarios remolones” acceden al sistema, se quedan mirando la pantalla durante 59 minutos y realizan las operaciones todos a la vez en menos de un minuto? El nivel de carga de estos usuarios sería mayor. Pero voy a ir más lejos, ¿qué ocurre si los “usuarios novatos” se confunden al introducir los datos y deben repetir constantemente el envío del formulario? Este grupo también genera bastantes peticiones, ¿verdad?

Con este ejemplo, parece difícil diseñar una prueba de prestaciones que simule el uso habitual de la aplicación. Pues bien, exceptuando pruebas cuyo objetivo sea medir el número de sesiones concurrentes, deberíamos enfocar las pruebas siempre hacia el número de operaciones que el sistema puede realizar en un tiempo determinado sin que el tiempo de respuesta de las mismas se vea afectado. Para esto contamos con los usuarios “virtuales” que también podemos denominar como “hilos de ejecución”. Este tipo de usuarios realizan una serie de operaciones en el sistema con tiempos de espera (los famosos thinktimes de los que hablaré en un futuro post) entre cada petición.

Con todo lo que hemos visto hasta ahora podemos empezar a afirmar que la importancia de la métrica “usuarios” en un informe de pruebas de prestaciones no tiene tanta importancia como podría parecer en un principio. Es una medida que nos es útil a los testers (a excepción de algunos tipos de pruebas, repito) para poder manejar el volumen de carga y la forma en la que esta se introduce en el sistema.

La métrica más importante es el número de operaciones por segundo/minuto que soporta el sistema. Esta medida nos indicará cuándo el rendimiento se degrada ya que se realizarán menos operaciones cuando los tiempos de respuesta se vean afectados. Otras métricas vitales en una buena prueba de rendimiento son todas las referentes a la monitorización de los sistemas implicados, sin esta información la prueba se queda “coja” ya que podemos saber cuándo se degrada el sistema pero no tenemos ninguna pista de dónde se pude encontrar el cuello de botella”. Adicionalmente se debe incluir el informe de tiempos de respuesta de las operaciones para poder analizar cuáles son las más “pesadas” y ayudar al cliente a focalizar el problema.

En resumen, el grado de simulación de un usuario “real” en unas pruebas de prestaciones es bajo debido a la variedad de situaciones que se dan en el “mundo real ^tm”. Para evitar desviar la información importante es preferible modificar nuestra terminología y referirnos a “hilos de ejecución”, “concurrencia” o similares.

Jorge Moya

Senior Test Engineer | SOGETI España