Les tests logiciels : tude de cas avec Visual Studio 2010

Auteurs :

Stphane Goudeau (Microsoft France - MTC Paris) Florent Santin (Access it) Etienne Margraff (Access it)

Sommaire
Avertissement ..........................................................................................................................4 Introduction ..............................................................................................................................5 1. Lomniprsence du logicielet de ses dysfonctionnements ..............................5 2. Le cot des dysfonctionnements logiciels ...............................................................5 3. Gouvernance pour la qualit logicielle .....................................................................6 4. Le test logiciel .....................................................................................................................7 5. Les impratifs du test logiciel .......................................................................................7 6. Le rle de chaque membre de lquipe de production logicielle ..................7 A. Qui doit tester ? .............................................................................................................8 B. Quoi tester ? ....................................................................................................................8 C. Quand tester ? ................................................................................................................8 Loffre Visual Studio ..............................................................................................................9 1. Les dfis du dveloppement logiciel..........................................................................9 2. Une rponse ces dfis : lALM ................................................................................. 10 3. Loffre ALM btie autour de Microsoft Visual Studio 2010 ............................. 11 4. Les trois ditions Visual Studio 2010 ....................................................................... 12 5. Team Foundation Server 2010................................................................................... 12 6. Visual Studio Test Elements 2010 ............................................................................. 13 7. Visual Studio Team Lab Management 2010 ......................................................... 13 8. Le portail dquipe ......................................................................................................... 14 9. Larchitecture de Team Foundation Server............................................................ 16 Lenvironnement Visual Studio pour les tests....................................................... 17 1. Outillage ............................................................................................................................ 17 2. Automatisation des tests ............................................................................................. 21 3. Notion de tests impacts ............................................................................................. 21 Les diffrents tests Visual Studio ................................................................................ 23 1. Les diffrents types de tests........................................................................................ 23 2. Les tests unitaires ............................................................................................................ 24 A. Introduction ................................................................................................................. 24 B. MSTest ............................................................................................................................ 34

C. La couverture de code.............................................................................................. 26 D. Les tests unitaires dinterface utilisateur............................................................ 26 3. Les tests de base de donnes..................................................................................... 27 4. Les tests gnriques....................................................................................................... 29 5. Les tests dinterface utilisateur .................................................................................. 30 A. Introduction ................................................................................................................. 30 B. Tests automatiss dinterface utilisateur ............................................................ 31 6. Les tests dinterface Web ............................................................................................. 35 7. Profiling .............................................................................................................................. 38 8. Les tests de charge ......................................................................................................... 38 A. Objectifs......................................................................................................................... 38 B. Cible ................................................................................................................................ 39 C. Dmarche ...................................................................................................................... 40 D. Prparation du Test ................................................................................................... 40 E. Infrastructure de Test ................................................................................................. 42 9. Les tests manuels ............................................................................................................ 44 Stratgies de tests avec Visual Studio 2010........................................................... 46 1. Introduction ...................................................................................................................... 46 2. Planification des tests.................................................................................................... 47 3. Communication, changes et traabilit des tests ............................................ 50 A. Excution ....................................................................................................................... 50 B. Analyse de rsultats ................................................................................................... 53 C. Communication avec lquipe de dveloppement ....................................... 54 4. Reporting sur les tests .................................................................................................. 56 5. Gestion denvironnements virtuels de dploiement et de test ..................... 58 Synthse ................................................................................................................................... 63 Annexe : Etendre le Framework de test........................................................................ 64 Annexe : Tests automatiss dinterface utilisateur : Technologies supportes ..................................................................................................... 66 Annexe : Tests automatiss dinterface utilisateur : Systmes supports ............................................................................................................... 67 Annexe : Rfrences techniques...................................................................................... 69

Avertissement
Ce document sadresse aux testeurs, aux architectes, aux concepteurs et dveloppeurs, ainsi quaux chefs de projet qui veulent pouvoir contrler les composants logiciels quils produisent dune manire plus systmatique et mieux outille que celle gnralement pratique dans lindustrie aujourdhui. Ce document est fourni uniquement titre indicatif. MICROSOFT NAPPORTE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, CE DOCUMENT. Les informations figurant dans ce document, notamment les URL et les rfrences aux sites Internet, peuvent tre modifies sans pravis. Les risques dutiliser ce document ou ses rsultats sont entirement la charge de lutilisateur. Sauf indication contraire, les socits, les entreprises, les produits, les noms de domaine, les adresses lectroniques, les logos, les personnes, les lieux et les vnements utiliss dans ce document sont fictifs. Toute ressemblance avec des entreprises, noms dentreprise, produits, noms de domaine, adresses lectroniques, logos, personnes ou vnements rels serait purement fortuite et involontaire.

Stphane GOUDEAU est Architecte au Microsoft Technology Center Il conseille les clients et partenaires de Microsoft dans leurs choix darchitecture lis lvolution de leur systme dinformation. Il possde une connaissance gnrale ainsi quune longue exprience terrain de lensemble des produits et solutions de la plateforme Microsoft, acquise lors de ses activits au sein du consulting Microsoft. Florent SANTIN et Etienne MARGRAFF sont tous les deux consultants formateurs dans la socit de services Access it, spcialise dans les technologies Microsoft. Ils sont reconnus Microsoft MVP (Most Valuable Professionnal) sur Visual Studio.
Pour les contacter :
fsantin@access-it.fr emargraff@access-it.fr

Introduction
1. Lomniprsence du logicielet de ses dysfonctionnements
Limportance du logiciel, quil sexcute sur le poste de travail de lutilisateur, sur son smartphone , sur sa console de salon, dans sa voiture, sur les serveurs de lentreprise, ou dans le Cloud , ne cesse de stendre. La garantie de son bon fonctionnement est donc une ncessit absolue pour tout un chacun. Pourtant, force est de constater quau sein des units de production logicielle, la mise en place systmatique de processus permettant de rduire le risque de dysfonctionnement est loin dtre une pratique gnralise.

2. Le cot des dysfonctionnements logiciels

Le dveloppement logiciel est intrinsquement sujet erreurs qui tt ou tard finiront par se manifester. Hors, plus un bogue apparait tard dans les diffrentes phases de projet, plus celui-ci va prendre du temps tre corrig et coter cher, parfois dans des proportions exponentielles.

Un

bogue trouv en phase de dveloppement au moment de son apparition va pouvoir tre corrig par le dveloppeur en quelques minutes. quelques heures : il va devoir tre identifi, remont au dveloppeur charg de le corriger qui doit le reproduire, puis livrer une nouvelle version corrige de lapplication en test. cheminement quen environnement de test, sauf que la livraison de celui-ci sous forme de patch ou de nouvelle version est souvent trs contraignante et onreuse (avec parfois laccroissement du cot de correction par un facteur de 1 100). De plus, il arrive frquemment que les dveloppeurs de lapplication ne soient pas les mme personnes que ceux assurant la maintenance (et un bogue peut apparaitre trs tard, voire trop tard), ce qui demande un temps de reproduction et didentification du problme beaucoup plus long.

Un bogue qui apparait en environnement de test peut tre rgl en

Un bogue trouv en environnement de production va suivre le mme

Limpact de lintroduction prcoce derreurs avant mme lintervention du dveloppeur est encore plus dsastreuse. Ainsi, il est prfrable de dcouvrir une erreur dans la dfinition dune exigence fonctionnelle pendant la phase de spcification, car ce type derreur affecte beaucoup plus de lignes de code que les erreurs apparaissant dans les phases de conception ou de codage. Les dcouvrir une fois le logiciel dploy en production entrane de graves consquences : nouveaux dveloppements et remise en cause lexistant.

3. Gouvernance pour la qualit logicielle

En outre, les consquences de la dfaillance dun composant logiciel sont dautant plus visibles lorsquil devient le maillon rutilisable dune chane logicielle du systme dinformation de lentreprise. En effet, parmi les briques logicielles du systme dinformation, certaines sont critiques et ncessitent une totale couverture de tests assortie dune vraie assurance qualit. Pour limiter les risques derreurs logicielles et les consquences des dysfonctionnements qui en rsultent, il est donc primordial de mettre en place une vritable gouvernance pour la qualit logicielle. Cette gouvernance suppose une amlioration des processus logiciel par le respect de meilleures pratiques et la mise en place dune gestion de cycle de vie des applications pour les quipes projet laide dun jeu de plusieurs disciplines, parmi lesquelles les tests logiciels sont llment pouvant avoir le meilleur impact sur la qualit logicielle.

