En Visual Studio 2010 Ultimate podemos hacer pruebas de carga de manera remota utilizando varias computadoras simultáneamente. Esto se logra a través de una arquitectura en la que se tiene un controlador de pruebas y uno o varios agentes de prueba. Cada agente de prueba corre las pruebas y almacena información del resultado, cada uno esta asociado a sólo un controlador. El controlador puede tener asociado varios agentes y administra y concentra los resultados de las pruebas de cada uno
Los agentes y controladores de prueba se instalan a través del instalador Visual Studio Agents 2010, que se muestra a continuación

Aquí tenemos tres opciones de instalación, “Install Microsoft Visual Studio Test Controller 2010” para instalar un controlador de prueba, “Install Microsoft Visual Studio Test Agent 2010” para instalar un agente de prueba e “Install Microsoft Visual Studio Lab Agent 2010” para instalar un agente de laboratorio de pruebas que se usa para pruebas remotas a través del TFS y que solo se puede instalar en máquinas virtuales
Para esta prueba yo instalé el controlador de pruebas en mi máquina local. Al final de la instalación podemos configurar el controlador si tenemos marcada la opción “Configure test controller now” o podemos entrar a configurar el controlador de pruebas luego de la instalación en Inicio->Programas->Mocrosoft Visual Studio 2010->Microsoft Visual Studio Test Controller 2010 Configuration Tool
La herramienta de configuración se muestra a continuación

En el primer bloque especificamos un usuario con cuenta de administrador de la máquina con el nombre de dominio si fuera necesario. El segundo bloque lo dejamos inhabilitado ya que no estamos trabajando con TFS en este caso. En el tercer bloque especificamos el nombre de un servidor sql donde el controlador va a guardar los datos de los resultados de las pruebas, este servidor puede ser sqlexpress de la máquina local
Con Visual Studio 2010 Ultimate tenemos la posibilidad de correr pruebas de carga simulando un máximo de 250 usuarios en pruebas locales y usando un solo núcleo del procesador de la máquina. Para simular usuarios de manera remota así como para usar mas de un núcleo del procesador de la máquina del controlador hay que obtener una licencia de un paquete de usuarios virtuales para pruebas de carga para visual studio 2010(Visual Studio Load Test Virtual User Pack 2010), cada licencia obtenida da un total de 1000 usuarios virtuales para la simulación de las pruebas de carga. Con una subscripción MSDN podemos obtener esta licencia. Para agregarla al controlador, en el configurador hacemos clic en el botón “Manage virtual user licenses” y agregamos nuestra o nuestras licencias.
Cuadro de diálogo para agregar las licencias

Con esto podemos aplicar los cambios y proceder a instalar los agentes de prueba
En este caso, yo instalé dos agentes de prueba, uno en mi máquina local que va a correr la prueba y otro en una máquina externa que va a recopilar información de la prueba a través del ASP.NET Profiler
Para instalar los agentes volvemos al instalador de Visual Studio Agents 2010 y escogemos la opción “Install Microsoft Visual Studio Test Agent 2010”. Al igual que en la instalación del controlador podemos configurar el agente al final de la misma, o podemos cerrar el instalador e ir a Inicio->Programas->Microsoft Visual Studio 2010->Microsoft Visual Studio Test Agent 2010 Configuration Tool. En el primer paso de la herramienta de configuración escogemos la opción Service, ya que no vamos a interactuar con aplicaciones de escritorio, sino con una sitio web. El siguiente paso es muy parecido a la herramienta de configuración del controlador

Especificamos un usuario administrador y su contraseña y en el segundo bloque especificamos el nombre de la máquina (o el número IP) donde esta el controlador de pruebas al que queremos asociar este agente y previamente instalamos. Si todo sale bien, al final, nos saldrá un cuadro de diálogo como el siguiente

Para configurar y correr las pruebas de carga utilizamos Visual Studio 2010 Ultimate. Aquí, creamos un proyecto de prueba

y en él agregamos un archivo de prueba web sobre el que vamos a correr la prueba de carga

Una prueba de este tipo nos permite “grabar” una secuencia de actividades sobre un sitio web para luego ser ejecutadas en el mismo orden. Yo en particular ejecuté la prueba sobre un pequeño sitio que solo consta de dos páginas. Cuando se agrega la prueba al proyecto inmediatamente aparece el navegador para guardar la secuencia de acciones que queremos probar

