Partager via

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

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

Utilisez des champs d’élément de travail qui prennent en charge l’intégration de build et de test pour améliorer la traçabilité, analyser les tendances de qualité et automatiser les flux de travail liés aux tests. Voici quelques exemples de scénarios courants :

  • Associez des bogues aux builds spécifiques où ils ont été découverts ou résolus.
  • Interrogez les bogues par version pour identifier les tendances et hiérarchiser les correctifs.
  • Marquez les cas de test comme Manuels ou Automatisés et suivez les métadonnées d'automatisation.
  • Définissez les étapes d’action et de validation pour les cas de test et les étapes partagées afin que les équipes puissent exécuter et vérifier les tests de manière fiable.

Cet article explique comment utiliser ces champs et propose des exemples de requêtes et de conseils.

Conditions préalables

Area Autorisation / rôle Ce qu’il autorise
Project-level Contributeurs Créez et modifiez des requêtes.
Project-level Lecteurs Afficher les requêtes (ne peuvent pas créer ou modifier).
Project-level Administrateurs de projet Contrôle total sur les paramètres du projet, y compris les requêtes.
Tester les artefacts Gérer les plans de test Créez, modifiez et supprimez des plans de test.
Tester les artefacts Gérer les suites de tests Créez, modifiez et supprimez des suites de test.
Tester les artefacts Modifier les éléments de travail dans ce nœud Ajoutez ou modifiez des éléments de travail spécifiques aux tests, tels que les cas de test et les suites de tests.

Remarque

  • Certaines autorisations de test sont limitées au niveau du plan de test ou du nœud de zone ; les administrateurs de projet peuvent attribuer ces autorisations.
  • Pour exécuter ou automatiser des requêtes sur plusieurs projets, vérifiez que vous disposez des autorisations inter-projets requises ou utilisez un compte de service avec l’accès approprié.

Opérateurs et macros pris en charge

La plupart des champs d’intégration de build et de test utilisent des types de données String, PlainText ou HTML. Utilisez les opérateurs et macros suivants lorsque vous spécifiez des clauses de requête pour les champs de texte ou de texte enrichi.

Type de données

Opérateurs et macros pris en charge

Texte enrichi (HTML) et
Texte multiligne (PlainText)

Contains Words, Does Not Contain WordsIs Empty, Is Not Empty.

Texte à ligne unique (chaîne)

= , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], Contains, Does Not Contain, InNot In, In Group, Not In Group, Was Ever.
Macros : [Any] (valide avec type d’élément de travail) ; @Project (valide avec le projet d’équipe). Le système sélectionne par défaut le projet actuel lorsque cela est approprié. Pour obtenir des exemples de projets croisés, consultez Requête sur plusieurs projets .

Filtres utiles

Filtrer pour

Inclure ces clauses de requête

Cas de test automatisés

Work Item Type = Test Case ET Automation Status = Automated

Suites de tests basées sur des requêtes

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

Suites de tests basées sur des exigences

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

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

Créez une 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 un filtre d’éléments de travail liés pour les cas de test.

Capture d’écran montrant les bogues et leurs cas de test liés.

Remarque

Vous ne pouvez pas construire une requête qui affiche une vue hiérarchique des plans de test, des suites de tests et des cas de test, car ces artefacts ne sont pas connectés par les types de liens parent-enfant. Pour afficher cette hiérarchie, ouvrez la > page Plans de test de test (voir Créer un plan de test).

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

Le tableau suivant décrit les champs qui apparaissent dans un ou plusieurs types d’éléments de travail liés aux tests. Pour plus d’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 sélection, consultez Ajouter ou modifier un champ pour prendre en charge les requêtes, les rapports et le flux de travail.

Nom du champ

Description

Type d'élément de travail

Étatd’automatisation 1

État d’un cas de test. Valeurs : automatisées, non automatisées, planifiées. Pour exécuter des tests automatisés, consultez Exécuter des tests automatisés à partir de plans de test.
Nom de référence=Microsoft.VSTS.TCM.AutomationStatus, Type de données=String

Cas de test

Trouvé dans2

