Team System 2008 : Fichier qui reste dans l’état “Checked out by someone else …”

Lorsque l’on travaille à plusieurs sur un même projet, il est utile de savoir si un fichier sur lequel on désire travailler est déjà extrait (checkout) par un autre utilisateur. C’est l’origine de la petite icone en forme de développeur (si si, si on zoome, ça ressemble à un développeur ! ;-)) à gauche du fichier “source contrôlé”.

On peut alors se rendre dans l’outil de visualisation du contrôleur de code source pour voir qui est en train de travailler sur ce fichier, et potentiellement se synchroniser avec lui, lui demander de le libérer par exemple. :

image

Il peut vous arriver de vous retrouver dans cette situation, mais que l’explorateur de contrôle de code source ne vous indique pas qui a extrait le fichier :

image

Dans ce cas :

  • Ne paniquez pas
  • Ne criez pas au bug ! :)

Cela arrive lorsqu’un utilisateur extrait un fichier, le modifie, et le met sur étagère (shelve). A partir de ce moment, même si le développeur en question n’a plus le fichier extrait dans son espace de travail, il est tout de même considéré comme extrait quelque part !

Dès que le shelve sera supprimé ou récupéré puis archivé, on récupère bien l’icone rassurante en forme de cadenas bleu, indiquant que tout est sous contrôle :)

image

Seul regret que j’ai par rapport à ça, c’est qu’on aurait pu avoir une autre icone indiquant que le fichier extrait dans une étagère.

.Dispose();

Vox Agile : Un nouveau podcast sur l’agilité !

Vous connaissez certainement le podcast sur la plateforme .NET : Visual Studio Talk Show ( http://www.visualstudiotalkshow.com ) ?

François Beauregard de la société Pyxis lance un nouveau podcast sur le même modèle, mais cette fois-ci sur les méthodes agiles, nommé : Vox Agile ! Lors de ce premier épisode, il discute avec Jean-René Rousseau des piliers du manifeste agile.

Pas la peine d’en dire plus, rendez-vous sur : http://voxagile.pyxis-tech.com/ 

Bonne écoute !

.Dispose();

Informations à propos des migrations/synchronisations vers TFS

Je viens de voir qu’une nouvelle page à été publiée sur le site de la MSDN contenant beaucoup d’information à propos des possibilités de migration/synchronisation entre TFS et d’autres outils tels que CVS, SVN, ClearCase, etc.

Plutôt intéressant de retrouver tout cela centralisé à un seul endroit :)

La page en question : http://msdn.microsoft.com/en-us/teamsystem/bb840033.aspx

Source (blog de Stephanie Saad Cuthbertson)

.Dispose();

[Visual Studio 2010] Les tests cases c’est bien, mais je vais devoir tout réécrire ?

Si vous avez jeté un coup d’œil aux nouveautés niveau tests dans Team Foundation Server 2010, vous être certainement tombés sur les tests cases. La première chose que vous avez dû vous dire c’est : “Super, je vais enfin pouvoir jouer mes tests de façon plus détaillée !”. Si vous avez déjà des tests manuel “à la mode” 2008, c’est à dire au format tableau Microsoft Word dans un fichier .mht vous avez dû vous dire ensuite “Ah oui… mais comme c’est une interface intégrée à Visual Studio je vais tout devoir réécrire !”.

Et bien non ! (et heureusement, sinon ce billet n’aurait aucun intérêt !) Il est possible de copier/coller d’un tableau Word, vers un test case. Cela va automatiquement créé les étapes correctement dans le work item :) Fonctionnalité basique pour sûr, mais I N D I S P E N S A B L E ! D’autant plus que cela vous permettra d’obtenir des cahiers de tests sous forme de tableau Word, saisis par des utilisateurs qui n’utilisent pas Visual Studio (ni Test and Lab Manager) et de les intégrer très rapidement dans des tests case. Et cela ne s’arrête pas là, car le copier/coller fonctionne aussi à partir d’Excel, d’une page HTML, etc. :)

Il faut seulement prendre en compte le fait que la première “colonne” de la sélection arrive dans la colonne “Action” du test case, et la seconde arrive dans “Expected Result”. Ceci implique que toutes les colonnes suivantes de la sélection sont ignorées.

Petite illustration en images avec en premier lieu la copie des deux colonnes du test manuel :

image

puis le “collage” dans le test case :

image

et le résultat :

image

Et le tour est joué !

Rapide, simple, efficace :)

.Dispose();

Visual Studio 2010 – Quoi de neuf… pour les requêtes de Work items ?

“Petite” nouveauté dans Visual Studio 2010 que vous trouverez certainement vitale si vous avez tendance à avoir beaucoup de requêtes de work items dans vos projets d’équipe : la possibilité d’organiser ces requêtes dans des “répertoires”, et surtout d’y appliquer de la sécurité.

Pour illustrer cette fonctionnalité, imaginons une équipe standard contenant notamment des développeurs et des testeurs. Pour éviter aux personnes appartenant à l’un ou l’autre de ces deux profils de perdre du temps à chercher les requêtes qui les intéressent, on pourrait les organiser comme ceci :

image

Pour ajouter un répertoire : 

image

Et il ne vous reste plus qu’a glisser déposer vos requêtes :)

Et on peut pousser la démarche en ajoutant de la sécurité. Cela peut notamment être utile si on sait que l’équipe de test dans notre exemple n’aura jamais besoin d’autres requêtes que celles concernant les tests. On ne lui donne alors accès qu’à celles là et ce qui évite de “polluer” la liste de ses requêtes avec des éléments qui ne l’intéresse pas.

La sécurité est gérée sur le nœud Team Queries pour les droits globaux mais également sur chaque répertoire ou même une requête. Le tout avec le principe d’héritage auquel nous sommes habitués.

On accède à la gestion de la sécurité au niveau du menu contextuel sur l’élément choisi :

image 

Les permissions que l’on peut gérer sont :

  • La lecture
  • La contribution
  • La suppression
  • La possibilité de gérer les droits sur l’élément

Dans notre exemple, j’ai refusé tous les droits sur la racine Team Queries au groupe Testers et ci-dessous, je lui assigne les droits souhaités uniquement sur le répertoire Tests :

image

Vous comprenez donc que si on ne donne accès qu’en lecture à un utilisateur, il ne pourra voir que les workitems des requêtes dont il a accès (et aucun autre, car il ne pourra pas non plus créer de requête).

Au final, quand un membre du groupe Testers se connecte au projet d’équipe, il ne verra que le répertoire qui l’intéresse :

image

Tout ceci est bien entendu appliqué dans Microsoft Test and Lab Management (MTLM) :

image

.Dispose();

