Analyser et créer un rapport sur l'évolution du code et la couverture du code à l'aide des perspectives Évolution du code et Couverture de série

Vous pouvez créer des rapports sur la qualité du logiciel en utilisant des vues de couverture d'évolution du code et de passage du cube de SQL Server Analysis Services pour Visual Studio Team Foundation Server.Grâce à ces vues, vous pouvez afficher uniquement les actions, les dimensions, les attributs associés aux modifications des lignes de code et le point auquel le code est couverte dans les builds et les séries de tests.

Ces vues sont basés sur des tables relationnels que vous pouvez utiliser pour rendre compte des modifications du code et couverture comme propriété de la génération, l'assembly ou la plateforme de génération, la série de tests, ou l'ensemble de modifications.Pour plus d'informations, consultez Tables Évolution du code et Tables Couverture de série.

En utilisant le point de vue d'évolution du code, vous pouvez créer des rapports qui répondent aux questions suivantes : Le nombre de fichiers dont l'extension de nom de fichier spécifique ont changé dans une build donnée ? Combien de lignes de code se trouvent dans le fichier source de base d'une build donnée ? Les ensembles de modifications ont été envoyés, et que sont les détails de chaque modification ?(Par exemple, qui a apporté la modification, les fichiers ont été modifiée, et lequel date a lieu la modification apportée) ?

En utilisant le point de vue de la couverture de exécution, vous pouvez créer des rapports qui répondent aux questions suivantes : Les assemblys ont la moins couverture de test ? Les séries de tests couvrent la plupart de code ? Les architectures ou types de builds ont la plupart de couverture de test ? 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 afin que vous n'ayez pas toutes les dimensions de mesures dans le cube entier en Team System.

Dans cette rubrique

• Exemple : Rapport Évolution du code

• Mesures d'évolution du code

• Exécutez les mesures couverture

• Dimensions et attributs du point de vue d'évolution du code qui prennent en charge le filtrage, et catégorisation

• Dimensions et attributs du point de vue de la couverture de passe qui prennent en charge le filtrage et catégorisation

• Activités requises pour la surveillance l'évolution du code et la couverture du code

Exemple : Rapport Évolution du code

En utilisant un rapport PivotChart dans Excel, vous pouvez créer un rapport de tendance qui affiche l'évolution du code avec le temps, semblable à l'état présente l'illustration suivante.

Les modèles de processus Microsoft Solutions Framework (MSF) v5.0 fournit automatiquement le rapport Évolution du code dans Excel.Pour plus d'informations, consultez Évolution du code, rapport Excel.

Retour au début

Sélection et filtrage des champs de pivot

Vous pouvez créer un rapport évolution du code en exécutant les étapes suivantes :

1. Dans Excel, connectez-vous à SQL Server le cube Analysis Services pour Visual Studio 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 et sélectionnez Modifier le type de graphique, Zone, Aire empilée.

3. Pour chaque filtre de rapport, ouvrez le menu contextuel pour 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 Filtre du rapport .

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

   • Hiérarchie work Item.Iteration de la dimension Élément de travail

   • Hiérarchie work Item.Area de la dimension Élément de travail

   • Date de semaine d'année de la dimension Date

4. Dans la dimension Date, développez Autres champs, puis faites glisser Date, Semaine, ou les champs Mois à la zone Champs Axe (Abscisses) selon la façon dont précise un rapport vous souhaitez générer.

5. Faites glisser Lignes ajoutées, Lignes modifiées, et les champs Lignes supprimées du groupe de mesures Évolution du code à la zone Valeurs .Vous devez faire glisser chaque champ séparément.

Retour au début

Mesures d'évolution du code

Les mesures d'évolution du code à l'échelle le nombre de modification se produit dans votre projet.En général les niveaux élevés de la baratte indiquent l'instabilité du projet.Attendez-vous à des taux élevé de baratte au début d'un cycle de produit ou lorsque l'équipe a implémenté de nombreuses modifications.Vers la fin d'une itération ou avant une version finale, vous devez vous attendre à ce que le niveau de la baratte diminue, ce qui indique que votre projet est plus stable.

