Ya está disponible Under Feed r5
7 diciembre, 2012
Nuevos planes de Yammer
19 diciembre, 2012

Hace unos meses un cliente nos pidió que le realizáramos una evaluación del rendimiento de dos soluciones que estaban pensando adoptar y debían elegir.

Desde el primer momento, pensamos en crear un entorno distribuido de pruebas mediante Test Controller y Visual Studio. Debido a que era posible hacerlo en las instalaciones del cliente optamos por montarlo on-premise en un entorno propio del cliente. La otra opción habría sido tener en cuenta Azure y montar todo el entorno en la nube, con los agentes de prueba corriendo sobre Azure, tal y como hemos hecho en otros proyectos. Esta posibilidad sobre Azure la contaré en un futuro post.

Debemos saber que para poder disponer de una plataforma de testing distribuido debemos instalar en un servidor la herramienta Microsoft Test Controller y en uno o varios servidores Microsoft Test Agent. Test Controller se encarga de distribuir la carga de las pruebas a los distintos Test Agents y recopila los resultados de las pruebas de carga ejecutadas, almacenándolos en una base de datos propia.

Cuando se instala inicialmente el Test Controller debemos, además, configurar la base de datos. Nos sirve para ello cualquier otro servidor en el que dispongamos de un SQL Server, aunque la recomendación es utilizar un SQL Express en la misma máquina en la que instalemos Test Controller. Al configurarlo, lo que nos hace es crear una base de datos que irá guardando los resultados de todas las ejecuciones de las pruebas de carga.

En esta imagen podemos ver la conexión a dicha base de datos, que se llama LoadTest2010, con ese nombre por defecto y que recomendamos no cambiar.

Una vez configurado el Test Controller, instalamos y configuramos Test Agent en todas las máquinas que vayan a actuar como agentes de pruebas en nuestro entorno.

Para cada una de ellas debemos indicar el nombre del controller correspondiente para registrarlas y que éste tenga la posibilidad de enviarles las ejecuciones de los tests, repartiendo la carga entre todas las máquinas disponibles.

En nuestro caso, la configuración del entorno tratamos de simplificarla al máximo, pues las máquinas eran suficientemente potentes y dispusimos la siguiente arquitectura (algo diferente de la propuesta por Microsoft).

Una vez tenemos todo instalado y configurado, nuestra intención era ejecutar pruebas de carga, por ello, resulta interesante disponer de una simulación con el mayor nº de usuarios posibles. La licencia que se dispone con Visual Studio Ultimate solamente permite la ejecución de 250 usuarios concurrentes, por lo que nuestro cliente solicitó una licencia para aumentar el nº de usuarios en la ejecución. Esta licencia se introduce en la ventana del configurador del Test Controller y nos permite tener hasta 1000 usuarios.

Con esto ya tenemos el entorno configurado y listo para ejecutar las pruebas en remoto. Ahora nos faltaría crear en Visual Studio 2010 un proyecto de test que se conecte a nuestro Controller para ejecutar las pruebas remotamente.

Para ello, una vez creado el proyecto de test, en uno de los ficheros .testsettings existentes o creando uno nuevo (recomendamos crear uno nuevo), realizamos la configuración pertinente.

En la pestaña Roles, indicamos la ejecución remota e introducimos el nombre de nuestro controlador.

Una vez se ha detectado y está conectado, nos aparece el icono con el enchufe que se puede ver en la imagen superior, a la derecha del nombre del Controller (tachado).

Antes de iniciar la ejecución de nuestras pruebas de carga, seleccionamos el fichero de tests que hemos indicado que ejecute remotamente y, una vez lancemos las pruebas, veremos como en los indicadores de controller y agents de los gráficos de las pruebas de carga nos aparecen los datos de consumo de memoria, CPU, etc., indicando que nuestras pruebas se están ejecutando remotamente.

Una nota a tener en cuenta es, que cuando indicamos una carga de usuarios alta (1000 usuarios, por ejemplo), los tests pueden comenzar a fallar debido a errores por falta de memoria.

La solución consiste en que en el fichero testsettings modifiquemos la configuración de la pestaña Hosts según la siguiente imagen.

De este modo, la ejecución en 64 bits permite que la memoria disponible en el Test Agent sea mayor, pudiendo direccionar en base a 64 bits, lo cual nos evitará este tipo de errores.

Conclusión

Hemos visto, a modo muy sencillo, como instalar y configurar un entorno de testing remoto y distribuido para Visual Studio 2010.

En un futuro post abordaremos la implementación de este entorno sobre Azure, con las ventajas inherentes a la configuración y potencia de los entornos en Azure.

Compártelo: Share on FacebookTweet about this on TwitterShare on LinkedInPin on Pinterest

Comments are closed.

NEWSLETTER