Pruebas de Carga con Team System (II): Pre y Post request Plugins

La mayoría de las veces, cuando necesitamos diseñar y crear nuestros webtest’s para una determinada prueba, el webtest que se genera desde el recorder de Team System es suficiente, y salvo pequeñas modificaciones, podemos utilizarlo directamente en nuestro test de carga. Hay ocasiones, sin embargo, en las que debemos introducir modificaciones más importantes y entonces necesitamos codificar nuestro webtest, de manera que perdemos un poco de la comodidad que resulta manejar nuestros webtest en formato visual.

En este POST os hablaré de los pre y post request plugins de los webtest, que nos van a permitir mantener nuestros webtest en formato visual, siendo estos plugins los que realicen de manera automática los cambios que necesitemos. Como su nombre indica, los pre y post request plugins incluyen acciones a realizar antes y después del envío de un request.

Imaginemos que nuestro webtest necesita enviar una cookie en concreto al servidor como parte de la cabecera del request. Esta cookie es dependiente del test en que nos encontremos y necesitamos controlar su inclusión en dicha cabecera. Desde la parte visual de configuración de un webtest no tenemos la posibilidad de modificar la inclusión de este tipo de parámetros, y siempre se mantendrá como parte del request aquello que el recorder haya grabado durante la creación del webtest. Si queremos modificar el valor de la cookie necesitamos pasar nuestro webtest a código para poder modificarlo:

 

