Indicateurs de qualité de build, rapport

Le rapport Indicateurs de qualité de build affiche la couverture des tests, l'évolution du code et le nombre de bogues pour une définition de build spécifique. Vous pouvez utiliser ce rapport pour déterminer si des parties du code sont proches de la qualité finale.

Idéalement, les taux de réussite des tests, les bogues et l'évolution du code reflètent tous la même situation ; toutefois, tel est rarement le cas. Lorsque vous identifiez une différence, vous pouvez utiliser le rapport Indicateurs de qualité de build pour examiner les détails d'une build et d'une série de données spécifiques. Dans la mesure où ce rapport combine les résultats des tests, la couverture du code par les tests, l'évolution du code et les bogues, il vous permet de voir simultanément de nombreuses perspectives.

Pour plus d'informations sur l'accès aux rapports, leur actualisation ou leur gestion, consultez Rapports (Agile).

Notes

Ce rapport nécessite la configuration préalable avec SQL Server Reporting Services de la collection de projets d'équipe qui contient votre projet d'équipe.Ce rapport n'est pas disponible si  Rapports ne s'affiche pas lorsque vous ouvrez Team Explorer et développez le nœud de votre projet d'équipe.

Dans cette rubrique Données du rapport Modification du nombre de builds dans le rapport Interprétation du rapport Filtrage du rapport

Vous pouvez utiliser ce rapport pour répondre aux questions suivantes : Quelle est la qualité du logiciel ? Quelle est la fréquence de réussite des tests et quelle est la proportion de code testée ? En fonction des métriques de code et de test, l'équipe est-elle susceptible d'atteindre ses objectifs ?

Autorisations requises

Pour afficher le rapport, vous devez avoir été affecté ou appartenir à un groupe auquel a été attribué le rôle Explorateur dans Reporting Services. Pour plus d'informations, consultez Ajouter des utilisateurs aux projets d'équipe.

Données du rapport

Les données qui s'affichent dans le rapport Indicateurs de qualité de build proviennent de l'entrepôt de données. L'axe des X répertorie les builds spécifiques incluses dans le rapport, en fonction des filtres que vous avez définis pour la plateforme, la configuration et la définition de build.

Chaque barre verticale représente un groupe de données dérivées d'une ou de plusieurs builds. Dans la variante du rapport basée sur la taille du code, la longueur de chaque barre verticale représente la taille de la base de code archivée. Les barres sont mises à l'échelle afin que la figure la plus grande s'ajuste à la hauteur du graphique. Des tests manuels peuvent être exécutés à tout moment après la build et sont associés à cette dernière. Les tests qui n'ont pas encore été exécutés sont considérés comme « non concluants ».

L'illustration suivante montre un exemple de rapport Indicateurs de qualité de build.

Le tableau suivant décrit les informations qui s'affichent pour chaque indicateur de qualité dans le rapport :

Indicateur de qualité	Description
Bogues actifs (nombre)	Graphique en courbes qui indique le nombre de bogues actifs au moment de la génération. Notes Les bogues ne sont pas associés explicitement aux builds.Il est possible que certains des bogues comptabilisés n'affectent pas les builds affichées dans le graphique.Vous pouvez utiliser le paramètre Zone pour filtrer les bogues par zone de produit.Cette technique permet éventuellement de montrer les bogues qui sont les plus susceptibles d'affecter les builds dans le rapport.
Évolution du code (lignes)	Graphique en courbes qui indique le nombre de lignes de code que l'équipe a ajoutées, supprimées et modifiées dans les archivages précédant la build. L'évolution du code est calculée en divisant le nombre de lignes de code ajoutées, supprimées ou modifiées dans la build, par le nombre total de lignes de la build.
Couverture du code (pourcentage)	Graphique en courbes qui indique le pourcentage de code couvert par les tests.
Tests non concluants	Partie de couleur grise du graphique à barres empilées qui indique le nombre de tests qui ont échoué ou ont été suspendus. En cas d'échec de la build, soit les tests ne sont pas comptabilisés, soit ils sont considérés comme non concluants.
Échecs de tests	Partie de couleur rouge du graphique à barres empilées qui indique le nombre de tests qui ont échoué pour la build.
Tests réussis	Partie de couleur verte du graphique à barres empilées qui indique le nombre de tests réussis pour la build.

Notes

Pour plus d'informations sur la signification de l'échec et de la réussite des résultats des tests, consultez Progression du plan de test, rapport.

Vous pouvez filtrer le rapport de différentes manières :

• Modifiez la plage de l'axe des X en spécifiant le nombre de builds et la date de fin du rapport. La date de la première build indiquée dépend de la fréquence des builds.

• Filtrez l'ensemble des builds affichées par le rapport en spécifiant la plateforme, la configuration et la définition de build à inclure dans le rapport. Définissez les paramètres dans cet ordre, car l'ensemble des valeurs disponibles pour la définition de build dépend de la plateforme et de la configuration.

