Partager via

Activation de l'interface avec le Gestionnaire de tests Microsoft pour les projets d'équipe mis à niveau

  • Article

Vous devez ajouter les nouveaux types d'éléments de travail Cas de test et Étapes partagées à votre projet d'équipe mis à niveau pour utiliser Gestionnaire de tests Microsoft. Une équipe utilise des cas de test pour définir les tests manuels et automatisés qui peuvent être exécutés et gérés à l'aide de Gestionnaire de tests Microsoft. Gestionnaire de tests Microsoft est disponible avec Visual Studio 2010 Ultimate et Visual Studio Test Professional 2010. Ces outils de test sont intégrés à Visual Studio Team Foundation Server, ce qui vous permet de définir des tests en fonction des mêmes projets d'équipe que ceux utilisés par d'autres sections de votre organisation.

Les types d'éléments de travail Cas de test et Étapes partagées sont inclus dans les modèles de processus pour Microsoft Solutions Framework (MSF). Pour plus d'informations, consultez les rubriques suivantes :

Outre les nouveaux types d'éléments de travail, vous devez ajouter des types de liens et des catégories qui sont fournis avec la version 5.0 des modèles de processus pour MSF. Vous devez personnaliser des types d'éléments de travail existants pour que les nouveaux champs apparaissent sur les formulaires d'élément de travail. Vous devez également télécharger un fichier de mappage qui spécifie le type d'élément de travail pour permettre la création automatique de bogues ou d'erreurs de code par Gestionnaire de tests Microsoft.

Important

Vous devez mettre à niveau votre projet d'équipe existant une fois que votre déploiement été mis à jour vers Team Foundation Server 2010.

Cette rubrique fournit la procédure permettant de mettre à niveau un projet d'équipe unique afin d'assurer l'interface avec Gestionnaire de tests Microsoft. Après avoir exécuté la procédure de mise à niveau, vous pouvez utiliser ces informations pour écrire le script de la mise à niveau de plusieurs projets et pour ajouter les nouvelles fonctionnalités au modèle de processus personnalisé de votre organisation.

Dans cette rubrique

  • À propos des noms d'éléments de travail, des champs d'éléments de travail et des conflits potentiels

  • Attribution d'un nouveau nom à un type d'élément de travail

  • Personnalisation d'un type d'élément de travail Cas de test existant

  • Téléchargement du modèle de processus pour MSF for Agile Software Development v5.0

  • Ajout d'objets de suivi d'éléments de travail

  • Modification de définitions de types d'éléments de travail

  • Spécification du type de bogue à créer dans le Gestionnaire de tests Microsoft

  • Octroi d'autorisations aux membres de l'équipe des tests

  • Lancement du Gestionnaire de tests Microsoft

Autorisations requises

Pour effectuer ces procédures, vous devez disposer des autorisations suivantes :

  • Pour télécharger un modèle de processus, vous devez être membre du groupe Project Collection Administrators. Si les autorisations de sécurité requises sont définies explicitement, votre autorisation Gérer le modèle de processus sur la collection de projets d'équipe doit avoir la valeur Autoriser.

  • Pour exécuter les outils en ligne de commande witadmin et tcm, vous devez être membre du groupe Team Foundation Administrators ou Project Administrators pour le projet.

  • Pour accorder des autorisations, vous devez être membre du groupe administratif au niveau du groupe que vous souhaitez modifier. Par exemple, si vous souhaitez modifier des autorisations pour un groupe ou un utilisateur au niveau de la collection de projets d'équipe, vous devez être membre du groupe Project Collection Administrators pour cette collection, ou votre autorisation Modifier les informations au niveau de la collection doit avoir la valeur Autoriser.

Pour plus d'informations, consultez Autorisations de Team Foundation Server.

À propos des noms d'éléments de travail, des champs d'éléments de travail et des conflits potentiels

