I. L'offre Team System

Visual Studio Team System n'est pas un produit mais une gamme de produits composée de deux catégories :

• Une gamme serveur, représentée par Team Foundation Server, dont le rôle est de rendre des services pour organiser les équipes de développement et centraliser toutes les données liées à un projet. Celles-ci sont accessibles par chacun au travers de l'outil le plus adapté tel que Visual Studio pour les développeurs, MS Project pour le chef de projet, Excel pour les testeurs, une interface Web pour les fonctionnels... :
  • Code source (gestion de source, développement parallèle)
  • Eléments de travail (bogues, tâche, demandes d'évolution ou tout type de fiche)
  • Données organisationnelles (documents, calendrier partagé, annonces, wiki, blogs...)
  • Build (génération et gestion des livrables)
  • Rapport (état de santé du projet, rapports de qualité, état d'avancement...)

Un ensemble d'outils clients appelés Visual Studio Team System Editions

Quatre éditions clients de Visual Studio existent dans la gamme Team System, chacune peut être utilisée indépendamment du serveur mais collaborent très bien avec pour stocker les informations :

• Architecture Edition : offre des outils pour modéliser l'architecture physique et logique des applications (hors contexte sur la partie performances)
• Development Edition : propose des outils d'analyse de la qualité des applications (complexité, optimisation, bonnes pratiques) et pour travailler avec les bases de données SQL Server (Intéressant pour les performances : le profiler)
• Test Edition : dispose d'un ensemble de types de test tels que unitaire, manuel, ordonné, web et de charge (très intéressant pour les problématiques de performance et de stress)
• Team Suite : Edition qui regroupe l'ensemble des fonctionnalités des trois autres

II. Visual Studio Team Test en détails

a. Différents types de test

Visual Studio Team Test permet la mise en œuvre de plusieurs types de test :

• Test unitaire: le plus classique, qui permet de tester du code en .NET, avec un squelette généré.
• Test unitaire de base de données : équivalent du test unitaire .NET mais en T-SQL
• Tests ordonnés : permet d'exécuter un ensemble de tests dans un ordre séquentiel, le test réussit si l'ensemble des sous tests réussissent
• Tests Web : capture d'un scénario de navigation Web
• Tests de charge : permet de rejouer en boucle un ou plusieurs tests en simulant de la charge
• Tests manuels : écriture d'un scénario de test dans un fichier texte ou word, permet de gérer les résutats dans le référentiel
• Tests générique : test pouvant exécuter n'importe quelle application externe
• Tests personnalisés : il est possible de créer vos propres types de test pour simplifier certaines tâches répétitives (par exemple, la génération d'un proxy lorsque l'on teste des services WCF). Plusieurs types de tests additionnels sont disponibles en téléchargement sur CodePlex.

II. Visual Studio Team Test en détails

b. Différents types de test : test unitaire

Les tests unitaires sont présents dans Visual Studio Team System Development Edition et Test Edition depuis la version 2005. En version 2008, ils sont présents dans la gamme professionnelle, leur utilisation devenant une commodité. L'intérêt du Framework de test Microsoft est vraiment sa très forte intégration dans Visual Studio et dans Team Foundation Server (exécution automatique, stockage et comparaison des résultats sur une échelle de temps...).

Un test unitaire est composé de code .NET qui est chargé d'utiliser et de valider (« Assert ») du code .NET. A ce titre, il peut être utilisé pour tester tout et importe quoi (un accès à une base SQL, OLAP, des services Web...) car est ouvert aux capacités du Framework .NET qui sont extrêmement étendues. Les tests unitaires peuvent donc être utilisés pour effectuer des tests de charge d'éléments serveur en évitant l'intermédiaire d'une IHM (ex : stresser une base de données Oracle).

Un test unitaire peut être lié à un jeu de données externes (base de données, fichier CSV, XML) pour être joué à chaque fois avec un ensemble de données en entrée consécutives ou aléatoires.

II. Visual Studio Team Test en détails

d. Différents types de test : test Web

Le test Web permet d'automatiser un scénario de navigation Web. Il se compose d'un ensemble de requêtes HTTP (POST / GET) pouvant être rejouées en boucle.

Pour capturer un test Web, le plus simple est d'utiliser un enregistreur (proxy) HTTP qui stocke les échanges client/serveur et les transcrits dans un fichier. Deux outils sont très bien adaptés pour ceci, le Web test Recorder, proposé par Visual Studio Team System et qui s'intègre à Internet Explorer et Fiddler, outil gratuit proposé par Microsoft qui enregistre l'ensemble des trames HTTP quelque soit le navigateur Web utilisé et est capable de générer un fichier .webtest un format lu par Visua Studio Team System Test Edition. A noter que Fiddler est très intéressant lors d'un test Web sur une application client/serveur basée sur des WebServices, car il est également capable d'enregistrer les échanges et de les reproduire.

Un test web peut contenir des règles d'extraction (capture de variables dans une requête pour les réinjecter dans un autre), de validation (code d'erreur http, texte présent dans la page, temps de réponse) et peut être lié à une source de données externe (par exemple : test d'un formulaire d'authentification avec plusieurs identifiants).

Un test Web est décrit dans un fichier XML mais peut, dans un contexte de personnalisation avancé, être transformé en code .NET.

II. Visual Studio Team Test en détails

e. Différents types de test : test générique

Le test générique permet d'exécuter n'importe quel type d'application tierce n'ayant pas d'interface graphique : .EXE, .BAT, script PowerShell...

Il peut être lié pour initialiser/finaliser une séquence de test ordonnés, valider un batch ou encore intégrer dans Visual Studio des Frameworks de test tiers (exemple : exécution de NUnit avec un test générique et extraction/transformation des résultats pour les intégrer dans Team Foundation Server.

II. Visual Studio Team Test en détails

f. Profiling

Autre sujet qui sort un peu du contexte des tests, Visual Studio Team System DEvelopment Edition dispose depuis sa version 2005 d'un outil pour analyser les performances des applications et mettre en avant les goulets d'étranglement. L'intérêt pour les analyses de performance est que cet outil peut être exécuté directement depuis un test.

Quelques exemples :

Analyse des performances d'une fonctionnalité applicative après isolation dans un test unitaire Analyse des performances d'une page Web et de ses sous-contrôles utilisateurs à partir d'un test Web ...

III. Mener une campagne de charge

a. Objectifs

Deux cas fréquent d'utilisation des tests de charge existent :

• Pour valider une infrastructure cible avant une mise en production : s'assurer que l'infrastructure et l'application vont supporter la charge utilisateur visée
• Pour assurer une qualité en continue de l'application : s'assurer quotidiennement qu'il n'y ait pas de régression en termes de performances de l'application afin de pouvoir réagir immédiatement en cas de soucis

III. Mener une campagne de charge

b. Cible

L'outillage Microsoft permet de tester en charge les applications spécifiques Web, Windows (client/serveur) en environnement .NET, Java, Php aussi bien que les logiciels (SharePoint, SQL Server ou autre SGDB, SQL Server Reporting Services...).

Seules contraintes :

• Etre capable d'écrire un type de test simulant l'utilisation
• Etre capable de récolter les compteurs de performance

Un test de charge n'est rien d'autre qu'un test capable d'exécuter en boucle plusieurs autres types de test. Le test de charge est souvent utilisé avec des tests Web pour valider des applications intra/extra/internet mais peut très bien être utilisé avec des tests unitaires ou SQL pour valider la solidité de tout autre type d'application.

III. Mener une campagne de charge

c. Démarche

La mise en place d'un test de charge nécessite une méthodologie en 4 étapes :

• Définition du périmètre de test : que va-t-on tester ? Comment et avec quels objectifs ?
• Définition de l'architecture matérielle : que va-t-on utiliser comme environnement de test et tester ?
• Création et exécution de la campagne
• Analyse des résultats : quels sont les problèmes et les axes d'amélioration ? Où est le point de rupture (à partir de quand est-ce que l'on considère que l'application/l'infrastructure à atteint ses limites) ? Et quels sont les facteurs limitant qui permettraient de décaler le point de rupture (processeur trop utilisé, mémoire saturée, goulets d'étranglements dans l'application...).

III. Mener une campagne de charge

d. Préparation du test

La phase de préparation du test est très importante et passe au travers de plusieurs étapes.

• Définition des scénarios : un test de charge doit se rapprocher au mieux de la réalité, il est donc important lors de la création de scénarios de bien cerner le contexte ciblé. Seront ainsi pris en compte les navigateurs utilisés (une application web peut générer de l'html différent si elle a un Internet Explorer ou un SmartPhone en face), le temps d'attente entre les clics des pages (le but n'est pas de reproduire du clic en continu mais de simuler des utilisateurs) et la bande passante (l'objectif est d'avoir des temps de réponses acceptables pour tous les utilisateurs, si certains utilisent des modems 56k, ils seront à surveiller en priorité). Plusieurs scénarios peuvent être capturés pour un test de charge, et chacun peut posséder un poids. Par exemple, si 80% des utilisateurs restent sur la page d'accueil de l'application, un scénario doit le simuler, si 10% créent un compte, 10% naviguent dans un catalogue, des scénarios doivent être créés avec un poids similaire dans le test de charge.
• Le type de charge parmi les trois proposées :
  • Montante : le nombre d'utilisateurs augmente pendant toute la durée du test, même si la plateforme s'écroule
  • Constante : le nombre d'utilisateurs est stable sur la durée
  • Par Objectif : le nombre d'utilisateurs augmente jusqu'à atteindre un objectif défini (processeur à moins de 80%, temps de réponse à moins de 2 secondes...), lorsque l'objectif est atteint, la charge est lissée pour ne pas écrouler le système

Les indicateurs de performance : quels sont les compteurs Windows à prendre en compte dans les résultats de ce test de charge

III. Mener une campagne de charge

e. Architecture matérielle

Au niveau de l’outillage requis, deux cas existent :

• Pour simuler une charge limitée (en environnement de développement par exemple), Visual Studio Team Test seul est souvent suffisant
• Pour une charge importante (être sûr d’écrouler un environnement de pré-production ou de la répartition de charge) : un contrôleur peut venir se substituer à Visual Studio pour piloter des agents de charge installés sur plusieurs machines. Visual Studio devient dans ce cas juste le pilote, les agents sont chargés de simuler la charge et de récolter les résultats et le contrôleur de tout centraliser.

III. Mener une campagne de charge

g. Objectifs

Les tests de performances permettent donc de s'assurer que la solution fonctionne correctement avec un grand nombre d'utilisateurs. Au final, le périmètre couvert par ces tests regroupe :

• Les tests caractéristiques de performances : comment la réactivité de l'application est affectée en augmentant la charge
• Les tests de stress : comment la solution gère les niveaux extrêmes de charge
• Les tests d'évolutivité : comment la solution réagit en fonction du modèle de « scaling » (« scale-up » ou « scale out »)
• Les tests de durée : comment se comporte la solution si une charge est appliquée sur une période prolongée de test
• Test de la continuité d'activité : comment la solution gère une mise en échec partielle de son infrastructure logicielle ou matérielle.

Le test de charge est le seul test dont le résultat n'est pas binaire. Tous les résultats de test sont stockés dans la base de données « TFS Data Warehouse » ce qui facilite ensuite la création de rapports de synthèse de test de charge détaillée pour l'analyse de résultats de test performance. Le rapport généré peut être consulté au fur et à mesure ou à postériori, car stocké dans une base de données relationnelles. Si Team Foundation Server est utilisé, les résultats peuvent également y être stockés. Il est possible d'industrialiser l'exécution des tests de charge et la mise à disposition des rapports en utilisant conjointement Visual Studio Team Test et Team Foundation Server (service de build). Des modèles de rapports dédiés aux tests de charge sont disponibles dans ce dernier. L'iIntégration VSTS-TFS aide donc à la génération de rapports personnalisés qui peuvent être utilisés pour l'analyse des causes des échecs observées lors des tests de charge.

III. Mener une campagne de charge

h. Compteurs de performances

Visual Studio Team Test intègre l'analyseur de performances permettant d' ajouter les compteurs selon les besoins de différents serveurs (serveurs de base de données, serveurs Web). Le tableau suivant nous propose une liste de ces compteurs pour les ressources du système.

Le tableau suivant synthétise les compteurs pertinents sur les serveurs Web.

Le tableau suivant synthétise les compteurs pertinents sur les serveurs SQL.

IV. Pour aller plus loin

Quelques liens vous permettant d'aller plus loin...

Blogs :

• Eric Le Loc'h - Spécialiste équipe Team System
• Florent Santin - MVP Team System
• Stephane Goudeau - Architecte MTC
• Etienne Margraff - MVP Team System
• Le blog du MTC Paris

Liens:

• Page officielle Team System
• Ensemble de ressources Françaises
• Ressources Francophones
• Microsoft® Visual Studio® Team System 2008 Team Foundation Server SP1 and Team Suite SP1 VPC Image (Trial)
• Visual Studio® Team System 2008 Team Foundation Server SP1 VPC Image (Trial)
• Team Foundation Server Administrator's Guide
• Guide d'installation de Team Foundation pour Visual Studio Team System 2008
• Conversion depuis VSS
• Reprise Existant
• TFS 2008 System Recommendations
• TFS at Microsoft
• o http://blogs.msdn.com/bharry/archive/2006/08/22/712746.aspx
• o http://blogs.msdn.com/bharry/archive/2008/07/03/july-08-devdiv-tfs-dogfood-statistics.aspx
• How do I ? (Videos)
• Team System Widgets
• Rapport de tests de charge et comparaison
• Licensing
• TFS Power Tools

Livres :
http://www.amazon.fr/Microsoft-Team-Foundation-Server-TFS/dp/274604711X