Partager via

Créer une requête basée sur des champs d’intégration de build et de test

  • Article

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Les champs Élément de travail qui prennent en charge l’intégration de build et de test prennent en charge les actions suivantes :

  • Associer des bogues aux builds dans lesquelles ils ont été trouvés ou résolus
  • Rechercher les bogues associés à une build
  • Marquer les cas de test comme étant manuels ou automatisés et stocker des informations pour prendre en charge les cas de test automatisés
  • Pour les cas de test et les étapes partagées, définissez les étapes d’action et de validation et les données utilisées pour effectuer les tests.

Opérateurs et macros pris en charge

La plupart des champs d’intégration de build et de test ont un type de données Chaîne, PlainText ou HTML. Les clauses de requête qui spécifient un champ de texte ou de texte enrichi peuvent utiliser les opérateurs et macros répertoriés dans le tableau suivant.

Type de données

Opérateurs et macros pris en charge

Texte enrichi (HTML) et
Chaînes de texte multilignes (PlainText)

Contains Words, Does Not Contain Words, Is Empty, Is Not Empty.
Les opérateurs Is Empty et Is Not Empty sont pris en charge pour Azure DevOps Server 2019 RC2 et versions ultérieures.

Texte unique (chaîne)

= , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], Contains, Does Not Contain, In, Not In, In Group, Not In Group, Was Ever
Macros[Any] : , valide avec le champ Type d’élément de travail@Project et Projet d'équipe. Le système effectue automatiquement un filtrage par défaut en fonction du projet actuel. Pour plus d’informations, consultez l’article Requête sur plusieurs projets.

Filtres utiles

Filtrer sur

Inclure ces clauses de requête

Cas de test automatisé

        Work Item Type = Test Case And Automation Status = Automated

Suites de tests basées sur des requêtes

        Work Item Type = Test Suite And Test Suite Type = Query Based

Suites de tests en fonction des exigences

        Work Item Type = Test Suite And Test Suite Type = Requirement Based

Répertorier les bogues et les cas de test qui les testent

Ouvrez une nouvelle requête, définissez le type de requête sur Éléments de travail et liens directs. Filtrez les bogues au niveau supérieur et ajoutez le filtre Cas de test dans le filtre d’éléments de travail liés.

Répertorier les bogues et les cas de test qui les testent

Notes

Vous ne pouvez pas construire une requête qui affiche une vue hiérarchique des Test Plans, Suites de tests et Cas de test. Ces éléments ne sont pas liés entre eux à l’aide de types de liens parent-enfant. Vous pouvez également afficher la hiérarchie via la page Test >Test Plans.

Générer et tester des champs de données

Le tableau suivant décrit les champs définis dans un ou plusieurs des types d'éléments de travail de test. Pour obtenir des informations sur les types de données et les attributs de champ, consultez Champs et attributs d’élément de travail.

Pour personnaliser un champ ou une liste de choix, consultez Ajouter ou modifier ou ajouter un champ pour prendre en charge les requêtes, les rapports et les workflows.

Nom du champ

Description

Type d'élément de travail

État de l'automatisation 1

Statut d'un cas de test. Vous pouvez spécifier les valeurs suivantes :

Cas de test

Trouvé dans 2

Numéro de build du produit, ou « révision », dans lequel un bogue a été trouvé.
Reference name=Microsoft.VSTS.Build.FoundIn, Data type=String

Notes

Vous pouvez également utiliser le type de lien Trouvé dans la build pour lier un élément de travail à une build. Ce type de lien est disponible à partir d’Azure DevOps et fonctionne uniquement avec les processus de builds actuels (et non avec les builds XAML).

Bug

Build d'intégration 2

Numéro de build du produit contenant le code ou corrigeant un bogue.
Reference name=Microsoft.VSTS.Build.IntegrationBuild, Data type=String

Notes

Vous pouvez également utiliser le type de lien Intégré dans la build pour lier un élément de travail à une build. Ce type de lien est disponible à partir d’Azure DevOps et fonctionne uniquement avec les processus de builds actuels (et non avec les builds XAML).

Tous

Problème

Indique que les étapes partagées sont associées à un résultat attendu. Les valeurs autorisées sont Oui et Non. Reference name=Microsoft.VSTS.Common.Issue, Data type=String

Étapes partagées

Paramètres

Contient les paramètres à utiliser lors de l'exécution d'un test manuel.
Microsoft.VSTS.TCM.Parameters, Data type=HTML

Paramètres partagés, Étapes partagées et Cas de test

Étapes