• Filtrez les bogues comptabilisés dans le rapport en spécifiant les zones de produit à inclure. Ce filtre n'affecte pas l'ensemble des builds qui apparaissent sur l'axe des X, l'évolution du code, la couverture du code ou les résultats des tests.

Pour plus d'informations, consultez Filtrage du rapport, plus loin dans cette rubrique.

Activités de gestion de tests et de builds obligatoires

Pour que le rapport Indicateurs de qualité de build soit utile et comporte tous les indicateurs de qualité possibles, les membres de l'équipe doivent effectuer les tâches de gestion de tests et de builds suivantes :

• Configurer un système de génération. Pour utiliser Team Foundation Build, vous devez installer un système de génération.

  Pour plus d'informations, consultez Configurer et gérer votre système de génération.

• Créer des définitions de build. vous pouvez créer plusieurs définitions de build, qui peuvent chacune être exécutées pour produire le code d'une plateforme différente. En outre, vous pouvez exécuter chaque build pour une configuration différente.

  Pour plus d'informations, consultez Définir votre processus de build.

• Définir des tests à exécuter automatiquement dans le cadre de la build : dans le cadre de la définition de build, vous pouvez définir des tests qui doivent s'exécuter avec la build, ou ne pas s'exécuter en cas d'échec de cette dernière.

  Pour plus d'informations, consultez Utiliser le modèle par défaut pour un processus de build.

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

• Exécuter les builds régulièrement. Vous pouvez exécuter les builds à des intervalles définis ou après chaque archivage. Vous pouvez créer des builds normales lorsque vous utilisez le déclencheur de planification.

  Pour plus d’informations, consultez Créer ou modifier une définition de build et Exécuter, surveiller et gérer des builds.

  Notes

  Même si un membre de l'équipe peut évaluer manuellement une build à l'aide de l'Explorateur de builds, cette évaluation n'est pas reportée dans le rapport Indicateurs de qualité de build.L'évaluation de la build s'affiche dans le rapport Résumé de la build.Pour plus d’informations, consultez Évaluer la qualité d'une build terminée et Résumé de la build, rapport.

Modification du nombre de builds dans le rapport

L'affichage du rapport Indicateurs de qualité de build varie considérablement en fonction du nombre de builds incluses dans le rapport et d'autres filtres que vous appliquez au rapport. Vous pouvez concentrer le rapport sur une plage spécifique de builds en modifiant le nombre de builds qui s'affichent dans le rapport.

Pour définir le nombre de builds représentées dans le rapport

1. Dans Nombre de builds, tapez le nombre à inclure.

2. En regard de Date de fin, cliquez sur l'icône de calendrier, puis sur la date qui correspond au dernier jour d'exécution des builds à inclure dans le rapport.

3. Cliquez sur Afficher le rapport.

Interprétation du rapport

Vous pouvez examiner le rapport afin de rechercher des réponses à ces questions pour une définition de build spécifique :

• Quelle est la qualité du logiciel ?

• L'équipe teste-t-elle assez de code ?

• Est-ce que les tests réussissent ?

• En fonction des métriques de code et de test, l'équipe est-elle susceptible de parvenir à ses objectifs ?

• Quelle est la fréquence de réussite des tests et quelle est la proportion de code testée ?

  Notes

  Le ratio des segments colorés par rapport aux segments grisés reflète la proportion de code couverte par les tests ; toutefois, les proportions contenues dans les segments colorés reflètent uniquement de manière approximative les proportions de code ayant réussi les tests ou ayant échoué à ces derniers.Cette ambiguïté vient du fait que la proportion de vert dans le segment coloré représente en réalité le nombre de tests réussis.Une seule erreur dans une partie du code peut provoquer l'échec de nombreux tests, ou un seul échec peut représenter une erreur de design étendue ayant des conséquences sur l'ensemble de la base de code.

Version correcte du rapport

Un rapport Indicateurs de qualité de build correct affiche les indicateurs suivants :

• La plupart des tests réussissent (grandes zones de vert) et peu de tests échouent (petites quantités de rouge).

• Le pourcentage de rouge est inférieur à 20-30 pour cent.

Comme le montre l'illustration suivante, la couverture du code et les taux de réussite des tests sont élevés et augmentent avec le temps. L'évolution du code, les bogues actifs, les tests non concluants et les tests ayant échoué sont à un niveau bas et ne cessent de diminuer.

Versions incorrectes du rapport Indicateurs de qualité de build

Une version incorrecte du rapport Indicateurs de qualité de build affiche un ou plusieurs des indicateurs ci-après. Vous pouvez en rechercher la cause en fonction des indications suivantes.

• Moins de couverture du code et plus d'évolution du code. L'illustration suivante montre une baisse de la couverture du code et une augmentation de l'évolution du code. Ces données signalent clairement que le nouveau code est archivé sans tests unitaires correspondants pour le couvrir.

  

• Faible taux d'exécution des tests. L'illustration suivante montre un taux faible d'exécution des tests. Ces données peuvent indiquer que l'équipe n'effectue pas assez de tests. Ce problème peut indiquer un manque de ressources ou montrer que les testeurs sont éventuellement occupés à une autre tâche, par exemple l'écriture de programmes d'automatisation des tests, au lieu de tester les fonctionnalités actuelles. Dans tous les cas, il peut s'avérer nécessaire de garantir l'équilibrage des ressources.

  

