Test, tableau de bord (CMMI)

Article
08/15/2011

Grâce au tableau de bord Test, vous pouvez surveiller des activités des tests, créer des rapports sur la progression, rechercher des écarts dans la couverture de test et identifier des zones de test susceptibles de nécessiter un examen complémentaire. Ce tableau de bord contient cinq rapports qui fournissent des informations à propos des tests réalisés au cours des quatre dernières semaines.

Notes

Vous accédez aux tableaux de bord via votre portail du projet d'équipe. Vous pouvez accéder au tableau de bord Test uniquement si ce portail a été activé et configuré pour utiliser Microsoft Office SharePoint Server 2007. Pour plus d'informations, consultez Tableaux de bord (Agile) ou Accéder à un portail de projet d'équipe et au guide de processus.

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

Vous pouvez utiliser 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 ?

Autorisations requises

Pour afficher le tableau de bord, vous devez appartenir ou être assigné à 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 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 Gestion des autorisations.

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. En particulier, ce tableau de bord affiche les WebParts qui sont présentés dans l'illustration et le tableau suivants.

Tableau de bord Test

Notes

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 lorsque l'équipe crée des plans de test et exécute des tests à l'aide de Test Runner et Gestionnaire de tests Microsoft. Pour plus d'informations sur la définition de suites et de plans de test, consultez Organisation de cas de test à l'aide de suites de tests.

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

Composant WebPart	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 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 cliquant sur chaque nombre. Cette liste est dérivée 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 cliquant sur une build spécifique. Cette liste est dérivée d'un composant WebPart Team Web Access. Légende : : build en cours de génération : build non démarrée : build ayant réussi : build ayant échoué : build arrêtée : build partiellement réussie	Gérer et afficher des builds terminées
	Liste des archivages les plus récents. Vous pouvez afficher davantage de détails en cliquant sur un archivage spécifique. Cette liste est dérivée d'un composant WebPart Team Web Access.	Utilisation des fenêtres Archiver et 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 assigner à ces derniers des cas de test.

Pour plus d'informations, consultez Définition de votre effort de test à l'aide de plans 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 d'accès 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 aux questions du tableau suivant :

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 restent à l'état Design pendant longtemps, c'est qu'un problème bloque sans doute la progression. Vous pouvez rechercher la cause de ce blocage. Un écart de test peut survenir si le nombre de cas de test n'apparaît 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 d'activité é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.

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 d'activité é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

Vous pouvez personnaliser le tableau de bord Test de différentes façons :

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 :