Mais quest-ce que le test logiciel ? Le test logiciel Certaines organisations assimilent test logiciel avec la simple capacit offerte au dveloppeur de dboguer le composant logiciel dont il est lauteur ou la mise en place dun systme dassurance qualit reposant sur des tests fonctionnels ou de performances. Ces lments sont importants mais ne suffisent pas garantir la qualit dun systme logiciel. Tester un logiciel va dabord consister lancer les composants logiciels cibls dans un contexte dexcution permettant de mesurer les rsultats obtenus afin de dterminer si les objectifs de ces composants sont atteints. Mais dtecter les erreurs du logiciel et les exposer pour correction nest pas suffisant car les erreurs ne se limitent pas aux erreurs de codage de logiciels ; elles peuvent se produire diffrentes tapes du cycle logiciel (y compris dans les tapes prliminaires de spcification fonctionnelle et de conception). Cest pourquoi, au-del de lexamen des rsultats de lexcution du composant cibl, le test logiciel englobe tout le processus associ, ce qui inclut la dfinition de la nature et la porte de ces tests en correspondance avec les exigences fonctionnelles (parfois avant mme le dveloppement des composants logiciels concerns ( Test Driven Developpement ou Test First Programming ), ainsi que lattribution de rle de responsable des tests au sein de lorganisation de lquipe de production logicielle

4. Les impratifs du test logiciel

Une dmarche de test logiciel se doit de respecter plusieurs impratifs : la dfinition des politiques dfinissant les modalits dapplications de ces tests (planification dans les diffrentes phases du cycle de vie de lapplication, frquence et conditions dexcution, rle de chaque membre de lquipe), le dploiement de linfrastructure (matrielle et logicielle) permettant la mise en uvre de ces politiques ainsi que les processus assurant le contrle du respect des politiques Les environnements matriels sont ncessaires pour lintgration fonctionnelle et la mise en uvre de tests de performances pertinents. Un logiciel spcialis est ncessaire pour la gestion du plan de tests, la cration de donnes fonctionnelles et de tests de performances, et les tests unitaires.

5. Le rle de chaque membre de lquipe de production logicielle

Les tests participent garantir la qualit dune application en ayant un fort impact sur les bogues. Ainsi une quipe projet appliquant une politique de tests complte pourra :

En phase de dveloppement, valider en continu la bonne intgration des

briques dveloppes par chaque dveloppeur ou sous-quipe en vitant la rgression de fonctionnalits dj implmentes et valides (par des tests).

En

phase de production, limiter lapparition des bogues en validant au pralable via les tests tous les scnarii utilisateurs possibles, ceux considrs comme bons mais aussi les mauvais (tests aux limites, tests sur des jeux de donns complets).

A. Qui doit tester ?

Chaque membre de lquipe projet doit tre impliqu dans les phases de test. Cependant, chacun doit tester ce quil connat le mieux et avec les outils les plus adapts : il nest pas appropri quun testeur fonctionnel ait valider le fonctionnement technique dobjets et quun dveloppeur ait tester des scnarii fonctionnels de navigation. Le contraire est par contre fortement conseill.

B. Quoi tester ?
De la mme faon que chacun des intervenants du projet doit participer aux tests, le maximum des lments dune application doit tre test.Plus les tests sont prsents, plus les fonctionnalits de lapplication seront couvertes. Cependant, tester deux fois la mme fonctionnalit dune application au travers de deux points dentres diffrents peut tre considr comme une perte de temps. Par exemple, il est inutile de tester une couche daccs aux donnes auto gnre. Il est bien plus opportun de se consacrer la validation de la couche mtier lexploitant. Au contraire, il sera plus utile de tester une base de donnes plutt que la couche daccs lexploitant si cette premire possde beaucoup de procdures stockes reprsentant une logique mtier. Linterface graphique dune application console naura aucun sens tre teste, par contre linterface dune application riche ayant beaucoup dinteractions avec lutilisation de validateurs de saisies devra tre couverte au maximum.

C. Quand tester ?
Lexcution des tests doit tre omniprsente au sein du cycle de dveloppement dune application. Certains types de tests rapides, comme les tests unitaires ou de base de donnes doivent tre excuts le plus frquemment possible : aprs chaque compilation dans lenvironnement de dveloppement, avant chaque archivage des modifications dans le contrle de code source, aprs chaque gnration de livrable par le service de build. Les tests dinterface (Web ou Windows), un peu plus lent lexcution, doivent au minimum tre excuts une fois par jour par le service de build afin de garantir constamment une non rgression de fonctionnalits et offrir un niveau de ractiv lev en cas de bogue. Enfin, les tests de charges peuvent tre classs dans la catgorie des tests nexcuter que ponctuellement, la demande, sur des priodes donnes.

Loffre Visual Studio

1. Les dfis du dveloppement logiciel
Aujourdhui, trs peu de projets logiciels sachvent en respectant dlais et budget. En outre, les projets mens terme sont rarement en totale adquation avec les spcifications initiales. Pourquoi ? Parce que le dveloppement dapplications doit faire face de nombreux dfis :

La gestion des exigences mtier fluctuant tout au long du projet. Les lacunes de communication entre les utilisateurs finaux et lquipe de
dveloppement.

La

difficult de tester la qualit et la fiabilit des applications de faon adquate. suivi du projet afin de pouvoir prendre les bonnes dcisions au bon moment et assurer la prdictibilit de la livraison du projet.

Le

Il ne faut pas perdre de vue que le cycle de vie des applications couvre toute la priode durant laquelle une organisation engage des moyens (budget, ressources) sur son patrimoine applicatif de lide de dpart jusqu la fin de vie de la solution.

10

2. Une rponse ces dfis : lALM

Comment surmonter ces dfis ? La gestion de cycle de vie des applications (ALM : Application LifeCycle Management) pour les quipes projet contribue raliser des projets logiciels de faon rentable et prvisible laide dun jeu de plusieurs disciplines : gestion des exigences, gestion de portefeuille de projet, Test Driven Development , suivi de projet, fonctions de collaboration, compilations incrmentales, gestion de configuration, mthodes agiles) lies pour influer sur le processus de dveloppement. Les trois composantes associes lALM (Application LifeCycle Management) sont :

La gouvernance : la prise de dcision et la gestion de projets. Le dveloppement : les processus qui permettent de crer (et mettre jour)
les applications. les applications.

Lexploitation : lensemble des tches requises pour exploiter et maintenir

11

3. Loffre ALM btie autour Microsoft Visual Studio 2010

Avec Visual Studio 2010, Microsoft propose une solution ALM intgre comprenant outils, processus et meilleures pratiques pour aider chaque membre de lquipe projet amliorer ses comptences et collaborer plus efficacement.

Loffre ALM Visual Studio propose une gamme de multiples catgories de produits dont le rle est de rendre des services pour organiser les quipes de dveloppement et centraliser toutes les donnes lies un projet. Celles-ci sont accessibles par chacun au travers de loutil le plus adapt tel que Visual Studio pour les dveloppeurs, MS Project pour le chef de projet, Microsoft Test and Lab Manager pour les testeurs, une interface Web pour les fonctionnels Visual Studio couvre tout le cycle de dveloppement des applications (modlisation graphique des applications, des bases de donnes et des processus, configuration de code source, industrialisation, tests et suivi de projet). Visual Studio permet damliorer la collaboration et la communication au sein de lquipe projet avec la gestion de lensemble des donnes des projets dans un module de gestion de configuration fiable, et de piloter les projets beaucoup plus efficacement grces aux nombreux rapports et lintgration avec MS Excel et MS Project. La version 2010 de Visual Studio offre de nombreuses nouvelles fonctions :

Diagrammes de squences pour application SOA, Construction dapplications WCF, Cration et visualisation des interactions entre classes

12

Ensemble de rgles danalyse statique, Dbugger historique (IntelliTrace ),

Visualisation des impacts sur les tests des modifications de code, Dbugger isol pour traquer les anomalies sur les postes clients

Planification de campagnes de tests, Excution des cas de test manuels Hirarchie de Work Items dans Excel, Cration de rpertoire pour grer ses

requtes, Rollback de checkin, Destruction, suppression et renommage des Work Items

4. Les trois ditions Visual Studio 2010

Les outils clients sont dclins selon trois ditions, chacune pouvant tre utilise indpendamment du serveur mais collaborent trs bien pour stocker les informations et fluidifier la communication :

5. Team Foundation Server 2010

Team Foundation Server est la partie serveur de loffre ALM Visual Studio : automatisation des dfinitions de builds ou des tests, gestion de configuration/des versions, gestion du changement, portail dquipe, reporting sur ltat davancement dun projet... Toutes ces fonctionnalits sont exposes sous forme de services Web, et donc accessibles depuis les ditions Visual Studio Team

13

Edition, mais aussi depuis des applications comme Excel ou Project ou des applications Web. Il est galement possible de se connecter Team Foundation partir de Team Explorer, un client riche prvu cet effet. Ce rfrentiel offre la centralisation des lments suivants :

Code source (gestion de source, dveloppement parallle). Elments de travail (bogues, tche, demandes dvolution
de fiches). blogs).

ou tout type

