Test de Carga: Web Performance Test con Visual Studio 2010

por Diego Rosso  22. diciembre 2011

 

Pequeña introducción

Continuando con el post anterior vamos a mostrar cómo podemos realizar pruebas de carga sobre nuestras aplicaciones web utilizando Visual Studio 2010 en forma más detallada. La idea principal es ver cómo responde nuestra web ante varias peticiones concurrentes y obtener información sobre los Performance Counters de nuestros servidores que nos servirán de base para detectar problemas en la aplicación o en los servidores donde está alojada.

Que son los Performance Counters?

Los contadores de rendimiento son objetos del sistema operativo que nos muestran información sobre el rendimiento del hardware y software, como por ejemplo la memoria, el disco y los procesos.

Un contador es una medida de un parámetro determinado. Estos se organizan en grupos como por ejemplo los que vienen con el sistema operativo que están comprendidos dentro del objeto System y otros que se instalan como los de SQL Server.

Windows trae una herramienta para acceder a los objetos y sus contadores, la misma se llama Performance Monitor, la cual podemos accederla yendo a Incio --> Ejecutar --> y escribir Perform.

 

 

LoadTest1

 

WebTests

Para realizar nuestras pruebas de stress lo primero que debemos hacer es crear nuestros Webtest, en el cual se definen cuáles son las urls sobre las que van a realizarse las pruebas. Algo muy importante es que deben tener instalada la versión Ultimate del Visual Studio 2010 para poder contar con estos tipos de test (la versión 2008 del Visual Studio ya contaba con esta funcionalidad).

Pasos para crearlo.

1. En el visual Studio vamos a crear un nuevo proyecto del tipo Test, para eso ir a New –> Proyect  --> Test --> Test project y generamos el proyecto base de test.

 

LoadTest2

 

2. Eliminamos la clase que nos agrega por default.

 

LoadTest3

 

3. Agregamos un nuevo test del tipo Web Performance Test, haciendo botón derecho sobre el proyecto –> Add --> Web Performance Test

 

LoadTest4

Al hacer esto se nos abrirá el Web Test Recorder, donde debemos ingresar la dirección web que deseamos testear, en nuestro ejemplo ingresaremos www.google.com.ar y vamos a buscar VEMN y veremos como el Recorder va guardando las urls junto con sus parámetros gets, los cuales están dentro de una carpeta llamada QueryStrings Parameters.

 

LoadTest5

Luego cerraremos esta ventana y vamos a quedarnos a nivel de ejemplo con solo la primer URL y sus parámetros.

 

LoadTest6

 

 

 

Ahora debemos agregar a nuestro proyecto un Load test (test de carga) que será el encargado de simular múltiples peticiones sobre la URL que cargamos en el Webtest. Para esto hacemos botón derecho sobre el proyecto y seleccionamos add-->Load Test y se nos abrirá un wizard con su clásica ventana de bienvenida le damos next para para a configurar el test de carga.

 

LoadTest7

 

Lo primero que nos pide es un nombre para el escenario de test que vamos a crear y nos pide seleccionar que tipo de pausas queremos entre la ejecución de las distintas iteraciones, en el ejemplo lo dejaremos como viene por default y le pasaremos al próximo paso.

 

LoadTest8

En este caso nos pide que seleccionemos el patrón de carga el cual puede ser constante donde le definimos la cantidad de usuarios que debe simular de forma constante durante el transcurso de toda la prueba, o incremental que es el que vamos a elegir nosotros para nuestro ejemplo, los parámetros que nos pide son los siguientes

  • · Start User Count: Cantidad de usuarios que se generaran cuando comience la prueba, en nuestro caso pondremos 20.
  • · Step Duration:  Donde definimos la cantidad de segundos que van a pasar hasta que se agreguen más peticiones sobre la URL que estamos testeando, en nuestro caso 15 segundos.
  • · Step User Count:  Cantidad de usuarios que se agregaran una vez transcurrido el tiempo configurado en Step Duration.
  • · Maximun User Count: Donde definimos la cantidad máxima de usuarios a simular.

 

LoadTest9

 

Luego nos pide el modelo a utilizar por el test de carga, en nuestro caso elegiremos el primer modelo basado a partir del número total de pruebas. Podemos ver aquí un detalle de cada uno de estos modelos.

 

 

LoadTest10

 

En el próximo paso del asistente debemos elegir los webtest que deseamos testear en el presente escenario, en nuestro caso vamos a elegir el único que tenemos pero podríamos seleccionar varios y asignar la distribución para cada uno de estos.

 

LoadTest11

Ahora ingresamos las distintas formas de conexión que deseamos testear y la distribución que queremos darle a cada uno.

 

LoadTest12

 

En el próximo paso seleccionaremos los distintos browsers que queremos que el test de carga simule y la forma en que se distribuirá la carga.

 

LoadTest13

 

Ahora debemos ingresar el nombre del equipo que deseamos supervisar que debería ser donde se encuentra alojado el sitio web que estamos probando, este debe ser un servidor el cual se encuentre en nuestra red o nuestra propia máquina. Si nuestro sitio tiene distintos servidores como por ejemplo uno para la BD y otro para donde se encuentra alojado el sitio, podemos agregar ambos haciendo click en add computer.