Visual Studio 2010 – Quoi de neuf… pour les tests web ?

Dans les nouveautés qu’on peut découvrir autour des tests dans Visual Studio 2010, les tests web ne sont pas oubliés ! De nouvelles règles, nouvelles instructions, etc. Je vous propose dans ce billet de passer en revue ces modifications.

Si vous avez jeté un coup d’œil rapide aux tests web dans Visual Studio 2010, vous avez pu vous dire qu’il n’y a rien qui a changé. Et pourtant, beaucoup d’éléments sont nouveaux. Certains améliorent l’expérience utilisateur en facilitant l’accès à certaines fonctionnalités, d’autres sont de nouvelles possibilités.

La première chose importante à noter est l’apparition de Conditions et de Boucles :

image

Nous avons accès à plusieurs types de boucles (basés sur l’existence d’un cookie, boucle for, etc.). Remarquez que la boucle en question peut s’appliquer à plusieurs requêtes, nous indiquons la première et la dernière comme pour les transactions :

image

image

L’exemple ci-dessus pourrait être utilisé pour exécuter la requête jusqu’à ce que la règle d’extraction ai réussi à trouver une valeur et l’ai ajouté en paramètre de contexte :)

C’est exactement le même principe pour les conditions :

image

image

Par exemple ci-dessus, deux groupes de requêtes dans un cas ou dans un autre, basé sur une chaîne de caractères extraite de la première requête.

Loin d’être basique, l’apparition de ces deux instructions est une bénédiction pour un webtesteur. Avant la version 2010, impossible de faire cela sans utiliser les web tests codés et perdre tout l’avantage de l’éditeur graphique (sans compter le temps que cela peut prendre). Personnellement j’attendais cela avec impatience !

Toujours dans la partie éditeur de test web, on retrouve une fonctionnalité très intéressante : Set Request Details

image

Celle-ci permet d’éditer certaines propriétés de toutes les requêtes via une vue rapide :

image

Idéal pour appliquer très rapidement des modifications ou par exemple chercher des think times aberrants (pause café pendant l’enregistrement du scénario ;))

On remarque également ici une nouvelle propriété sur les requêtes qui permet de modifier le nom affiché dans le rapport d’exécution du test. Cette fonctionnalité est extrêmement utile d’autant plus si vous testez une application web ne possédant qu’une page dont le contenu est modifié en fonction des paramètres, ou si vous avez beaucoup d’ajax. Dans la capture ci-dessus, j’ai nommé deux fois la pages NewForm.aspx pour savoir plus facilement à quoi correspond chacune des deux requêtes pendant l’exécution :

image

On a également de nouvelles règles d’extraction :

image

Et de nouvelles règles de validation :

image

Les nouveautés suivantes se situent au niveau du rapport d’exécution d’un test web. Le temps d’analyse est réduit par un certains nombre d’accélérateurs.

En affichant le menu contextuel d’une requête, nous avons maintenant accès à deux fonctionnalités :

image

Go to Web Test est bien une nouveauté même si cela aurait dû être présent dans les versions précédentes tellement c’est vital dans un test contenant beaucoup de requêtes : il s’agit de pouvoir arriver directement sur la définition de la requête dans l’éditeur de test web !

Quick Find est un pas de géant dans l’analyse d’un résultat de test web. Comme son nom l’indique, il permet de rechercher du texte dans le résultat. Il est vraiment très puissant car il nous offre un nombre de filtres intéressants :

image

Comme vous pouvez le voir, il ne cherche pas que dans la réponse HTTP, il chercher également dans le contexte :

image

Toujours dans l’idée de gagner du temps, nous avons la possibilité de créer une règle d’extraction automatiquement à partir du corps de la réponse :

image

Dans l’exemple ci-dessus, on créé une règle qui permettra d’extraire la valeur qui se trouvera à l’endroit ou se trouve le texte true à l’heure actuelle. La règle suivante est alors créée :

image

Du gain de temps en perspective ! :)

Dans un prochain billet, je vous parlerais des nouveautés qu’on peut trouver au niveau des tests de charge.

.Dispose();

Visual Studio 2010 – Quoi de neuf ? Les tests d’interfaces graphiques !

Nous allons maintenant parler d’une nouveauté très attendue de l’édition Team Test de Visual Studio 2010 : les Tests d’interfaces graphiques. J’en avais déjà parlé dans un précédent article basé à l’époque sur la version Community Technology Preview d’octobre 2008. La version disponible dans la beta 1 à été revue, notamment au niveau du design des outils. Nous allons également découvrir une fonctionnalité très intéressante : la possibilité de créer un test automatisé d’interface graphique à partir d’un enregistrement effectué à partir de l’outil Microsoft Test and Lab Manager.

Le principe

Tester l’aspect fonctionnel d’une interface graphique peut rapidement devenir redondant et prend énormément de temps aux équipes de test. Même s’il faut toujours une validation humaine pour certains tests, la majorité de ce type de scénarios peut être automatisé sans trop de problèmes. C’est le rôle de ce nouveau type de test : les tests d’interfaces graphiques ou Coded Ui Tests.

Qu’est-ce qu’un coded ui test ?

Il s’agit d’une méthode de test, ressemblant fortement aux tests unitaires, contenant du code qui permet de simuler des actions normalement effectuées par un utilisateur. Bien évidemment, on ne va pas écrire nous même ce code : il sera généré par un enregistreur. L’idée est d’effectuer une première fois manuellement le scénario pendant qu’un outil analyse ce qui se passe et produit un ensemble de méthodes que nous pourrons alors appeler pour rejouer ce scénario.

Jouer un test seul n’a pas de grande utilité. Il trouve son réel intérêt lorsqu’on y ajoute de la validation, ce qui est tout à fait possible grâce à un second outil qui permet de sélectionner les contrôles d’une application pour pouvoir en vérifier la valeur lors du test.

La nouvelle interface d’enregistrement

Pour commencer, il vous faut un projet de type test que vous rajoutez à une solution existante (ou une nouvelle solution):

image

nb : on admirera au passage la nouvelle interface d’ajout de projet :)

Une fois le test ajouté, il suffit de créer un test de type Coded Ui Test:

image

On nous propose alors de choisir le type d’outil que l’on souhaite utiliser :

image

(Notez que le texte d’aide est un peu plus explicite que dans la version précédente.)

Il existe 3 outils :

  • Un assistant de création de test d’interface à partir d’un enregistrement pré fait (dont nous parlerons plus loin)
  • L’enregistreur d’actions
  • Le sélectionneur de contrôle, qui permet d’ajouter des contrôles à valider dans un test

L’utilisation la plus courante sera le second outil: le Test Builder :

image