Lorsque vous modifiez la définition d'un type d'élément de travail, les conflits potentiels suivants peuvent se produire :

  • Le nom de l'un de vos types d'éléments de travail est en conflit avec le nom d'un type d'élément de travail que vous devez importer. Par exemple, il se peut que vous disposiez déjà d'un type d'élément de travail intitulé « cas de test ».

    Vous pouvez résoudre un conflit de noms de types d'éléments de travail en renommant un type d'élément de travail ou en personnalisant le type d'élément de travail existant pour qu'il contienne les nouveaux contrôles d'élément de travail permettant la prise en charge de Gestionnaire de tests Microsoft. Pour plus d'informations, consultez les sections suivantes plus loin dans cette rubrique :

    • Attribution d'un nouveau nom à un type d'élément de travail

    • Personnalisation d'un type d'élément de travail Cas de test existant

  • Il se peut que l'un de vos champs définis dans un type d'élément de travail soit utilisé par d'autres projets d'équipe dans l'une ou plusieurs des collections de projets spécifiées pour le déploiement de Team Foundation. Si les attributs assignés aux champs signalables varient entre les différents projets d'équipe du déploiement, des conflits de données peuvent se produire lors du traitement de l'entrepôt de données. Pour plus d'informations, consultez Résolution de conflits de schéma qui se produisent dans l'entrepôt de données.

  • Lorsque vous importez des types d'éléments de travail, un message d'erreur peut indiquer un conflit de nom. Ce conflit se produit plus fréquemment dans les déploiements mis à niveau à partir d'une version précédente de Team Foundation. Le nom convivial a été renommé pour plusieurs champs système et plusieurs champs de gestion de cas de test avant la version finale de Visual Studio Team Foundation Server 2010. Les champs système renommés suivants figurent parmi ceux qui ont été renommés : System.AreaID, System.IterationID, System.HyperLinkCount, System.ExternalLinkCount et System.AttachedFileCount.

    Vous pouvez résoudre cette erreur en renommant le champ dans la définition XML d'un type d'élément de travail ou en utilisant l'outil en ligne de commande witadmin changefield. Pour plus d'informations, consultez Gestion des champs d'éléments de travail (witadmin).

Retour au début

Attribution d'un nouveau nom à un type d'élément de travail

Vous pouvez résoudre un conflit de noms de types d'éléments de travail en renommant un type d'élément de travail.

Pour renommer un type d'élément de travail

  1. Sur un ordinateur sur lequel Visual Studio 2010 est installé, ouvrez une fenêtre d'invite de commandes.

  2. Accédez au répertoire qui contient l'outil en ligne de commande witadmin en tapant la commande suivante et en appuyant sur ENTRÉE.

    cd Lecteur:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

  3. Tapez la commande suivante, en substituant les arguments indiqués par vos données et appuyez sur ENTRÉE.

    witadmin renamewitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /n:CurrentName /new:NewName

    La commande suivante est un exemple illustrant l'attribution du nouveau nom My Test Case au type d'élément de travail Cas de test :

    witadmin renamewitd /collection:"http://MyServer:8080/tfs/Collection0" /p:MyProject /n:"Test Case" /new:"My Test Case"

Retour au début

Personnalisation d'un type d'élément de travail Cas de test existant

Si votre projet d'équipe existant contient un type d'élément de travail que vous utilisez pour gérer des cas de test, vous pouvez le personnaliser pour prendre en charge les nouveaux contrôles requis pour assurer l'interface avec Gestionnaire de tests Microsoft. Sinon, vous pouvez importer le type d'élément de travail Cas de test décrit dans la section Ajouter les types d'éléments de travail Cas de test et Étapes Partagées plus loin dans cette rubrique.

Pour personnaliser un type d'élément de travail Cas de test existant

  1. Sur un ordinateur sur lequel Visual Studio 2010 est installé, ouvrez une fenêtre d'invite de commandes.

  2. Accédez au répertoire qui contient l'outil en ligne de commande witadmin en tapant la commande suivante et en appuyant sur ENTRÉE.

    cd Lecteur:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

  3. Tapez la commande suivante, en substituant les arguments indiqués par vos données et appuyez sur ENTRÉE.

    witadmin exportwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /n:"Test Case" /f:MyTestCase.xml

  4. Ouvrez le fichier MyTestCase.xml dans Visual Studio ou dans un éditeur de texte.

  5. Ajoutez les éléments FIELD suivants dans la section FIELDS du fichier XML, comme illustré dans l'exemple suivant :

    <FIELD name="Steps" refname="Microsoft.VSTS.TCM.Steps" type="HTML">
       <HELPTEXT>Steps required to perform the test</HELPTEXT>
</FIELD>
<FIELD name="Automated Test Name" refname="Microsoft.VSTS.TCM.AutomatedTestName" type="String" >
       <HELPTEXT>The name of the test that automates this test case</HELPTEXT>
