En los últimos años se ha incrementado el uso de portales en Internet, sitios web que ofrecen al usuario acceso a recursos y servicios relacionados. A modo de ejemplo se encuentran links, buscadores, foros de discusión, documentos, aplicaciones, e-commerce, entre otros.
La disciplina de pruebas de performance intenta modelar el uso que los usuarios de una aplicación le dan a la misma a fin de detectar posibles cuellos de botella, aislarlos e intentar, con un equipo de expertos en la infraestructura y la aplicación, realizar cambios hasta encontrar la mejor configuración.
En el CES realizamos a diario pruebas de performance sobre distintos tipos de aplicaciones, con más o menos capas y distintas tecnologías. Contamos con una metodología la cual ha sido reconocida a nivel internacional. Si bien cada sistema tiene sus particularidades, las ideas generales para realizar un buen modelado de la realidad son similares.
En este artículo voy a centrarme en aspectos comunes para realizar pruebas de performance en portales. La principal particularidad se encuentra en la etapa de relevamiento, aquí a diferencia de otras aplicaciones, podrán estar integradas varias aplicaciones con lo cual se hace necesario identificarlas y, en base a ellas, seleccionar las herramientas a incluir para realizar la automatización. Luego, por cada una de estas aplicaciones, habrá que realizar las actividades que proponemos en nuestra metodología (Relevamiento, Automatización, Armado de la Infraestructura definitiva y Ejecución). Finalmente se deberá ejecutar una prueba en conjunto con todas las aplicaciones que brinda el portal, a fin de modelar su verdadero uso.
Una simplicidad que se da a diferencia de sistemas transaccionales es lo relacionado a la generación de datos. Ya que salvo excepciones, a priori no se consumen los datos utilizados para las pruebas. Lo cual al realizar varias pruebas complica el proceso, ya que la ejecución y posterior comparación queda ligada a la posibilidad de volver a un estado conocido el estado de la aplicación (incluyendo todos los componentes de la infraestructura, ej.: bases de datos).
Lo que más difiere últimamente entre portales y otro tipo de aplicaciones es lo relativo a facilidades que se le brinda al usuario.Ejemplos de esto son el “single sign on” y lastecnologías que apuntan a mejorar la percepción del usuario, como ser Ajax, Silverlight, flash, entre otras…que se dan más desde el lado del cliente. Todo esto habrá que considerarlo y ver la forma de emularlo a fin de lograr una carga similar a la que el portal estará recibiendo una vez en producción.
Lo otro que cambia, es el modelado del tráfico y del comportamiento de los usuarios. No es lo mismo a un sistema en donde el usuario tiene que usarlo y finalizar una tarea. Un portal es diferente. Por ejemplo, se tiene abandono de los usuarios (usuarios que abandonan el portal a la mitad de algo y no terminan transacciones), usuarios que buscan algo y no lo encuentran…
La literatura, en general, dice que hay que basarse en logs de navegación de portales similares o anteriores para poder determinar un escenario de uso lo más real posible.Este tipo de informaciónno siempre está disponible con lo cual muchas veces se estima en base entrevistas la simulación del uso del portal a generar. Asimismo, se intenta tipificar usuarios además de transacciones (lo que generalmente se tipifica), ya que para una misma transacción hay gente que puede llegar a utilizarla de manera diferente. A modo de ejemplo si la transacción fuese “consultar horarios de trámites” algunos usuarios tal vez solo consulten esos horarios y los impriman y otros de allí pasen a solicitar un número para realizar un trámite.
En conclusión, dado que los usuarios tienen un comportamiento diferente y son potencialmente diferentes para cada ejecución de la transacción (no es como en un sistema transaccional en donde se loguea una vez y nada más) es que la forma de modelar la realidad se basa en el comportamiento que los usuarios le dan al sistema más que en las funcionalidades.