Revu par rapport à la précédente version, il est simplifié et plus clair. On remarquera également qu’il y a maintenant deux onglets, le premier concernant l’enregistrement des actions, le second l’ajout de validation pour le test.

Après avoir cliqué sur Record Actions, l’outil d’enregistrement d’actions trace tout ce que nous faisons. Une fois une étape du test terminée, on renseigne le nom de la méthode qui permettra de rejouer cette étape, et on clique sur Generate Method :

nb : une “étape” peut bien entendu comprendre plusieurs actions, la capture ci-dessous n’étant qu’un exemple

image

Plutôt simple, non ? :)

Je vous conseille vivement de découper un scénario en plusieurs méthodes pour pouvoir facilement les réutiliser dans d’autres tests et ne pas avoir à ré enregistrer chaque fois des actions comme : “ouverture de l’application”, “connexion en tant qu’administrateur”, etc.

Chaque fois que vous générez méthode, vous revenez à l’interface principale, qui vous permet de savoir où vous en êtes dans votre scénario :

image

Passons maintenant à l’ajout de validation, pour cela, l’onglet Add Assertions est là !

image

Après avoir cliqué sur le bouton ci-dessus, nous avons accès à l’outil de sélection de contrôle. Pour choisir un contrôle d’une application, il suffit de glisser/déposer la cible que l’on voit en haut à droite sur le contrôle en question.

image

Il ne reste plus qu’a ajouter le contrôle à la liste de ceux que l’on veut valider, et cliquer sur Show Properties pour afficher la liste de ses propriétés publiques. Elle sont automatiquement découvertes par l’outil qui nous invite à en sélectionner une ou plusieurs, et à choisir comment et à quelle valeur il faudra la comparer pendant l’exécution automatique du test :

image

Après avoir ajouté tous les contrôles que vous souhaitez valider, fermez l’outil principal (on vous demande alors si vous voulez générer le code, répondez oui bien entendu).

Le code généré

Je ne vais pas revenir en détail sur le code qui est généré, mais on retrouve 6 fichiers :

  • App.config
  • NomDuTest.cs : contient le test, les appels aux méthodes de simulation et la validation
  • RecordedMethods.cs : contient les méthode de simulation
  • UIMap.uitest associé à UIMap.designer.cs : Contient des informations nécessaires à la localisation des contrôles
  • UserControl.cs : contient le code wrappant les appels aux controles windows. Utilisé dans RecordedMethods.cs

Plus particulièrement, voici le code du test que j’ai généré plus haut :

image

Si vous créez un test automatisé ressemblant à celui-ci, vous remarquerez que je l’ai légèrement modifié comme indiqué dans les commentaires pour sauvegarder la valeur à valider avant la fermeture de l’application.

L’exécution peut être faite directement via le menu contextuel dans le code :

image

image

De plus, on peut très facilement enregistrer des actions supplémentaires ou ajouter de la validation par après, toujours via le menu contextuel :

image

Exploiter une automatisation déjà enregistrée

Nous avons vu dans le billet sur Microsoft Test and Lab Manager qu’il est possible d’enregistrer les actions réalisées pendant le test manuel. Vous comprenez maintenant à quoi correspondait alors le fichier .uitest généré. Nous allons maintenant voir un exemple de l’interaction que l’on peut avoir entre les différents outils.

L’idée est très astucieuse et par du principe qu’un testeur ne doit pas perdre de temps à effectuer des actions répétitives. Pourquoi serait-il forcé de toujours rejouer les mêmes tests ?

Le scénario est le suivant :

  • Le testeur joue manuellement un cas de test via Microsoft Test and Lab Manager
  • Après la réalisation du test, un fichier contenant les actions qu’il a réalisé est sauvegardé dans le work item
  • Un testeur technique créé alors un test d’interface graphique automatisé
  • Ce test peut rejoindre la batterie de tests automatiques jouée lors des tests d’intégration
  • Tant qu’il n’est pas nécessaire de rejouer manuellement le test, l’équipe de test peut se concentrer sur d’autres scénarios

Le gain de temps est au rendez-vous, difficile de ne pas adhérer au principe ! :)

Pour cela, nous allons choisir la première option lors de la création d’un test d’interface graphique :

image

On nous invite à sélectionner un work item de type Test Case :

image

On clique sur OK et le test est généré.

nb: lorsque vous créez un test d’interface graphique dans un projet qui en contient déjà un, seul le fichier contenant le test est ajouté, les méthodes sont toutes centralisées dans le même fichier RecordedMethods.cs.

Le code généré est relativement clair, puisqu’il reprend les étapes du Test Case :

image

Tout ce qu’il reste à faire, c’est d’ajouter la validation comme vu plus haut !

Conclusion

Bien qu’étant plutôt à classer dans la catégorie des tests techniques, les tests d’interfaces graphiques permettent de compléter le travail des testeurs génériques et fonctionnels. Automatiser un grand nombre de scénarios permettra d’ajouter à la qualité de chaque build d’intégration et laissera le soin aux équipes de test de se concentrer sur les fonctionnalités les plus critiques et complexes.

Voilà encore une fonctionnalité très aboutie de cette version 2010 de Visual Studio :)

Bon tests !

.Dispose();

Visual Studio 2010 – Quoi de neuf ? Microsoft Test and Lab Manager !

Anciennement appelé Camano, Microsoft Test and Lab Manager, est le nouvel outil de test de la gamme de produit Team System. Incontournable dans le monde du test au sein de l’univers Team System 2010, il fait l’objet de ce second billet sur les nouveautés autour des tests. Certains articles ont déjà été écrits à ce sujet, mais la version disponible dans la Beta 1 est complètement différente en termes d’interface et certaines fonctionnalités ont été revues.

Le principe de l’outil

Si vous vous êtes déjà intéressé à Camano, vous avez forcément une idée du principe de base : offrir un outil destiné aux testeurs généralistes hors de Visual Studio, tout en restant connecté à Team Foundation Server.

Les mots clés autour de cet outil sont :

  • Planification des campagnes de tests
  • Définition des tests
  • Organisation des tests, des configurations de tests, etc.
  • Reporting des bugs
  • Suivi de l’évolution des tests au travers des builds 
  • Exécution des tests

Camano vous permet de planifier des campagnes de tests. Ces campagnes (ou Test Plan) sont organisées sous forme de groupes de tests appelés Test Suites. Ce sont ces Test Suites qui contiennent les Test Cases dont nous avons parlé dans le billet précédent Visual Studio 2010 – Quoi de neuf ? Les Test Cases !.