</FIELD>
<FIELD name="Automated Test Storage" refname="Microsoft.VSTS.TCM.AutomatedTestStorage" type="String" >
       <HELPTEXT>The assembly containing the test that automates this test case</HELPTEXT>
</FIELD>
<FIELD name="Automated Test Id" refname="Microsoft.VSTS.TCM.AutomatedTestId" type="String" >
       <HELPTEXT>The ID of the test that automates this test case</HELPTEXT>
</FIELD>
=<FIELD name="Automated Test Type" refname="Microsoft.VSTS.TCM.AutomatedTestType" type="String" >
       <HELPTEXT>The type of the test that automates this test case</HELPTEXT>
</FIELD>
<FIELD name="Parameters" refname="Microsoft.VSTS.TCM.Parameters" type="HTML" />
<FIELD name="Local Data Source" refname="Microsoft.VSTS.TCM.LocalDataSource" type="HTML" />
<FIELD reportable="detail" type="String" name="Automation status" refname="Microsoft.VSTS.TCM.AutomationStatus">
       <WHEN field="Microsoft.VSTS.TCM.AutomatedTestId" value="">
         <ALLOWEDVALUES>
           <LISTITEM value="Not Automated" />
           <LISTITEM value="Planned" />
         </ALLOWEDVALUES>
         <DEFAULT from="value" value="Not Automated" />
       </WHEN>
       <WHENNOT field="Microsoft.VSTS.TCM.AutomatedTestId" value="">
         <ALLOWEDVALUES>
           <LISTITEM value="Automated" />
         </ALLOWEDVALUES>
         <COPY from="value" value="Automated" />
       </WHENNOT>
</FIELD>

  6. Ajoutez l'élément Control dans la section FORM :

    <Control FieldName="Microsoft.VSTS.TCM.AutomationStatus" Type="FieldControl" Label="Automation Status:" LabelPosition="Left" />

    Vous pouvez ajouter cet élément dans la section supérieure du formulaire d'élément de travail.

  7. Ajoutez l'élément Tab dans la section FORM :

    <Tab Label="Steps">
           <Control FieldName="Microsoft.VSTS.TCM.Steps" Type="Test Steps Control" LabelPosition="Top" Dock="Fill" />
         </Tab>

    Vous devez ajouter cet élément comme premier onglet dans le groupe des onglets définis dans la section FORM.

  8. Ajoutez l'élément Tab dans la section FORM du fichier de définition XML :

    <Tab Label="Tested Work Items">
   <Control Type="LinksControl" Name="Tested">
      <LinksControlOptions>
      <WorkItemLinkFilters FilterType="include">
      <Filter LinkType="Microsoft.VSTS.Common.TestedBy" FilterOn="reversename"/>
      </WorkItemLinkFilters>
      <ExternalLinkFilters FilterType="excludeAll"/>
         <LinkColumns>
                 <LinkColumn RefName="System.ID" />
                 <LinkColumn RefName="System.WorkItemType" />
                 <LinkColumn RefName="System.Title" />
                 <LinkColumn RefName="System.AssignedTo" />
                 <LinkColumn RefName="System.State" />
                 <LinkColumn LinkAttribute="System.Links.Comment" />
           </LinkColumns>
      </LinksControlOptions>
   </Control>
</Tab>

    Cet élément permet de limiter la formation de relations de liens dans cet onglet pour inclure uniquement le type de lien TestedBy. Cet onglet est généralement utilisé pour créer des relations de liens avec les éléments de travail testés, lesquels sont le plus souvent des récits utilisateur, des scénarios ou des spécifications. Pour plus d'informations, consultez Liaison d'éléments de travail (Agile).

  9. Ajoutez l'élément Tab dans la section FORM du fichier de définition XML :

    <Tab Label="Associated Automation">
    <Control Type="AssociatedAutomationControl" LabelPosition="Top" Dock="Fill" />
</Tab>

    Cet élément permet de prendre en charge l'association entre un cas de test et un test automatisé. Pour plus d'informations, consultez Comment : associer un test automatisé à un cas de test.

  10. Enregistrez le fichier XML.

  11. Tapez la commande suivante pour importer le fichier MyTestCase, en substituant les arguments indiqués par vos données, et appuyez sur ENTRÉE.

    witadmin importwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:MyTestCase.xml

    Lorsque l'importation est terminée, le message suivant s'affiche :

    Importation du type d'élément de travail terminée.

  12. Pour vérifier les modifications, dans Team Explorer, cliquez avec le bouton droit sur vos projets d'équipe, puis cliquez sur Actualiser Actualiser.

  13. Cliquez avec le bouton droit sur Éléments de travail, pointez sur Nouvel élément de travail, puis cliquez sur Cas de test.

    Vérifiez que les nouveaux champs et les modifications du formulaire d'élément de travail apparaissent.