Debemos seleccionar los performance counter que deseamos monitorear en cada uno de los equipos.

 

 

 

LoadTest14

En el último paso del Wizard, nos pide la duración del test que en nuestro caso lo vamos a dejar en 10 minutos y también podemos configurar si queremos que nos genere un log cada vez que un test falle, entre otras cosas.

Presionamos sobre Finish y podemos ver como quedo configurado nuestro test de carga.

 

LoadTest15

 

Listo! Estamos en condiciones de poner a correr nuestro test y ver el comportamiento de los performance counters de los diferentes equipos supervisados.

 

LoadTest16

 

En nuestro próximo post vamos a ver cómo generar el código de nuestros Webtest para hacerlos más dinámicos y como pasar parámetros a la URL a través de distintas fuentes como pueden ser base de datos, archivos csv o xmls.

Tags:

.NET | Desarrollo Web | Testing | Visual Studio

Testing unitario y TDD con Visual Studio 2010

por Victor Passador  4. agosto 2011

“Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.” ExtremeProgramming.org

 

Un poco de contexto

Como generalmente sucede en todos los ámbitos, una de las cosas más difíciles de conseguir es el equilibrio, y la creación de Tests Unitarios no queda fuera de esta premisa.

Por un lado es imposible negar los beneficios que aporta contar con pruebas automatizadas, pero por otro lado también se hace difícil contradecir a aquellos que argumentan que es muy costoso su mantenimiento ante cambios en los requerimientos.

No es la idea de este post entrar en un debate interminable defendiendo una postura u otra, sólo me limitaré a decir que no somos fanáticos de los extremos y que si bien consideramos que es indispensable contar con un buen set de pruebas unitarias, tampoco perdemos de vista el costo de su mantenimiento y vamos adaptando el modelo según las necesidades y posibilidades.

Antes de ir directamente a la herramienta, repasemos algunas definiciones.

 

El ABC de las pruebas unitarias

Toda prueba unitaria que se precie de tal, deberá contar sí o sí con las siguientes características:

  • Ejecución rápida
  • Ambito limitado
  • Automatizable y repetible
  • Cualquiera puede ejecutarlo
  • Independiente
  • Alta cobertura de código

 

El ABC del TDD

En el Desarrollo Guiado por Pruebas (Test-Driven Development – TDD) se dice que no existe ningún motivo para escribir código salvo alguna prueba que esté fallando. Esto obliga (a modo de resumen) a trabajar con un ciclo de vida que incluye los siguientes pasos:

  • Ante cada nuevo requerimiento, escribir un test. El test inevitablemente fallará porque no hay código que implemente ese requerimiento todavía.
  • Escribir el código que pase el test. Se deben enfocar los recursos a que el test pase, sin preocuparse por cuestiones “superfluas” (.. del tipo “ya que estamos, agrego una sobrecarga que reciba tal parámetro porque probablemente lo necesite más adelante”). Tampoco por la elegancia del código. El único objetivo es que el test pase.
  • Refactorizar: Es aquí donde se modifca el código para mejorar cuestiones como mantenibilidad, limpieza de código duplicado, etc., sin afectar obviamente la funcionalidad. Esto se comprueba corriendo sucesivamente las pruebas (aquí se ve el beneficio de pruebas que se puedan ejecutar en poco tiempo).

 

Entrando ahora sí de lleno en la herramienta, veamos qué nos aporta en este sentido.

 

Ayudas en la edición de código

Como soporte a la práctica de TDD, Visual Studio 2010 cuenta con algunas funcionalidades orientadas a la mejora en la productividad en este ámbito:

Code Snippets: permiten rápidamente generar clases de test (“testc”) o métodos de test (“testm”)

imageimage

Al escribirse primero las pruebas, obviamente fallaran las referencias a las clases a testear, pero con la generación automática de código, se facilita la tarea de crear el esqueleto de esas clases:

image

image

Intellisense en modo Suggestion: En el modo al que estábamos acostumbrados a usar Intellisense (modo Completion), era fácil agregar una referencia a un tipo o variable existente, pero esto no es muy “TDD Friendly”. En VS2010 existe también el modo Suggestion (se activa con Ctrl+Alt+Space) que muestra, mientras estamos tipiando, un cuadro de texto sobre la lista de tipos sugeridos sin obligarnos a seleccionar ninguno.

image

Ejecución de pruebas unitarias

En cuanto a la ejecución de las pruebas unitarias, más allá de nuestro objetivo de ver muchos iconitos verdes, una de las metas buscadas es conseguir una alta cobertura de código. De nada sirve tener toda una batería de pruebas unitarias si estamos cubriendo (probando) menos de la mitad del código escrito.

La cobertura de código (Code Coverage) es una métrica importantísima que deberíamos obtener para poder certificar que nuestros casos de prueba están cubriendo la totalidad (o la mayor parte posible) del código de la aplicación.

Para habilitar los reportes de Code Coverage en VS2010 tenemos que modificar el archivo “Local.testsettings” y dentro de la opción “Data and Diagnostics” marcar el check correspondiente a “Code Coverage”