Cada comando que ejecutemos en nuestro sitio se irá guardando como se muestra a continuación en el panel de la izquierda del navegador

Este panel izquierdo aparece en el navegador gracias a un Add-on de internet explorer que se llama Web Test Recorder. Si al ejecutar la prueba no aparece esta barra o aparece deshabilitado el botón de grabar, entonces es probable que este deshabilitado este Add-on. Para habilitarlo, en el internet explorer, en el menú, vamos a Tools->Manage Add-ons, nos parece un cuadro de diálogo y bajo la sección “Toolbars and Extensions”, buscamos “Microsoft Web Test Recorded” de “Microsoft Corporation” y lo habilitamos como se muestra en la imagen

Cuando hayamos ejecutado todas las acciones que queremos guardar en nuestra prueba, la detenemos a través del botón de Stop del “Web Test Recorder”. Visual Studio nos muestra todas las páginas visitadas en nuestra “grabación”

Ejecutar esta prueba, significa volver a visitar todas las páginas que se guardaron en la misma. El objetivo de la prueba de carga es correr esta prueba varias veces simulando varios usuarios simultáneos
Ahora agregamos una prueba de carga al proyecto

Al agregarla aparece un wizard para la configuración de la misma. La primera página es una introducción. En la segunda página podemos poner el nombre de la prueba y cómo queremos que se comporte la simulación del “tiempo de pensamiento” entre cada prueba. Esto es un tiempo de espera entre cada iteración de las pruebas simulando usuarios reales visitando nuestro sitio a probar

En el siguiente paso especificamos la cantidad de usuarios que queremos simular y cómo va a ir comportándose la cantidad de éstos durante el transcurso de la prueba o si se van a mantener constante

Como en las pruebas de carga se pueden ejecutar varias pruebas al mismo tiempo, en el siguiente paso tenemos la opción de escoger la forma en la que queremos que se ejecuten estas en conjunto

Esto es porque un paso más adelante nos van a preguntar sobre el porciento de ejecución de cada prueba que agreguemos. La opción que escojamos aquí nos dice cómo se van a interpretar esos porcientos. Si tuviéramos dos pruebas, la A y la B y a la prueba A le ponemos un 75% de ejecución y a la prueba B un 25% de ejecución, entonces para cada opción la interpretación es la siguiente:
Basados en el número de pruebas que se hagan: Si la cantidad total de veces que se corrieran las pruebas en nuestra prueba de carga fuera 100, 75 de ellas se hicieran sobre la prueba A y 25 de ellas sobre la prueba B
Basados en el número total de usuarios: Si vamos a hacer nuestra prueba de carga con 1000 usuarios virtuales, 750 de ellos van a correr solo la prueba A y 250 de ellos solo la prueba B
Basados en el ritmo del cada usuario: Cada usuario virtual va a ejecutar 3 veces la prueba A y una vez la prueba B cíclicamente
Basado en el orden de ejecución: Cada vez que se terminen tres ejecuciones de la prueba A se va a ejecutar la prueba B una vez, independientemente del usuario virtual que le toque. La diferencia de este caso con el primero es que aquí se sigue un orden secuencial, solo se ejecuta la prueba B si la A ya se ha ejecutado tres veces
En realidad para nuestro caso solo vamos a agregar una prueba a ejecutar, por lo que mi opción a escoger en este paso no hace ninguna diferencia
En el siguiente paso agregamos nuestra prueba web hecha anteriormente que va a acaparar el 100% de las pruebas de la prueba de carga

En el siguiente paso podemos simular una mezcla de velocidades de red para las pruebas

En el siguiente paso una mezcla de navegadores para las pruebas

En el siguiente paso vamos a ver agregados los contadores que tenemos en nuestra máquina para medir la prueba y podemos agregar contadores de otras máquinas

y en el último paso podemos escoger si la prueba va a tener un límite de duración, o un límite de cantidad de iteraciones así como detalles del logeo en caso de errores

Una vez configurada la prueba veremos en el Diseñador de Visual Studio un sumario en forma de árbol de la configuración que acabamos de hacer
Ahora tenemos que agregar el controlador y los agentes a la prueba de carga
En Visual Studio, vamos a la opción de menú Test->Manage Test Controllers…, aparecerá una ventana de diálogo donde pondremos el nombre de la máquina donde esta el controlador, y veremos la cadena de conexión de la base de datos donde se va a guardar la información de los resultados de la prueba y los agentes asociados al controlador, como se muestra a continuación

