Analyser et créer un rapport sur les détails de la build et de la couverture de la build à l'aide de la perspective Build

À l'aide de le point de vue de génération, vous pouvez afficher uniquement les mesures, les dimensions, les attributs et dans le cube SQL Server Analysis Services pour Visual Studio Team Foundation Server relatives au processus de génération.Par exemple, vous pouvez utiliser ces mesures de déterminer le nombre de builds et quelle quantité de code a changé dans une génération.

La perspective build est basé sur les tables relationnels qui permettent la création de rapports sur des builds comme propriété de la build, la couverture du code, ou ensemble de modifications dans le contrôle de version.Pour plus d'informations, consultez Tables Détails de la build, Tables Projet de build, Tables Couverture de build et Tables Ensemble de modifications de build.

À l'aide de le point de vue de génération, vous pouvez créer des rapports qui répondent aux questions suivantes : Rapports sur l'état des bogues : Que génère et quelles builds ayant réussi ? Quelles sont les builds reflètent un nombre important de modifications du code ? Quelles sont les builds prêtes à être installées ? Rapports de tendance : Quel est l'état de toutes les builds dans le temps ? Quelle quantité de code a été exécutée par les tests au fil du temps ? Remarque Si votre entrepôt de données de Visual Studio Application Lifecycle Management (ALM) utilise SQL Server Enterprise Edition, la liste de cubes inclura Team System et un ensemble de perspectives.Les perspectives fournissent une vue ciblée des données. Ainsi, il n'est pas nécessaire de faire défiler toutes les dimensions et tous les groupes de mesures définis pour l'ensemble du cube Team System.

Dans cette rubrique

• exemple : État de la build

• Actions de génération

• Dimensions et attributs de la perspective build qui prennent en charge le filtrage et catégorisation

• Activités requises pour gérer des builds et des tests

exemple : État de la build

En utilisant des rapports pivotchart dans Excel, vous pouvez consulter l'état de la build avec le temps, comme les données dans l'illustration suivante.

Les modèles de processus Microsoft (MSF) Solutions Framework v5.0 incluent l'état de la build dans Excel.Pour plus d'informations, consultez État de la build, rapport Excel.

Retour au début

sélection et filtres de champ de pivot

Vous pouvez créer le rapport de synthèse pour l'état de la build en exécutant les étapes suivantes :

1. Dans Excel, connectez au cube Analysis Services de Team Foundation Server, et insérez un rapport PivotChart.

   Pour plus d'informations, consultez Créer un rapport dans Microsoft Excel pour Visual Studio ALM.

2. Cliquez avec le bouton droit sur le graphique, cliquez sur Modifier le type du graphique, cliquez sur Zone, puis cliquez sur Histogramme empilé.

3. Pour chaque filtre de rapport, cliquez avec le bouton droit sur chacun des champs suivants, spécifiez les hiérarchies, les semaines, ou d'autres éléments intéressants, puis faites glisser le champ à la zone de Filtre de rapport .

   • hiérarchie de projet d'équipe de la dimension de Projet d'équipe

   • Année Semaine Date de la dimension Date

   • Nom de définition de build de la dimension de Générer

4. Dans la dimension Date, développez Autres champs, puis faites glisser les champs de Date, de Semaine, ou de Mois à la zone de Champs Axe (catégories) pour spécifier le niveau de granularité un rapport vous souhaitez générer.

5. Faites glisser le champ de Nombre de détails de build : du groupe de mesures de Détails de la build à la zone de Valeurs .

6. Faites glisser le champ de Nom de l'état de build de la dimension d' État de la build à la zone de Champs Légende (série) .

7. (Facultatif) filtrez le champ de Nom de l'état de build pour afficher uniquement les builds qui Échec, Succès partiel, ou Opération réussie.

Retour au début

Actions de génération

Le tableau suivant décrit les actions associées aux builds.Le groupe de mesures de Couverture de build requiert que les tests d'instrumenter de l'équipe des tests pour collecter des données de couverture du code.Pour plus d'informations, consultez l' Activités requises pour gérer des builds et des tests plus loin dans cette rubrique.Pour obtenir un exemple de rapport utilisant plusieurs de ces étapes, consultez Indicateurs de qualité de build, rapport.

groupe de mesures	Mesure	Description
Détails de la build	Nombre de détails de build	Nombre de fois qu'une build spécifique a été exécutée.
	durée de génération	Nombre de minutes que la génération a effectué à terminer.
