Visual Studio Team Test et les tests de charge

 

Les auteurs : Florent Santin (Architecte Access it), Eric Le Loc'h (Ingénieur Spécialiste Team System) et Stéphane Goudeau (Architecte Microsoft)

L'objectif de ce document est de présenter les fonctions offertes par le produit Microsoft Visual Studio Team Test et de décrire plus particulièrement les principes de mise en œuvre d'une campagne de tests. Il constitue la synthèse des thèmes abordés lors de la « PerfWeek », semaine dédiée à l'outillage Microsoft de test de performance des applications, qui s'est déroulée du 04 au 11 Mai 2009 dans les locaux de Microsoft Technology Center Paris.
Durant 5 jours, 9 sociétés différentes ont pu, une demi-journée leur étant entièrement consacrée, assister à une présentation et des démonstrations sur mesure des possibilités offertes par la gamme de produits Visual Studio Team System. Cette semaine a été animée en par Florent Santin, spécialiste Team System de la société Access it et Pierre Lagarde architecte du MTC.
A noter que les captures d'écran ont été effectuées avec la Beta 1 de Visual Studio 2010 mais que chacune des fonctionnalités détaillées dans ce document existent dans la version 2008.

Sommaire

I. L'offre Team System

II. Visual Studio Team Test en détails
a. Différents types de test
b. Différents types de test : test unitaire
c. Différents types de test : test SQL
d. Différents types de test : test Web
e. Différents types de test : test générique
f. Différents types de test : outils

 

<< Précédent Suivant >>

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

c. Différents types de test : test SQL

Le test SQL est une surcouche au test unitaire et permet de générer le même code .NET de validation, mais sans compétences .Net requises car en écrivant directement du Transact SQL (celui-ci est transformé automatiquement en .NET). Un test SQL dispose de validateurs spécifiques qui permettent, une fois la requête ou procédure stockée utilisée, de vérifier un comportement : nombre de résultats, temps d'exécution, validateur personnalisé... Un test SQL peut être utilisé dans un test de charge (test aux limites d'une base SQL Server).

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

f. Outils

Visual Studio Team System 2008 Test Load Agent génère des tests de performance des applications Internet. Il permet aux entreprises d'améliorer la qualité de service en testant de manière plus efficace et plus proche de la charge future les serveurs sur lesquels sont déployés leurs applications Web.

Visual Studio Team System 2008 Test Load Agent simule la charge utilisateur sur les applications Internet et les serveurs pour donner aux équipes "qualité" des informations précises sur le comportement de leurs applications dans un mode de fonctionnement proche de la réalité.

Les résultats permettent de connaître les performances de ses applications et de dimensionner les serveurs pour des performances optimales. En un mot d'anticiper. Visual Studio Team System 2008 Test Load Agent fonctionne avec toutes les technologies d'applications Web : .NET ou non, progiciel ou non.

Les tests web VSTS peuvent également être utilisés dans les tests de performances en les ajoutant dans les tests de charge VSTS. Une documentation accompagne le produit et intègre une liste de compteurs, de seuils prédéfinis et leur effet sur les serveurs en charge.

La combinaison de Load Test et des tests Web fournit des règles de validation et d'extraction qui sont essentielles pour rendre les scripts robustes : les règles d'extraction aident à définir comment paramétrer les données générées dynamiquement.

Le schéma ci-dessous illustre le scénario de test de charge tel qu'appliqué pendant la Performance Week. Le Load agent est installé sur plusieurs machines différentes avec un contrôleur de l'agent de test charge dans une zone commune d'administration. Le test de charge réside sur le client Visual Studio d'édition des tests depuis lequel le testeur va configurer et lancer le test de telle sorte que les injecteurs (les agents de charge) générèrent la charge depuis différents emplacements sur l'application web.
Pour les mesures de performance du code et de la mémoire sur un comportement spécifique d'une portion du code .NET en charge, il est recommandé d'ajouter les tests unitaires dans les tests de charge et d'activer l'analyseur de performance Visual Studio Team System pour pouvoir faire un « profiling » prenant en compte le comportement technique de l'application sous la charge.

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.
Counter Instance Category Computer Color Range Min Max Avg
% User Time _Total Processor BL465C16-2   100 2,63 34,9 23,7
% User Time _Total Processor BL465C16-4   100 3,72 42,2 30,3
Bytes Received/sec Intel[R] 82566DM Gigabit Network Connection Network Interface DC7800-003   1000000 37608 668726 433616
Bytes Received/sec Intel[R] 82566DM Gigabit Network Connection Network Interface DC7800-004   1000000 26084 658671 434351
Avg. Response Time _Total LoadTest:Request DC7800-002   10 0,089 8,07 2,69

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.

