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

Cuando se acaba el soporte de Microsoft a un producto?

por Daniel Laco  15. abril 2011

 

A menudo nos encontramos en las empresas con aplicaciones, software y tecnologías que les queda poco tiempo de soporte de parte de Microsoft.

En otros cosas el tema es mas complicado porque ya no tienen directamente soporte de ningún tipo.

Hablando con un Arquitecto el otro día me comentaba que tenían varias aplicaciones desarrolladas en .NET 1.1, y que no conseguía que la gerencia encarara un proyecto de migración a versiones mas nuevas de .NET

En el caso de la versión 1.1 ya no tiene mas soporte de MS en cuanto a liberacion de Services Pack por temas de errores del código, y solamente le queda 1 año y medio aproximadamente de soporte extendido (solo sacan hotfixes por temas de seguridad).

Creo que esto es argumento mas que suficiente para para encarar un proyecto de migración serio.

Ni hablar de compañias donde hay muchas aplicaciones corriendo en VB6, Visual Fox, etc.

Aquí les dejo el ink http://support.microsoft.com/lifecycle/search/Default.aspx donde pueden consultar el estado de los productos dentro del ciclo de vida de MS.

 

 

Aquí también dejo un artículo con mas explicación sobre el tema y que fué el que me motivó a escribir esta nota. (http://www.ewaldhofman.nl/post/2011/04/14/When-runs-a-product-out-of-support.aspx)

Tags: ,

.NET

TFSJobAgent dejó de funcionar luego de la instalación del SP1 de TFS 2010

por Victor Passador  5. abril 2011

En uno de los servidores con los que estamos trabajando, tuvimos problemas luego de la instalación del Service Pack 1 de Team Foundation Server 2010.

Era uno de esos servidores prolijitos, instalados desde cero, nada de migraciones raras ni parches extraños.

Luego de una instalación exitosa del SP1, los servicios parecían funcionar bien pero la Project Collection empezó dar error de acceso y se empezaron a encolar tareas sin pudieran completarse (ver Consola de Administración de TFS –> Team Project Collections –> Solapa “Status”).

Después de investigar un buen rato, resultó que uno de los nuevos servicios que trae la versión 2010 conocido como TFSJobAgent no podía iniciar por un problema de logon (primer indicio, alguien recordó que el usuario con el que se instalaron el SP1 había cambiado su password luego de la instalación inicial del servidor pero antes de la instalación del SP1).

Sabiendo esto, actualizamos las credenciales de las cuentas desde la misma consola pero el servicio seguía sin levantar. Por otra parte, ¿donde está ese servicio?. Si no hubiera leído esto no hubiera sabido que el nombre real es “Visual Studio Team Foundation Background Job Agent”. En algún momento tuvimos la necesidad de detenerlo, pero lo hicimos usando el comando “net stop tfsjobagent”.

Cambiando las credenciales con las que se inicia ese servicio por las nuevas, todo volvió a funcionar con debía. Por algún motivo, no se habían actualizado justo en ese punto.

Saludos !

Tags: ,

TFS

Testing en aplicaciones web: Load testing y Stress testing

por Gustavo Lombardo  1. abril 2011

El rendimiento es una de las mayores preocupaciones en nuestras aplicaciones web y de comercio electrónico, ya que procesan miles de transacciones para miles de usuarios en algunos segundos, la escalabilidad y estabilidad de cargas es esencial para que las aplicaciones tengan éxito. Diversos estudios han indicado que los usuarios no toleran un interfaz con tiempos de respuesta mayores a 8 segundos y que el 58% de los clientes nunca vuelven a un sitio Web con bajo rendimiento.

Las crecientes demandas por mayor calidad en estos sistemas, han transformado al testing en una amenaza importante para los equipos de desarrollo de software y para los presupuestos de las compañías. Por este motivo les contaré de un par de herramientas bastante útiles para el testeo de nuestra aplicaciones on-line.

Primero veamos cuales son las diferencias entre el Load testing y Stress testing. Los test de carga (Load testing) nos permiten verificar el comportamiento de nuestra aplicación bajo condiciones de carga máxima y normales verificando si el sistema satisface los requisitos de rendimiento para situaciones críticas como, por ejemplo, la cantidad límite de usuarios accediendo de forma concurrente a los servicios, cantidad de transacciones que se pueden procesar de forma concurrente cada minuto, etc. Con esto comprobaremos que la aplicación satisface con los objetivos de rendimiento que deseados. Podes medir:

  • tiempos de respuesta,
  • las tasas de rendimiento,
  • la utilización de los niveles de recursos,
  • identificar el punto de ruptura de la aplicación, en el supuesto de que se produzca bajo condiciones de carga máxima.

 

Los test de estrés o de tensión (Stress testing) en cambio, permite evaluar el comportamiento de la aplicación cuando las forzamos más allá de las condiciones de carga máxima o normal desbordando sus recursos o reduciéndolos. Con dicho testing identificaremos los puntos débiles de la aplicación, cómo se comporta bajo condiciones de carga extrema y asegurar que tras un fallo el sistema, se recupera sin causar graves problemas.

Con estos tipos de test podremos identificar cuellos de botella y sus causas y optimizar la configuración de la plataforma (tanto el hardware y software) para obtener el máximo rendimiento. El proceso para ambos testing incluye los siguientes pasos:

Drawing1

Recomendaciones a tener en cuenta

  • El testeo de carga y de estrés hay que hacerlo siempre antes de que el sistema entre en producción reduciendo la probabilidad de llevarnos con una sorpresa cuando el sistema comienza a utilizarse.
  • Realizar el testeo en una red privada aislada.
  • Contar con un ancho de banda de red 100 Mbps o superior.
  • Varias placas de red para distribuir la carga.
  • Una máquina multiprocesador para las pruebas de escalabilidad.

Para las pruebas de estrés escogí la herramienta gratuita: Web Capacity Analysis Tool 5.2 (WCAT). Con esta herramienta podremos probar y planear la capacidad que tiene nuestro sitio, probar el servidor y diferentes configuraciones de red mediante contenido de diseño personalizado y simulaciones de carga de trabajo. Cuenta con tres componentes:

  • Web Server es el sistema bajo prueba. El software de servidor web puede ser de cualquier versión de IIS, Apache, etc.
  • WCAT Controller envía señales a los WCAT Client para iniciar o detener la generación de carga HTTP, cuyos contadores de rendimiento recopila y consolida todos los datos recogidos por WCAT Client en un único informe.
  • WCAT Client genera carga HTTP directamente contra el servidor o servidores web .Los clientes serán controlados mediante el WCAT Controller.

    Les dejo el link para que la descarguen. Los pasos para realizar las pruebas son los siguientes:

1. Una vez descargada la herramienta es necesario crear tres archivos de configuración.

· script.txt: este archivo define las solicitudes, es decir, qué páginas de solicitar y cómo solicitarlo. Ejemplo:

NEW TRANSACTION
classId = 1
NEW REQUEST HTTP
Verb = "GET"
URL = “http://localhost/prueba/Page1.aspx” (aquí remplazan por la url que quieren probar)

· distribution.txt: define los pesos entre las diferentes peticiones. Por ejemplo, si tengo que generar solicitud de Page1.aspx dos veces a Page2.aspx, esto quedará establecido en este archivo. En el caso de la carga de una sola página, el archivo no tiene sentido. Ejemplo: 1 50 el primer parámetro hace referencia a classId en el archivo script.txt, y 50 es que el 50% de la carga que no tiene sentido si hago una solicitud a una sola página por lo que recibirá el 100% de carga completa. Ejemplo:
1 50
· config.txt: determina la duración de la prueba, el número de clientes que va a generar las peticiones contra la aplicación web. Ejemplo:

Warmuptime 5s
Duration 30s
CooldownTime 5s
NumClientMachines 1
NumClientThreads 20

2. Guardar los tres archivos la carpeta en "C:\Program Files (x86)\IIS Resources\WCAT Controller".

3. Ejecutar la prueba, para ello en una ventana de DOS ejecutar el comando:

wcctl -c config.txt -d distribution.txt -s script.txt -a localhost

4. En una nueva ventana de DOS ejecutar en "C:\Program Files (x86)\IIS Resources\WCAT Client" el comando wcclient.exe localhost.

Los resultados la herramienta los arroja en las ventana de consola correspondiente tanto en la del server como en el cliente. En la siguiente imagen se muestra los resultados en el cliente.

image_thumb3

En el caso de los test de carga, les presentaré una herramienta que esta integrada el Visual Studio desde la versión del 2008, se trata Load Test del Visual Studio, para ello:

1. En la misma solución del proyecto de ASP.NET, hay que agregar un nuevo Test project.

2. Hacer clic en el nodo TestProject en el Solution Explorer seleccionar la opción "Add", y se despliegan diferentes tipos de pruebas. Elegir un "Web Performance Test". En el Internet Explorer aparece una barra “Web Test Recorder”. Se introduce en el browser la url de la página que se desea probar. La grabadora de prueba grabará todo lo que se está haciendo: acceder al sistema, la navegación a otras páginas, y así sucesivamente. Para finalizar con la grabación, simplemente debemos hacer clic en "Stop Recording". De esta manera quedará en parte configurada la prueba web.

3. Para finalizar solo basta añadir una Load Test. De nuevo con el menú contextual sobre el proyecto, seleccionamos Agregar y, esta vez seleccionar "Load Test". Se abre un wizard como el que se muestra a continuación:

image_thumb7

Componentes del escenario

Los escenarios son importantes porque proporcionan la flexibilidad en la configuración de características de la prueba que permiten simulaciones complejas. Por ejemplo, se puede estar probando un sitio que tiene una gran cantidad de usuarios simultáneos con diferentes velocidades de conexión y diferente browser. También podríamos tener dos grupos diferentes de usuarios: aquellos usuarios internos que acceden al sitio con el mismo navegador y en una conexión LAN de alta velocidad y también los clientes externos.

  • Browser Mix: simula usuarios virtuales examinando un sitio Web a través de una variedad de exploradores Web, además de Internet Explorer.
  • Network Mix: simula usuarios virtuales examinando un sitio Web a través de una variedad de conexiones de red. La combinación de redes ofrece opciones que incluyen una red LAN, cable módem, y otros.
  • Load Pattern: especifica un número de usuarios virtuales activos durante una prueba de carga y la velocidad a la que los nuevos usuarios se han iniciado.
  • Test Mix: especifica la probabilidad de que un usuario virtual ejecute una prueba determinada en un escenario de prueba de carga. Se puede seleccionar la combinación de pruebas que se prefiera ajustando los controles deslizantes en la distribución de la columna, o escribiendo los valores porcentuales directamente en el % de la columna.

Los reportes que nos devuelve esta herramienta pueden visualizarse tanto en el Visual Studio o exportarse en formato Excel si lo quisiese. Así que solo resta jugar un poco con los diferentes parámetros de configuración e ir analizando los resultados que arroja.

Tags:

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