Donnes organisationnelles (documents, calendrier partag, annonces, wiki, Build (gnration et gestion des livrables). Rapport (tat de sant du projet, rapports de qualit, tat davancement).
6. Visual Studio Test Elements 2010
Cet environnement intgre Microsoft Test and Lab Manager qui permet de dfinir une stratgie de tests structure selon un plan de test associ au projet Team System. Elle offre galement les agents Lab Management, permettant Team Foundation Server de piloter une machine virtuelle pour y raliser des tests manuels ou automatiss.

7. Visual Studio Team Lab Management 2010

Visual Studio Team Lab Management 2010 permet de mettre en place des laboratoires de tests. Cette fonctionnalit offre la possibilit de crer des modles denvironnements qui pourront tre instancis la demande, ou de manire automatique pendant une gnration de build serveur.

14

8. Le portail dquipe
Un portail (figure suivante), fond sur Windows Sharepoint, complte lintgration des diffrents outils collaboratifs (Visual, Studio, Excel, Project,) en offrant laffichage des rapports davancement gnrs partir des workitems publis.

Ce portail peut tre personnalis et reflte le choix de la mthodologie de dveloppement associe au projet.

15

Le portail permet galement dafficher les multiples types de rapports : suivi des bugs, vlocit du projet

16

9. Larchitecture de Team Foundation Server

La figure suivante illustre larchitecture de Team Foundation Server :

17

Lenvironnement Visual Studio pour les tests

1. Outillage
Depuis sa version 2005, lenvironnement de dveloppement Visual Studio dispose dune dition enrichie ddie lcriture et lexcution de tests. Intitule Visual Studio Team Test, celle-ci est enrichie au fil des versions par des nouveaux types de tests. Dans ldition 2010 de Visual Studio, la dnomination Team disparait pour laisser place 3 nouvelles ditions. Les outils concernant les tests se retrouvent dsormais dans les ditions Professional, Premium et Ultimate pour les aspects test web et test de charge. Visual Studio 2010 met disposition loutillage complet permettant chacun de simpliquer dans les phases de test :

Le dveloppeur au travers de tests techniques (test unitaire, test gnrique). Le dveloppeur snior ou larchitecte grce des tests de validation de
qualit et danticipation des problmes (test de charge, test WCF, test cod, test dinterface). pour tester des cas SQL (test de base de donnes). cas de test (Test Web, manuel).

Le spcialiste de bases de donnes en utilisant des tests crits en langage SQL Le fonctionnel ou le testeur pour valider des scnarios de navigation et des
Pour dmocratiser leur utilisation, les tests unitaires sont depuis 2008 mis disposition des dveloppeurs dans la version Professionnel de Visual Studio, sans cot supplmentaire. La cration et la gestion des tests seffectuent directement depuis lenvironnement de dveloppement. Les tests sont physiquement organiss par projets de tests, projets .Net pouvant faire partie dune solution .Net classique. La cration dun projet de test peut donc tre ralise par nimporte quel membre de lquipe technique, au travers de lassistant de cration de projet de Visual Studio.

18

Cration dun projet de test

Une fois cr, le projet de test ressemble tout autre projet de dveloppement .Net : il possde des rfrences vers le Framework de test de Microsoft et peut contenir des types de fichiers spcifiques reprsentant des tests.

Contenu dun projet de test

19

Les tests peuvent tre organiss logiquement par groupe pour tre excuts ensemble. Toute cette gestion seffectue au travers de la fentre Test List Editor . Celle-ci offre la possibilit de :

plusieurs nuds dune arborescence. Tous les types de tests peuvent tre pris en compte dans cette interface.

Crer une arborescence dorganisation des tests. Classer et regrouper les tests plusieurs niveaux de larborescence. Demander lexcution de lintgralit des tests disponibles dans

un ou

Fentre dorganisation des tests dans Visual Studio

Lditeur de listes de tests offre la possibilit de dmarrer lexcution dun ensemble de test. Pour tre plus rapide et productif dans lexcution de ceux-ci, Visual Studio dispose dune autre fentre intitule Test View . Celle-ci liste lensemble des tests prsents pour le projet et propose de les excuter un un ou par groupe.

Fentre dexcution des tests

20

Enfin, il est galement possible dexcuter un test ou un ensemble de tests directement depuis son code grce au menu contextuel de Visual Studio ou des raccourcis claviers. Ceci a pour but dacclrer les phases criture de test > excution. Ces facilits sont trs importantes lors de la mise en place de pratiques ou les tests unitaires sont cruciaux, tels que le Test Driven Development .

Quelques soit le type de test ou le contexte dans lequel il est excut, lors de la demande manuelle dexcution de test, le rsultat apparait toujours dans la fentre Test Results . Le rsultat dun test est souvent binaire : russi ou chou, reprsent par la couleur verte ou rouge. Les tests unitaires possdent galement un tat jaune inconclusive intermdiaire. Ce rsultat apparait lors de la gnration automatique de squelette de test unitaire, si les rsultats attendus de ceux-ci nont pas t renseigns. En plus dun tat de russite ou dchec, la fentre de rsultat propose en rsultat un rapport complet.

Visual Studio 2010 propose les outils de test permettant dtre plus productif tout au long du cycle de vie du dveloppement et de suivre plus facilement la progression. Ces outils de test sont intgrs avec Team Foundation Server, ce qui permet de dfinir des tests bass directement sur les projets Team System.

21

2. Automatisation des tests

Ds quil y a plus dune personne qui modifie le code source dune application, il est vital de valider frquemment lintgration du travail de chacun avec celui des autres. Pour cela, une validation manuelle locale par le dveloppeur lui-mme ne suffit pas. Lidal est deffectuer un ensemble de vrifications sur un environnement dont on matrise la configuration et indpendant des postes de lquipe de dveloppement. Le processus qui permet deffectuer cette validation est couramment appel Chane dintgration continue . Ce processus comprend en gnral les tapes suivantes :

automatiss, par exemple). Gnralement, ce processus, qui exploite le service de Build de Team Foundation Server, est dclench le plus frquemment possible : chaque mise jour du rfrentiel de code source. Il peut cependant tre effectu rgulirement sans pour autant le faire chaque archivage, comme par exemple Tous les soirs 2h00 .