Retour au début

Téléchargement du modèle de processus pour MSF for Agile Software Development v5.0

Téléchargez la version 5.0 du modèle de processus MSF. Pour plus d'informations, consultez Télécharger les modèles de processus MSF version 5.0.

Ajout d'objets de suivi d'éléments de travail

Pour ajouter des objets destinés au suivi d'éléments de travail, vous devez exécuter la procédure suivante dans l'ordre indiqué :

  1. Ajouter les types de liens SharedSteps et TestedBy

  2. Ajouter les types d'éléments de travail Cas de test et Étapes partagées

  3. Ajouter des catégories de types d'éléments de travail

Ajouter les types de liens SharedSteps et TestedBy

Pour ajouter des types de liens

  1. Sur un ordinateur sur lequel Visual Studio 2010 est installé, ouvrez une fenêtre d'invite de commandes.

  2. Accédez au répertoire qui contient l'outil en ligne de commande witadmin en tapant la commande suivante et en appuyant sur ENTRÉE.

    cd Lecteur:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

  3. Pour importer les fichiers de définition de types de liens, tapez les deux commandes suivantes, en substituant les arguments indiqués par vos données, et appuyez sur ENTRÉE.

    witadmin importlinktype /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /f:"DirectoryPath\TestedBy.xml"
witadmin importlinktype /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /f:"DirectoryPath\SharedStep.xml"

    Pour DirectoryPath, spécifiez l'emplacement du dossier LinkTypes pour le modèle de processus que vous avez téléchargé. Le chemin d'accès au répertoire doit respecter la structure suivante :

    Lecteur:\MSFTemplateFolder\Agile\Files\WorkItem Tracking\LinkTypes

    La commande suivante illustre un exemple d'importation du type de lien TestedBy :

    witadmin importlinktype /collection:"http://MyServer:8080/tfs/Collection0" /f:"C:\MyTemplates\Agile\Files\WorkItem Tracking\LinkTypes\TestedBy.xml"

Ajouter les types d'éléments de travail Cas de test et Étapes partagées

Notes

Si vous avez modifié un type d'élément de travail Cas de test existant en suivant la procédure décrite dans la section Personnalisation d'un type d'élément de travail Cas de test existant présentée précédemment dans cette rubrique, vous devez importer uniquement le type d'élément de travail Étapes partagées.

Pour importer les fichiers de définition de types d'éléments de travail

  • Dans la fenêtre d'invite de commandes, tapez les deux commandes suivantes, en substituant les arguments indiqués par vos données, et appuyez sur ENTRÉE.

    witadmin importwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:"DirectoryPath\TestCase.xml"
witadmin importwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:"DirectoryPath\SharedStep.xml"

    Pour DirectoryPath, spécifiez l'emplacement de répertoire du dossier LinkDefinitions pour le modèle de processus que vous avez téléchargé. Le chemin d'accès au répertoire doit respecter la structure suivante :

    Lecteur:\MSFTemplateFolder\Agile\Files\WorkItem Tracking\TypeDefinitions

    La commande suivante illustre un exemple d'importation du fichier de définition du type TestCase :

    witadmin importwitd /collection:"http://MyServer:8080/tfs/Collection0" /p:MyProject /f:"C:\MyTemplates\Agile\Files\WorkItem Tracking\TypeDefinitions\TestCase.xml"

Ajouter des catégories de types d'éléments de travail

Pour importer les fichiers de définition de catégories

  • Dans la fenêtre d'invite de commandes, tapez la commande suivante, en substituant les arguments indiqués par vos données, et appuyez sur ENTRÉE.

    witadmin importcategories /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:"DirectoryPath\categories.xml"

    Pour DirectoryPath, spécifiez l'emplacement du dossier WorkItem Tracking pour le modèle de processus que vous avez téléchargé. Le chemin d'accès au répertoire doit respecter la structure suivante :

    Lecteur:\MSFTemplateFolder\Agile\Files\WorkItem Tracking\

    La commande suivante illustre un exemple d'importation de fichiers de définition de catégories :

    witadmin importcategories /collection:"http://MyServer:8080/tfs/Collection0" /p:MyProject /f:"C:\MyTemplates\Agile\Files\WorkItem Tracking\categories.xml"

    Notes

    L'importation du fichier XML de catégories dans un projet remplacera toutes les catégories existantes. Les catégories précédemment définies mais non spécifiées dans le fichier seront supprimées.

