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

Article
06/09/2015

Vous pouvez créer des rapports sur la qualité du logiciel en utilisant les perspectives d'évolution du code et de couverture de série à partir du cube SQL Server Analysis Services pour Visual Studio Team Foundation Server. Grâce à ces perspectives, vous pouvez consulter les mesures, les dimensions et les attributs associés aux modifications des lignes de codes et le niveau de couverture du code dans les builds et les séries de tests.

Ces perspectives sont basées sur les tables relationnelles que vous pouvez utiliser pour créer des rapports sur les modifications et la couverture du code en tant que propriété de la build, de l'assembly ou de la plateforme de build, de la série de tests ou de l'ensemble de modifications. Pour plus d’informations, consultez tables Évolution du code et tables Couverture de série.

Avec la perspective d'évolution du code, vous pouvez créer des rapports qui répondent aux questions suivantes :

Combien de fichiers ayant une 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 ?
Quels ensembles de modifications ont été envoyés et quels sont les détails de chaque modification ? (Par exemple, l'auteur de la modification, les fichiers modifiés et la date de modification) ?

Avec la perspective de couverture de série, vous pouvez créer des rapports qui répondent aux questions suivantes :

Quels assemblys présentent la couverture des tests la moins importante ?
Quelles séries de tests couvrent le plus de code ?
Quels architectures ou types de build ont la couverture des tests la plus importante ?

Notes

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 du cube Team System.

Dans cette rubrique

Exemple : Rapport d'évolution du code
Mesures d'évolution du code
Mesures de couverture de série
Dimensions et attributs de la perspective d'évolution du code qui prennent en charge le filtrage et la catégorisation
Dimensions et attributs de la perspective de couverture de série qui prennent en charge le filtrage et la catégorisation
Activités requises

Exemple : Rapport d'évolution du code

En utilisant un rapport sous forme de tableau croisé dynamique dans Excel, vous pouvez créer un rapport de tendance qui affiche l'évolution du code dans le temps, semblable au rapport présenté dans l'illustration suivante.

Rapport Évolution du code

Les modèles de processus Microsoft Solutions Framework (MSF) Agile et CMMI incluent le rapport d'évolution du code dans Excel. Pour plus d'informations, consultez Évolution du code, rapport Excel.

Sélection et filtrage des champs dynamiques

Champs dynamique pour le rapport Évolution du code

Vous pouvez créer un rapport d'évolution du code en procédant comme suit :

Dans Excel, connectez-vous au cube SQL Server Analysis Services pour Visual Studio Team Foundation Server et insérez un rapport de graphique croisé dynamique.

Pour plus d'informations, consultez Créer des rapports Excel à partir d'une requête d'élément de travail.
Cliquez avec le bouton droit sur le graphique, cliquez sur Modifier le type de graphique, sur Zone, puis sur Aire empilée.
Pour chaque filtre de rapport, ouvrez le menu contextuel pour chacun des champs suivants, spécifiez les hiérarchies, les semaines ou autres éléments intéressants, puis faites glisser le champ sur la zone Filtre de rapport.
- Hiérarchie de projet d'équipe à partir de la dimension Projet d'équipe
- Élément de travail.Hiérarchie d'itération à partir de la dimension Élément de travail
- Élément de travail.Hiérarchie de zone à partir de la dimension Élément de travail
- Année Semaine Date à partir de la dimension Date
Dans la dimension Date, développez Autres champs, puis faites glisser les champs Date, Semaine ou Mois dans la zone Champs Axe (catégories) pour spécifier le niveau de précision du rapport que vous souhaitez générer.
Faites glisser les champs Lignes ajoutées, Lignes modifiées et Lignes supprimées du groupe de mesures Évolution du code vers la zone Valeurs. Vous devez faire glisser chaque champ séparément.

Mesures d'évolution du code

Les mesures d'évolution du code mesurent le nombre de modifications de votre projet. En général, un niveau d'évolution du code élevé indique un projet moins stable. Attendez-vous à des niveaux d'évolution du code élevés au début d'un cycle de produit ou après l'implémentation de nombreuses modifications. Vers la fin d'une itération ou avant une version finale, le niveau d'évolution doit diminuer, ce qui indique que votre projet est plus stable.

Le tableau suivant décrit les mesures incluses dans le groupe de mesures d'évolution du code. Grâce à ces étapes, vous pouvez créer des rapports qui indiquent le nombre de versions de fichiers stockées dans le contrôle de version Team Foundation et à quel point le code a changé. Vous pouvez analyser les métriques en fonction du répertoire de fichiers, de la build ou du membre de l'équipe qui a archivé les modifications, et vous pouvez déterminer l'évolution de ces métriques au fil du temps.

Pour plus d'informations sur les métriques similaires qu'il est possible de collecter pour les builds, consultez Analyser et créer un rapport sur les détails de build et la couverture de build à l'aide de la perspective Build.

Mesure	Description
Nombre d'évolutions du code	Nombre de fois où l'équipe a modifié les fichiers dans le contrôle de version.
Lignes ajoutées	Nombre de lignes de code que l'équipe a ajoutées aux fichiers pour les dimensions que vous spécifiez.
Lignes supprimées	Nombre de lignes de code que l'équipe a supprimées des fichiers pour les dimensions que vous spécifiez.
Lignes modifiées	Nombre de lignes de code que l'équipe a modifiées pendant la période que vous spécifiez.
Nombre total d'évolutions	Évolutions du code, calculées comme suit : [lignes ajoutées] + [lignes supprimées] + [lignes modifiées].
Nombre total de lignes	Nombre de lignes dans la partie de la hiérarchie de chemins d'accès de fichier que vous spécifiez. Vous devez également spécifier une ou plusieurs builds pour indiquer le ou les points auxquels effectuer ce calcul. Si vous ne spécifiez pas une ou plusieurs builds, la valeur null est renvoyé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 La mesure Nombre total de lignes peut provoquer l'expiration de la requête OLAP.Si votre rapport met trop de temps à s'afficher, envisagez de raccourcir l'ensemble des modifications, la génération, la série de tests ou la plage de dates.

Mesures de couverture de série

Le tableau suivant décrit les mesures incluses dans le groupe de mesures de couverture du code. Grâce à ces mesures, vous pouvez créer des rapports qui indiquent le niveau de couverture du code par les tests dans une série de tests. Pour plus d'informations sur les métriques similaires qu'il est possible de collecter pour les builds, consultez Analyser et créer un rapport sur les détails de build et la couverture de build à l'aide de la perspective Build.

Mesure	Description
Couverture de série	Nombre de séries de tests possédant des statistiques de couverture du code.
Couverture de série : blocs couverts	Nombre de blocs couverts par l'ensemble des tests d'une série. Toutefois, la couverture entre les tests peut se chevaucher.
Couverture de série : blocs non couverts	Nombre de blocs qui ne sont pas couverts par les tests d'une série. Toutefois, la couverture entre les tests peut se chevaucher.
Couverture de série : lignes couvertes	Nombre de lignes couvertes par l'ensemble des tests d'une série. Toutefois, la couverture entre les tests peut se chevaucher.
Couverture de série : lignes non couvertes	Nombre de lignes qui ne sont pas couvertes par les tests d'une série. Toutefois, la couverture entre les tests peut se chevaucher.
Couverture de série : lignes partiellement couvertes	Nombre de lignes partiellement couvertes par les tests d'une série. Toutefois, la couverture entre les tests peut se chevaucher.

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

Le tableau suivant décrit les dimensions et les attributs de la perspective d'évolution du code. Ces attributs complètent les dimensions partagées Projet d'équipe et Date décrits dans la section Utilisation des dimensions partagées. Vous pouvez regrouper les mesures pour chacun de ces attributs.

Dimension	Attribut	Description
Build	Nom de définition de build	Nom assigné à la définition de build pour laquelle une build a été exécutée.
	ID de build	Numéro assigné à la build. Chaque fois qu'une définition de build particulière est exécutée, cet attribut est incrémenté de 1.
	Nom de la build	Nom ou expression qui identifie une build de manière unique. Pour plus d'informations, consultez Utiliser des numéros de build pour attribuer des noms pertinents aux builds terminées.
	Heure de début de build	Date et l'heure auxquelles la build a démarré.
	Type de build	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 suivants : en manuel, en continu (déclenché par chaque archivage), enchaîné (cumul des archivages jusqu'au terme 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	URL (Uniform Resource Locator) de la build terminée. Une URL spécifie le protocole avec lequel les navigateurs Web recherchent les 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 d'ensemble de modifications	Numéro assigné à l'ensemble de modifications qui incluait les modifications de fichier.
	Archivé par	Nom d'utilisateur du membre de l'équipe qui a archivé l'ensemble de modifications.
	Description	Commentaire d'archivage associé à l'ensemble de modifications.
	Commentaire de substitution de stratégie	Commentaire fourni lorsqu'une stratégie est substituée. Si une stratégie n'a pas été remplacée par cet ensemble de modifications, le champ a la valeur null.
Fichier de contrôle de version	Fichier de contrôle de version.Hiérarchie du fichier	Chemin d'accès réseau complet du fichier source.
	Fichier de contrôle de version.Extension de fichier	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 les données des éléments de travail et des cas de test à l'aide de la perspective Élément de travail.

Dimensions et attributs de la perspective de couverture de série qui prennent en charge le filtrage et la catégorisation

Le tableau suivant décrit les dimensions et les attributs de la perspective de couverture de série. Ces attributs complètent les dimensions partagées Projet d'équipe et Date décrits dans la section Utilisation des dimensions partagées plus loin dans cette rubrique. Vous pouvez regrouper les mesures pour chacun de ces attributs.

Notes

Avant de pouvoir utiliser les attributs Assembly ou Version de build, l'équipe des tests doit les spécifier et publier les résultats des tests dans le magasin de données de Team Foundation Server.Pour plus d'informations, consultez Activités requises plus loin dans cette rubrique.

Dimension	Attribut	Description
Assembly	Assembly	(Résultats des tests publiés uniquement) Nom du code de l'application testée dans le cadre du processus de génération. Pour plus d'informations, consultez Exécuter des tests dans votre processus de génération.
Build	Nom de définition de build	Nom assigné à la définition de build pour laquelle une build a été exécutée.
	ID de build	Numéro assigné à la build. Chaque fois qu'une définition de build particulière est exécutée, l'ID de build est incrémenté d'une unité.
	Nom de la build	Nom ou expression qui identifie une build de manière unique. Pour plus d'informations, consultez Utiliser des numéros de build pour attribuer des noms pertinents aux builds terminées.
	Heure de début de build	Date et heure auxquelles la build a démarré.
	Type de build	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 suivants : en manuel, en continu (déclenché par chaque archivage), enchaîné (cumul des archivages jusqu'au terme 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	URL (Uniform Resource Locator) de la build terminée. Une URL spécifie le protocole avec lequel les navigateurs Web recherchent les ressources Internet. L'URL comprend également le nom du serveur sur lequel la ressource réside. Vous pouvez également spécifier le chemin d'accès à une ressource.
Version de build	Version de build	(Résultats des tests publiés uniquement) Nom qui désigne la catégorie de builds qui est assignée à un ensemble de builds terminées publiées dans le cadre d'une série de tests. Par exemple, vous pouvez utiliser une version de build pour désigner une version bêta ou une version finale.
Plateforme de génération	Plateforme de génération	(Résultats des tests publiés uniquement) Nom de la plateforme d'ordinateur pour laquelle une build de bout en bout (et non une build de bureau) a été créée et qui a été publiée 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.
Série de tests	Hiérarchie par mois de date d'achèvement ou Hiérarchie par mois de semaine d'achèvement Hiérarchie par mois de date de création ou Hiérarchie par semaine de date de création	Les dimensions de date qui sont basées sur la date d'exécution du test ont été créées et sont terminées. Pour plus d'informations, consultez Dimensions partagées dans le cube Analysis Services.

Activités requises

Pour créer des rapports contenant des données relatives à l'évolution du code et à la couverture du code, les membres de l'équipe doivent passer en revue les informations dans les rubriques suivantes :