En esta ventana, a cada agente le vamos a poner una propiedad con un valor, el nombre de esta propiedad puede ser cualquiera y su valor también. El objetivo de esto es poder asociar mas adelante los roles de nuestra prueba de carga con cada uno de estos agentes, como veremos mas adelante. Esto lo hacemos a través del botón Properties. En este caso, yo le puse a mi máquina local, la propiedad Server, con valor true y a la máquina externa la propiedad con nombre Server con valor false como se muestra a continuación

Cerramos estas ventanas y en el explorador de soluciones de Visual Studio hacemos doble clic en el elemento Local.testsettings que esta debajo de Solutions Items. Nos aparece un cuadro de diálogo de propiedades de la prueba. Vamos a la sección Roles y en la lista desplegable “Test execution method” escogemos la opción “Remote execution” y en la caja de texto “Controller” ponemos el nombre de la máquina donde esta el controlador

Mas abajo en “Roles”, vamos a agregar dos roles, cada uno de ellos nos va a representar un agente de prueba para este caso, aunque en realidad cada rol puede tener asociado mas de un agente. Agregamos los dos roles que en este caso yo les llame “WebTest” y “Profiler”, dejándole al rol WebTest la opción de ser el rol que va a correr la prueba

Debajo de los roles agregados, aparece una lista de atributos asociados a cada uno, que en este momento esta vacía. Estos atributos nos sirven para filtrar los agentes asociados a cada rol. O sea, si en este momento le damos a la opción “Preview matching test agents” para cada rol nos aparecerán los dos agentes asociados al controlador como se muestra a continuación

Esto es porque no tenemos ningún filtro asociado a los roles para los agentes. Si agregamos al rol WebTest un atributo con nombre Server y valor true veremos que al ir a “Preview matching test agents” solo nos sale el agente que cumple con estos atributos porque así lo configuramos anteriormente. De la misma manera, al rol Profiler le ponemos un atributo con nombre Server y valor false solo nos saldrá asociado el otro agente
Ahora en la sección “Data and Diagnostics” vamos a deseleccionar todos los valores para el rol WebTest, ya que este solo nos interesa para correr la prueba, como se muestra a continuación

Y para el rol Profiler solo seleccionamos el valor de ASP.NET Profiler, pues solo lo queremos para guardar los datos del ASP.NET Profiler

Hecho esto aplicamos los cambios y podemos proceder a ejecutar nuestra prueba de carga
Mientras se ejecuta la prueba de carga en el diseñador de Visual Studio veremos gráficas del avance de a lo más cuatro de nuestros contadores

Al final veremos un sumario de la prueba

En esta vista, le damos clic al botón “View profile performance report” (Penúltimo botón en la barra de botones del sumario). Esto nos genera el reporte del resultado obtenido por el ASP.NET Profiler. El reporte debe ser parecido a este

En este reporte se muestra al inicio, el camino hacia la función que mas se demoró en la ejecución de la prueba. Ahí vemos el proceso del IIS, el w3wp como raíz, debajo el método ProcessRequest de la página defualt2.aspx, luego el método ProcessRequest del objeto Page, luego el método Page_Load de la página default2.aspx y luego un llamado al índice de cadena del objeto HttpRequest de la página. Si damos clic en cualquiera de estas ligas de llamado a métodos, se nos muestra una representación del tiempo de demora, en porcientos de cada uno de los comandos que ocurrieron en este método y, de ser posible(o sea, si se tiene el archivo de símbolos asociado), el código ejecutado. Por ejemplo, en mi prueba, yo tengo el archivo de símbolos de la página default2.aspx, por lo que al darle a la liga del llamado al método Page_Load de la misma, me muestra lo siguiente

A través de la representación gráfica superior se puede navegar por cada uno de los métodos ejecutados, pero solo si se tiene el archivo de símbolos del código en cuestión, se podrá ver el código exacto ejecutado, mostrando en rojo la línea mas demorada. En mi ejemplo, si en vez de darle a la liga del Page_Load de mi página, le hubiera dado a la liga del llamado al ProcessRequest del objeto Page me hubiera mostrado lo siguiente

Aquí se ve una representación gráfica de los llamados de las funciones, pero no el código porque yo no tengo el archivo de símbolos asociado a la clase Page
Posteriormente escribiré otro post haciendo una prueba de carga similar sobre una aplicación en SharePoint