Au delà d’un simple planification, Camano permet également d’exécuter les cas de tests définis. Pour cela, un nouvel exécuteur de tests manuel apparait, le Microsoft Test Runner. Cet outil n'a rien à envier à son grand frère qu’on trouvait déjà dans l’édition Team Test de Visual Studio 2008. Il guide le testeur, récolte tous les indicateurs importants et construit pour lui le work item de Bug si un report à besoin d’être fait vers l’équipe de développement suite à un problème rencontré sur l’application lors du test.

Et cela ne s’arrête par là ! Non content de vous aider avant et pendant les tests, Camano vous assiste également après ceux-ci. Il vous donne accès à des rapports de l’évolution des différentes exécutions qui ont eu lieu au cours du temps.

Cerise sur le gâteau : couplé à System Center Virtual Machine Manager 2008 et Hyper-V, il permet de gérer et d’exécuter vos tests sur des machines virtuelles, qui constituent alors votre laboratoire de test (d’où le Lab dans Microsoft Test and Lab Manager :)).

Comprendre l’organisation de l’outil

La première chose que l’on remarque lorsqu’on lance cette nouvelle version de Camano, c’est que le design et l’ergonomie ont complètement été revues depuis la version d’octobre 2008. Ceci est plutôt une bonne idée, car l’organisation est beaucoup plus logique désormais ce qui n’est pas simple à réaliser car vous allez le voir, beaucoup d’éléments sont interconnectés et se croisent dans cet outil.

image

Comment est organisée cette interface ?

On retrouve en premier une Vue (2) qu’on retrouve ici en haut à gauche Testing Center. On retrouvera deux autre vues : Lab Center et Organize. Associé à cette vue, on retrouve un Contexte (1). Ce contexte défini la liste des éléments sur lesquels vous travaillez. Pour la vue Testing Center, on retrouve “Nom du Team project – Nom de la campagne de test” (ici : le Team Project Demonstrations, et la campagne Campagne de tests côté client). nb : pour changer de serveur/team project, cliquez sur le nom du projet dans le context (1).

Une vue est constituée de plusieurs Onglets (3). Chacun de ces onglets définit une catégorie contenant les outils relatifs à cette catégorie. Ces Outils (4) permettent d’avoir accès à des listes (de tests, de configurations, etc.), de créer des éléments, etc.

Dans ce billet, nous allons nous concentrer sur les vues Testing Center et Organize.

La vue Testing Center

Cette vue est celle qui apparaît par défaut lorsqu’on lance Camano. Du fait qu’il est fortement lié à Team Foundation Server, il est impossible d’utiliser cet outil sans avoir au préalable défini un context. Pour cela, choisissez tout d’abord un Team Project dans une Collection d’un serveur TFS :

image

Une fois ceci fait, vous êtes redirigé vers l’outil Set Plan Context:

image

Ouvrez l’assistant de création d’un plan en cliquant sur New.

Comment est définit une campagne de tests ? Via :

  • Un nom, qui permet de l’identifier au fil des outils
  • Une description
  • Une area et une itération (classification des work items)
  • Une configuration d’exécution pour les tests manuels et une pour les tests automatisés
  • Des configurations cibles pour l’exécution (purement informatif, pouvant contenir différents paramètres, voir plus loin dans le billet)
  • La build utilisée (facultatif)
  • L’état de la campagne (pouvant être  : Actif ou Inactif)
  • Une date de début et une date de fin

image

Elément important pour la suite (notamment pour l’exécution du plan de test) : il est possible de modifier ici la configuration du test par défaut en cliquand sur Open à droite de Local Test Run.

Dans l’onglet Data ang Diagnostics, nous avons la possibilité de choisir ce qui sera automatiquement enregistré lors du test (nb : par défaut, la vidéo n’est pas sélectionnée) :

image

Cliquez sur Finish.

Au niveau de la campagne, cliquez sur Save and Close. Une fois terminé, sélectionnez la campagne venant d’être créée puis sur Set context :

image

Le contexte est maintenant configuré :)

Voyons plus en détail cette vue Testing Center. L’onglet Plan vous permet d’avoir une vue sur la campagne sélectionnée dans le contexte courant. L’onglet Contents, vous présente les différents cas de tests contenus dans la campagne courante. Ces cas de tests sont organisés dans des Test Suites (a gauche) :

image

La partie gauche contient la liste des test suites, que vous pouvez organiser sous forme d’arborescence : une suite pouvant en contenir d’autres. La partie droite contient les cas de tests contenus dans la suite sélectionnée.

Pour ajouter des cas de tests, vous avez deux possibilités :

  • Via le bouton Add Requirements qui va ajouter un work item de type User Story directement dans la campagne et les tests qui lui sont associés (à droite dans la vue des tests). La User Story est alors considéré comme un type particulier de Test Suite :

image

image

  • Via le bouton Add dans la vue des tests. Ceci n’a pas pour résultat d’ajouter le work item User Story testé par le ou les cas de tests ajouté(s) :

image

Remarquez sur l’on peut également :

  • Assigner un testeur à la suite
  • Créer un nouveau Test Case (bouton Add dans la partie droite)
  • Modifier les Configurations cibles à utiliser pour exécuter ces tests
  • Importer des suites de tests à partir d’une autre campagne (bouton Import) dans la partie gauche

On nous présente également l’état d’avancement de la suite, en haut à droite (le bleu signifiant qu’aucun test n’a été exécuté, vert la proportion de tests réussis, et rouge celle échouée).

L’onglet Test permet de gérer les exécution des tests inclut dans les Test Suites de vos campagnes. Il s’agit d’un tableau de bord offrant un suivi de l’état des tests :

image

Remarquez qu’automatiquement, nous avons à exécuter chaque cas de test une fois par type de configuration : Windows 7, et Vista and IE 7. (Que nous avons défini au niveau de la campagne de test). On voit donc les tests à exécuter en Bleu, les tests dont la dernière exécution est réussie en Vert, et ceux qui ont échoués, ou qui ne sont pas à exécuter en Rouge.

Nous reviendrons plus tard sur l’exécuteur de tests, mais c’est à partir de cet outil Run Tests que cela se passe :)

L’outil Analyze Test Runs, nous donne une vue des différentes exécutions de tests que nous avons déjà effectuées. Il faut savoir qu’on peut demander d’exécuter plusieurs tests à la suite, ce qui constitue une “exécution de tests” :

image

En faisant un clic droit puis Open Test Run nous avons accès à un rapport complet de l’exécution de tests. Cela nous permet d’avoir une vision claire et instantanée de ce qui s’est passé lors de cette exécution :

image

Par exemple, sur le rapport ci-dessus, on voit que 3 test cases ont été exécutés, que ont été un succès et un a échoué. Ce rapport est également accessible durant l’exécution, ce qui permet d’avoir un rapport temps réel ! :)