Le tableau suivant décrit les actions au groupe de mesures d'évolution du code.À l'aide de ces étapes, vous pouvez créer des rapports qui indiquent le nombre versions de fichiers sont stockées dans contrôle de version Team Foundation et combien le code a modifié.Vous pouvez analyser les mesures par le répertoire de fichiers, la build, ou le membre de l'équipe qui a archivé des modifications, et vous pouvez déterminer comment ces métriques change avec le temps.

Pour plus d'informations sur les métriques manière que vous pouvez collecter des builds, consultez l' 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.

Mesure	Description
Nombre d'évolution du code	Le nombre de fois que l'équipe a modifié des fichiers dans le contrôle de version.
Lignes ajoutées	Le nombre de lignes de code que l'équipe a ajouté aux fichiers pour les dimensions que vous spécifiez.
Lignes supprimées	Le nombre de lignes de code que l'équipe a supprimées à partir de fichiers pour les dimensions que vous spécifiez.
Lignes modifiées	Le nombre de lignes de code que l'équipe a modifiées pendant la période que vous spécifiez.
Baratte totale	Baratte dans le code, calculé comme suit : [Lignes ajoutées +] [lignes supprimées] [+] lignes modifiées.
Nombre total de lignes	Le nombre de lignes de la partie de la hiérarchie de chemin d'accès de fichier que vous spécifiez.Vous devez également spécifier un ou plusieurs builds pour indiquer le débogage ou les points auxquels pour effectuer ce calcul.Si vous ne spécifiez pas un ou plusieurs builds, NULL est retournée.Le nombre de lignes est calculé par la combinaison des lignes ajoutées et des lignes supprimées qui ont contribué à une combinaison spécifique de type de build et de système d'exploitation. Conseil Toute la mesure de lignes peut provoquer une requête d'OLAP au délai d'attente.Si votre rapport utilise trop long pour afficher, envisagez de réduire l'ensemble de modifications, la génération, la série de tests, ou la plage de dates.

Retour au début

Exécutez les mesures couverture

Le tableau suivant décrit les actions au groupe de mesures couverture de passage.À l'aide de ces étapes, vous pouvez créer des rapports qui indiquent le niveau de couverture du code a été couvert par les tests d'une série de tests.Pour plus d'informations sur les métriques manière que vous pouvez collecter des builds, consultez l' 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.

Mesure	Description
Couverture de série	Le nombre de séries de tests possédant des statistiques de couverture du code associé avec elles.
Exécutez les blocs couverts de couverture	Nombre de blocs qui tous les tests d'une couverture des tests.Toutefois, la couverture entre les tests peut se chevaucher.
Exécutez les blocs de couverture non couverts	Nombre de blocs qui ne sont couvertes par tous les tests d'une série de tests.Toutefois, la couverture entre les tests peut se chevaucher.
Exécutez les lignes de couverture couvertes	Le nombre de lignes qui tous les tests d'une couverture des tests.Toutefois, la couverture entre les tests peut se chevaucher.
Exécutez les lignes de couverture non traitées	Le nombre de lignes qui ne sont couvertes par tous les tests d'une série de tests.Toutefois, la couverture entre les tests peut se chevaucher.
Exécutez les lignes de couverture partiellement couvertes	Le nombre de lignes qui teste dans une couverture de passage partielle.Toutefois, la couverture entre les tests peut se chevaucher.

Retour au début

Dimension et attributs du point de vue d'évolution du code qui prennent en charge le filtrage et catégorisation

Le tableau suivant décrit les dimensions et les attributs du point de vue d'évolution du code.Ces attributs complètent Projet d'équipe et les dimensions partagées par Date, qu' Utilisation des dimensions partagées décrit.Vous pouvez regrouper les mesures le long de ces attributs.