Retour au début

Modification de définitions de types d'éléments de travail

Vous devez modifier les définitions des types d'éléments de travail pour des bogues et pour des scénarios ou des spécifications. Vous devez ajouter deux champs à la définition de bogue, puis ajouter des contrôles de formulaire aux deux types de définitions.

Exécutez les tâches suivantes :

  • Modifier la définition de type Bogue

  • Modifier la définition de type Scénario ou Spécification

Modifier la définition de type Bogue

Pour modifier la définition de type Bogue

  1. Dans la fenêtre d'invite de commandes, tapez la commande suivante, en substituant les arguments indiqués par vos données, et appuyez sur ENTRÉE.

    witadmin exportwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /n:bug /f:MyBug.xml

  2. Ouvrez le fichier MyBug.xml dans Visual Studio ou dans un éditeur de texte.

  3. Ajoutez les éléments FIELD suivants dans la section FIELDS du fichier XML :

    <FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" >
   <HELPTEXT>Test context, provided automatically by test infrastructure</HELPTEXT>
</FIELD>
<FIELD name="Repro Steps" refname="Microsoft.VSTS.TCM.ReproSteps" type="HTML">
   <HELPTEXT>How to see the bug. End by contrasting expected with actual behavior.
   </HELPTEXT>
</FIELD>

  4. Remplacez l'élément Tab suivant appelé « History » :

    <Tab Label="History">
<Control Type="WorkItemLogControl" FieldName="System.History" Label="&amp;History:" LabelPosition="Top" Dock="Fill"/>
</Tab>

    à l'aide de la syntaxe suivante :

    <Tab Label="History">
   <Group>
      <Column PercentWidth="50">
      <Control FieldName="Microsoft.VSTS.TCM.ReproSteps" Type="HtmlFieldControl" Label="Steps to Repro&amp;duce:" LabelPosition="Top"  MinimumSize="(100,200)"  Dock="Fill"/>
      </Column>
      <Column PercentWidth="50">
      <Control FieldName="System.History" Type="WorkItemLogControl" Label="&amp;History:" LabelPosition="Top" Dock="Fill" />
      </Column>
   </Group>
</Tab>

  5. Ajoutez l'élément Control après l'élément Group dans l'élément Tab appelé « Details » sous la section FORM du fichier XML :

    <Tab Label="Details">
   <Group>
. . . 
    </Group>
<Control FieldName="Microsoft.VSTS.TCM.SystemInfo" Type="HtmlFieldControl" Label="System I&amp;nfo:" LabelPosition="Top" Dock="Fill" />
</Tab>

  6. Supprimez l'élément Tab appelé « Links », car vous allez le remplacer par deux nouveaux éléments d'onglet.

    <Tab Label="Links">   <Control Type="LinksControl"/></Tab>

  7. Ajoutez un élément Tab après l'onglet intitulé Details dans la section FORM à l'aide de la syntaxe suivante :

    <Tab Label="Test Cases" >
   <Control Type="LinksControl" Name="TestedBy" Label="Test &amp;Cases testing this Bug:" LabelPosition="Top">
      <LinksControlOptions>
         <WorkItemLinkFilters FilterType="include">
            <Filter LinkType="Microsoft.VSTS.Common.TestedBy" FilterOn="forwardname" />
            </WorkItemLinkFilters>
            <WorkItemTypeFilters FilterType="include">
            <Filter WorkItemType="Test Case" />
            </WorkItemTypeFilters>
            <ExternalLinkFilters FilterType="excludeAll"/>
                <LinkColumns>
                  <LinkColumn RefName="System.ID" />
                  <LinkColumn RefName="System.WorkItemType" />
                  <LinkColumn RefName="System.Title" />
                  <LinkColumn RefName="System.AssignedTo" />
                  <LinkColumn RefName="System.State" />
                  <LinkColumn LinkAttribute="System.Links.Comment" />
              </LinkColumns>
        </LinksControlOptions>
   </Control>