Le dernier outil de cet onglet Test permet de suivre les bugs qui ont été reportés.

image

Ici, on voit que 2 work items de type Bug ont été créés par l’utilisateur courant (Created by me). Au delà d’un simple outil de supervision, My Bugs permet d’aller plus loin et nous propose de vérifier qu’une correction est bien valide : en sélectionnant un bug et en cliquant sur Verify dans la barre supérieure, on rejoue directement le Test case correspondant au bug ! De plus, si on estime qu’un problème mérite d’avoir son propre cas de test, on peut en créer un directement à partir de cette interface (Create test case from bug). (On peut imaginer que la partie Connexion à l’application à échoué lors d’un test plus complet, et qu’on veut alors créer un cas de test uniquement pour cette connexion).

Un testeur travaille très souvent par rapport à une version précise de l’application ou Build. Il est donc logique d’avoir la possibilité d’associer une campagne à une build particulière. De plus, l’outil va nous proposer les tests pertinents à exécuter en fonction de certains paramètres. C’est au niveau de l’onglet Track de cette première vue Testing Center que cela se passe :

image

Sans entrer dans les détails, cet onglet nous propose 3 outils :

  • Recommended Tests : qui nous donne une liste de cas de tests dont les fonctionnalités testées ont été modifiée depuis une ancienne build
  • Queries : qui permet de gérer les requêtes sur les work items (de la même manière que le permet le Team Explorer dans Visual Studio)
  • Select Build : qui permet de sélectionner la version sur laquelle on souhaite travailler

Exécuter une batterie de tests

Un des aspects les plus intéressants de l’outil Camano est le nouvel exécuteur de tests manuels. Il permet d’exécuter un ou plusieurs tests fonctionnels et récolte un grand nombre d’informations nécessaires à la correction d’un potentiel bug. C’est le point central du crédo de l’équipe qui l’a développé : No More No Repro ! Soit en clair : plus jamais un bug non reproductible ! Plus de fiche de bug à moitié saisie, pas claire pour le développeur qui s’arrache les cheveux à essayer de reproduire les problèmes de type : “J’ai eu un message d’erreur quand j’ai cliqué là, mais je sais plus ce que j’ai fait avant…”. Attention, je ne jette pas la pierre aux testeurs, ils ont énormément de travail et on peut comprendre qu’il n’aient pas forcément le temps de tout faire. Mais plus d’excuses pour eux désormais !

Pour exécuter une batterie de tests, rendons nous dans la vue Testing Center onglet Test outil Run Tests :

image

Sur un test, ou plusieurs comme dans la capture ci-dessus, on peut exécuter le test via un clic droit et Run. Microsoft Test and Lab Manager est alors réduit, et se “transforme” en Test Runner ! On nous offre alors deux (ou trois (*)) choix : exécuter simplement le test, ou exécuter et enregistrer des informations complémentaires :

image

(*) Nous avons un choix supplémentaire comme vous pouvez le voir sur la capture, si le cas de test a déjà été exécuté et que les actions avaient été enregistré à ce moment. On peut alors demander à l’exécuteur de jouer automatiquement ce que l’on avait enregistré à l’époque. Idéal pour valider une correction de bug !

Nous choisissons bien évidemment la seconde option, pour avoir tout ce qui sera nécessaire à la résolution d’un potentiel bug. Les différents éléments que l’on enregistre sont à définir dans la configuration d’exécution. Celle-ci est définie au niveau du plan de test. Nous avons vu précédemment comment la modifier pour activer plus ou moins d’éléments à sauvegarder. Pour la démonstration, j’ai choisi :

  • Action Log : un fichier texte contenant la liste de toutes les actions ayant été réalisées
  • Action Recording : un fichier .uitest qui contient les informations permettant de rejouer automatiquement ce que l’on va faire manuellement. Dans le prochain billet sur les tests d’interfaces graphiques nous verrons qu’on pourra utiliser ce fichier pour générer un test automatiquement !
  • Video : un enregistrement de la vidéo de ce qu’il se passe sur l’écran du testeur. Idéal pour que le développeur puisse voir tout ce que fait le testeur, et comprendre plus rapidement l’origine du problème (s’il y en a un)

Voyons maintenant comment se présente l’outil :

image

On y retrouve 3 sections :

  • Tests : partie supérieure qui contient la liste des tests à exécuter. Cela correspond aux tests que nous avons sélectionné plus haut. On voit facilement quel test est en cours d’exécution, ceux qui sont encore à exécuter (en bleu) et on verra une fois un test exécuter s’il est un échec ou une réussite. On y voit également une roue crantée définissant que le test possède déjà une version automatisée
  • Test Steps : contient les différentes étapes à réaliser pour ce test. Il s’agit des étapes qui ont été définies dans le Test Case correspondant. Chacune des étapes peut être marquée comme réussie ou échouée via le bouton à sa droite. Remarquez également qu’on distingue les Shared Steps et qu’on peut choisir également le mode de test (enregistrement, ou pas)
  • Properties : cette partie est présentée sous forme d’onglet. On y retrouve un certain nombre d’informations et principalement le résultat attendu pour l’étape du test en cours de réalisation. Ceci correspond bien entendu au résultat attendu qui a été spécifié dans le cas de test.

Vous comprenez bien que plus le test est détaillé, plus il est simple pour le testeur de le réaliser. Cette phase d’exécution ne doit pas être une phase de réflexion, qui est réservée à l’écriture du cas de test.

Pour chacune des étapes, le testeur valide que le résultat qu’il obtient correspond bien à ce qu’on lui précise et indique l’état de l’étape courante :

image

Une fois le test terminé, on clic sur End Test et les enregistrements sont finalisés. On a alors la possibilité de créer un bug (s’il y a eu un problème, bien sûr…) :

image

Un formulaire s’ouvre, correspondant à celui que l’on retrouverait directement à partir du Team Explorer. Il est pré-rempli avec les informations qui ont été récoltées :

image 

La partie haute du work item est tout ce qu’il y a de plus standard (un titre, un état, etc.). Par contre la partie basse est enrichie avec un tableau contenant la liste des différentes étapes, si elles ont échouées ou non, la liste des actions réalisées, et un marque page dans la vidéo sous forme de lien qui permet au développeur d’ouvrir cet enregistrement directement au moment où l’action à été effectuée !

Nous avons également accès à une liste d’informations sur le système sur lequel a été effectué le test via l’onglet System Info. La liste des cas de tests correspondant via l’onget Test Cases et les différentes données enregistrées sous forme de liens dans l’onglet Other Links :

image

On retrouve ici le fichier .uitest, qui permettra de rejouer automatiquement le test.

