menu_superior

El tiempo de respuesta no es un valor absoluto ni estático

dashboardLas pruebas de rendimiento, a diferencia de las pruebas funcionales, producen unos resultados no booleanos. Es decir el resultado de una prueba funcional sólo puede ser Fallo o No Fallo, mientras que el resultado de una prueba de rendimiento puede ser 2,5 segundos, 112 trasacciones por minuto o 38 usuarios simultáneos. ¡Incluso los 3 a la vez! Esta característica hace necesario un análisis de resultados al final de la prueba con el fin de conocer si se ha sometido al sistema a la carga esperada y si ha superado los objetivos iniciales de la prueba.

En resumidas cuentas, las pruebas de rendimiento requieren de una cierta ingeniería, no son triviales, de ahí el título del post. No es la primera vez que en el inicio de un proyecto de pruebas, al preguntar por los objetivos de las pruebas, el cliente responde que pretende “conseguir que una aplicación tenga un tiempo de respuesta inferior a X segundos”. En algunos casos (pocos) si estás familiarizado con el contexto de la aplicación este tipo de objetivos te pueden servir. Desgraciadamente, la mayoría de las veces no estás familiarizado y te falta contexto para comprender este objetivo porque, como digo en el título, el tiempo de respuesta no es valor absoluto ni estático.

No es un valor estático

Dependemos de las condiciones en las que esté trabajando el sistema, entre otras de circunstancias como las siguientes:

  • Nivel de concurrencia o carga de trabajo. El tiempo de respuesta del sistema con 100 usuarios no será igual que cuando hay un nivel de 1000 usuarios. Es decir, que la carga de trabajo y la concurrencia juegan un papel muy importante. Incluso aunque el número de usuarios operando en el sistema sea el mismo, dos pruebas que ataquen con diferentes esquemas de ejecución (puntos de agrupación de usuarios, entrada escalonada, etc.) tendrán tiempos de respuesta y resultados diferentes.
  • Condiciones de la prueba. Los componentes hardware que soportan al sistema, así como las comunicaciones necesarias también aportan un factor de variabilidad. Normalmente estos factores se tienen en cuenta… a medias, porque todos solemos ser conscientes de la potencia de las máquinas pero no del resto del entorno: no es igual hacer las pruebas dentro del edificio de la empresa que en las ubicaciones desde donde se accede a la aplicación. Igual que no es lo mismo hacer pruebas en plataformas idénticas a las de producción que hacerlas en un entornos no comparables o que se están sujetos a cambios constantemente.

No es un valor absoluto

Necesitamos matizar el tiempo de respuesta, aderezarlo con otros datos para que el nivel de información aportado sea relevante:

  • Picos, valles y volumen. El tiempo medio de respuesta depende del tipo de prueba que estemos ejecutando, si la carga varia significativamente el tiempo de respuesta debería hacerlo tambien. En estos casos nos interesa acotar el tiempo de respuesta a los picos (máximos de la representación gráfica), los valles (mínimos) y cuando indican saturación del sistema por haber sobrepasado la capacidad máxima.
  • La velocidad de procesamiento puede ocultar consumo de recursos, ineficiencia, etc. Tener tiempos de respuesta muy buenos no nos garantiza que la aplicación sea muy eficiente, especialmente si las pruebas son cortas. Es aconsejable ejecutar pruebas de volumen (alta carga de trabajo con duración prolangada) y verificar el uso de recursos antes, durante y después de la prueba para asegurarnos que hace un uso eficiente.

Asi que la próxima vez que alguien mencione el tiempo de respuesta como objetivo único y primordial, recordadle que hay muchas variables que hay que tener en cuenta ya que por sí solo no es valor significativo para calibrar el rendimiento de un sistema informático.

, , ,

Comments are closed.