Compilation de la dernire version disponible de lapplication. Excution des tests unitaires. Dploiement de lapplication sur un environnement de test. Excution de tests supplmentaires (dinterfaces graphiques

3. Notion de tests impacts

Lors dune phase de dveloppement, les tests unitaires sont vitaux pour sassurer que les modifications ralises sur le code ne donnent pas lieu un effet de bord sur dautres lments de lapplication. De ce fait, il est ncessaire dexcuter les tests le plus souvent possible. Lorsquun projet contient un nombre important de tests unitaires, leur excution peut prendre un certain temps. Pour viter davoir jouer la totalit de ces tests, Visual Studio 2010 offre une nouvelle fonctionnalit nomme : Analyse de tests impacts. Cette fonctionnalit permet denregistrer chaque test, en exploitant les informations de couverture de code, la liste des blocs de code utiliss lors de lexcution du test. Grce ces informations Visual Studio est capable de trouver la liste des tests impacts par les modifications que lon vient de raliser chaque compilation de lapplication.

22

Cette fonctionnalit nomme : Tests impacts peut tre exploite localement dans Visual Studio, mais galement dans le processus de Build ou encore lors de lexcution dun test manuel via loutil Microsoft Test and Lab Manager. Le plus frquemment, celle-ci sera exploite pour les tests unitaires.

23

Les diffrents tests Visual Studio

1. Les diffrents types de tests
laide de Microsoft Visual Studio 2010, vous pouvez crer diffrents types de tests automatiss ou manuels. Parmi les tests automatiss, on trouve notamment :

Tests unitaires: le plus classique, qui permet de tester du code

un squelette gnr. T-SQL.

en .Net, avec

Tests unitaires de base de donnes : quivalent du test unitaire .Net mais en Tests
ordonns : permet dexcuter un ensemble de tests dans un ordre squentiel, le test russit si lensemble des sous-tests russissent. tests en simulant de la charge pour vrifier les performances de votre application sous diffrents niveaux de stress.

Tests Web : capture et rejoue un scnario de navigation Web. Tests de charge : permet de rejouer en boucle un ou plusieurs

Tests gnriques : test pouvant excuter nimporte quelle application externe. Tests dinterface utilisateur. Tests personnaliss : il est possible de crer vos propres types de tests pour

simplifier certaines tches rptitives (par exemple, la gnration dun proxy lorsque lon teste des services WCF).

24

Plusieurs types de tests additionnels sont galement disponibles en tlchargement sur CodePlex.

2. Les tests unitaires A. Introduction

Les dveloppeurs mettent en uvre des tests unitaires afin de vrifier si un module particulier rpond aux spcifications fonctionnelles et si les lments de code de ce module fonctionnent correctement indpendamment du reste de lapplication et en toutes circonstances. Lusage de tests unitaires est frquent dans les applications critiques et se gnralise aujourdhui tout type dapplications. En renouvelant leur excution aprs la modification du ou des modules concerns, ils permettent de valider la non rgression du systme. Certaines mthodologies de dveloppement prconisent leur usage systmatique lors de limplmentation du module, voire en amont de cette implmentation : dveloppement pilot par les tests ou Test Driven Development . Cest notamment le cas de la mthodologie XP ( Extreme Programming ).

B. MSTest
MSTest est le Framework de tests unitaires propos par Microsoft depuis 2005. Les tests unitaires sont prsents dans Visual Studio Team System Development Edition et Test Edition depuis la version 2005. En version 2008 et 2010, ils sont prsents dans la gamme professionnelle, leur utilisation devenant une commodit. Lintrt du Framework de test Microsoft est sa trs forte intgration dans Visual Studio et dans Team Foundation Server (excution automatique, stockage et comparaison des rsultats sur une chelle de temps). Syntaxiquement, son utilisation est trs proche des autres Framework de tests unitaires rpandus sur le march tels que NUnit et MbUnit : utilisation dattributs sur les classes et les mthodes de tests dassertions pour les validations. Un test unitaire est compos de code .Net qui est charg dutiliser et de valider ( Assert ) du code .Net. A ce titre, il peut tre utilis pour tester tout et nimporte quoi (un accs une base SQL, OLAP, des services Web) car il est ouvert aux capacits du Framework .Net qui sont extrmement tendues. Les tests unitaires peuvent donc tre utiliss pour effectuer des tests de charge dlments serveur en vitant lintermdiaire dune IHM (ex : stresser une base de donnes Oracle).

25

Un test unitaire peut tre li un jeu de donnes externe (base de donnes, fichier CSV, XML) pour tre jou chaque fois avec un ensemble de donnes en entres conscutives ou alatoires. Assez critiqu dans sa premire version pour ses problmes de performance dexcution, MSTest rivalise aujourdhui sans aucun problme avec les Frameworks existants et loutillage Open Source et dispose de plusieurs avantages pour les dveloppements .Net :

Une Un

intgration parfaite dans Visual Studio pour lexcution des tests, la consultation des rsultats, ou lintgration des tests aux builds automatiques. gnrateur de squelette de test (instanciation de lobjet crer, isolation des paramtres, assertion) partir de nimporte quelle mthode pour rduire le temps dcrire des tests unitaires.

26

C. La couverture de code
Les tests unitaires sont souvent lis la vrification de la couverture de code, qui permet de sassurer que les critres de tests permettent de garantir lexcution dune partie significative des lments de code tester. A quoi bon obtenir 100 % de succs sur les tests si ceux-ci ne couvrent que 20% du code utilisable ? Comme pour les tests unitaires, Microsoft dispose de son propre outillage de couverture. L galement, lintgration dans lenvironnement joue un rle trs important pour faciliter ladoption et simplifier lutilisation. Il est ainsi possible dexplorer le code source dans lequel les zones non couvertes par les tests unitaires sont surlignes en rouge.

D. Les tests unitaires dinterface utilisateur

Ce type de test repose sur la mise en uvre de pattern adapt au dveloppement de la couche de prsentation. Prenons le cas de WPF (Windows Presentation Foundation). Depuis sa sortie en 2007 avec le .Net Framework 3.0, diffrents patterns ont t explors pour faciliter lutilisation de cette technologie dans un contexte dapplications dentreprises. Le dernier en date - qui est de loin le plus abouti - est le pattern M-V-VM (Model - View - ViewModel). Cest un Pattern driv du pattern MVC indpendant de la technologie. Il permet de sparer clairement le mtier de linterface. Il facilite les tests unitaires sur les applications WPF (en aidant remplacer le test manuel simulant linteraction utilisateur). Dans le cas des applications Winform, on utilisera plutt le pattern MVP. Dans la logique de dcomposition propos par le pattern M-V-VM, le Model (ou DataModel ) est responsable des donnes mtiers, la View reprsente la partie visuelle de lapplication tandis que le ViewModel expose les donnes et les comportements (notamment les commandes) pour la View . Ce ViewModel est spcifique pour chaque vue mais nhrite daucune classe WPF. Le ViewModel est une classe qui implmente le pattern Observable : elle implmente linterface INotifyPropertyChanged . De mme, les proprits de la classe ViewModel doivent implmenter INotifyPropertyChanged (ou DependencyObject ) ou ObservableCollection suivant quil sagisse dobjet ou de collection, afin de prvenir la vue lors de tout changement des donnes. Ainsi la View peut utiliser le ViewModel dans son DataContext pour le

27

binding afin de transformer les donnes en lments visuels avec les Data Templates . Le View Model quant lui ne fait aucune supposition sur la faon dont va soprer le binding. Lorsque ce pattern est mis en uvre avec WPF, la View ne contient quasiment pas de code behind part les animations et la gestion de layout . Le code rside dans le ViewModel qui est facile tester unitairement, do lintrt de cette approche dans le cadre de test unitaire dinterface utilisateur.

Source : http://www.nikhilk.net/Silverlight-ViewModel-Pattern.aspx

3. Les tests de base de donnes

Les tests de base de donnes ont fait leur apparition avec la version Database Professionals de Visual Studio Team System. Leur objectif est de simplifier lcriture de tests ciblant directement les bases de donnes SQL Server. Pour rpondre ce besoin de simplicit, lcriture des tests ne seffectue pas en .Net mais directement en T-SQL (Transact SQL). Ceux-ci sont ensuite traduits de manire invisible en code .Net par lenvironnement de dveloppement. Le test SQL devient ainsi une surcouche des tests unitaires et permet de gnrer le mme code .Net de validation. Ceci permet dtendre le produit des administrateurs de base de donnes nayant pas forcement de comptences en dveloppement .Net. Un test SQL dispose de validateurs spcifiques qui permettent, une fois la requte ou procdure stocke utilise, de vrifier un comportement : nombre de rsultats, temps dexcution, validateur personnalis Un test SQL peut tre utilis dans un test de charge (test aux limites dune base SQL Server).

28

Les validateurs sont positionns par configuration de manire graphique dans linterface de test. Lors de lajout dun test unitaire de base de donnes un assistant nous permet de configurer un certain nombre dinformations :

29

1. Permet de choisir une source de donnes contenant les lments de validation des tests. 2. Permet dexploiter un projet Visual Studio 2010 de type Base de donnes . Ce type de projet offre la possibilit de dfinir des scripts de cration dune base de donnes. Celle-ci sera alors dploye automatiquement pour lexcution des tests. 3. Permet dexploiter un fichier de gnration automatis de donnes de tests. Ce type de fichier peut tre cr partir dun projet de type Base de donnes .

4. Les tests gnriques

Comme son nom lindique, un test gnrique est un test capable dexcuter nimporte quelle action. Concrtement, un test gnrique a pour rle dexcuter une application tierce, ventuellement avec des paramtres spcifiques afin dextraire les rsultats de sortie et de les intgrer aux cts des autres rsultats de test. Voici plusieurs exemples pour lesquels lutilisation de tests gnriques savre fort utile :

Utilisation dun Framework de test tiers (NUnit, MBUnit, JUnit) et intgration Initialisation
de lapplication teste afin de la rendre disponible pour la campagne de tests (voir cas des tests ordonns). de linitialisation de la plateforme de test ou de son nettoyage.

des rsultats dans lenvironnement de dveloppement / rapports de builds aux cts des autres tests.

Excution dune application console tierce ou dun script Windows en charge

Le test gnrique permet dexcuter nimporte quel type dapplication tierce nayant pas dinterface graphique : .EXE, .BAT, script PowerShell Il peut tre li pour initialiser/finaliser une squence de tests ordonns, valider un batch ou encore intgrer dans Visual Studio des Frameworks de test tiers (exemple : excution de NUnit avec un test gnrique et extraction/transformation des rsultats pour les intgrer dans Team Foundation Server.

30

5. Les tests dinterface utilisateur A. Introduction

Un grand nombre de types de tests pouvaient dj tre automatiss. La version 2010 de Visual Studio offre un nouveau type de tests nomms Coded UI tests . Il sagit de tests automatiss dinterfaces graphiques permettant de simuler les actions du clavier et de la souris enregistrs lors dune excution manuelle dun scnario dutilisation dune application. Les tests automatiss dinterface graphique sappuient sur lutilisation de Microsoft UI Automation (User Interface Automation), le nouveau framework daccessibilit pour Microsoft Windows fourni avec la version 3.0 du Framework .Net. Ce Framework volutif, permet aux dveloppeurs daccder par programmation :

Aux lments de linterface. Aux informations des lments de lIHM. Dinteragir avec ces lments. De recevoir des notifications lies aux changements de linterface. Et donc de coder des tests automatiss dinterface graphique.
LUI Automation distingue :

Les

fournisseurs (UI Automation Providers) : les applications existantes ou en dveloppement et qui pourraient-tre utilises par des utilisateurs ncessitant une aide, en terme daccessibilit. propose un fournisseur pour amliorer laccessibilit.

Les clients (UI Automation Clients) : les applications qui utilisent ce que

31

B. Tests automatiss dinterface utilisateur

Avec la version Premium et suprieure de Visual Studio 2010, les tests automatiss dinterface graphique, par gnration de code, sont intgrs directement dans lenvironnement de dveloppement. Celui-ci dispose ainsi dun enregistreur capable de capturer une squence de clicks utilisateurs sur le bureau Windows (indpendamment de la rsolution) ou dans un navigateur Web (quel quil soit).

Lenregistreur de test dinterface

Dans le premier cas, lenregistreur sintresse aux vnements Windows ainsi quaux proprits des objets, permettant de tester toute application que Windows est capable dafficher ! (nul besoin de possder son code source).

Extraction des proprits Windows pour une validation

Dans le deuxime cas, lenregistreur sintresse au DOM interprt par le navigateur et est sensible aux vnements Javascript et autres applications de feuilles de style CSS. Il est donc bien ici question de test dinterface et de comportement graphique et non de tests de composants techniques. Lorsque lon demande la cration dun test dinterface graphique, il nous est

32

demand si lon souhaite crer le test en partant de zro et en utilisant lenregistreur ou si lon souhaite utiliser un enregistrement existant. Il est en effet possible de demander lenregistrement des actions ralises par un testeur fonctionnel lors de lexcution dun test manuel. Cet enregistrement est alors associ au cas de test (work item) qui pourra tre utilis pour reproduire ces actions dans un test cod dinterface graphique. Quelques soit le mode de cration que lon utilise, le principe reste le mme : des actions ayant un point commun sont regroupes dans des mthodes dont lexcution peut tre enchane de faon reproduire ces actions.

Le plus gnralement, on retrouvera des mthodes du type :

ExecuterApplication() ; RealiserActions() ; RealiserAutresActions() ; FermerApplication() ;

Lavantage de regrouper de manire logique les diffrentes actions dans de telles mthodes permet de les rutiliser trs facilement pour recomposer dautres tests sans avoir renregistrer ces actions.

33

Voici un exemple de mthode gnr :

Les coordonnes que lon aperoit ici ne sont pas les coordonnes absolues du contrle dans lcran mais lendroit o a eu lieu le click en relatif dans le contrle. Les contrles sont bien videmment rcuprs via une arborescence de contrles et suivant des recherches sur des proprits (si deux Button se retrouvent au mme niveau dans larborescence, on les reconnait grce leur proprit, Name ). Sur le mme principe que pour les tests unitaires, il est possible dajouter des assertions concernant cette fois ci des proprits dun lment de lapplication. Pour cela, on slectionne un lment graphique de linterface et lui ajoute un test de validation :

34

Il est alors trs simple de choisir le type dassertion, puis de demander la gnration du code de validation correspondant :

Un certain nombre de fichiers sont gnrs ou mis jour lors de la cration dun test automatis :

UIMap.uitest : Fichier XML de cartographie de lapplication et des actions

ralises.

Une classe partielle dcompose en : UIMap.Designer.cs : code gnr

mthodes enregistres.

partir du fichier XML contenant les

UIMap.cs : code personnalis crer partir de duplications de mthodes

provenant du fichier UIMap.Designer.cs

UserControl.cs : Contient des classes permettant de manipuler les contrles

graphiques des applications Windows.

VotreTest.cs

: Contient une classe dcore par lattribut [CodedUITest] ainsi que des mthodes dcores par lattribut [TestMethod] contenant les enchanements dappels aux mthodes que vous avez gnres.

Tout comme les tests unitaires, lexcution dun test dinterface graphique peut se faire directement via le code partir du menu contextuel (puis Run Test), ou partir de la fentre Test View . De plus, lutilisation des sources de donnes est galement possible. On pourra donc utiliser en entre de tests dinterface

35

graphique des donnes provenant dune base de donnes SQL Server, dun fichier CSV ou XML, voir mme dun nouveau type de source de donnes disponible pour ce type de test : les Test Cases DataSources . Grce cela, un test peut rcuprer des paramtres dcrits dans un cas de test manuel dfini par un testeur fonctionnel dans Microsoft Test and Lab Manager. Lavantage est de navoir besoin de dfinir les valeurs pour ces paramtres qu un seul endroit que ce soit pour une excution manuelle ou automatise. Une fois quun test dinterface graphique est automatis il est possible de lutiliser pour enrichir un cas de test manuel existant. De cette faon, le testeur gnraliste aura le choix dexcuter ledit test manuellement ou de faon automatique. Pour cela, il suffit dassocier le test automatis au work item correspondant au cas de test :

NB : Du fait que ce test automatis nest pas connu de loutil Test and Lab Manager utilis pour dmarrer lexcution dun cas de test fonctionnel, il est ncessaire dassocier le plan de test (voir Stratgie de tests avec Visual Studio 2010) une dfinition de build contenant les binaires du test.

6. Les tests dinterface Web

Un test Web a pour rle de reproduire un scnario de navigation sur un ou plusieurs sites Web. Concrtement, le test Web permet de dcrire un ensemble de requtes HTTP (GET / POST) et se charge de rejouer celles-ci en assurant que les requtes et le contenu HTML renvoy par le serveur sont ceux attendus. Il ne sagit donc pas dun test dinterface graphique (pas de validation ou dinterprtation JavaScript ou CSS) mais bel et bien dun test denchainement de requte (de navigation).

36

Le test Web permet dautomatiser un scnario de navigation Web. Il se compose dun ensemble de requtes HTTP (POST / GET) pouvant tre rejou en boucle. Pour capturer un test Web, le plus simple est dutiliser un enregistreur (proxy) HTTP qui stocke les changes client/serveur et les transcrit dans un fichier. Deux outils sont trs bien adapts pour ceci, le Web test Recorder, propos par Visual Studio et qui sintgre Internet Explorer ou Fiddler2, outil gratuit propos par Microsoft qui enregistre lensemble des trames HTTP quelque soit le navigateur Web utilis et est capable de gnrer un fichier .webtest : un format lu par Visual Studio 2010. A noter que Fiddler est trs intressant lors dun test Web sur une application client/serveur base sur des services web, car il est galement capable denregistrer les changes SOAP et de les reproduire.

37

Enregistrement partir de loutil Web Test Recorder

Un test web peut contenir des rgles dextraction (capture de variables dans une requte pour les rinjecter dans une autre), de validation (code derreur http, texte prsent dans la page, temps de rponse) et peut tre li une source de donnes externe (par exemple : test dun formulaire dauthentification avec plusieurs identifiants). Un test Web est dcrit dans un fichier XML mais peut, dans un contexte de personnalisation avanc, tre transform en code .Net. Le Test Web peut servir valider dun point de vue fonctionnel :

La page renvoye doit afficher vous tes bien connect aprs transfert de
tels identifiants / mots de passe .

Pas derreur 404 (page non trouve) ou autre lors dune navigation sur
toute lapplication mais galement dun point de vue qualitatif.

Les pages doivent sexcuter en moins de 2 secondes . Les pages doivent avoir un poids infrieur 2 ko .
Une dizaine de rgles sont proposes par dfaut ( Find Test , Maximum Request Time , Required Tag , etc.), mais la liste peut trs facilement tre enrichie au travers de rgles personnalises. Depuis la version 2010 de Visual Studio il est possible dutiliser des boucles et des conditions dans les requtes. Ceci peut tre extrmement pratique lorsque le nombre dexcutions dune requte dpend dun paramtre dynamique, rcupr lors de lexcution du test web.

38

7. Profiling
Autre sujet qui sort un peu du contexte des tests, Visual Studio dispose depuis sa version 2005 dun outil pour analyser les performances des applications et mettre en avant les goulets dtranglement. Lintrt pour les analyses des performances est que cet outil peut tre excut directement depuis un test. Quelques exemples :

Analyse des performances dune fonctionnalit applicative aprs isolation

dans un test unitaire

Analyse

des performances dune page Web et de ses sous-contrles utilisateurs partir dun test Web

8. Les tests de charge A. Objectifs

Deux cas frquents dutilisation des tests de charge existent :

Pour valider une infrastructure cible avant une mise en production : sassurer
que linfrastructure et lapplication vont supporter la charge utilisateur vise.

Pour

assurer une qualit en continue de lapplication : sassurer quotidiennement quil ny ait pas de rgression en termes de performances de lapplication afin de pouvoir ragir immdiatement en cas de souci.

Les tests de charge permettent donc de sassurer que la solution fonctionne correctement avec un grand nombre dutilisateurs. Au final, le primtre couvert par ces tests regroupe :

Les

tests caractristiques de performances : comment la ractivit de lapplication est affecte en augmentant la charge.

Les tests de stress : comment la solution gre les niveaux extrmes de charge. Les tests dvolutivit : comment la solution ragit en fonction du modle de
scaling ( scale-up ou scale out ).

Les

tests de dure : comment se comporte la solution si une charge est applique sur une priode prolonge de test. partielle de son infrastructure logicielle ou matrielle.

Test de la continuit dactivit : comment la solution gre une mise en chec

Le test de charge est le seul test dont le rsultat nest pas binaire. Tous les rsultats de test sont stocks dans la base de donnes TFS Data Warehouse ce qui facilite ensuite la cration de rapports de synthse de test de charge dtaills

39

pour lanalyse de rsultats de test performance. Le rapport gnr peut tre consult au fur et mesure ou a posteriori, car stock dans une base de donnes relationnelle. Si Team Foundation Server est utilis, les rsultats peuvent galement y tre stocks. Il est possible dindustrialiser lexcution 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 modles de rapports ddis aux tests de charge sont disponibles dans ce dernier. Lintgration VS-TFS aide donc la gnration de rapports personnaliss qui peuvent tre utiliss pour lanalyse des causes des checs observs lors des tests de charge.

B. Cible
Loutillage Microsoft permet de tester en charge les applications spcifiques 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 dcrire un type de test simulant lutilisation. Etre capable de rcolter les compteurs de performance.
Un test de charge nest rien dautre quun test capable dexcuter 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 trs bien tre utilis avec des tests unitaires ou SQL pour valider la solidit de tout autre type dapplication.

40

C. Dmarche
La mise en place dun test de charge ncessite une mthodologie en 4 tapes :

Dfinition du primtre de test : que va-t-on tester ? Comment et avec quels

objectifs ?

Dfinition de larchitecture matrielle : que va-t-on utiliser comme environnement de test et tester ?

Cration et excution de la campagne. Analyse des rsultats : quels sont les problmes et les axes damlioration ?
O est le point de rupture ( partir de quand est-ce que lon considre que lapplication/linfrastructure a atteint ses limites) ? Et quels sont les facteurs limitant qui permettraient de dcaler le point de rupture (processeur trop utilis, mmoire sature, goulets dtranglements dans lapplication)

D. Prparation du Test
La phase de prparation du test est trs importante et passe au travers de plusieurs tapes.

Dfinition des scnarios : un test de charge doit se rapprocher au mieux de

la ralit, il est donc important lors de la cration de scnarios de bien cerner le contexte cibl. Seront ainsi pris en compte les navigateurs utiliss (une application web peut gnrer de lhtml diffrent si elle a un Internet Explorer ou un SmartPhone en face), le temps dattente entre les clics des pages (le but nest pas de reproduire du clic en continu mais de si-

41

muler des utilisateurs) et la bande passante (lobjectif est davoir des temps de rponses acceptables pour tous les utilisateurs, si certains utilisent des modems 56k, ils seront surveiller en priorit). Plusieurs scnarii peuvent tre capturs pour un test de charge, et chacun peut possder un poids. Par exemple, si 80% des utilisateurs restent sur la page daccueil de lapplication, un scnario doit le simuler, si 10% crent un compte, 10% naviguent dans un catalogue, des scnarios doivent tre crs avec un poids similaire dans le test de charge.

Le type de charge parmi les trois proposes : Montante : le nombre dutilisateurs augmente pendant toute la dure du
test, mme si la plateforme scroule.

Constante : le nombre dutilisateurs est stable sur la dure. Par Objectif : le nombre dutilisateurs augmente jusqu

atteindre un objectif dfini (processeur moins de 80%, temps de rponse moins de 2 secondes), lorsque lobjectif est atteint, la charge est lisse pour ne pas crouler le systme.

Les

indicateurs de performance : quels sont les compteurs Windows prendre en compte dans les rsultats de ce test de charge.

42

E. Infrastructure de Test
Au niveau de loutillage requis, deux cas existent :

Pour simuler une charge limite (en environnement de dveloppement par

exemple), Visual Studio seul est souvent suffisant.

Pour

une charge importante (tre sr dcrouler un environnement de pr-production ou de la rpartition de charge) : un contrleur peut venir se substituer Visual Studio pour piloter des agents de charge installs sur plusieurs machines. Visual Studio devient dans ce cas le pilote, les agents sont chargs de simuler la charge et de rcolter les rsultats et le contrleur de tout centraliser.

Visual Studio 2010 Test Agent gnre des tests de performance des applications Internet. Il permet aux entreprises damliorer la qualit de service en testant de manire plus efficace et plus proche de la charge future des serveurs, le comportement de leurs applications Web. Visual Studio 2010 Test Agent simule la charge utilisateur sur les applications Internet et les serveurs pour donner aux quipes qualit des informations prcises sur le comportement de leurs applications dans un mode de fonctionnement proche de la ralit. Les rsultats permettent de connatre les performances de ses applications, de dimensionner les serveurs pour des performances optimales. En un mot danticiper. Visual Studio 2010 Test Agent fonctionne avec toutes les technologies dapplications Web. Les tests web Visual Studio peuvent tre galement utiliss dans les tests de

43

performances en les ajoutant dans les tests de charge Visual Studio. Une documentation accompagne le produit et intgre une liste de compteurs, de seuils prdfinis et leur effet sur les serveurs en charge. La combinaison de Load Test et des tests Web fournit des rgles de validation et dextraction qui sont essentielles pour rendre les scripts robustes : les rgles dextraction aident dfinir comment paramtrer les donnes gnres dynamiquement. Le schma ci-dessous illustre le scnario de test de charge tel quappliqu pendant la Performance Week au MTC Paris. Le Load agent est install sur plusieurs machines diffrentes avec un contrleur de lagent de test de charge dans une zone commune dadministration du test de charge. Le test de charge rside sur le client Visual Studio ddition des tests de charge depuis lequel le testeur va configurer et lancer le test de telle sorte que les injecteurs (les agents de charge) gnrent la charge depuis diffrents emplacements sur lapplication web.

Pour les mesures de performance du code et de la mmoire sur un comportement spcifique dune portion du code en charge, il est recommand dajouter les tests unitaires dans les tests de charge et dactiver lanalyseur de performance Visual Studio Team System pour pouvoir faire un profiling prenant en compte le comportement en charge.

44

9. Les tests manuels

Avant Visual Studio 2010, les testeurs manuels navaient pas rellement doutils pour dfinir et excuter leurs tests fonctionnels. Il tait tout de mme possible de dfinir un scnario dans un fichier texte et de lexcuter partir de Visual Studio. Cependant, le fait de devoir utiliser Visual Studio pour raliser ces tests tait souvent un frein lutilisation et la dmocratisation de cet outil. Avec la version 2010 de Visual Studio arrive un nouveau type de tests : les cas de test. Il sagit dlments de travail (Work Items) au mme titre que les tches ou les bogues. De ce fait, ils bnficient de toutes les fonctionnalits en termes de partage, communication et traabilit que tous les autres types de work items. Un cas de test est dfini principalement par un ensemble dtapes raliser manuellement par un testeur gnraliste pour tester une fonctionnalit de lapplication. Chacune de ces tapes peut se voir enrichir dune indication sur le rsultat auquel doit sattendre le testeur lorsquil ralise cette tape ou encore dun fichier attach permettant de donner des informations plus compltes sur ltape en question.

Il est possible de factoriser un ensemble dtape dans un second type de work items : les Etapes partages ou Shared Steps. De cette manire, on pourra rutiliser facilement cet ensemble dtapes dans plusieurs cas de tests distincts. Trs souvent, on veut pouvoir excuter le mme scnario de test avec des paramtres diffrents. Par exemple si on simule la connexion un site web, on voudra pouvoir le raliser avec des informations de connexion diffrentes.

45

Pour raliser cela, un systme de paramtres est disponible. On ajoutera alors dans lintitul des tapes le nom du paramtre prfix du caractre @ tel que : @ Login. Il ne restera plus qu saisir les diffrentes valeurs pour tous les paramtres dans une grille. Ceci amnera lors de lexcution plusieurs itrations de test. Lexcution dun cas de test sera aborde dans le chapitre suivant au paragraphe 3.a : Excution .

46

Stratgies de tests avec Visual Studio 2010

1. Introduction
Visual Studio 2010 introduit un nouvel outil destin aux testeurs gnralistes et fonctionnels, non obligatoirement techniques : Microsoft Test and Lab Manager. Indpendant de Visual Studio cet outil reste connect Team Foundation Server pour permettre de faciliter et fluidifier la communication principalement entre testeurs et dveloppeurs. Cet outil offre deux centres de fonctionnalits :

Le Testing Center . Le Lab Center .

Le Testing Center permet de mettre en place des plans de test (campagnes) qui dfinissent la manire dont vos quipes de test vont tester fonctionnellement lapplication en cours de dveloppement. Cest au sein de ces plans de test que seront grs des cas de test (Test Cases) qui dfinissent un scnario de test de lapplication. Ces cas de tests sont des work items stocks et partags dans le serveur Team Foundation. Ce centre permet galement dexcuter des scnarios de tests, den suivre les rsultats, de reporter des anomalies au reste de lquipe et de valider des corrections ralises par lquipe de dveloppement. Lexcution des tests donne lieu la production de rapports sur la progression dun plan de test et permet de rpondre aux questions suivantes :

Combien de tests ont russi ou chou ? Combien de tests sont encore excuter pour cette itration ? Quand les tests seront-ils achevs ? Quelles zones ont des taux dchec lev de tests ? Quelles configurations de test ont des taux dchec levs de tests ? Qui a encore le plus de tests excuter ? Comment raffecter les ressources pour mieux quilibrer les tests restants ?
Le Lab Center permet de grer un laboratoire de tests. Cest dans ce centre que lon pourra dfinir des environnements virtuels de tests et les instancier pour pouvoir mettre en place rapidement et simplement des machines virtuelles de tests.

47

2. Planification des tests

La planification de leffort de tests raliser passe par le Testing Center. Dans cet outil il est possible de crer un ou plusieurs plans de tests pour chaque projet dquipe du serveur Team Foundation. Il faut voir chaque plan de test comme une vue sur les diffrents cas de tests disponibles pour le projet dquipe. Un plan est dfini principalement par son titre, sa classification (zone et itration), la personne qui le gre, et les paramtres dexcution :

Un plan de tests peut contenir et permettre dexcuter la fois des tests manuels et automatiss. Cest pour cette raison que lon retrouve deux types de paramtres dexcution :

Les paramtres dexcution permettent de dfinir les informations qui seront collectes automatiquement lors de lexcution dun test. On retrouve plusieurs collecteurs par dfaut, tels que :

48

Vido : enregistre ce quil se passe lcran pendant que le testeur excute

le test.

IntelliTrace

: collecte les informations vnementielles de dbug historique permettant au dveloppeur de comprendre rapidement lorigine dune anomalie si besoin. que ralise le testeur dans le but de pouvoir gnrer un test dinterface graphique cod automatiquement. Impact : permet dactiver lanalyse de test impact de faon pouvoir automatiquement connatre la liste des tests rejouer pour valider une nouvelle version et viter la rgression des fonctionnalits dj testes.

Action recording et Action Log : permet denregistrer la liste des actions Test

Le but dun plan de tests est de valider une version cible de lapplication, comme par exemple celle produite par litration 1. La validation se fait au fur et mesure du dveloppement, priode pendant laquelle les quipes de test vont frquemment valider les nouvelles versions intermdiaires produites par les quipes de dveloppement travers le service de Build. De manire garantir la traabilit, il est possible et conseill dindiquer quel est le contexte courant de test en prcisant la Build utiliser. De cette manire, quand une anomalie sera remonte, elle sera automatiquement marque comme dcouverte dans la dfinition de build : XXX . De mme, il est possible de dfinir un ensemble de configurations au sein desquelles on doit excuter la campagne de test. On pourra par exemple imaginer devoir valider une application web avec un systme dexploitation Windows 7 dot dun navigateur Internet Explorer 8 et dans un Windows Vista exploitant Internet Explorer 7.

Au-del dune simple fiche de dfinition, le plan de test permet de grer les cas de tests qui permettront de valider fonctionnellement lapplication. Ces cas de tests proviennent du serveur Team Foundation, et peuvent tre crs partir de Microsoft Test and Lab Manager. Ils sont crs dans des listes appeles suites de tests permettant de les organiser pour regrouper ceux qui sont en rapport les uns les autres. Les suites peuvent tre de plusieurs types :

Suite simple : rpertoire permettant dorganiser un ensemble de cas de tests.

49

Suite de type Requirement : rpertoire associ un work item de type

renvoys par une requte de work items.

requirement dans Team Foundation Server. Tout test associ cette suite sera li au work items requirement.

Suite de type Requte : rpertoire dynamique affichant les cas de tests

50

Cest dans ces suites que les cas de tests seront crs ou ajouts sils existent dj dans le serveur. Le schma suivant rcapitule les informations stockes dans un plan de test Microsoft Test and Lab Manager.

3. Communication, changes et traabilit des tests A. Excution

Au-del dun simple outil de dfinition de cas de tests et de campagnes les organisant, Microsoft Test and Lab Manager permet de les excuter et de reporter des anomalies vers les quipes de dveloppement et de suivre lvolution des corrections. Les outils ncessaires lexcution de cas de test sont compris dans longlet Test du testing center de Microsoft Test and Lab Manager :

51

Les outils disponibles permettent :

Dexcuter un ensemble de cas de tests. De suivre lvolution des anomalies (bogues)

dveloppement.

reportes lquipe de

Danalyser les rsultats dexcutions de tests passs.

On y retrouve les diffrentes suites de tests excutables pour ce plan de test ainsi que les cas de tests les comprenant. Chaque cas de test est identifi par un tat indiquant la dernire information connue pour ce test. On retrouvera notamment les tats Failed et Passed indiquant le rsultat de la dernire excution, mais galement les tats Active et Running permettant de savoir respectivement si le test doit tre excut, ou sil est en cours dexcution par un autre testeur. Chaque fois que lon dmarre une excution de test, loutil se place dans une logique de Test Run . Un test run inclut potentiellement lexcution de plusieurs cas de tests et un rapport sera disponible pour lensemble du test run et enfin pour chacun des tests contenus dans ce run. Lexcution dun ou plusieurs tests transforme loutil Test and Lab Manager en un autre outil destin guider le testeur dans son travail : le Test Runner. Il permet de connatre la liste des tests excuter ainsi que les tapes raliser pour chacun de ces tests :

52

Chaque tape est alors raliser, et marquer comme russie ou choue :

La force de cet outil est de faciliter la communication avec le reste de lquipe. De ce fait, lorsquune anomalie est dcouverte, il est trs simple de reporter un bogue lquipe de dveloppement. Ce bogue sera automatiquement rempli avec les informations rcupres par les diffrents collecteurs configurs pour le plan de test :

53

On retrouvera des informations telles que :

La vido et des marques pages dans celle-ci pour chacune des tapes. La liste des tapes et leur tat chou ou russi. Les commentaires associs ces tapes. Les fichiers attachs ces tapes, sils existent.
Mais galement des informations relatives lenvironnement dexcution (utilisation de la mmoire, architecture du processeur, version de Windows, etc.). De plus, un lien est automatiquement cr entre ce nouveau Bogue Team Foundation Server et le cas de test utilis par le testeur pour trouver cette anomalie. De cette manire, le dveloppeur en charge de lanalyse de ce problme identifi sur lapplication aura toutes les informations ncessaires la reproduction du bogue. Ceci est identifi sous le terme : Plus jamais de non-reproductibilit ! . Lavantage de cette solution est que le testeur na plus qu se concentrer sur ce qui fait sa valeur ajoute : lexcution et lanalyse de tests, la collection des informations tant automatise.

B. Analyse de rsultats
Chaque test run amne un rapport exploitable directement partir de Microsoft Test and Lab Manager. Ce rapport contient les informations telles que :

Quand a t excut le run ? Par qui ? Quelle tait la dfinition de build associe au plan lors de cette excution ? Combien de tests taient excuts dans ce run ? Etc.
On y retrouve galement un accs au rapport de chacun de tests excuts :

54

Pour chacun des tests, un rapport complet et dtaill est disponible dans lequel on retrouve notamment :

Sa dure. Les dtails de chacune des tapes ralises. Russie ou choue. Liste des fichiers attachs. Commentaires du testeur.
On y retrouve galement la liste des anomalies associes, potentiellement reportes lors de lexcution de ce test.

C. Communication avec lquipe de dveloppement

Lorsque les dveloppeurs mettent disposition une nouvelle version de lapplication, celle-ci peut potentiellement corriger des anomalies, ou contient des volutions de fonctionnalits existantes. Il est important pour lquipe de test de pouvoir facilement suivre ces modifications et corrections. Pour cela, chaque testeur pourra visionner nimporte quel moment la liste des anomalies quil a reportes

55

A partir de la vue Verify Bugs, il peut trs simplement connatre la liste des bogues rsolus et demander de valider la correction associe. Pour cela il lui suffit de cliquer sur le bouton Verify et le cas de test ayant t utilis lorigine pour dtecter lanomalie sera automatiquement r-excut. Si le test est un succs, et que le testeur estime que la correction est valide, il sera invit marquer le bogue comme rsolu. Dans le cas inverse, il pourra le marquer comme actif nouveau pour le renvoyer vers lquipe de dveloppement. Nous avons vu prcdemment quun plan de test est associ une dfinition de build. Longlet Track permet notamment de visionner la liste des builds disponibles, et den assigner une nouvelle (par exemple : la plus rcente) au plan courant. De ce fait, une vue lui est propose mettant en avant :

La liste des tests recommands. La liste des lments de travail

de build.

(work item) associs cette dfinition

Les tests recommands sont lis la notion danalyse de tests impacts. Quand un testeur excute un test manuel, un collecteur analyse le code excut et enregistre cette information. Cette analyse est alors couple au code qui a t modifi dans la dfinition de build courante, et tous les tests qui ont t marqus comme ayant utilis ce code sont alors proposs comme Tests recommands . Il sagit ici dun premier niveau de non rgression. Cela nvite bien entendu pas de jouer les cas de tests pour les nouvelles fonctionnalits.

Chaque fois quun dveloppeur archive (envoie) du code dans le contrle de code source, il a la possibilit dy associer un work item. Celui-ci peut tre un bogue, une tche ou encore un scnario dutilisation ou requirement. Cette information est vitale pour les testeurs car elle permet de savoir si de nouvelles fonctionnalits ont t implmentes et par l-mme, quels tests il faudra jouer voir crer.

56

4. Reporting sur les tests

Toutes les donnes de Team Foundation Server sont stockes dans une base de donnes. Celles-ci alimentent un entrept de donnes permettant de gnrer des rapports donnant une vue macro sur lvolution du projet dans son ensemble. Ceci est galement vrai pour la partie test, dautant que chaque rapport de Microsoft Test and Lab Manager est stock dans cet entrept. Il existe par dfaut un certain nombre de rapports disponibles suivant la mthode que vous avez slectionne lors de la cration de votre projet dquipe. Ils permettent de mettre en avant suivant diffrentes vues lvolution de lavancement de lexcution ou la cration des plans de tests par votre quipe de test. Un premier exemple pertinent, est le rapport de Test Case Readiness permettant davoir une vue globale de lavancement de la cration des cas de tests, tous plans confondus. En effet, un cas de test peut avoir trois tats (suivant la mthode) :

Proposed (propos). In Design (en cours de ralisation). Ready (prt tre excut).
Voici un exemple de rapport gnr :

57

Le rapport Test Plan Progress quant lui permet de mettre en avant lavancement de laspect excution des plans de tests du projet dquipe. Vous pouvez voir par exemple sur le graphique suivant que 25 tests sur 40 sont actuellement dans un tat Russi . Ceci permet davoir une excellente vision sur la qualit de lapplication et leffort ralis par lquipe de test pour la valider fonctionnellement.

Le dernier rapport disponible permettra davoir une vue diffrente de la progression des tests, plus tabulaire et organise par plan de test, puis par requirement.

58

Les rapports sont vitaux pour assurer le bon droulement dun projet, et dautant plus pour laspect qualit de celui-ci. Cest pour cette raison quil est possible de personnaliser les rapports par dfaut et den crer de nouveaux suivant les besoins des projets. Ceci peut tre ralis trs simplement du fait de lutilisation de Reporting Service 2008.

5. Gestion denvironnements virtuels de dploiement et de test

De nos jours les applications sont de plus en plus complexes, destines tre excutes sur de nombreux types denvironnements diffrents ou sur des infrastructures contenant un nombre lev de machines. Mettre en place de tels environnements dans le cadre des processus dassurance qualit est long, complexe et rptitif. Depuis quelques annes, la virtualisation a dj permis de faire un grand pas en avant dans la simplification de la mise en place denvironnement de test, en permettant de dpasser la limite des machines physique et de dupliquer aisment une ou plusieurs machines virtuelles. Cela tant, cette opration reste manuelle et gourmande en temps. Visual Studio 2010 Team Lab Management permet dautomatiser la cration denvironnement, offrant aux testeurs la possibilit de crer et contrler eux-mmes la gnration de ces environnements. Team Foundation Server est ainsi connect lapplication System Center Virtual Machine Manager 2008. Cette application permet de contrler un serveur de virtualisation Hyper-V et de stocker des modles de machines virtuelles dans une bibliothque. Vous pouvez voir dans le schma ci-dessous la nouvelle infrastructure des tests induite par cette nouvelle fonctionnalit :

59

Le Lab Center de loutil Microsoft Test and Lab Manager permet de grer tous les aspects du Lab Management. Le principe est simple : le testeur ajoute au plan de tests des modles de machines virtuelles pralablement crs dans loutil System Center Virtual Machine Manager. Il peut alors crer des modles denvironnements. Un environnement contient potentiellement plusieurs machines virtuelles, comme par exemple : Un serveur SQL, un serveur Web et un client contenant un navigateur web. Chaque machine virtuelle se verra dote de 3 services pralablement installs :

Le Lab Agent : permettant au Lab Management de grer cette machine

distance.

Le

Test Agent : permettant un testeur de lancer lexcution dun test automatis sur cette machine, et de rcolter les diffrentes informations provenant des collecteurs slectionns dans le plan de test. utilis dans le cadre dune dfinition de build, lors de la phase de dploiement de lapplication sur la machine. Un workflow est alors excut sur cette machine pour excuter un certain nombre dinstruction comme par exemple la copie de fichiers, ou lexcution dun installeur (MSI).

Le Build Agent : permettant dexcuter un workflow. Ceci est principalement

Un exemple denvironnement pourrait ressembler au schma suivant :

Une fois cet environnement cr, il est possible de linstancier autant de fois que ncessaire. On pourra alors en un simple clic gnrer une nouvelle version de ce dernier, dans le but dy excuter des tests.

60

Au-del dun simple outil de cration denvironnements de tests, le Lab Management peut tre exploit lors de lexcution dun test manuel ou automatis. En effet, il est possible de choisir un environnement virtuel lors de lexcution dun test. Toute lexcution se produira alors dans cet environnement. Un des avantages de cette solution est dviter de demander au testeur davoir lapplication installe sur son poste pour pouvoir la tester. Un autre avantage vident est de pouvoir facilement tester lapplication dans plusieurs environnements diffrents, comme par exemple : sur Windows Vista, Windows 7, etc. sans avoir changer de poste.

61

Lorsquun testeur excute un test dans un environnement virtualis, il a sa disposition une nouvelle fonctionnalit nomme : Snapshot . Le principe est simple :

Le testeur dcouvre une anomalie et il veut conserver lenvironnement tel

quil est au moment o cette anomalie est mise en vidence. ltape courante.

Il sauvegarde un snapshot de tout lenvironnement. Celui-ci est alors attach

Lorsque le dveloppeur ouvre le bogue cr par le testeur, il a la possibilit de cliquer sur un lien correspondant ce snapshot et par l mme douvrir lenvironnement tel quil tait lorsque le snapshot a t pris. Grce cette fonctionnalit, on peut revenir au moment mme o lerreur a eu lieu : pas uniquement pour la machine cliente, mais pour lensemble des machines de lenvironnement, incluant le serveur de base de donnes, le serveur web, etc.

62

Pour exploiter pleinement tous les aspects dautomatisation du Lab Management, des activits de workflow de build existent permettant davoir un contrle total sur les environnements grs par ce service. On pourra donc, lors dun processus dintgration continue, en plus de la compilation de lapplication, lexcution des tests unitaires automatiques, la gnration de la couverture de code : gnrer ou r-exploiter un environnement du lab management pour dployer lapplication, prte tre teste !

63

Synthse
Les diffrentes analyses montrent que les tests prennent effectivement de plus en plus dimportance en entreprise, et que ceux-ci ont de beaux jours devant eux. Cependant, la mise en uvre de ces tests suppose deux pr-requis :

Dun point de vue technique, sassurer que les dveloppeurs ont facilement
accs aux diffrents types de tests et que leur criture ne se traduit pas par une contrainte mais par un rel gain de productivit.

Dun

point de vue organisationnel, rapprocher le monde des testeurs fonctionnels de celui des dveloppeurs responsables de la correction de bogues, en simplifiant et fluidifiant leur communication.

Et cest exactement sur ces deux points que Visual Studio 2010 innove, en outillant la cration de tests dune manire parfaitement intgre dans lenvironnement de dveloppement et en offrant un rfrentiel commun aux testeurs fonctionnels et aux dveloppeurs sur lensemble du cycle de vie des applications tout en leur permettant dutiliser des outils qui leur sont propres. Ce livre blanc nous aura permis de faire un tour dhorizon de la problmatique des tests et de la rponse que Microsoft y apporte avec Visual Studio 2010.

64

Annexe : Etendre le Framework de test

Lors de la mise en uvre de tests de composants logiciels, il est frquent davoir recours au pattern Stub de Service (Martin Fowler) pour sassurer que le code sous test a obtenu tous les lments requis pour mettre lpreuve sa logique, indpendamment de toute autre logique dont il dpende. La mise en uvre de ce pattern est ralise grce lusage dun systme de bouchonnage souvent appel Mock . Un objet Mock partage la mme interface (au sens type .Net) que les objets utiliss par la logique tester et est conu pour en permettre la validation. Lcriture manuelle de ces objets Mock est souvent rptitive et fastidieuse. Fort heureusement, il existe des frameworks offrant un jeu dAPI permettant lautomatisation de la cration de ces Mocks . Roy Osherove, auteur de louvrage Art of Unit Testing propose une liste quasi exhaustive des outils que vous pouvez utiliser lors de lcriture de vos tests unitaires (voire vos tests dintgration) sur son site : http://www.artofunittesting.com/Chapters/Tools_and_ frameworks

65

Voici un aperu de quelques-uns de ces outils :

Pex (http://research.microsoft.com/projects/pex) est un assistant pour le programmeur. Avec Pex, il est possible dassocier des attributs des tests paramtrs. Dans un test unitaire paramtr, le moteur de Pex gnre automatiquement une suite de tests unitaires avec un taux de couverture de code lev. Pex permet ainsi didentifier les cas aux limites mal grs dans le code. Microsoft Chess (http://research.microsoft.com/projects/CHESS) est un outil automatis pour rechercher des erreurs dans les logiciels multithreads par exploration systmatique. Il dtecte les erreurs, telles que les deadlocks , les suspensions et les violations daccs induites par corruption de donnes, qui sont extrmement difficiles trouver avec les outils de test actuels. Une fois lerreur localise, il fournit une excution entirement reproductible du programme conduisant lerreur, et facilite donc grandement le processus de dbogage. En outre, il propose une couverture de test adapte pour les programmes multithreads. Project White (http://www.codeplex.com/white) est un framework de tests dintgration proposant une API pour tester les applications riches (WPF, WinForm, Win32 et Java JWT). dveloppement de tests unitaires ciblant les services WCF. Les services WCF sappuient souvent sur la notion de contexte WCF (OperationContext et WebOperationContext) pour effectuer diffrentes actions (en particulier les services REST pour lesquels le contexte est ncessaire pour les paramtres et lobtention de codes den-ttes http). WCFMock fournit un ensemble de classes pour supprimer toutes les dpendances explicites avec le contexte de lopration et propose une faon adapte de simuler le comportement de ce contexte. simple dusage et exploite les fonctions du .Net Framework 3.5 comme les Lambda Expressions et les mthodes dextension.

WCFMock (http://wcfmock.codeplex.com/) est un framework facilitant le

Moq (http://code.google.com/p/moq/) propose une API de Mocking trs MockingBird (http://mockingbird.codeplex.com/) est un ensemble doutils
facilitant le bouchonnage de services web. Le moteur de MockingBird est un intercepteur de messages configurable pour nimporte quel type de service web. MockingBird facilite le dveloppement de services Web en proposant une approche contract first ainsi que lisolation des serveurs de dveloppement et de build vis--vis des dpendances externes.

66

Annexe : Tests automatiss dinterface utilisateur : Technologies supportes

Le tableau suivant dtaille lensemble des technologies supportes : Windows Internet Explorer 7.0 Windows Internet Explorer 8.0 (Including HTML and AJAX) Windows Internet Explorer 6.0 Chrome Opera Safari Silverlight 3.0 Flash/Java Windows Forms 2.0 and greater WPF 3.5 and greater Windows Win32 MFC SharePoint Office Client Applications Dynamics (Ax) SAP Citrix/Terminal Services Not supported Not supported Fully supported Fully supported May work with some known issues, but not officially supported May work with some known issues, but not officially supported Partially supported Not supported Partially supported Not supported Partially supported Not supported Not supported Fully supported

67

Annexe : Tests automatiss dinterface utilisateur : Systmes supports

Le tableau suivant dtaille lensemble des systmes supports. Windows 2000 with Service Pack 4 Windows XP with Service Pack 3 Windows Server 2003 with Service Pack 1 Windows Server 2003 with Service Pack 2 Operating Systems Windows Server 2008 and Windows Server 2008 R2 Note Windows Internet Explorer Enhanced Security must be turned off for Windows Server 2003 and Windows Server 2008. Windows 7 32-bit Windows that is running 32-bit Microsoft Test and Lab Manager can test 32-bit applications. 32-bit / 64-bit Support 64-bit Windows that is running 32-bit Microsoft Test and Lab Manager can test 32-bit WOW Applications that have UI Synchronization. 64-bit Windows that is running 32-bit Microsoft Test and Lab Manager can test 64-bit Windows Forms/WPF Applications that do not have UI Synchronization. x86 and x64 Architecture Note Windows Internet Explorer is not supported in 64-bit mode

68

.Net 2.0, 3.0, 3.5, and 4 Note .Net Microsoft Test and Lab Manager and Microsoft Visual Studio 2010 will both require .Net 4 to operate. However, applications developed by using the listed .Net versions are supported. English, Japanese, Korean, Hindi

Languages

69

Annexe : Rfrences techniques

Quelques liens vous permettant daller plus loin Livres : http://www.amazon.fr/Microsoft-Team-Foundation-Server-TFS/dp/274604711X http://www.artofunittesting.com/Chapters/The_Basics_Of_Unit_Testing Blogs :

Eric Le Loch Spcialiste quipe Team System : http://blogs.msdn.com/ericleloch Florent Santin MVP Team System : http://blogs.developpeur.org/azra Stephane Goudeau Architecte MTC : http://blogs.msdn.com/stephgou Etienne Margraff MVP Team System : http://blogs.developpeur.org/etienne Le blog du MTC Paris : http://blogs.msdn.com/mtcparis/
Liens:

Service Stub Pattern http://www.martinfowler.com/eaaCatalog/serviceStub.html Software Testing http://msdn.microsoft.com/en-us/library/cc188960.aspx MSDN Test Edition ms-help://MS.VSCC.v90/MS.MSDNQTR.v90.en/dv_vsetetesttoc/html/796b7d6dad45-4772-9719-55eaf5490dac.htm Page officielle Team System: http://msdn.microsoft.com/teamsystem Ensemble de ressources Franaises: http://www.team-system.fr Microsoft Visual Studio Team System 2008 Team Foundation Server SP1 and

Team Suite SP1 VPC Image (Trial) http://www.microsoft.com/downloads/details.aspx?FamilyID=c7a809d8-8c9f439f-8147-948bc6957812&displaylang=en

Visual Studio Team System 2008 Team Foundation Server SP1 VPC Image (Trial) http://www.microsoft.com/downloads/details.aspx?FamilyID=72262ead-e49d43d4-aa45-1da2a27d9a65&displaylang=en

70

Team Foundation Server Administrators Guide http://www.microsoft.com/downloads/details.aspx?familyid=2AED0ECC-155249F1-ABE7-4905155E210A&displaylang=en Guide dinstallation http://www.microsoft.com/downloads/details.aspx?familyid=ff12844f-398c-4fe98b0d-9e84181d9923&displaylang=en Conversion depuis VSS http://www.codeplex.com/Wiki/View.aspx?ProjectName=VssConverterGui Reprise Existant http://www.codeplex.com/MigrationSyncToolkit TFS 2008 System Recommendations http://blogs.msdn.com/bharry/archive/2007/10/18/tfs-2008-system-recommendations.aspx TFS at Microsoft http://blogs.msdn.com/bharry/archive/2006/08/22/712746.aspx http://blogs.msdn.com/bharry/archive/2008/07/03/july-08-devdiv-tfs-dogfoodstatistics.aspx How do I ? (Videos) http://msdn.microsoft.com/en-us/vsts2008/bb507749.aspx?wt.slv=topsectionsee Ressources Francophones http://www.team-system.fr/default.aspx Team System Widgets http://widgets.accentient.com/ Rapport de tests de charge et comparaison (pour 2008) http://www.codeplex.com/loadtestreports Licensing http://www.microsoft.com/Downloads/details.aspx?FamilyID=ce194742-a6e84126-aa30-5c4e969af2a3&displaylang=en TFS Power Tools http://www.microsoft.com/downloads/details.aspx?FamilyId=FBD14EEA-781F45A1-8C46-9F6BA2F68BF0&displaylang=en Blog de lquipe de test Microsoft http://blogs.msdn.com/vstsqualitytools/

71

Blog de lquipe de Team Lab de Microsoft http://blogs.msdn.com/lab_management/ Test Scribe (outil de gnration de documentation de plan de test) http://visualstudiogallery.msdn.microsoft.com/en-us/d18873c7-909d-4788a56e-0c496a1d8bb9 Outil pour gnrer une machine virtuelle prte pour le Lab Management http://vslabmgmt.codeplex.com/documentation

Les tests Logiciels : Une tude de cas avec Visual Studio 2010 Les tests prennent de plus en plus dimportance dans le monde de lentreprise. Fort de ce constat, Microsoft tend sa suite logicielle Visual Studio en couvrant la totalit du spectre de la technique au fonctionnel. Ce Livre Blanc a pour objectif de faire un tat des lieux de lutilisation des tests en entreprise en dtaillant les possibilits quoffre aujourdhui cet environnement.

Microsoft France - RCS Nanterre B 327 733 184 - Imprimeur : RGI -