</Tab>

  8. Ajoutez un élément Tab après l'onglet Cas de test à l'aide de la syntaxe suivante :

    <Tab Label="All Links" >
   <Control Type="LinksControl" Name="GeneralLinks">
      <LinksControlOptions>
         <LinkColumns>
         <LinkColumn RefName="System.ID" />
         <LinkColumn RefName="System.WorkItemType" />
         <LinkColumn RefName="System.Title" />
         <LinkColumn RefName="System.AssignedTo" />
         <LinkColumn RefName="System.State" />
         <LinkColumn LinkAttribute="System.Links.Comment" />
         </LinkColumns>
      </LinksControlOptions>
   </Control>
</Tab>

  9. Enregistrez le fichier XML.

  10. Tapez la commande suivante pour importer le fichier MyBug, en substituant les arguments indiqués par vos données, et appuyez sur ENTRÉE.

    witadmin importwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:MyBug.xml

    Lorsque l'importation est terminée, le message suivant s'affiche :

    Importation du type d'élément de travail terminée.

  11. Pour vérifier les modifications, dans Team Explorer, cliquez avec le bouton droit sur votre projet d'équipe, puis cliquez sur Actualiser Actualiser.

  12. Cliquez avec le bouton droit sur Éléments de travail, pointez sur Nouvel élément de travail, puis cliquez sur Bogue.

  13. Vérifiez que les nouveaux champs et les modifications du formulaire d'élément de travail apparaissent.

Retour au début

Modifier la définition de type Scénario ou Spécification

Pour modifier la définition de type Scénario ou Spécification

  1. Dans la fenêtre d'invite de commandes, tapez la commande suivante, en substituant les arguments indiqués par vos données, et appuyez sur ENTRÉE.

    Notes

    Cet exemple fait référence au type d'élément de travail Scénario. Si votre projet d'équipe est basé sur le modèle de processus CMMI, remplacez la spécification ou tout autre type d'élément de travail que vous utilisez pour effectuer le suivi des fonctionnalités de produit. Si votre projet d'équipe ne comporte pas de spécification, vous pouvez importer les fichiers de définition du type Récit utilisateur ou Spécification fournis avec la version 5.0 des modèles de processus pour MSF. Pour plus d'informations, consultez Exporter et importer des types d'éléments de travail à partir d'un projet existant.

    witadmin exportwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /n:bug /f:MyScenario.xml

  2. Ouvrez le fichier MyScenario.xml dans Visual Studio ou dans un éditeur de texte.

  3. Supprimez l'élément Tab appelé « Links », car vous allez le remplacer par deux nouveaux éléments d'onglet qui fournissent le contrôle de lien.

    <Tab Label="Links">   <Control Type="LinksControl"/></Tab>

  4. Ajoutez l'élément Tab suivant dans la section FORM du fichier XML :

    <Tab Label="Test Cases" >
   <Control Type="LinksControl" Name="TestedBy" Label="&amp;Work items testing this Story:" LabelPosition="Top">
   <LinksControlOptions>
      <WorkItemLinkFilters FilterType="include">
         <Filter LinkType="Microsoft.VSTS.Common.TestedBy" FilterOn="forwardname" />
      </WorkItemLinkFilters>
      <WorkItemTypeFilters FilterType="include">
      <Filter WorkItemType="Test Case" />
      </WorkItemTypeFilters>
      <ExternalLinkFilters FilterType="excludeAll"/>
      <LinkColumns>
         <LinkColumn RefName="System.ID" />
         <LinkColumn RefName="System.WorkItemType" />
         <LinkColumn RefName="System.Title" />
         <LinkColumn RefName="System.AssignedTo" />
         <LinkColumn RefName="System.State" />
         <LinkColumn LinkAttribute="System.Links.Comment" />
      </LinkColumns>
      </LinksControlOptions>
   </Control>
