Test, tableau de bord (CMMI)

Le tableau de bord Test affiche cinq rapports qui vous permettent de surveiller les activités des tests, de créer des rapports sur la progression, de déceler des écarts dans la couverture de test et d'identifier les zones de test susceptibles de nécessiter un examen complémentaire. Les données couvrent les tests réalisés au cours des quatre dernières semaines.

Dans cette rubrique Données qui s'affichent dans le tableau de bord Activités requises pour le suivi des tests Surveillance de la progression des tests Détermination d'écarts de tests Surveillance des échecs et régressions de tests Personnalisation du tableau de bord Test

Utilisez ce tableau de bord pour répondre aux questions suivantes : La création des cas de test progresse-t-elle ? L'équipe a-t-elle défini des cas de test pour toutes les spécifications ? Quelle est la proportion des cas de test qui réussissent, échouent et sont bloqués ? Les mesures d'échec de test indiquent-elles un problème qui requiert un examen approfondi ? Quel est l'état de la build exécutée hier soir ? Quels sont les archivages les plus récents ?

Spécifications

• Vous pouvez accéder au tableau de bord Test et à tous les autres tableaux de bord uniquement si le portail de votre projet d'équipe a été activé et configuré pour utiliser SharePoint Server Enterprise. Pour plus d'informations, consultez Tableaux de bord (Agile).

• Pour afficher le tableau de bord, vous devez appartenir ou être affecté à un groupe disposant de l'autorisation Lire dans les Produits SharePoint pour le projet d'équipe. Pour modifier, copier ou personnaliser un tableau de bord, vous devez être assigné ou appartenir à un groupe disposant de l'autorisation Membres dans les Produits SharePoint pour le projet d'équipe.

  Pour afficher un élément de travail, vous devez être membre du groupe Lecteurs ou l'autorisation Afficher les éléments de travail dans ce nœud doit avoir la valeur Autoriser. Pour créer ou modifier un élément de travail, vous devez être membre du groupe Contributors ou disposer de l'autorisation Modifier les éléments de travail dans ce nœud avec la valeur Autoriser.

  Pour plus d'informations, consultez Ajouter des utilisateurs aux projets d'équipe.

• Pour modifier un rapport dans Office Excel, vous devez être membre du rôle de sécurité TfsWarehouseDataReaders dans SQL Server Analysis Services et être assigné ou appartenir à un groupe disposant de l'autorisation Membres dans les Produits SharePoint pour le projet d'équipe. Pour plus d'informations, consultez Accorder l'accès aux bases de données de l'entrepôt de données pour Visual Studio ALM.

• Pour afficher un élément de travail, vous devez être membre du groupe Lecteurs ou l'autorisation Afficher les éléments de travail dans ce nœud doit avoir la valeur Autoriser. Pour créer ou modifier un élément de travail, vous devez être membre du groupe Contributors ou disposer de l'autorisation Modifier les éléments de travail dans ce nœud avec la valeur Autoriser. Pour plus d'informations, consultez Ajouter des utilisateurs aux projets d'équipe.

• Les rapports Progression du plan de test, Disponibilité du cas de test, État du test des spécifications et Activité de test sont disponibles uniquement quand l'équipe crée des plans de test et exécute les tests comme indiqué dans la section Planifier des tests manuels à l'aide de Team Web Access.

Données qui s'affichent dans le tableau de bord Test

Vous pouvez utiliser le tableau de bord Test pour connaître la progression de l'équipe dans le cadre des tests des spécifications. Pour en savoir plus sur les composants WebPart qui sont affichés dans le tableau de bord Test, consultez l'illustration et le tableau suivants.

Les graphiques d'avancement, de progression et de tendances, ainsi que les rapports à , ne s'affichent pas lorsque le serveur qui héberge Analysis Services pour le projet d'équipe n'est pas disponible.