A noter qu’en plus des informations enregistrées automatiquement, nous avons la possibilité d’ajouter des fichiers supplémentaires ou de prendre une capture d’écran (ou d’un morceau de l’écran). Ces fichiers seront automatiquement ajoutés en fichier joint au work item de type bug.

image

Cerise sur le gâteau, vous pouvez voir ci-dessus que le testeur à la possibilité de demander de rejouer automatiquement ce qu’il vient de réaliser :)

La vue “Organize”

Cette vue, comme son nom l’indique, permet de gérer vos campagnes de tests, vos cas de tests, etc. Elle relativement importante car c’est à cet endroit que vous aller pouvoir gérer de façon macro vos tests.

Chose importante à noter : le contexte de cette vue n’inclut pas la campagne de test. Vous pouvez donc y gérer toutes vos campagnes, contrairement à la vue Testing Center qui ne s’applique qu’à une campagne en particulier.

Le premier onglet Test Plans donne accès à la liste des différentes campagnes. Vous pouvez en créer de nouvelles, ou modifier les existantes.

image 

L’onglet Configurations permet de définir les environnements cibles pour les campagnes. Je vous en ai parlé plus haut, un test est destiné à être exécuté sur une configuration précise, “Windows 7 et IE8” ou “Windows Vista et IE 7”, etc.

image

Une configuration cible est définie par un ensemble de variables de configuration (ici Browser et Operating System). Ces variables et la liste de leurs valeurs sont définies à l’avance, via l’assistant accessible à partir du bouton Manage configuration variables :

image

A gauche, on retrouve la liste des variables, et à droite la liste de leurs valeurs. Encore une fois, il s’agit de texte purement informatif.

L’onglet Test Cases permet de gérer la liste des cas de tests. On a la possibilité d’en créer de nouveaux, d’éditer les existants et même d’en créer un à partir d’une copie d’un autre. Tout est fait pour gagner du temps ! :)

image

Enfin, le dernier onglet : Shared Steps permet de gérer les… shared steps. Nous avons parlé de ces morceaux de tests factorisés et réutilisables dans plusieurs tests dans le billet sur les Test Cases :

image

Remarquez que nous avons une fonctionnalité supplémentaire par rapport aux Test Cases ici : l’enregistrement du fichier .uitest pour pouvoir automatiser un morceau de test (Shared Step).

Conclusion

De mon point de vue, l’intégration des testeurs dans l’équipe de développement est complètement revue dans Team System 2010. Tout le processus de test interagit et est connecté avec tous les aspects du cycle de vie d’un projet et la majorité des problématiques qu’on pouvait avoir auparavant, en termes de gestion des campagnes, de suivi et de reporting à été pris en compte dans cet outil ! :)

Difficile de parler de tout ce qu’il y a dans cette nouvelle version de Camano. Le but de ce billet est de vous permettre de démarrer facilement vos essais. Nous parlerons de la partie Lab Management dans un futur article !

.Dispose();

Visual Studio 2010 – Quoi de neuf ? Les Test Cases !

Sujet numéro 1 de ma série de “Quoi de neuf?” sur Visual Studio 2010, les Test cases sont la première étape et un premier pas dans la collaboration avec Team Foundation Server pour les testeurs généralistes.

Vous avez dit Test Case ?

Que sont-ils ? Un type d’élément de travail ou Work Item en anglais. Pour ceux qui ne seraient pas familier avec le concept de work item, il s’agit de “fiches” contenant des informations nécessaires à la gestion d’un projet et sont un point charnière au sein d’une équipe. Ils leur permettent de communiquer, tracer des opérations, reporter sur des métriques de temps ou de qualité, etc.

A quoi sert un test case ? Bien plus qu’un simple type de work item supplémentaire, un test case contient des informations nécessaires à l’exécution d’un test. On y retrouve également des informations un peu plus standards dont principalement :

  • Le titre
  • La personne à qui le cas de test est associé
  • L’état (Design, Ready, Closed)
  • L’area et l’itération
  • Si le test est manuel ou automatisé (Automation Status)

image

Quelles sont les informations nécessaires à l’exécution d’un test (manuel) ? Tout simplement les différentes étapes (Action) à réaliser par le testeur, et le résultat attendu (Expected Result) à chacune de ces étapes. Si vous les imaginez et saisissez correctement, n’importe quel utilisateur devrait être capable d’exécuter ce test sans même connaître l’application. Elle sont définies dans l’onglet Steps de la fiche de Work Item :

image

Factoriser des actions

On imagine facilement qu’on risque rapidement d’avoir certaines étapes qui reviennent assez souvent au travers de nos tests, surtout au sein d’une même application. Si on prend l’exemple d’une application web, la majorité des scénarios débutera par “Rendez-vous sur le site”, “Connecter vous en tant que …”. Pour éviter de trop se répéter, et surtout pour gagner du temps, nous avons la possibilité de factoriser ces actions redondantes grâce aux Shared Steps (action partagées).

Dans l’exemple que vous avez ci-dessus, je souhaite factoriser les deux premières actions. Pour cela, je les sélectionne, effectue un clic droit, puis Create Shared Steps :

image

Je renseigne un nom pour cet ensemble d’actions (ici Connexion), clic sur OK et me retrouve avec une seule action à la place de deux initialement :

image

L’idée, c’est que lors de l’exécution de ce test manuel, cet ensemble d’actions sera remplacé par son contenu :).

Vous pouvez d’ailleurs consulter ces Shared Steps directement à partir du cas de test courant, via l’onglet Other Links :

image

Test Case et traçabilité

Pour aller encore plus loin dans la traçabilité au niveau des tests avec Team Foundation Server, il est possible (et fortement recommandé) de préciser quels work items sont testés par ce cas de test. Pour cela, il suffit de se rendre dans l’onglet Tested Work Items :

image

Un assistant nous permet d’ajouter un work item. Dans le cas le plus courant, on testera un cas d’utilisation de l’application ou User Story :

image

On peut bien entendu ajouter plusieurs work items testés, comme vous pouvez le voir ci-dessous :

image

Grâce à cela, on peut très simplement savoir pour chaque spécification, tâche, bug corrigé, lesquels ont été testés et lesquels ne l’ont pas encore été (ou du moins, ceux pour lesquels aucun test n’a été planifié/prévu). Une des requêtes de work item par défaut, User Stories without Test Cases, nous permet d’ailleurs de savoir cela :

image

Nous donne rapidement accès à la liste des User Stories non testées :

image

C’est également au sein des Test Case eux mêmes que nous retrouverons les work items de Bug relevés par les testeurs. Tout est lié ! :)

Les rapports pour les tests