Ensemble de modifications de build	Générez le nombre d'ensemble de modifications	Nombre des ensembles de modifications dans l'ensemble sélectionné de builds.
Couverture de build	blocs couverts	Nombre de blocs que la build sélectionnée couvre.Si plusieurs séries de tests sont exécutées sur une build, la couverture de build reflète la couverture combinée des séries.Toutefois, les séries peuvent couvrir les blocs qui chevauchent.
	blocs non couverts	Nombre de blocs que la build sélectionnée n'inclut pas.Si plusieurs séries de tests sont exécutées sur une build, la couverture de build reflète la couverture combinée des séries.Toutefois, les séries peuvent couvrir les blocs qui chevauchent.
	Couverture de build	Nombre de builds associées à des statistiques de couverture du code.
	lignes couvertes	Nombre de lignes que la build sélectionnée couvre.Si plusieurs séries de tests sont exécutées sur une build, la couverture de build reflète la couverture combinée des séries.Toutefois, les séries peuvent couvrir les lignes qui chevauchent.
	Lignes non traitées	Nombre de lignes que la build sélectionnée n'inclut pas.Si plusieurs séries de tests sont exécutées sur une build, la couverture de build reflète la couverture combinée des séries.Toutefois, les séries peuvent couvrir les lignes qui chevauchent.
	lignes partiellement couvertes	Nombre de lignes que la build sélectionnée couvre partiellement.Si plusieurs séries de tests sont exécutées sur une build, la couverture de build reflète la couverture combinée des séries.Toutefois, les séries peuvent couvrir les lignes qui chevauchent.
Projet de build	Nombre de projet de build	Nombre de fichiers .csproj, de fichiers .vbproj, et d'autres fichiers projet dans l'ensemble sélectionné de builds.
	erreurs de compilation	Nombre d'erreurs de compilation qui se sont produites pour les builds sélectionnées.
	avertissements de compilation	Nombre d'avertissements de compilation qui se sont produits pour les builds sélectionnées.
	erreurs d'analyse statique	Nombre d'erreurs d'analyse statique qui se sont produites pour les builds sélectionnées.
	avertissements d'analyse statique	Nombre d'avertissements d'analyse statique qui se sont produits pour les builds sélectionnées.

Retour au début

Dimensions et attributs de la perspective build qui prennent en charge le filtrage et catégorisation

Vous pouvez utiliser les attributs du tableau suivant pour agréger une action, pour filtrer un rapport, ou pour spécifier un axe d'état.ces attributs complètent Projet d'équipe et les dimensions partagées par Date qu' Utilisation des dimensions partagées décrit.

[!REMARQUE]

Pour utiliser Assembly, les attributs de dimension de Version de build, ou de Plateforme de génération , l'équipe des tests doivent publier les résultats des tests dans le magasin de données pour Team Foundation Server.Pour plus d'informations, consultez l' Activités requises pour gérer des builds et des tests plus loin dans cette rubrique.

Dimension	Attribut	Description
Assembly	Assembly	(Résultats des tests publiés uniquement) le nom du code de l'application testée dans le cadre de la génération.Pour plus d'informations, consultez Exécuter des tests dans votre processus de génération.
Générer	nom de définition de build	Nommez assigné à la définition de build pour laquelle une build a été exécutée.
	ID de génération	Le numéro assigné à la génération.Chaque fois qu'une définition de build particulière est exécuté, ID de build est incrémenté par 1.
	nom de build	Le nom ou l'expression qui identifient une seule build.Pour plus d'informations, consultez Travailler avec des numéros de build.
	heure de début de génération	La date et l'heure de la génération a démarré.
	type de build	La raison pour laquelle la build a été exécutée.Les types de build sont associés au déclencheur défini pour la génération.Team Foundation Server prend en charge les types suivants de builds : manuel, en continu (déclenché par chaque archivage), enchaîné (cumul des enregistrements tant que des builds précédentes), archivage contrôlé, et planifié.Pour plus d'informations, consultez Spécifier les raisons et les déclencheurs de build.
	emplacement cible	L'URL (URL) pour la génération terminée.UNE URL spécifie le protocole utilisé par les navigateurs Web répond bien rechercher des ressources Internet.Chaque URL comprend le nom du serveur dans lequel les détails de la build réside.vous pouvez également inclure le chemin d'accès à une ressource.