Composant Web Part	Données affichées	Rubrique connexe
	Graphique en aires empilées des résultats de tous les tests regroupés selon le résultat enregistré le plus récent au cours des quatre dernières semaines. Les résultats peuvent être Jamais exécuté, Bloqué, Échec ou Réussite.	Progression du plan de test, rapport
	Graphique en aires empilées qui indique combien de cas de test ont possédé l'état Design ou Prêt au cours des quatre dernières semaines.	Disponibilité du cas de test, rapport
	Graphique à barres horizontales qui indique le nombre de résultats des tests pour chaque combinaison de cas de test et configuration de test définie pour chaque spécification. Le graphique regroupe les résultats des tests en fonction de leur série de tests la plus récente, avec les options Réussite (vert), Échec (rouge), Bloqué (violet) ou Pas exécuté (gris).	État du test des spécifications, rapport Excel (CMMI)
	Graphique en courbes qui indique le nombre cumulé de tous les résultats exécutés pour tous les cas de test manuel au cours des quatre dernières semaines.	Activité de test, rapport Excel
	Graphique en aires empilées qui indique le nombre cumulé de tous les résultats négatifs des tests, triés par type d'échec, au cours des quatre dernières semaines. Les types d'échec sont Régression, Nouveau problème et Problème connu.	Analyse de l'échec, rapport Excel
	Liste des événements à venir. Cette liste est dérivée d'un composant WebPart SharePoint.	Non applicable
	Nombre d'éléments de travail actifs, résolus et fermés. Vous pouvez ouvrir la liste d'éléments de travail en sélectionnant un numéro. Cette liste est issue d'un composant WebPart Team Web Access.	Éléments de travail et flux de travail (CMMI)
	Liste des builds récentes et leur état. Vous pouvez afficher davantage de détails en sélectionnant une build spécifique. Cette liste est issue d'un composant WebPart Team Web Access. Légende : : la génération n'a pas démarré : la génération est en cours : la génération a réussi : la génération a échoué : la génération est arrêtée : la génération a partiellement réussi	Managing and Reporting on Builds
	Liste des archivages les plus récents. Vous pouvez afficher davantage de détails en sélectionnant un archivage spécifique. Cette liste est issue d'un composant WebPart Team Web Access.	Développer du code et gérer des modifications en attente

Activités requises pour le suivi des tests

Pour que les rapports du tableau de bord Test soient utiles et précis, l'équipe doit mettre en œuvre les activités suivantes :

• Définir des cas de test et des spécifications, et créer des liens Testé par entre les cas de test et les spécifications.

• Définir des plans de test et leur attribuer des cas de test.

• Pour les tests manuels, marquer les résultats de chaque étape de validation dans le cas de test comme ayant réussi ou échoué.

  Important

  Les testeurs doivent marquer une étape de test en précisant un état s'il s'agit d'une étape d'un test de validation.Le résultat total pour un test reflète l'état de toutes les étapes de test marquées par le testeur.Par conséquent, l'état Échec sera affecté au test si l'une des étapes de test a été marquée comme ayant échoué par le testeur ou n'a pas été marquée.

  Pour les tests automatisés, chaque test est automatiquement marqué comme ayant réussi ou échoué.

• (Facultatif) Pour prendre en charge le filtrage, assignez des chemins Itération et Zone à chaque cas de test.

Surveillance de la progression des tests

Vous pouvez utiliser les trois premiers rapports du tableau de bord Test pour surveiller la progression des tests et répondre à ces questions :

Rapport	Questions répondues	Remarques
Disponibilité du cas de test	Combien de cas de test l'équipe des tests a-t-elle défini ? Combien de cas de test sont prêts à être exécutés aujourd'hui ? Combien de cas de test l'équipe doit-elle encore rédiger et réviser ? Le nombre total de cas de test semble-t-il suffisant pour le nombre de spécifications implémentées par l'équipe ? Quel pourcentage de cas de test l'équipe des tests peut-elle exécuter aujourd'hui ? L'équipe sera-t-elle en mesure de préparer tous les cas de test d'ici la fin de l'itération ?	Une progression correcte indique une augmentation continue du nombre de cas de test conçus par l'équipe et possédant l'état Prêt. Une progression incorrecte indique aucun ou un nombre limité de cas de test prêts à être exécutés. Lorsque tous les cas de test demeurent dans l'état Conception pendant longtemps, cela signifie qu'un problème bloque sans doute la progression. Vous pouvez rechercher la cause de ce blocage. Un écart de test peut apparaître si le nombre de cas de test n'est pas suffisant. Le nombre de cas de test définis pour un projet doit être supérieur ou égal au nombre de spécifications implémentées par l'équipe. Le nombre de cas de test ne semble pas être suffisant.
Progression du plan de test	Combien de cas de test réussissent ? Combien de cas de test échouent ? Combien de cas de test sont bloqués ? Combien de cas de test ne sont jamais exécutés ? Quel pourcentage de cas de test réussissent dans tous les plans de test ? Combien de tests l'équipe a-t-elle effectué ? L'équipe est-elle susceptible de terminer l'itération dans les temps ?	À mesure que le cycle de développement progresse, le nombre de cas de test qui réussissent doit augmenter et le nombre de cas de test possédant un autre état doit diminuer. Une progression incorrecte se produit lorsque trop de cas de test échouent. Selon la phase du cycle de produit dans laquelle vous vous trouvez, vous pouvez rechercher la raison de l'échec d'un si grand nombre de cas de test. Si le nombre de cas de test qui échouent ou ne sont jamais exécutés reste stable, vous pouvez étudier les causes spécifiques qui affectent chaque zone.
État du test des spécifications	Des cas de test sont-ils exécutés pour chaque spécification ? Si des cas de test sont bloqués ou non exécutés, l'équipe a-t-elle identifié les problèmes majeurs et est-elle en train de les corriger ?	Une progression correcte indique que la plupart des cas de test de chaque spécification réussissent. Une progression incorrecte indique un trop grand nombre de cas de test pour une spécification précise avec l'état Jamais exécuté, Bloqué ou Échec. Vous pouvez étudier les causes qui empêchent les cas de test définis pour une spécification de réussir.