Numéro de build du produit (révision) dans lequel un bogue a été trouvé. Nom de référence=Microsoft.VSTS.Build.FoundIn, Type de données=String.

Remarque

Utilisez le type de lien Trouvé dans la build pour lier un élément de travail à une build. Ce type de lien fonctionne avec les processus de génération actuels (Azure Pipelines et définitions de build classiques) ; elle ne s’applique pas aux builds XAML héritées.

Bug

Build d'intégration2

Numéro de build du produit qui incorpore le correctif. Nom de référence=Microsoft.VSTS.Build.IntegrationBuild, Type de données=String.

Remarque

Utilisez le type de lien Intégré dans la build pour lier un élément de travail à une build. Ce type de lien fonctionne avec les processus de génération actuels (Azure Pipelines et définitions de build classiques) ; elle ne s’applique pas aux builds XAML héritées.

Tous

Problème

Indique si les étapes partagées sont associées à un résultat attendu. Valeurs autorisées : Oui, Non. Nom de référence=Microsoft.VSTS.Common.Issue, Type de données=String.

Étapes partagées

Paramètres

Contient des paramètres utilisés lors de l’exécution d’un test manuel. Nom de référence=Microsoft.VSTS.TCM.Parameters, Type de données=HTML.

Paramètres partagés, étapes partagées, cas de test

Étapes

Étapes d’action et de validation requises pour exécuter le test. Nom de référence=Microsoft.VSTS.TCM.Steps, Type de données=HTML.

Étapes partagées, cas de test

Informations système

Informations système et environnement pertinentes pour le test. Nom de référence=Microsoft.VSTS.TCM.SystemInfo, Type de données=HTML.

Bug, réponse aux commentaires

Étapes de reproduction (étapes à reproduire)

Étapes nécessaires pour reproduire un comportement inattendu. Capturez suffisamment d’informations pour que d’autres personnes puissent reproduire et valider des correctifs. Nom de référence=Microsoft.VSTS.TCM.ReproSteps, Type de données=HTML.

Bug

Type de suite de tests1

Catégorie de suite de tests. Valeurs autorisées : Basée sur la requête, Basée sur les conditions requises, Statique. Pour plus d’informations, consultez Créer un plan de test. Nom de référence=Microsoft.VSTS.TCM.TestSuiteType, Type de données=String.

Suite de tests

Remarque

  1. Ne personnalisez pas la liste de sélections pour ces champs : le système et les intégrations attendent les valeurs répertoriées.
  2. En ajoutant l'élément GLOBALLIST à la définition FIELD, vous pouvez fournir un menu déroulant de versions. Consultez Builds et auto-remplissage de liste globale.

Autres champs

Les champs suivants n’apparaissent pas sur les formulaires d’élément de travail, mais sont suivis pour les cas de test ou les suites de test. Vous pouvez utiliser certains d’entre eux pour filtrer les requêtes et créer des rapports. (Ces champs ne sont pas ajoutés à l’entrepôt de données ni indexés.)

Nom du champ

Description

Type d'élément de travail

Stockage de test automatisé

Assembly contenant le test automatisant le cas de test. Nom de référence=Microsoft.VSTS.TCM.AutomatedTestStorage, Type de données=String.

Cas de test

Type de test automatisé

Type de test automatisant le cas de test. Nom de référence=Microsoft.VSTS.TCM.AutomatedTestType, Type de données=String.

Cas de test

AutomatedTestId

ID du test automatisé. Nom de référence=Microsoft.VSTS.TCM.AutomatedTestId, Type de données=String.

Cas de test

NomDuTestAutomatisé

Nom du test automatisé. Nom de référence=Microsoft.VSTS.TCM.AutomatedTestName, Type de données=String.

Cas de test

LocalDataSource

Source de données locale utilisée par le test. Nom de référence=Microsoft.VSTS.TCM.LocalDataSource, Type de données=HTML.

Cas de test

Texte de la requête

Champ servant à saisir la requête définie pour un type de suite de requête. Nom de référence=Microsoft.VSTS.TCM.QueryText, Type de données=PlainText.

Suite de tests

Test Suite Audit