Version de build	Version de build	(Résultats des tests publiés uniquement) nom d'Un qui indique la catégorie de builds qui a été assignée à un ensemble de builds terminées publiés dans le cadre d'une série de tests.Par exemple, une version de build peut indiquer une version bêta ou une version finale.Pour plus d'informations, consultez Options de ligne de commande pour la publication des résultats de tests.
Plateforme de génération	Plateforme de génération	le nom de la plateforme pour laquelle une génération (non de bureau) de bout en bout a été faite (par exemple, x86 ou Any CPU).Pour obtenir un exemple de rapport utilisant cet attribut, consultez Résumé de la build, rapport. Pour plus d'informations, consultez Définir un processus de build basé sur le modèle par défaut.
Qualité de build	Qualité de build	La qualité de la build.Par exemple, vous pouvez évaluer la qualité d'une build terminée comme Prêt pour le déploiement, Rejeté, ou Examen en cours.Pour plus d'informations, consultez Ajouter ou supprimer des valeurs de qualité de build.
État de la build	nom d'état de la build	L'état actuel de la build.les valeurs valides sont Échec, Succès partiel, Arrêté, Opération réussie, et Inconnu.Pour plus d'informations, consultez Gérer vos builds dans l'Explorateur de builds.
Fichier projet source de build	hiérarchie des fichiers	le chemin d'accès réseau complet du fichier source.
	Extension de fichier	Extension du nom du fichier source.
Ensemble de modifications de contrôle de version	ID de l'ensemble de modifications	Le numéro assigné à l'ensemble de modifications.
	Archivé par	Le nom d'utilisateur du membre de l'équipe qui a archivé l'ensemble de modifications.
	Description	Le commentaire d'archivage associé à l'ensemble de modifications.
	Commentaire de la priorité de stratégie	Le commentaire qui est fourni lorsqu'une stratégie est substituée.Si une stratégie n'était pas substituée à un ensemble de modifications, le champ a la valeur null.

Retour au début

Activités requises pour gérer des builds et des tests

Pour créer des rapports de build qui contiennent des informations utiles, les membres de l'équipe doivent effectuer les activités suivantes pour gérer des builds et des tests :

• Configurer un système de génération.pour utiliser Team Foundation Build, l'équipe doit installer un système de génération.

  Pour plus d'informations, consultez Configure Your Build System.

• Créer des définitions de build.l'équipe doit créer au moins une définition de build.L'équipe peut créer plusieurs définitions, qui peuvent être exécutées afin de produire le code pour une plateforme différente ou une configuration différente.

  Pour plus d'informations, consultez Créer une définition de build.

• (recommandé)Le passage de génère l'erreur régulièrement.L'équipe peut automatiquement exécuter les builds à des intervalles qu'ils spécifient ou après chaque archivage.En utilisant le déclencheur de planification, l'équipe peut exécuter automatiquement des builds en même temps ou des heures le même jour ou les jours qu'ils spécifient.

  Pour plus d'informations, consultez Spécifier les raisons et les déclencheurs de build et Exécuter, surveiller et gérer des builds.

• (facultatif) Builds terminées de réalisation.Pour remplir une dimension de qualité de build avec des informations utiles, un membre de l'équipe doit évaluer manuellement une build à l'aide de Explorateur de builds.

  Pour plus d'informations, consultez Évaluer la qualité d'une build terminée.

• (Facultatif) définissez les tests à exécuter automatiquement dans le cadre de la génération.Dans le cadre de la définition de build, l'équipe peut définir des tests automatisés pour exécuter dans le cadre de la génération et pour l'analyse de l'impact des modifications du code sur les tests.

  Pour plus d'informations, consultez Définir un processus de build basé sur le modèle par défaut.

• (Facultatif) configurez des tests pour collecter des données de couverture du code.pour que les données de couverture du code s'affichent dans le rapport, les membres de l'équipe doivent instrumenter des tests pour rassembler ces données.

  Important

  Pour collecter les données de couverture du code, l'équipe doit configurer Visual Studio Premium ou Visual Studio Ultimate sur l'ordinateur de l'agent de build.Pour plus d'informations, consultez Déployer et configurer des agents de build.

  Pour plus d'informations, consultez La configuration de la couverture du code à l'aide de paramètres de test est déconseillée et How to: Gather Code-Coverage Data with Generic Tests.

• publiez les tests.Lorsque l'équipe teste des builds, elle doit publier les résultats de ces tests dans le magasin de données pour Team Foundation Server.

  Pour plus d'informations, consultez Activités Team Foundation Build et Options de ligne de commande pour la publication des résultats de tests.

Retour au début

Voir aussi

Concepts

Perspectives et groupes de mesures fournis dans le cube Analysis Services pour Team System

Autres ressources

Exécuter des tests dans votre processus de génération