Étapes d’action et de validation requises pour effectuer le test. Microsoft.VSTS.TCM.Steps, Data type=HTML

Étapes partagées, cas de test

Informations système

Informations sur la configuration logicielle et système en rapport avec le test.
Microsoft.VSTS.TCM.SystemInfo, Data type=HTML

Bogue, réponse aux commentaires

Étapes de reproduction (ou étapes à reproduire)

Étapes nécessaires pour reproduire un comportement inattendu. Capturez suffisamment d’informations afin que les autres membres de l’équipe puissent comprendre l’impact complet du problème et savoir si les bogues ont été résolus. Cela inclut les actions entreprises pour rechercher ou reproduire le bogue et le comportement attendu. Reference name=Microsoft.VSTS.TCM.ReproSteps, Data type=HTML

Bug

Type de suite de tests 1

Catégorie de la suite de tests. Les valeurs autorisées sont les suivantes :

  • Basé sur une requête : permet de regrouper les cas de test ayant une caractéristique particulière, par exemple, tous les tests qui ont Priorité=1. La suite inclut automatiquement chaque cas de test retourné par la requête que vous définissez.
  • Basé sur les exigences : permet de regrouper les cas de test conçus pour effectuer le suivi de l'état de test des éléments de backlog. Chaque cas de test que vous ajoutez à une suite de tests fondée sur une spécification est automatiquement lié à l'élément de backlog.
  • Statique : permet de regrouper les cas de test selon des caractéristiques ou des suites de tests données.
    Pour plus d’informations, consultez Créer un plan de test.
    Reference name=Microsoft.VSTS.TCM.TestSuiteType, Data type=String

Suite de tests

Notes

  1. Ne personnalisez pas la liste de choix pour ces champs. Le système accepte uniquement les valeurs répertoriées.
  2. Si vous ajoutez un élément GLOBALLIST à la définition de FIELD, vous pouvez proposer un menu déroulant dans lequel les utilisateurs peuvent sélectionner des builds. Pour savoir comment procéder, consultez Population automatique de la liste globale et de builds plus loin dans cet article.

Autres champs

Les champs suivants n’apparaissent pas sur les formulaires d’élément de travail, mais ils font l’objet d’un suivi pour les cas de test ou les suites de tests. Vous pouvez utiliser certains de ces champs pour filtrer les requêtes et créer des rapports. (Aucun de ces champs n’est ajouté à l’entrepôt de données ni indexé.)

Nom du champ

Description

Type d'élément de travail

Stockage du test automatisé

Assembly contenant le test automatisant le cas de test.

Reference name=Microsoft.VSTS.TCM.AutomatedTestStorage, Data type=String

Cas de test

Type de test automatisé

Type de test automatisant le cas de test.

Reference name=Microsoft.VSTS.TCM.AutomatedTestType, Data type=String

Cas de test

ID Test automatisé

ID du test automatisant le cas de test

Reference name=Microsoft.VSTS.TCM.AutomatedTestId, Data type=String

Cas de test

Nom du test automatisé

Nom du test utilisé pour automatiser le cas de test

Reference name=Microsoft.VSTS.TCM.AutomatedTestName, Data type=String

Cas de test

Source de données locale

Source de données locale prenant en charge le test

Reference name=Microsoft.VSTS.TCM.LocalDataSource, Data type=HTML

Cas de test

Texte de la requête

Champ utilisé pour capturer la requête définie pour un type de suite basée sur une requête.

Reference name=Microsoft.VSTS.TCM.QueryText, Data type=PlainText

Suite de tests

Audit de suite de tests

Fait le suivi d’opérations supplémentaires effectuées lors de la modification d’une suite de tests, par exemple pour ajouter des tests à une suite de tests ou pour modifier des configurations. Ce champ est accessible par l'intermédiaire de l'onglet Historique ou d'une requête distincte. La vue consolidée de l’historique qui est présentée comprend les modifications apportées aux champs d’élément de travail et celles résultant d’artefacts connexes tels que des points et des configurations de test.

Reference name=Microsoft.VSTS.TCM.TestSuiteAudit, Data type=PlainText

Suite de tests

ID du type de suite de tests 1

Valeur assignée par le système qui correspond à la catégorie de suite de tests et qui ne s'applique qu'aux suites de tests. Les valeurs assignées sont les suivantes :

  • 1 (Statique)

  • 2 (Basé sur la requête)

  • 3 (Basé sur l’exigence)

Reference name=Microsoft.VSTS.TCM.TestSuiteTypeId, Data type=Integer

Suite de tests