Object Counter Instance
Network
Network interface Bytes received /s Each NIC
Network interface Bytes sent /s Each NIC
Network interface Bytes total /s Each NIC
Network interface Packets received /s Each NIC
Network interface Packets sent /s Each NIC
Network interface Output Queue Length Each NIC
Processors
Processor % Processor time _Total
Processor % Privileged time _Total
Processor % User Time _Total
System Processor queue length Not applicable
System Context switches /s Not applicable
Memory
Memory Available megabytes Not applicable
Memory Pages /s Not applicable
Memory Page Faults/sec Not applicable
Memory Cache faults/s Not applicable
Memory % Committed Bytes in use Not applicable
Server Pool non paged failures Not applicable
Process
Process % Processor Time W3wp.exe
Process Page faults/s Total
Process Working set (Monitored process)
Process Private bytes (Monitored process)
Process Handle count (Monitored process)
Disk I/O
Process Current disk queue length Physical Disk (_Total)
Process % Idle Time Physical Disk (_Total)
Process % Disk Read Time Physical Disk (_Total)
Process % Disk Write Time Physical Disk (_Total)


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

Object Counter Instance
ASP.NET
ASP.NET Requests current Not applicable 
ASP.NET Requests queued Not applicable
ASP.NET Requests rejected Not applicable
ASP.NET Requests execution time Not applicable
ASP.NET Requests wait time Not applicable
ASP.NET Application Restarts Not applicable
ASP.NET Requests wait time Not applicable
ASP.NET Applications
ASP.NET Applications Anonymous Requests /s Virtual directory
ASP.NET Applications Requests /s Virtual directory
ASP.NET Applications Requests executing Virtual directory
ASP.NET Applications Requests in application queue Virtual directory
ASP.NET Applications Requests timed out Virtual directory
ASP.NET Applications Cache total hit ratio Virtual directory
ASP.NET Applications Cache API hit radio Virtual directory
ASP.NET Applications Cache Total Entries Virtual directory
ASP.NET Applications Output cache hit ratio Virtual directory
ASP.NET Applications Errors total /s Virtual directory
ASP.NET Applications Pipeline instance count Virtual directory
.NET Framework
.NET Framework CLR memory Time in garbage collector percentage w3wp.exe
.NET Framework CLR memory Number of bytes in all heaps w3wp.exe
.NET Framework CLR memory Number of pinned objects w3wp.exe
.NET Framework CLR memory Large object heap size w3wp.exe
.NET Framework CLR memory Finalization Survivors w3wp.exe
.NET Framework CLR memory Number of exceptions thrown /s w3wp.exe
.NET Framework CLR memory Contention rate /s w3wp.exe
.NET Framework CLR memory Current queue length w3wp.exe
.NET Framework CLR Data
.NET Framework CLR Data .NET Data Provider:: number of connection pools  
.NET Framework CLR Data .NET Data Provider: current number of pooled connections  
Web service ISAPI extension requests /s WebSite
Process
Process % Processor Time w3wp.exe


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

Object Counter Instance
SQL Server : general statistics User connections Not applicable
SQL Server access methods Index searches /s Not applicable
SQL Server access methods Buffer Manager Not applicable
SQL Server access methods Full scans /s Not applicable
SQL Server : databases Transactions /s (Your database)
SQL Server : databases Active transactions (Your database)
SQL Server : locks Lock requests /s _Total
SQL Server : locks Lock timeouts /s _Total
SQL Server : locks Lock waits /s _Total
SQL Server : locks Lock waits /s _Total
SQL Server : locks Lock waits time (s) _Total
SQL Server : locks Number of deadlocks /s _Total
SQL Server : latches Average latch wai time(ms) Not applicable
SQL Server: cache manager Cache hit ratio _Total
SQL Server: cache manager Cache used counts /s _Total
SQL Server: Statistics Batch Requests/sec NA
SQL Server: Statistics SQL compilations/sec NA
SQL Server: Statistics SQL recompilations/sec NA
Disk I/O
PhysicalDisk Average disk queue length (disk instance on SAN)
PhysicalDisk Average disk read queue length (disk instance on SAN)
PhysicalDisk Average disk write queue length (disk instance on SAN)
PhysicalDisk Average disk seconds per read (disk instance on SAN)
PhysicalDisk Average disk seconds per transfer (disk instance on SAN)
PhysicalDisk Average disk bytes per transfer (disk instance on SAN)
PhysicalDisk Disk writes /s (disk instance on SAN)
Process
Process % Processor Time Sqlserv.exe

IV. Pour aller plus loin

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

Blogs :

Liens:

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

<< Précédent Suivant >>