La dernière chose intéressante est le fait que deux rapports par défaut existent pour vos tests :

  • Test Case Readiness : vous donne une vision macro des tests prêt à être exécuter au fil du temps. Vous avez vu plus haut que l’état d’origine d’un Test Case était Design, qui correspond à la phase de création du test. Un test est considéré comme Ready quand il passe dans cet état. C’est ce que ce graphique vous présente !

image

  • Test Plan Progress : vous donne une vision macro des tests exécutés au fil du temps, et de la proportion de tests réussis/échoués.

image

Conclusion

Les tests cases ne sont pas simplement un nouveau type de work items, ils sont le point d’entrée des tests dans l’univers Team System. Vous vous demandez certainement comment vont être utilisés ces éléments, comment vont être exécutés les tests, etc. Nous verrons tout cela dans le billet sur le nouvel outil Camano (aka Microsoft Test and Lab Manager) :)

.Dispose();

Visual Studio 2010 - Quoi de neuf pour les tests ?

Ca y est ! Vous n’avez certainement raté l’annonce de la journée : la Beta 1 de Visual Studio est enfin là (disponible actuellement pour les abonnés MSDN) ! On va enfin pouvoir installer, découvrir et jouer avec une version un peu plus récente que la précédente qui date d’Octobre l’année dernière :)

Et vous qui comme moi ont un faible pour l’aspect tests d’un projet, vous êtes servi ! Microsoft Test and Lab Manager, les tests d’interfaces graphiques, le debugeur historique, les nouveautés du profiler, et bien d’autres !

Pour vous guider dans votre découverte, je vous propose cette semaine une série de billets sur les nouveautés autour des tests :

Et un peu plus tard…

Je mettrais à jour ce post au fur et à mesure pour y inclure les liens vers les billets !

Il y vraiment de quoi s’amuser, dans cette beta 1 :)

image

image

.Dispose();

[Visual Studio 2010] 3 produits autour des tests

Edit : Nous avons plus d’informations sur le contenu des éditions, et un schéma pour éclaircir les fonctionnalités ! (Ajouté en vert dans ce post)

L’annonce à été faite hier sur le blog de Jason Zander, il y aura 3 éditions pour Visual Studio Team Test 2010.

Vous avez peut être déjà entendu parlé de l’outil “Camano” ? Ce nouvel outil indépendant de Visual Studio destiné principalement aux testeurs non techniques. Celui-ci s’appellera Microsoft Test and Lab Manager. Il permet d’organiser plus facilement vos tests, de les planifier, de les exécuter, de créer des rapports, etc. Il contient également un exécuteur de tests manuels beaucoup plus évolué que ce qu’on avait jusqu’a présent pour ce type de scénario. Cet outil sera bien entendu connecté à Team Foundation Server 2010 notamment pour l’exploitation des Work Items destinés aux tests.

Nb : Si vous avez envie d’en savoir un peu plus sur cet outil, je vous invite à visionner le webcast de la session que j’ai animé lors des Techdays 2009 avec Florent, entre autres sur ce sujet.

Plus de détail sur les fonctionnalités :

image_thumb_6

Les 3 produits seront :

- Visual Studio Team Test 2010 Essentials, destinés aux testeurs plus généralistes. Il sera épuré des fonctionnalités dont ils n’ont pas besoin. On y retrouvera la possibilité de gérer les cas de tests et de les exécuter (qu’ils soient manuels ou automatiques).

Inclut : Microsoft Test Runner, Microsoft Test And Lab Manager, Reporting, Data Collection, et une licence d’accès à TFS (CAL) (En bleu sur le schéma)

- Visual Studio Team Test 2010, qui sera la version la plus “complète” en termes de fonctionnalités en incluant les tests techniques dont notamment les tests web et de charge et  bien entendu l’outil Microsoft Test and Lab Manager.

Inclut en plus de l’édition Essentials : Tests unitaires, les tests d’interfaces graphiques, les tests web, les tests de charge (En vert sur le schéma)

- Visual Studio Lab Management, permettra de créer des environnements virtualisés destinés à accueillir les exécutions de vos tests, sauvegarder l’état de vos environnements via un système de Snapshots. (Très utile pour pouvoir montrer l’état d’une application lorsqu’un bug se produit à un développeur en lui donnant accès à un snapshot !)  En orange sur le schéma.

Bel effort de la part des équipes de développement chez Microsoft pour nous fournir un panel enrichit de produits et fonctionnalités autour des tests, bravo et merci à eux ! :)

Personnellement, j’ai hâte de pouvoir mettre tout ça en place !

.Dispose();

[Team Test] Ajouter de la trace SQL à vos rapports de charge

Savez-vous qu’il est possible de récupérer des informations de trace d’un serveur SQL Server de manière automatique à partir d’un test de charge ?

Et bien non seulement c’est possible, mais c’est en plus très simple !

Il suffit d’activer celle-ci au niveau des Run Settings :

image

Dans ses propriétés :

image

Le principe est simple. Vous donnez une chaine de connexion vers le serveur (SQL Tracing Connect String) et un répertoire partagé accessible en écriture et en lecture par le client qui exécute le Team Test et le serveur SQL (SQL Tracing Directory). Il ne reste plus qu’a activer la trace (SQL Tracing Enabled = True) et vous pouvez exécuter votre test.

Pour voir les données enregistrées, rendez vous dans les tables du rapport de charge. Vous trouverez un tableau “SQL Trace” qui est apparut depuis que vous l’avez activé :

image

Plus d’informations :

Je trouve ça super pratique :)

.Dispose();

Fiddler2 et l’erreur “The underlying connection was closed”

Si comme moi il vous arrive d’enregistrer un scénario avec Fiddler2 sur une application qui contient du code .NET faisant appel à un serveur HTTP et que Fiddler2 “perturbe” le bon fonctionnement de l’application lorsqu’il est activé, vous aurez certainement une exception contenant le texte : “The underlying connection was closed: A connection that was expected to be kept alive was closed by the server”.

Si tel est le cas, il suffit de modifier les règles de Fiddler2 pour qu’il évite ce comportement.

Pour cela, rendez vous dans “Rules > Customize Rules”

image

Cela ouvre une instance de notepad avec le fichier de règles. Cherchez la méthode “OnBeforeResponse” et dé-commentez la dernière condition comme suit :

// Uncomment to reduce incidence of "unexpected socket closure" exceptions in .NET code. 
// Note that you really should also fix your .NET code to gracefully handle unexpected connection closure.
//
if (!(((oSession.responseCode == 401) && oSession.oResponse["WWW-Authenticate"].Length > 9) ||
   ((oSession.responseCode == 407) && oSession.oResponse["Proxy-Authenticate"].Length > 9))) {
  oSession.oResponse["Connection"] = "close";
}