</Tab>

  5. Ajoutez l'élément Tab suivant dans la section FORM du fichier XML :

    <Tab Label="Other Links" >
   <Group>
      <Column PercentWidth="100">
         <Control Type="LinksControl" Name="GeneralLinks">
         <LinksControlOptions>
         <WorkItemLinkFilters FilterType="exclude">
         <Filter LinkType="System.LinkTypes.Hierarchy"   />
         <Filter LinkType="Microsoft.VSTS.Common.TestedBy" />
         <Filter LinkType="Microsoft.VSTS.TestCase.SharedStepReferencedBy" />
         </WorkItemLinkFilters>
         <LinkColumns>
            <LinkColumn RefName="System.ID" />
            <LinkColumn RefName="System.WorkItemType" />
            <LinkColumn RefName="System.Title" />
            <LinkColumn RefName="System.AssignedTo" />
            <LinkColumn RefName="System.State" />
            <LinkColumn LinkAttribute="System.Links.Comment" />
         </LinkColumns>
      </LinksControlOptions>
   </Control>
   </Column>
</Group>
</Tab>

  6. Enregistrez le fichier XML.

  7. Tapez la commande suivante pour importer le fichier MyScenario, en substituant les arguments indiqués par vos données, et appuyez sur ENTRÉE.

    witadmin importwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:MyScenario.xml

    Lorsque l'importation est terminée, le message suivant s'affiche :

    Importation du type d'élément de travail terminée.

  8. Pour vérifier les modifications, dans Team Explorer, cliquez avec le bouton droit sur votre projet d'équipe, puis cliquez sur Actualiser Actualiser.

  9. Cliquez avec le bouton droit sur Éléments de travail, pointez sur Nouvel élément de travail, puis cliquez sur Scénario.

  10. Vérifiez que les nouveaux champs et les modifications du formulaire d'élément de travail apparaissent.

Retour au début

Spécification du type de bogue à créer dans le Gestionnaire de tests Microsoft

Pour permettre la création automatique d'un élément de travail afin d'assurer le suivi d'erreurs de code ou de bogues détectés lors de l'utilisation de Gestionnaire de tests Microsoft par un membre de l'équipe des tests, vous devez spécifier le type de bogue à utiliser pour votre projet d'équipe existant. La commande tcm bugfieldmapping prend en charge l'importation et l'exportation d'un fichier de mappage vers le projet d'équipe. Le fichier de mappage définit le type d'élément de travail à créer et les trois champs de données qui doivent être remplis par Gestionnaire de tests Microsoft. Les trois champs concernent des étapes à reproduire, des informations système et le nom de la build dans laquelle l'erreur a été trouvée. Lorsqu'un testeur exécute un test et trouve une erreur, il peut créer un bogue dans lequel les trois champs sont remplis automatiquement.

Pour plus d'informations, consultez Spécification du type de bogue à consigner dans le Gestionnaire de tests Microsoft.

Pour spécifier le type de bogue qui doit être créé par le Gestionnaire de tests Microsoft

  1. Ouvrez le Bloc-notes ou un éditeur de texte, puis copiez le code suivant dans le fichier :

    <?xml version="1.0" encoding="utf-16"?
<BugFilerMappings workitemtypetocreate="Bug">
   <ReproSteps>Microsoft.VSTS.TCM.ReproSteps</ReproSteps>
   <SystemInformation>Microsoft.VSTS.TCM.SystemInfo</SystemInformation>
   <BuildFoundIn>Microsoft.VSTS.Build.FoundIn</BuildFoundIn>
</BugFilerMappings>

    Notes

    Si le type d'élément de travail que vous utilisez pour créer des erreurs de code porte un autre nom que « Bug », remplacez « Bug » dans l'exemple précédent par le nom de ce type d'élément de travail.

  2. Enregistrez le fichier sous le nom bugfieldmappings.xml.

  3. Dans la fenêtre d'invite de commandes, tapez la commande suivante, en substituant les arguments indiqués par vos données, et appuyez sur ENTRÉE.

    tcm bugfieldmapping /import /mappingfile:"DirectoryPath\bugfieldmappings.xml" /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /teamproject:project

    Pour DirectoryPath, spécifiez le dossier dans lequel vous avez enregistré le fichier bugfieldmappings.xml.

    La commande suivante illustre un exemple d'importation du fichier bugfieldmappings.xml :

    tcm bugfieldmapping /import /mappingfile:"C:\MyFiles\bugfieldmappings.xml" collection:"http://MyServer:8080/tfs/Collection0" /p:MyProject

Retour au début

Octroi d'autorisations aux membres de l'équipe des tests

Vous devez accorder des autorisations aux membres de l'équipe qui seront chargés de gérer des environnements et des configurations de test, de créer et visualiser des séries de tests et d'effectuer d'autres tâches.