Dimension	Attribut	Description
Générer	Nom de définition de build	Le nom assigné à la définition de build pour laquelle la 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é, cet attribut est incrémenté par 1.
	Nom du build	Le nom ou l'expression qui identifient une génération.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 de builds : manuel, en continu (déclenché par chaque archivage), enchaîné (accumulez les enregistrements jusqu'à ce que la fin précédentes de génération), 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 build terminée.UNE URL spécifie le protocole avec lequel les navigateurs Web placeront des ressources Internet.Chaque URL comprend le nom du serveur sur lequel les détails de la build résident.Vous pouvez également inclure le chemin d'accès à une ressource.
Ensemble de modifications de contrôle de version	ID de l'ensemble de modifications	Le numéro assigné à l'ensemble de modifications qui a fourni le fichier change.
	Archivé par	Le nom d'utilisateur du membre de l'équipe qui a archivé l'ensemble de modifications.
	Description	Le commentaire d'archivage qui est associé à l'ensemble de modifications.
	Commentaire de priorité de stratégie	Le commentaire fourni lorsqu'une stratégie est substituée.Si une stratégie n'a pas été substituée à cet ensemble de modifications, ce champ est null.
Fichier de contrôle de version	Hiérarchie du contrôle de version File.File	Le chemin d'accès réseau complet du fichier source.
	Extension du contrôle de version File.File	Extension du nom du fichier source.
Élément de travail	Type d'élément de travail etc.	Pour plus d'informations, consultez Analyser et créer un rapport sur des données d'élément de travail et de cas de test à l'aide de la perspective Élément de travail.

Retour au début

Dimensions et attributs du point de vue de la couverture de passe qui prennent en charge le filtrage et catégorisation

Le tableau suivant décrit les dimensions et les attributs du point de vue de la couverture des tests.Ces attributs complètent Projet d'équipe et les dimensions partagées par Date qu' Utilisation des dimensions partagées décrit ultérieurement dans cette rubrique.Vous pouvez regrouper les mesures le long de ces attributs.

[!REMARQUE]

Avant de pouvoir utiliser les attributs Assembly ou de Version de build, l'équipe des tests doit spécifier les et publier les résultats des tests au 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 uniquement publiés) 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	Le nom assigné à la définition de build pour laquelle la 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 du build	Le nom ou l'expression qui identifient une génération.Pour plus d'informations, consultez Travailler avec des numéros de build.
	Heure de début de génération	Date et heure auxquelles 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 de builds : manuel, en continu (déclenché par chaque archivage), enchaîné (accumulez les enregistrements jusqu'à ce que la fin précédentes de génération), 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 build terminée.UNE URL spécifie le protocole avec lequel les navigateurs Web placeront des ressources Internet.L'URL inclut également le nom du serveur sur lequel réside la ressource.Vous pouvez également spécifier le chemin d'accès à une ressource.
Version de build	Version de build	(Résultats des tests uniquement publiés) nom d'Un qui indique la catégorie assignée à un ensemble de builds terminées qui ont été publiés dans le cadre d'une série de tests.Par exemple, vous pouvez utiliser une version de génération pour 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	(Résultats des tests uniquement publiés) la plateforme de nom de l'ordinateur pour laquelle une génération (non de bureau) de bout en bout a été effectuée et qui ont été publiées dans le cadre d'une série de tests (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 Options de ligne de commande pour la publication des résultats de tests.
Série de tests	Terminez la hiérarchie de date par mois ou par semaine Hiérarchie de date de création par mois ou par semaine	Dimensions Date qui ont lieu sur la date à laquelle la série de tests a été créée et terminées.Pour plus d'informations, consultez Utilisation des dimensions partagées dans le cube Analysis Services.

Retour au début

Activités requises pour la surveillance l'évolution du code et la couverture du code

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 pour 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é) Exécutez des générations 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 les builds en même temps ou les 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.

• Définissez les tests à exécuter automatiquement dans le cadre de la génération(facultatif).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 analyser l'impact des modifications du code sur les tests.

  Pour plus d'informations, consultez Exécuter des tests dans votre processus de génération.

• **Configurer des tests pour rassembler les 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 des données à propos de couverture du code, l'équipe doit avoir installé 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.

• Publier des tests.Dans le cadre de les activités de build et de test, l'équipe des tests doit publier les résultats des tests au 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

Tables Évolution du code

Tables Couverture de série

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