Cela devrait corriger votre problème :)

En espérant que cela puisse vous aidez !

.Dispose();

Tests web : Eviter l’erreur “Argument de publication ou de rappel non valide”

Imaginons qu’on teste une application développée en ASP.NET. Dans le scénario de test web, on utilise un formulaire qui permet à l’utilisateur de modifier ses informations personnelles pour tester la modification de son nom. Ce formulaire contient toujours son nom, prénom, age, adresse, etc. mais possède des champs supplémentaires, dynamiques en fonction de l’utilisateur connecté.

Hors en général, on souhaite dynamiser le test pour qu’il se connecte avec plusieurs utilisateurs différents. Si vous avez déjà été dans ce cas, vous avez dû être confronté à l’erreur suivante :

Une erreur s'est produite dans l'application :
Argument de publication ou de rappel non valide. […]

Cette erreur survient quand on envoie à l’application des paramètres POST qu’elle n’attend pas, ou bien qu’il manque des paramètres qu’elle attend. Ce principe est une sécurité permettant de s’assurer que jamais rien n’est envoyé alors que cela n’est pas attendu. Ceci est très bien en production, mais peut être problématique pendant les tests.

Pour éviter d’être gêné par ce problème pendant vos tests, il vous est possible de désactiver cette validation, directement dans le fichier web.config, dans l’attribut <pages /> :

<pages enableEventValidation=”false”> […] </pages> <!-- Ne pas utiliser en prod -->

Bon tests ! :)

.Dispose();

edit : Ajout du commentaire suite à la remarque de Cyril. Je pensais que c'était clair que je ne conseillais de faire ça que pendant les tests ;)

Visual Studio Team Test Quick Reference Guide 1.0

Une équipe de Rangers VSTS vient de publier (le 30 mars) un guide de référence pour Visual Studio Team Test , principalement orienté tests web et unitaires utilisés dans des tests de charge.

Ce document d’environ 80 pages contient une mine d’informations présentées sous forme de Trucs et Astuces. On y retrouve des explications sur les erreurs les plus courantes et les plus rares qu’on peut rencontrer et comment les contourner/corriger. Il couvre les tests web, unitaires et de charge en abordant également les problématique liées à l’utilisation d’un Test Rig (plusieurs agents de charge et un contrôleur).

Si vous utilisez Team Test, je vous conseille d’y jeter un coup d’oeil :)

image

.Dispose();

MVP Team System !! :)

Je viens d’apprendre avec plaisir ma nomination en tant que MVP Team System !! :) (Non, il ne s’agit pas d’un poisson d’avril… du moins j’espère :))

Je remercie toutes les personnes qui m’ont encouragé, accompagné et lu tout au long de cette année (et qui continueront à le faire, j’en suis persuadé !) :)

MVP_Horizontal_FullColor

.Dispose();

Ps : Merci à Phil pour sa dédicace ;)

Help, mon Web Test Recorder n’est plus là sous IE 8 !

Si comme tout bon utilisateur, vous installez IE 8 aujourd’hui et que dans la foulée, vous voulez enregistrer un test web avec l’enregistreur de Visual Studio, vous risquez comme moi de ne pas le voir apparaître dans la fenêtre d’enregistrement.

Pas de panique, il suffit de désactiver et réactiver l’add-on “Microsoft Web Test Recorder” et de relancer Internet Explorer :)

image

image

.Dispose();

Team Test : Récupérer des compteurs de performances quand on est pas dans le domaine

Souvent, quand je fais un test de charge chez un client, j’arrive avec ma machine qui du coup n’est pas dans le même domaine.

Or Team Test à besoin de récupérer les compteurs de performances des serveurs testés pour récolter des indicateurs pour l’analyse. Pour pouvoir récupérer ces compteurs de performances, il faut que l’utilisateurs avec lequel vous êtes logué soit dans le groupe local “Performance Monitor Users” de la machine en question. Donc si vous n’êtes pas dans le domaine, ceci ne peut pas fonctionner !

Comment faire dans ce cas ? Il suffit de créer un répertoire partagé sur le serveur duquel vous voulez récupérer les compteurs, y accéder à partir votre machine en donnant comme identifiant un compte du domaine étant dans le groupe “Performance Monitor Users” dudit serveur. Une fois ceci fait, vous avez les droits ! :)

Voilà, une simple petite astuce qui m’est très souvent utile.

Bon tests.

.Dispose();

Comment réparer des compteurs de performance?

Est-ce qu’il vous est déjà arrivé de vouloir analyser les performances d’une application et de vous rendre compte avec stupéfaction qu’il manque des compteurs de performance qui DOIVENT normalement être là (comme par exemple l’utilisation du processeur) ? Cela peut arriver même si je n’ai pas l’explication exacte du pourquoi du comment. Toujours est-il que cela peut être plutôt bloquant.

Et bien la solution est toute simple et elle s’appelle “lodctr” !

Cette commande permet entre autre d’ajouter de nouveaux compteurs de performance dans votre système. Il est possible de donner en argument “/R” qui a pour effet de reconstruire vos compteurs de performance tels qu’ils étaient avant !

image

Cela m’est souvent utile avant des tests de charge, lors desquels on récolte lesdits compteurs. :)

Pour plus d’information sur cette fonctionnalité : http://technet.microsoft.com/en-us/library/bb490926.aspx

.Dispose();

“Inside the Microsoft Build Engine” : le livre qui m’a manqué

 Je pense que toutes les personnes qui ont un jour décidé de se lancer dans l’apprentissage et l’utilisation un peu “poussée” de MSBuild se diront la même chose : ce livre est une bénédiction pour les gens qui veulent découvrir ce qu’on peut vraiment faire avec MSBuild.

Inside The Microsoft Build Enfine : Using MSBuild and Team Foundation Build”, écrit par Sayed Ibrahim Hashimi et William Bartholomew nous plonge dans le monde de la compilation avec MSBuild. Le livre est très progressif, les explications sont claires, les exemples bien choisi. J’ai également beaucoup apprécié les “cas réels” qui nous sortent de la théorie et qui sont vraiment à prendre comme un ensemble de recettes à appliquer sur vos projets.

Bref, je ne saurait que vous en conseiller la lecture ! :)

Pour plus d’informations : http://www.microsoft.com/learning/en/us/books/12999.aspx (en anglais)

51dZYD055WL__SL500_AA240_

.Dispose();


Les 10 derniers blogs postés

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01

- SharePoint Online: Script PowerShell pour supprimer une colonne dans tous les sites d’une collection par Blog Technique de Romelard Fabrice le 11-27-2018, 18:01