Le tableau suivant décrit les autorisations qui contrôlent l'accès aux fonctions de test et prennent en charge l'interface avec le projet d'équipe à des fins de test. Il indique également les affectations par défaut effectuées dans la version 5.0 des modèles de processus MSF, en plus des autorisations qu'il est recommandé d'accorder aux testeurs manuels et aux responsables des tests.

Autorisation

Description

Portée

Readers

Contributors

Builders

Recommandée pour les testeurs manuels

Recommandée pour les responsables des tests

Afficher les informations au niveau du projet

permet de visualiser l'appartenance de groupes au niveau des projets et les autorisations de ces membres.

Au niveau du projet

 coche coche coche coche coche

Afficher les séries de tests

permet d'afficher les plans de test de ce nœud.

Au niveau du projet

 coche coche coche coche coche

Créer des séries de tests

permet d'ajouter et de supprimer des résultats de tests et d'ajouter ou de modifier des séries de tests pour le projet d'équipe.

Au niveau du projet

coche coche coche coche

Gérer des configurations de test

permet de créer et supprimer des configurations de test pour le projet d'équipe.

Au niveau du projet

coche coche

coche

Gérer les environnements de test

permet de créer et supprimer des environnements de test pour le projet d'équipe.

Au niveau du projet

coche coche

coche

Supprimer des séries de tests

permet de supprimer un test planifié pour le projet d'équipe.

Au niveau du projet

coche coche

coche

Afficher ce nœud

permet d'afficher les paramètres de sécurité d'un nœud de zone.

Nœud de zone

 coche coche coche

coche

Gérer des plans de test

permet de créer et modifier les plans de test assignés à un nœud de zone. Si les plans de test n'ont pas été exécutés, vous pouvez également les supprimer.

Nœud de zone

coche coche coche coche

Gérer les contrôleurs de test

permet d'enregistrer et d'annuler l'enregistrement des contrôleurs de test pour la collection de projets d'équipe.

Collection de projets

coche

Vous pouvez accorder des autorisations en suivant les procédures indiquées pour la zone de portée spécifique :

  • Vous pouvez définir des autorisations au niveau du projet dans Team Explorer en cliquant avec le bouton droit sur le projet, puis en cliquant successivement sur Paramètres du projet d'équipe et Sécurité. Vous pouvez également définir ces autorisations à l'aide de l'outil en ligne de commande TFSSecurity. Pour plus d'informations, consultez Gestion des autorisations.

  • Vous pouvez définir des autorisations au niveau du nœud de zone dans Team Explorer en cliquant avec le bouton droit sur Zones et itérations, puis en cliquant successivement sur l'onglet Zone et Sécurité. Pour plus d'informations, consultez Créer et modifier des zones et des itérations.

  • Vous pouvez définir des autorisations pour une collection de projets en cliquant avec le bouton droit sur le serveur dans Team Explorer, puis en cliquant sur Sécurité, en ouvrant et en utilisant la console d'administration de Team Foundation ou en utilisant les outils en ligne de commande TFSSecurity et tf. Pour plus d'informations, consultez Groupes au niveau de la collection.

Pour plus d'informations, consultez Modifier les autorisations pour un groupe ou utilisateur.

Retour au début

Lancement du Gestionnaire de tests Microsoft

Une fois que vous avez terminé les tâches de mise à niveau décrites précédemment dans cette rubrique, vous pouvez démarrer Gestionnaire de tests Microsoft, vous connecter à votre projet et commencer à planifier vos efforts de test. Pour plus d'informations, consultez Test de l'application.

Retour au début

Voir aussi

Concepts

Cas de test (Agile)

Étapes partagées (Agile)

Autres ressources

witAdmin : administration des objets de suivi des éléments de travail

Spécification du type de bogue à consigner dans le Gestionnaire de tests Microsoft

Personnalisation des modèles de processus

Mise à jour d'un projet d'équipe mis à niveau pour accéder à de nouvelles fonctionnalités

Historique des modifications

Date

Historique

Motif

Juillet 2010

Des informations ont été ajoutées à propos des conflits potentiels que peuvent engendrer les modifications des noms conviviaux de champs. Certains exemples illustrant la commande witadmin ont été corrigés car il manquait une barre oblique inverse dans le chemin d'accès au répertoire. Les noms conviviaux de plusieurs champs de gestion de cas de test ont été corrigés, et des liens Retour au début ont été ajoutés.

Commentaires client.