Détermination d'écarts de tests

Vous pouvez utiliser le rapport État du test des spécifications pour déterminer si les tests couvrent tout le code et pour répondre aux questions suivantes :

• Pour quelles spécifications le nombre total de cas de test est-il faible ?

• Pour quelles spécifications le nombre total de cas de test bloqués ou jamais exécutés est-il élevé ?

• La couverture des cas de test de chaque spécification répond-elle aux attentes ?

• Quelles spécifications ont un taux d'échecs aux tests élevé ?

• Quel est le nombre moyen de cas de test définis pour chaque spécification ?

Surveillance des échecs et régressions de tests

En surveillant les échecs de test, vous pouvez identifier et résoudre rapidement les problèmes de code. Les deux derniers rapports du tableau de bord Test vous permettent de mieux visualiser le nombre des tests qui échouent.

Rapport	Questions répondues	Remarques
Activité de test manuel	Le nombre de tests que l'équipe n'a jamais exécutés a-t-il diminué ? L'équipe parvient-elle à réduire le nombre global de tests bloqués ? Le nombre de tests qui échouent diminue-t-il avec le temps ? Le nombre de tests qui réussissent augmente-t-il ? L'activité de test connaît-elle des pics que vous ne pouvez pas expliquer ?	Le rapport Activité de test manuel indique les résultats de chaque cas de test exécuté pour chaque configuration de test et pour tous le plans de test. Les pics éventuels peuvent être les premiers indicateurs de problèmes liés à l'activité de test ou à la qualité du code archivé. Vous pouvez vérifier les mesures des builds récentes, l'état des bogues et l'évolution du code pour déterminer si l'un de ces éléments peut expliquer les changements.
Analyse de l'échec du test	Combien de tests sont-ils en régression ? L'équipe conserve-t-elle le nombre total de régressions ou d'échecs de test dans les limites ou objectifs attendus ? L'équipe traite-t-elle les problèmes dès qu'ils sont identifiés et les problèmes connus en temps voulu ?	Un rapport Analyse de l'échec du test correct affiche un nombre modéré de nouveaux problèmes, de problèmes connus et de régressions. Si des pics d'activité se produisent dans ces zones, l'équipe devra peut-être étudier la question de façon plus approfondie. Les pics peuvent indiquer des problèmes dans l'activité de test ou dans la qualité du code archivé. De plus, vous pouvez vérifier les mesures des builds récentes, l'état des bogues et l'évolution du code pour déterminer si l'un de ces éléments peut expliquer les changements.

Personnalisation du tableau de bord Test

Voici comment personnaliser le tableau de bord Test :

• Modifiez les filtres de chaque rapport dans Office Excel pour vous concentrer sur des zones de produit ou des itérations spécifiques.

• Filtrez le rapport Activité de test manuel dans Office Excel pour accéder à des plans de test spécifiques ou à des cas de test manuel ou automatisé.

• Ajoutez des rapports Excel existants tels que État des bogues, Évolution du code et Couverture du code au tableau de bord.

• Créez et ajoutez des rapports dans Office Excel qui affichent la progression par des membres spécifiques de l'équipe. Pour obtenir un exemple, consultez Bogues par assignation, rapport Excel.

Pour plus d'informations sur l'utilisation et la personnalisation des rapports dans Office Excel, consultez les pages suivantes sur le site Web Microsoft :

• Méthodes de personnalisation des rapports de tableau croisé dynamique

• Modifier ou supprimer un classeur dans Excel Services

• Publier un classeur dans Excel Services

• Enregistrer un fichier dans une bibliothèque SharePoint ou un autre emplacement web

Voir aussi

Concepts

Exécution de tests manuels à l'aide de Team Web Access

Disponibilité du cas de test, rapport

Progression du plan de test, rapport

Autres ressources

Tableaux de bord (CMMI)