Effectue le suivi des opérations lors de la modification d’une suite de tests (par exemple, l’ajout de tests ou la modification de configurations). Visible par le biais de l’onglet Historique ou d’une requête. Nom de référence=Microsoft.VSTS.TCM.TestSuiteAudit, Type de données=PlainText.

Suite de tests

ID de type de suite de test 1

Valeur affectée par le système qui correspond à la catégorie de suite de tests : 1 (statique), 2 (basé sur une requête), 3 (basé sur les exigences). Nom de référence=Microsoft.VSTS.TCM.TestSuiteTypeId, Type de données=Integer.

Suite de tests

Remarque

  1. Ne personnalisez pas la liste de sélections pour ces champs : le système et les intégrations attendent les valeurs répertoriées.

Champs qui s’intègrent à Team Foundation Build et Azure Pipelines

Team Foundation Build est le système de build local utilisé avec les versions antérieures d’Azure DevOps Server. Azure Pipelines fournit des fonctionnalités de build et de pipeline hébergées dans le cloud dans Azure DevOps Services. Les deux systèmes intègrent des métadonnées de build à des éléments de travail lors de l’exécution des builds et lorsque les éléments de travail sont résolus dans les builds.

Les deux champs couramment utilisés pour l’intégration de build sont Found In et Integration Build. Lorsqu’ils sont présents dans une définition WIT, ils permettent à un système de génération d’associer des éléments de travail aux numéros de build appropriés.

Vous pouvez ajouter ces champs à une définition WIT :

<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>

Lorsque le champ Found In existe dans une définition WIT, un processus de génération compatible peut créer un élément de travail en cas d’échec d’une build et définir Found In sur le numéro de build. Quand la build d’intégration existe, un processus de génération compatible peut mettre à jour les éléments de travail résolus par une compilation ayant le numéro de compilation correspondant.

Remplissage automatique des builds et de la liste globale

La première fois que vous mettez en file d'attente un build pour un projet à l’aide de Team Foundation Build ou d’Azure Pipelines, le système crée une liste globale nommée Build - <ProjectName>. Chaque exécution de build ajoute une LISTITEM entrée pour cette build. La liste globale utilise le nom complet du projet et peut être référencée dans un élément GLOBALLIST dans une définition FIELD pour fournir une liste déroulante de compilations.

<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 aux plans de test

Les plans de test peuvent créer un bogue ou un autre élément de travail en cas d’échec d’un test. Lorsque vous ajoutez un élément de travail de cette façon, le système de test capture les détails de l’environnement et les étapes de reproduction dans les champs Informations système et Étapes de reproduction.

<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 à Team Foundation Version Control (TFVC)

TFVC prend en charge l'association ou la résolution d'éléments de travail lors de la validation. Lorsque vous liez un élément de travail à partir de la fenêtre de validation et que l’action est prise en charge, TFVC applique la transition d’état configurée à l’élément de travail.

Remarque

Lorsque vous utilisez l’action Checkin, définissez les états de départ et d'arrivée appropriés pour la transition attendue.

Pour plus d’informations, consultez Automatiser les affectations de champs en fonction de l’état, de la transition ou de la raison.

Limites

Limitations clés lors de l’interrogation par cas de test :

  • Vues hiérarchiques : vous ne pouvez pas construire une requête qui affiche une vue hiérarchique des plans de test, des suites de tests et des cas de test, car ces artefacts ne sont pas connectés par les types de liens parent-enfant.
  • Suites de test basées sur des requêtes : les suites basées sur des requêtes incluent chaque cas de test retourné par la requête ; assurez-vous que votre requête est précise pour éviter les inclusions involontaires.
  • Limitations de champ : certains résultats d’exécution détaillés ne sont pas disponibles en tant que champs standard et peuvent nécessiter une utilisation personnalisée des rapports ou des API.
  • Limites de performances et de débit : Azure DevOps applique les limites de requête et de ressources ; les requêtes non optimisées ou les appels d’API excessifs peuvent entraîner des retards ou une limitation.
  • Liaison de cas de test : les cas de test ne sont pas automatiquement liés à d’autres éléments de travail d’une manière qui prend en charge des requêtes hiérarchiques complexes.

Contenu connexe

  • Last updated on