• Évolution du code élevée, faible taux de couverture du code. Une forte évolution du code suggère que les bogues sont représentés comme des effets secondaires des modifications. Dans un projet parfaitement refactorisé, vous pouvez constater une évolution du code sans modification de la couverture du code ou du taux de réussite des tests. Sinon, une forte évolution du code peut indiquer une réduction de la couverture et la nécessité de réécrire les tests.

  L'illustration suivante montre un taux important d'évolution du code et un taux faible de couverture du code en matière de tests, bien que les taux de réussite des tests restent élevés. Ces données indiquent que les tests exécutés ne s'appliquent pas au nouveau code.

  

• Taux élevé d'échec des tests. L'illustration suivante montre que de nombreux tests sont exécutés avec une couverture du code raisonnable, mais que ces tests échouent. Ces données peuvent indiquer des insuffisances en matière de développement, ou, dans les premières itérations, que les tests sont éventuellement trop sévères à cette étape du produit.

  

  Les échecs des tests doivent être traités dès que possible. Si la correction du code n'est pas pratique, les tests ayant échoué doivent être temporairement désactivés et un bogue doit être enregistré. Bien qu'il soit parfois acceptable de traiter les erreurs d'analyse du code avec moins d'empressement en début de projet, ne laissez pas s'accumuler les sections problématiques.

• Taux élevé de tests réussis et taux élevé de bogues actifs. L'illustration suivante montre un taux élevé de réussite des tests mais également un taux important de bogues entrants. Cette situation peut se produire pour plusieurs raisons. Les tests ne sont peut-être pas suffisamment rigoureux à cette étape du produit.

  

  Dans les premières itérations, des tests simples sont suffisants, mais au fur et à mesure que le produit évolue, les tests doivent prendre en compte des scénarios et des intégrations plus larges. Les tests peuvent être périmés ou s'appliquer à des fonctionnalités inappropriées. Il est peut-être temps de changer de technique de test.

• Augmentation du taux de réussite des tests et non-augmentation de la couverture du code. D'ordinaire, plus il y a de tests exécutés, plus la couverture du code est importante. En revanche, si l'exécution des tests et le taux de réussite des tests augmentent sans correspondance avec la couverture du code, les tests incrémentiels peuvent être redondants.

• Augmentation du nombre de bogues actifs, mais non-augmentation du taux d'échec des tests. Si le nombre de bogues actifs augmente et si vos tests ne montrent pas de taux d'échec correspondant, vos tests ne couvrent probablement pas les mêmes fonctionnalités que celles auxquelles s'appliquent les bogues.

• Diminution du nombre de bogues actifs, mais non-augmentation du taux de réussite des tests. Si le nombre de bogues actifs diminue et si le taux de réussite des tests n'augmente pas, vous risquez d'être confronté à un taux de réactivation croissant.

• Grandes zones de gris. Les segments en gris représentent le code qui n'a pas été généré ou testé dans la build spécifiée. Ces données s'affichent uniquement dans un rapport périodique, lorsqu'une ou plusieurs des builds spécifiées n'ont pas eu lieu au cours de la période concernée.

Filtrage du rapport

Vous pouvez filtrer le rapport Indicateurs de qualité de build de différentes manières :

• Modifiez l'intervalle de temps en spécifiant le nombre de builds et la date de fin du rapport.

• Filtrez l'ensemble des builds représentées dans le rapport en spécifiant la plateforme, la configuration et la définition de build à inclure dans le rapport.

  Notes

  Vous pouvez configurer les définitions de build afin de n'effectuer aucun test, d'en effectuer une partie ou de les effectuer tous.Le rapport varie grandement selon la configuration des définitions de build.

• Filtrez les bogues comptabilisés dans le rapport en spécifiant les zones de produit à inclure.

L'illustration suivante présente les filtres disponibles :

Appliquez les filtres dans l'ordre spécifié par la procédure ci-après. Les options disponibles avec certains filtres dépendent des filtres que vous avez définis précédemment.

Pour filtrer les builds qui s'affichent dans le rapport

1. Dans Nombre de builds, tapez le nombre à inclure.

2. En regard de Date de fin, cliquez sur l'icône de calendrier, puis sur la dernière date des builds à inclure.

3. Dans la liste Plateforme, activez la case à cocher de chaque plateforme à inclure.

4. Dans la liste Configuration, activez la case à cocher de chaque configuration à inclure.

5. Dans la liste Définition de build, activez la case à cocher de chaque définition de build à inclure.

6. Cliquez sur Afficher le rapport.

Pour filtrer le nombre de bogues affichés dans le rapport

1. Dans la liste Zone, activez la case à cocher de chaque résultat de test à inclure.

   Cette étape filtre le rapport selon la hiérarchie des résultats des tests.

2. Cliquez sur Afficher le rapport.

Voir aussi

Autres ressources

Rapports (Agile)