CodeCoverageSettings

Una vez ejecutadas las pruebas, en la ventana Code Coverage Results, podremos ver los porcentajes de ese indicador y a su vez, en el editor de código, ver resaltadas las líneas afectadas por la prueba.

CodeCoverageResults

Posts anteriores de esta serie:

Para ir calentando motores …

Contribuyendo a la mejora de calidad de software

Algunas referencias más:

http://geeks.ms/blogs/adiazmartin/archive/2010/01/12/m-225-s-r-225-pido-con-visual-studio-2010-intellisense-para-tdd.aspx

http://blogs.msdn.com/b/ukvsts/archive/2010/03/17/test-driven-development-with-visual-studio-2010.aspx

 

Hasta la próxima!

Tags: , ,

Testing | Visual Studio | ALM

Testing con VSTS 2010–Contribuyendo a la mejora de calidad de software

por Victor Passador  19. abril 2011

Como habíamos prometido, daremos inicio con este post a la serie de publicaciones con las que intentaremos mostrar de qué manera se puede incrementar la calidad del software que nuestra empresa produce, mejorando el proceso de testing en las diferentes formas que toma a lo largo del ciclo de vida de la aplicación.

Tipos de testing vs. herramientas de testing

En las primeras etapas del ciclo de vida de la aplicación, en aquellas donde se comienzan a implementar mayormente requerimientos no funcionales (APIs, frameworks, etc.), se requiere de un tipo de tester especializado, con altos conocimientos de programación, que genere casos de pruebas unitarias con un alto grado de automatización (cuando digo alto apunto al 100% de automatización)

A medida que las iteraciones avanzan y se empiezan a obtener las primeras piezas funcionales, aparece la necesidad de un testing totalmente diferente, opuesto, donde el tester necesita altos conocimientos del proceso de negocio y pocos o nulos conocimientos de programación.

Si trazáramos una línea, podríamos decir entonces que tenemos en una punta un testing de tipo “especializado”, con mayoría de casos de test automatizados construidos por expertos en programación, y en la otra punta un testing más “generalista” con gran cantidad de casos de test manuales a cargo de especialistas en el negocio en cuestión, con toda una escala de grises en el medio.

Generalista vs. Especialista 001

Según algunos estudios, se indica que la mayoría de las herramientas de apoyo al testing apuntan a la parte “especialista”, siendo que el grueso del esfuerzo que realiza la empresa se ubica en la parte “generalista”

Generalista vs. Especialista 002

VSTS 2010 como solución ALM ante la problemática del testing

Con este enfoque como guía, iremos mostrando en sucesivas entregas, de qué manera VSTS 2010 contribuye a la mejora del proceso de testing en todo el espectro.

Comenzaremos mostrando las herramientas que propone la solución de MS desde el extremo más especialista, hasta llegar al punto opuesto, abarcando los siguientes tópicos:

  • Testing unitario y las mejoras para aplicación de técnicas de TDD (Test Driven Development)
  • Intellitrace
  • Coded UI Test
  • Lab Management
  • Integración Continua

 

Hasta la próxima !

Tags: , , ,

ALM | TFS | Testing | Visual Studio

ALM Bootcamp

por Alejandra Federico  19. abril 2011

El 28 de abril estarán participando Daniel Laco junto a Victor Passador como oradores en el evento que organiza Microsoft sobre la nueva versión de Visual Studio Team Foundation Server 2010, aplicado a todas las actividades de ALM.

Compartirán una tarde completa recorriendo las principales características de la última versión de Visual Studio Team Foundation Server 2010: Novedades Project Management, Version Control, nuevas herramientas de Testing, entre otras.

Este evento va a contar principalmente de Tracks Prácticos los cuales vas a poder seguir desde tu Notebook.

En http://bit.ly/fzKgTV pueden encontrar toda la agenda y el link de registración.

 

Tags:

ALM | Eventos | Testing | TFS | Visual Studio

Testing con VSTS 2010 – Para ir calentando motores …

por Victor Passador  18. febrero 2011

Estamos preparando una serie de post dedicados a testing con VSTS 2010 en las diferentes variantes en que se presenta a lo largo del ciclo de vida de la aplicación, y para ir introduciendo el tema quisiera dejarles unos links para que tengan a mano.

Se trata del blog de Mathew Aniyan, PM de Microsoft. En su blog, Mathew ha estado publicando una serie de Tips relacionado a lo que se conoce como Coded UI Test (Pruebas programáticas de Interfaz de Usuario).

Al momento de publicar este post, llegó hasta el N° 8, posteado con fecha enero/2010. Esperamos que retome la iniciativa y siga publicando más trucos.

Pueden ver la serie de tips aquí.

Saludos !

Tags: , , ,

ALM | TFS | Visual Studio | Testing

Acerca de los Autores

Este es el blog del equipo de VEMN SA 
Presentaremos temas que nos parezcan de interés sobre tecnología .NET, Procesos y Metodologías y todo aquello relacionado con el proceso de desarrollo de Software

Month List

BlogRoll

Download OPML file OPML