Notes

  1. Ne personnalisez pas la liste de choix pour ces champs. Le système accepte uniquement les valeurs répertoriées.

Champs qui s'intègrent à Team Foundation Build

Team Foundation Build est le système de build local que vous pouvez utiliser avec Azure DevOps Server et TFS. Vous pouvez configurer votre processus de build à l’aide de la build Team Foundation et Team Foundation Build peut générer des éléments de travail en cas d’échec d’une build. Il peut également ajouter des informations de build aux éléments de travail qui ont été résolus dans une build particulière. Pour cela, la build Team Foundation exige l’ajout des deux champs suivants à la définition du type d’élément de travail : Trouvé dans et Build d’intégration.

Les champs Trouvés dans et Intégrés dans Build sont définis pour les bogues dans les processus par défaut. Ces champs associent les bogues aux builds dans lesquelles ils ont été trouvés ou résolus.

Vous pouvez utiliser l'extrait de code suivant pour ajouter ces champs à une définition de type d'élément de travail.

<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
    <HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>
<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
    <HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>

Si le champ Trouvé dans est présent dans la définition d’un type d’élément de travail, la build Team Foundation crée un élément de travail en cas d’échec d’une build et affecte le champ Trouvé dans au numéro de build de celle qui a échoué. Si le champ Trouvé dans est manquant, la build Team Foundation ne crée pas d’élément de travail lors de l’échec d’une build, mais tout le reste fonctionne comme prévu.

Quand le champ Build d’intégration est présent dans la définition du type d’élément de travail, la build Team Foundation identifie les éléments de travail résolus dans chaque build, puis met à jour ces éléments de travail en affectant le numéro de build dans lequel ils ont été résolus au champ Build d’intégration. Si le champ Build d’intégration est manquant, la build Team Foundation ne stocke pas le numéro de build dans les éléments de travail, mais tout le reste fonctionne comme prévu.

Remplissage automatique des builds et de la liste globale

La première fois que vous mettez une build en file d'attente pour un projet d'équipe à l'aide de la build Team Foundation, TFS ajoute automatiquement une liste globale intitulée Build - ProjectName. Chaque fois qu'une build est exécutée, un élément LISTITEM est ajouté à cette liste globale avec le nom de la build.

Si vous ajoutez un élément GLOBALLIST à la définition de FIELD, les utilisateurs se voient proposer un menu déroulant dans lequel ils peuvent sélectionner une build. Par exemple :

<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
    <HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
        <SUGGESTEDVALUES expanditems="true" filteritems="excludegroups">
          <GLOBALLIST name="Builds - TeamProjectName" />
        </SUGGESTEDVALUES>
</FIELD>

Champs qui s’intègrent à Test Plans

Avec Test Plans, vous pouvez automatiser la création d’un bogue ou d’un autre type d’élément de travail en cas d’échec d’un test. Pour plus d’informations, consultez Ajouter des résultats aux bogues existants avec des tests exploratoires.

Si un élément de travail est créé de cette manière, les informations relatives au système et les étapes à suivre pour reproduire le bogue sont capturées dans les champs Informations système et Étapes de reproduction.

Vous pouvez ajouter ces champs aux types d’éléments de travail que vous créez pour effectuer le suivi des erreurs à l’aide de l’extrait de code suivant.

<FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" />
<FIELD name="Repro Steps" refname="Microsoft.VSTS.TCM.ReproSteps" type="HTML" />

Champs qui s'intègrent au contrôle de version Team Foundation

L’une des fonctionnalités disponibles dans la gestion de version Team Foundation (TFVC) vous permet d’associer ou de résoudre des éléments de travail quand vous archivez du code. Si vous travaillez sur un élément de travail particulier pendant que vous modifiez du code, vous pouvez définir cette association à partir de la fenêtre d’archivage du contrôle de source une fois votre travail sur le code terminé.

La capacité de la gestion de version de Team Foundation de résoudre un élément de travail requiert des éléments de travail qui contiennent une action particulière. Le système de contrôle de code source interroge alors le suivi des éléments de travail pour déterminer si l'élément de travail prend en charge cette action et, si tel est le cas, interroge les états source et de destination de la transition. Si l’action est trouvée, le système de contrôle de code source peut effectuer la transition de l’élément de travail en fonction de la transition définie lors de l’archivage du code.

Notes

Quand vous utilisez l'action Archiver, vous devez définir les états depuis et vers pour refléter la transition d'état de votre choix.

Pour plus d'informations sur Actions, consultez Automatiser les assignations des champs par état, transition ou raison.