Namespace TestProject1

    Public Class WebTest1Coded

        Inherits ThreadedWebTest       

        Public Sub New()

            MyBase.New

            Me.Context.Add(«WebServer1», «http://www.myserver.com»)

        End Sub

       

        Public Overrides Sub Run()

            Dim request1 As WebTestRequest = New WebTestRequest((Me.Context(«WebServer1»).ToString + «/»))

            request1.Timeout = 0

 

Dim CookieC As CookieCollection = New CookieCollection()

Dim c1 As Cookie = New Cookie(«OldCustomer», «TRUE»)

c1.Expired = False

CookieC.Add(c1)

request1.cookie.add(CookieC)

 

 

            MyBase.Send(request1)

            request1 = Nothing

CookieC  = Nothing

c1  = Nothing

 

        End Sub

    End Class

End Namespace

Vemos resaltadas las líneas necesarias para modificar el código de nuestro webtest e incluir la gestión de una cookie particular. Si además tenemos varios request que utilizan esta cookie, nos veremos obligados a codificar todos ellos y utilizar las mismas líneas de código. Una solución es utilizar los pre request plugins que nos van a permitir por un lado reutilizar el código y por otro mantener los webtest originales sin necesidad de codificación.

En el siguiente cuadro se muestra el código de un ejemplo de plugin que será llamado antes del envío de un request que lo incluya como referencia. Los detalles de cómo incluirlo como referencia en nuestro webtest y de cómo crear la clase que contendrá este plugin pueden consultarse en este link:

Imports System

Imports Microsoft.VisualStudio.TestTools.WebTesting

Imports System.Net

 

Namespace WebTestPluginNamespace

    Public MustInherit Class SampleWebTestPlugin

        Inherits WebTestRequestPlugin

        Public Sub PreWebTest(ByVal sender As Object, ByVal e As PreWebTestEventArgs)

 

            Dim CookieC As CookieCollection = New CookieCollection()

            Dim c1 As Cookie = New Cookie(«OldCustomer», «TRUE»)

            c1.Expired = False

            CookieC.Add(c1) 

e.request.cookie.add(CookieC)

 

            CookieC = Nothing

            c1 = Nothing

        End Sub

    End Class

End Namespace

Planificando el tráfico de nuestra página web

En uno de mis post’s anteriores os hable de las facilidades que nos dan herramientas como Team System para poder realizar pruebas de carga sobre una página o aplicación web. También hablé de cuáles eran los elementos a medir más importantes desde el punto de vista del rendimiento, y existe un dato común e importante que es el tiempo de respuesta o tiempo de carga de cada página.

Quiero hablar en este nuevo post sobre la importancia de realizar un buen análisis del uso que se va a dar a nuestra página, para poder facilitar la creación de modelos de uso o modelos de comportamiento de los usuarios que la visitan.

Una técnica muy interesante a la hora de planificar la carga que recibirá la página es la construcción de lo que se llama «Customer Behavior Model Graph». Este modelo o gráfico va a representar mediante probabilidades las transiciones que los clientes realizan cuando visitan la página. La utilidad de este tipo de gráficos es vital, sobretodo a la hora de realizar un buen diseño de las pruebas de carga, o a la hora de identificar el comportamiento típico de los usuarios. Muchas veces es curioso descubrir como aquellas páginas que diseñamos con más mimo, o a las que añadimos más características son luego las menos visitadas. 

Scott Barber presentó hace tiempo su UCML (User Community Modelling Language) con la intención de disponer de un lenguaje común para la representación del comportamiento de usuarios en la navegación web. En el siguiente link http://www.perftestplus.com/resources/ucml_1.1.pdf podéis encontrar toda la información sobre el mismo, así como plantillas de Visio con los objetos que necesita.

Os incluyo un ejemplo que he creado utilizando este lenguaje. Este ejemplo representa cuál serían las transiciones que los usuarios que se conectan a geeks.ms van a realizar. Como veis se tienen en cuenta tres tipos de usuarios, y se establecen tres páginas a partir de la de inicio: Blogs, Foros y Login. Los usuarios que hacen login también transitan hacia las páginas de Blogs o Foros. Este ejemplo es muy sencillo, y no se incluyen todas las páginas disponibles, ni todas las transiciones que se pueden producir de unas páginas a otras, pero da una idea de la utilidad de este lenguaje.

image

Conseguir los datos necesarios para obtener este modelo puede ser una tarea complicada. Necesitamos saber qué páginas visitan los usuarios, con qué probabilidad, que transiciones hacen desde cada una de las páginas, etc. Existen varias maneras de obtener los datos que necesitamos: 

  • Estimaciones basadas en páginas similares o proyectos con un contenido comparable
  • Demos, betas o presentaciones ante usuarios que van a poder jugar con la página, proporcionando información sobre los comportamientos más típicos
  • Logs de IIS

Los logs de IIS son sin duda la fuente más fiable y precisa, aunque estos logs sólo estarán accesibles una vez la página esté en producción, y siempre vamos a necesitar evaluar el rendimiento de la página antes de tener la versión final. 

¿Cuánto es el tiempo de carga de una página web que consideramos aceptable?

La verdad es que es una pregunta que cada vez me tengo que hacer más a menudo, y es que no hay duda de que a la hora de realizar el análisis del rendimiento de una aplicación web, o bien, a la hora de definir los requisitos mínimos de rendimiento que ésta debe cumplir, este es uno de los datos,  más importante que tenemos que definir.

El tiempo de carga o tiempo de respuesta de nuestra aplicación web va a depender de numerosos factores, siendo un hecho que el rendimiento de la aplicación va a disminuir a medida  que damos servicio a un mayor número de usuarios concurrentes. En el siguiente gráfico muestro un ejemplo de como puede variar el rendimiento de una página web a medida que más usuarios se conectan a ella:

clip_image002[4]

Para este caso concreto, vemos como el rendimiento de nuestra página web empieza a degradarse a partir de 200 usuarios concurrentes. En ese punto, el tiempo de respuesta empieza a crecer de una manera exponencial y es ya superior a los 10 segundos. La pregunta aquí es, ¿por qué establezco 10 segundos como límite? ¿Podría haber dicho 8 o 4? La verdad es que sí, el hecho de elegir un valor u otro puede ser demasiado arbitrario, depende de los requisitos de nuestra aplicación y carece del respaldo de un criterio ampliamente aceptado sobre este dato.

¿Cómo establecemos este dato? En alguno de los primeros proyectos en los que participé, el tiempo de respuesta máximo que se estableció estaba en torno a los 2 segundos. Este era un tiempo que parece razonable para un administrador de una página o para un usuario «impaciente», pero en la mayor parte de los casos está alejado de la realidad, en cuanto a que un usuario que se encuentra navegando en nuestro sitio, va a poder encontrar igualmente aceptable un tiempo de 4 segundos.

Vemos cómo el tipo de usuario al que va destinado nuestra aplicación es un primer elemento a tener en cuenta a la hora de definir estos tiempos máximos.

En segundo lugar, ¿tiene importancia el tipo de acción que el usuario está realizando en el tiempo de respuesta aceptable? La respuesta es claramente sí. Todos nosotros sabemos que el tiempo máximo que estamos dispuesto a esperar en la página de login no es el mismo que en un página en la que hacemos una consulta muy pesada sobre una base de datos para la obtención de un informe mensual.  La calidad que el usuario percibe sobre nuestra página puede verse afectada si en la página de login de hacemos esperar 20 segundos, provocando incluso que el usuario decida abandonar la página. Sin embargo, si el usuario puede ser mucho más paciente cuándo tiene la certeza de que la operación que realiza conlleva mucho más procesamiento.

A partir de lo anterior, vemos como el tipo de contenido que el usuario está visitando también va a influir en el tiempo de carga aceptable.

Os comentaba antes que en algunos proyectos el tiempo máximo de carga se establece en 2 segundos En otros en cambio, el tiempo de carga se establece en 30 segundos. Para este tipo de páginas lentas, que implican consultas pesadas o descarga de software extra, es fundamental nutrir al usuario con información sobre lo que está ocurriendo. Se hace fundamental proveer de mecanismos cómo las barras de progreso que hacen que el usuario no se impaciente, y espere el tiempo necesario para la carga de la página. El otro día me encontré con el siguiente ejemplo descargando el Windows Live Writer:

image 

De hecho, este fue el segundo mensaje que aparecía, ya que la descarga estaba siendo demasiado lenta, y los mensajes que se daban al usuario eran acordes al tiempo que ya llevaba esperando. En este caso, estuve más de 2 minutos esperando poder realizar la instalación antes de desistir. Un tiempo de 2 minutos puede llegar a ser aceptable para el usuario siempre y cuando le mantengamos informado sobre lo que está ocurriendo. En casos en los que el usuario no tenga porque conocer qué tipo de contenido es más o menos lento (tal y cómo comentaba en el punto anterior), la información que le proporcionemos puede ser fundamental para influir en su concepto de calidad o de tiempo de respuesta aceptable.

Incluyo pues cómo último elemento la información al usuario, que sumado al tipo de usuario y al tipo de contenido, nos va a ayudar a fijar los requisitos de calidad para nuestra aplicación. Así en lugar de fijar un tiempo máximo de respuesta por página, deberíamos fijarlo según el tipo de contenido, el tipo de usuario al que va dirigida y la cantidad de información que proporciona.

Os animo a que completéis este post con comentarios sobre experiencias propias en proyectos, o sobre aquellos otros elementos que podéis considerar interesante incluir en la lista de elementos a tener en cuenta.

Pruebas de Carga con Team System (I)

 

En este primer post quiero hacer un pequeño resumen de las capacidades para el análisis de rendimiento y pruebas de carga que introduce la versión de Visual Studio 2005 o 2008 Team System en su edición para testers.


Dada la cada vez mayor proliferación de arquitecturas basadas en modelos SOA, o en cualquiera de los modelos distribuidos ya existentes en multitud de aplicaciones que tenemos en funcionamiento ahora mismo, el aseguramiento de la calidad de servicio en cuanto al rendimiento que estas aplicaciones proporcionan se hace cada vez más importante y cada vez más difícil de garantizar.


En el siguiente esquema se muestra un ejemplo de una de estas arquitecturas distribuidas:


 


En este esquema vemos como la experiencia que el usuario final va a tener sobre el rendimiento de la aplicación va a venir determinada por la combinación del rendimiento de cada uno de las partes que la componen. En estas partes incluimos el rendimiento de nuestro servidor web, su interacción con el servidor de aplicaciones, los accesos a la base de datos, etc.


A pesar de que sigue siendo importante determinar el rendimiento y el consumo de recursos de la aplicación en cada una de las partes que la componen, es necesario y mucho más importante conocer el rendimiento que experimenta el usuario final de la aplicación. La forma más típica de caracterizar este rendimiento es a través del «Tiempo de Respuesta». Este tiempo de respuesta nos va indicar el tiempo medio en cargar en una página web, realizar una transacción on-line, obtener respuesta sobre una petición a un web service, etc.


Team System Testers Edition nos proporciona la posibilidad de realizar este tipo de análisis, con una suite de nuevas herramientas y un modelo de objetos que nos permitirá generar scripts para la generación de pruebas de carga. He tenido la posibilidad de trabajar en varios proyectos utilizando esta suite y los resultados han sido muy buenos, estando estas herramientas muy orientadas hacia las pruebas de sistemas que utilizan tecnologías como SOAP, XML, web services, etc


En el siguiente link podéis una muy buena introducción sobre esta suite y a sus características básicas:


http://msdn2.microsoft.com/en-us/library/ms364077(vs.80).aspx


Os incluyo aquí un resumen de lo que han sido para mi las características más interesantes:



  • Posibilidad de grabar directamente desde un navegador los pasos o transiciones que vamos a realizar sobre la pagina web que sirve de front-end a nuestra aplicación

  • Codificación de scripts para poder modificarlos a mano.

  • Base de datos con resultados de todas las pruebas generadas.

  • Generación de webtest para la prueba de peticiones unitarias sobre páginas web, servicios web, etc.

  • Generación de loadtest para la simulación de multiples usuarios realizando peticiones sobre nuestra aplicación web.

  • Sencillez de manejo.

  • Gran capacidad de generación de usuarios virtuales.

En siguientes post’s hablaré más en detalle de las posibilidades de esta herramienta así como de la solución a problemas concretos que han surgido durante su utilización.