Analyser et créer un rapport sur les résultats de test à l'aide de la perspective Test de la base de données Analysis Services pour Visual Studio ALM

À l'aide de le point de vue de test dans le cube SQL Server Analysis Services pour Visual Studio Team Foundation Server, vous pouvez afficher uniquement les mesures, les dimensions, et attributs qui se rapportent à rendre compte des résultats des tests et séries de tests.Par exemple, vous pouvez utiliser ces mesures de déterminer la qualité globale de chaque build, les tests qu'une build particulière est affectée, le nombre de cas de test exécutés.Vous pouvez également répondre à des questions sur les modifications apportées aux résultats.

Le groupe de mesures de test est basée sur la table/relationnel résultats des tests, qui active la création de rapports sur des résultats des tests en tant que propriété des tests ou de résultats indépendants.Pour plus d'informations, consultez Tables Résultat de test.

À l'aide de le point de vue de test, vous pouvez créer des rapports qui répondent aux questions suivantes : Rapports sur l'état des bogues : Quel est l'état des tests des récits utilisateur spécifiques ou des zones de produit ? Quelle est la qualité des builds en fonction de le nombre de tests et réussi ? Combien de cas de test jamais exécutés ? Les cas de test jamais exécutés ? Rapports de tendance : Combien de tests sont bloqués, en passant, ou manquant au fil du temps ? Combien de tests sont-ils en régression ? Le nombre cohérente est l'activité de test manuel au fil du temps ? 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 mesures dans le cube entier en Team System.

Pour utiliser de nombreuses mesures et attributs de dimension de test, l'équipe de test doivent publier les résultats des tests dans le magasin de données pour Team Foundation Server.Pour plus d'informations, consultez l' Activités requises pour la gestion de tests et de builds plus loin dans cette rubrique.

Dans cette rubrique

• exemple : Rapport d'avancement pour tester les récits utilisateur

• Actions de test

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

  • Générez, générez la version, et générez des dimensions de plateforme

  • Cas de test, configurations de test, plan de test, et dimensions de la suite de tests

  • Dimension résultat de test

  • Dimension série de tests

  • Élément de travail et dimensions connexes d'élément de travail

• Activités requises pour gérer des tests et aux builds

exemple : Rapport d'avancement pour tester les récits utilisateur

À l'aide de le tableau croisé dynamique et des rapports pivotchart dans Excel, vous pouvez créer un rapport état des bogues qui affiche la progression des tests sur des récits utilisateur, semblable à l'état dans l'illustration suivante.

Les modèles de processus Microsoft (MSF) Solutions Framework v5.0 incluent le rapport état des bogues du test du récit utilisateur et le rapport état des bogues du test des spécifications dans Excel.Pour plus d'informations, consultez État du test du récit utilisateur, rapport Excel (Agile) et État du test des spécifications, rapport Excel (CMMI).

Retour au début

Spécifiant et le filtrage des champs de pivot

En exécutant les étapes suivantes, vous pouvez créer un rapport d'avancement pour tester les récits utilisateur :

1. Dans Excel, connectez au cube Analysis Services de Team Foundation Server, puis 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, cliquez sur Modifier le type du graphique, cliquez sur Zone, puis cliquez sur Barres empilées.

3. Pour chaque filtre de rapport, cliquez avec le bouton droit sur chacun des champs suivants, spécifiez les hiérarchies ou les éléments intéressants, puis faites glisser le champ à la zone de Filtre de rapport .

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

   • Chemin de la zone de la dimension de Projet d'équipe

   • Chemin de l'itération de la dimension de Cas de test

   • Type d'élément de travail de la dimension d' Élément de travail lié

     Spécifiez le type comme un récit utilisateur, une spécification, ou un autre type d'élément de travail avec des cas de test liés à ce que vous souhaitez enregistrer.

4. Faites glisser le champ de Tendance du nombre de points : à partir de le groupe de mesures de Test à la zone de Valeurs .

5. Faites glisser le champ de Résultat dans sous la dimension de Résultat de test à la région d' Étiquettes de colonne .

Retour au début

Actions de test

Le tableau suivant décrit les actions que le groupe de mesures de test inclut.Vous pouvez analyser les résultats des tests par l'agrégat des résultats des tests et leurs résultats d'une build donnée ou par les résultats modifiés pour un résultat des tests.

Mesure	Description
Tendance du nombre de résultats de build	Compte la version la plus récente de chaque résultat dans une build particulière. Pour obtenir un exemple de rapport utilisant cette mesure, consultez Qualité de build, rapport Excel.
Pointez la tendance du nombre	Nombre de la version la plus récente de chaque résultat de test dans une build particulière.Si un test est exécuté plusieurs fois sur une build, la Tendance du nombre de point compte le résultat le plus récent pour ce test avec cette build.Si un cas de test n'est pas inclus dans la build, le cas de test est considéré comme « jamais exécuté ». Utilisez cette mesure de déterminer les tests ou les combien de tests échouent dans la génération en cours.
Nombre de résultats	Compte la version la plus récente de chaque résultat de test.Utilisez cette mesure lorsque vous voulez déterminer le volume total de test. Pour obtenir un exemple de rapport utilisant cette mesure, consultez Indicateurs de qualité de build, rapport.
nombre de transition de résultat	Compte tous les résultats dont les résultats ont changé dans une build particulière.Utilisez cette mesure lorsque vous souhaitez déterminer les tests impactés par une build particulière.
Nombre de cas de test	Nombre de cas de test.Utilisez cette mesure lorsque vous voulez déterminer le nombre de cas de test exécutés pour une série de tests ou une build particulière.

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

À l'aide de attributs que cette section décrit, vous pouvez agréger une action, filtrer un rapport, ou spécifier un axe d'état.ces attributs sont en plus de Projet d'équipe et des dimensions partagées par Date qu' Utilisation des dimensions partagées décrit.

Dans cette section

• Générez, générez la version, et générez des dimensions de plateforme

• Cas de test, configurations de test, plan de test, et dimensions de la suite de tests

• Dimension résultat de test

• Dimension série de tests

• Élément de travail et dimensions connexes d'élément de travail

Retour au début

Générez, générez la version, et générez des dimensions de plateforme

Vous pouvez filtrer les rapports de test en fonction de la définition de build, générer la version, ou construire la plateforme à l'aide de les attributs décrits dans le tableau suivant.

Dimension	Attribut	Description
Générer	nom de définition de build	Le nom assigné à la définition de build pour laquelle une build a été exécutée. Pour obtenir un exemple de rapport utilisant cet attribut, consultez Qualité de build, rapport Excel.
	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 de build	Le nom ou l'expression qui identifient une seule build.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 suivants de génération : manuel, en continu (déclenché par chaque archivage), enchaîné (cumul des enregistrements tant que 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	Le dossier de dépôt défini pour la génération et spécifié comme URL (URL).UNE URL spécifie le protocole utilisé par les navigateurs Web placent des ressources Internet.L'URL comprend également le nom du serveur dans lequel la ressource réside.vous pouvez également inclure le chemin d'accès à une ressource. Pour plus d'informations, consultez Sélectionner un emplacement intermédiaire et installer un dossier de dépôt.
Version de build	Version de build	(Résultats des tests publiés uniquement) nom d'Un qui indique la catégorie de builds qui sont assignées à un ensemble de builds terminées publiés dans le cadre d'une série de tests.Par exemple, une version de génération peut être utilisée 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	La plateforme de nom de l'ordinateur pour laquelle une génération (non de bureau) de bout en bout a été faite (par exemple, x86 ou Any CPU).Pour plus d'informations, consultez Définir un processus de build basé sur le modèle par défaut.

Retour au début

Cas de test, configurations de test, plan de test, et dimensions de la suite de tests

Le cas de test, configurations de test, plan de test, et les dimensions de la suite de tests correspondent à la façon dont vous pouvez planifier, configurer, automatisent, et les tests exécutés à l'aide de le gestionnaire de tests Microsoft Visual Studio 2010 ultimate ou Visual Studio test professional.

Le cas de test correspond à un type d'élément de travail que l'équipe de test utilise pour définir les tests manuels et automatisés que votre équipe peut exécuter et gérer à l'aide de le gestionnaire de tests Microsoft.un plan de test se compose des configurations de test et des suites de tests.Une configuration de test définit le logiciel ou le matériel sur lequel vous souhaitez exécuter vos tests.Une suite de tests définit une hiérarchie dans le plan afin que vous puissiez regrouper des cas de test.

Pour plus d'informations, consultez les rubriques suivantes :

• Gestion de nouveaux efforts de test

• Comment : créer un cas de test manuel

• Configurations de test : spécification des plateformes de test

• Création de tests pour des éléments du journal des travaux en souffrance du produit, des récits utilisateur ou des spécifications

Dimension	Attribut	Description
Cas de test	Hiérarchie et une plus grande zone	Les dimensions et des éléments de travail cas de test contiennent tous les attributs relatifs aux éléments de travail, tels que l'ID d'état, de type d'élément de travail, et d'éléments de travailPour plus d'informations sur la structure de la dimension cas de test, 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. Pour obtenir une description de chaque attribut, consultez Référence des champs d'éléments de travail pour Visual Studio ALM. Pour plus d'informations sur l'utilisation de la date, la zone, et les hiérarchies d'itération, consultez Utilisation des dimensions partagées dans le cube Analysis Services. Ce groupe de mesures contient des attributs supplémentaires lorsque les champs personnalisés dans la définition d'un type d'élément de travail spécifient Dimension en tant qu'attribut Reportable.Pour plus d'informations sur l'utilisation de l'attribut facultatif d' reportable et ses valeurs, consultez Ajouter et modifier des champs d'éléments de travail pour prendre en charge la création de rapports.
Configuration de test	ID de configuration et nom de configuration	Le nombre que le système et assigne le nom d'une configuration de test.
Plan de test	Hiérarchie de zones, chemin de zone, hiérarchie d'itération, et chemin de l'itération	La zone de produit et jalon assignée au plan de test. 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.
	Hiérarchie de fin par mois ou par semaine hiérarchie de date de début par mois ou par semaine	Valeurs facultatives qu'un propriétaire du plan de test peut assigner au plan de test.Ils représentent la date à laquelle le plan de test doit commencer et la date à laquelle le plan de test doit se terminer. Pour plus d'informations sur l'utilisation des hiérarchies de date, consultez Utilisation des dimensions partagées dans le cube Analysis Services.
	Nom de l'identificateur du plan de test et du plan de test	Le nombre que le système et assigne le nom que le propriétaire du plan de test assigne.
	Propriétaire du plan de test	Le nom d'utilisateur du membre de l'équipe des tests qui l'a créé ou actuellement assigné en tant que propriétaire du plan de test.
	ID et état du plan de test	Le nombre et le nom système-assignés de l'état du plan de test.Par exemple, Inactif indique que le plan de test est défini, et Actif indique que le plan de test est prêt à être révisé et exécuté.
Suite de tests	Hiérarchie des suites de tests	Fournit un mécanisme pour spécifier plusieurs filtres basés sur la collection de projets, le projet d'équipe, et la suite de tests.
	chemin d'accès de suite	Correspond à la hiérarchie des suites de tests configurées pour tous les projets d'équipe dans toutes les collections de projets d'équipe.

Retour au début

Dimension résultat de test

Le tableau suivant répertorie toutes les dimensions et les attributs spécifiques au test mesure dans le cube.Avant de pouvoir rendre compte de Type d'échec ou de Résolution, l'équipe des tests doit respecter ces informations au sein de leurs activités de test.

Attribut	Description
Type d'échec et l'ID de ce type d'échec	Correspond à l'une des raisons suivantes pour lesquelles un test a échoué : Aucun, Problème connu, Nouveau problème, ou Régression. Le gestionnaire de tests Microsoft assigne automatiquement un nombre ou un ID à chaque raison.l'équipe des tests peut, mais n'est pas requise à, assignent un type d'échec à chaque test. Remarque Vous ne pouvez pas ajouter ou modifier l'ensemble de types d'échec. Pour obtenir un exemple de rapport de tendance qui montre les résultats des résultats des tests selon le type d'échec, consultez Analyse de l'échec, rapport Excel.
résultats et identificateur de résultats	les résultats du test (par exemple, Réussite, Échec, ou Non concluant). Pour obtenir un exemple de rapport de tendance qui montre les résultats des plans de test et des configurations de test, consultez Progression du plan de test, rapport.
État de disponibilité et identificateur d'état de disponibilité	l'état d'un test particulier dans une série de tests.les valeurs valides sont Terminé, InProgress, Aucun, NotReady, et Prêt.
état de résolution	(Facultatif) le nom de Résolution avec lequel un testeur a identifié la cause d'un test.par défaut, tous les modèles de processus MSF ont les états de résolution suivants : Nécessite un examen, Problème de test, Problème de produit, et Problème de configuration.l'équipe des tests peut, mais n'est pas requise à, affectent un état de résolution à chaque test. Remarque Vous ne pouvez pas modifier ces états ou ajouter des états après la création du projet d'équipe.Pour plus d'informations, consultez Defining Resolution States for Test.
Résultat de test exécuté par	le nom d'utilisateur ou autre compte sous lequel le test a été exécuté. Pour obtenir un exemple de rapport utilisant cet attribut, consultez Productivité de l'équipe des tests, rapport Excel.
Propriétaire du résultat de test	Le nom d'utilisateur ou un autre compte qui est assigné en tant que propriétaire du résultat des tests.L'assignation correspond à la valeur définie à l'aide de le commutateur d' tcm /resultowner .
Priorité de résultat de test	la priorité d'un test particulier dans une série de tests.

Retour au début

Dimension série de tests

Le tableau suivant décrit les attributs définis pour la dimension série de tests.Plusieurs de ces attributs correspondent aux paramètres que l'équipe des tests spécifie lorsqu'elle s'exécute et publie des tests.Pour plus d'informations, consultez tcm : exécution des tests à partir d'un plan de test à l'aide de l'utilitaire de ligne de commande.

Attribut	Description
Terminez la date, la date de création, hiérarchie de date de début par mois ou par semaine	Dates où la série de tests a été créée, terminé, ou exécuté.Vous pouvez utiliser ces attributs pour filtrer ou structurer un rapport.Pour plus d'informations, consultez Utilisation des dimensions partagées dans le cube Analysis Services.
est automatisé	Réduisez qui indique que la série de tests contient un ou plusieurs tests automatisés. Pour obtenir un exemple de rapport utilisant cet attribut, consultez Qualité de build, rapport Excel.
a lieu le passage de vérification de build	Réduisez qui indique si la série de tests contient les tests de vérification de build qui vérifient les fonctionnalités de base de la génération.Cette balise correspond au commutateur de tcm /buildverification . Pour obtenir un exemple de rapport utilisant cet attribut, consultez Qualité de build, rapport Excel.
identificateur de série de tests	Le nombre que le système assigné à la série de tests.
Propriétaire de série de tests	Correspond au propriétaire assigné à la série de tests que l'équipe des tests est créée ou a publié.Correspond au commutateur de tcm /owner .
état et identificateur de série de tests	Nommez ou comptez assigné à l'état d'une série de tests (par exemple, Abandonné, Terminé, En cours, Non démarré, ou Inconnu).
titre de série de tests	Correspond au titre assigné à la série de tests que l'équipe des tests est créée ou a publié.Correspond au commutateur de tcm /title .

Retour au début

Élément de travail et dimensions connexes d'élément de travail

Vous pouvez lier des cas de test à d'autres éléments de travail tels que les récits utilisateur, spécifications, et les bogues.À l'aide de l'élément de travail dimension, vous pouvez créer un rapport qui fournit les résultats des tests relatifs aux éléments de travail liés.Le rapport progression pour tester les récits utilisateur, décrit précédemment dans cette rubrique, fournit un exemple d'utilisation de l'élément de travail lié.

Pour obtenir une description de chaque attribut, consultez Référence des champs d'éléments de travail pour Visual Studio ALM.

Activités requises pour la gestion de tests et de builds

Pour créer des rapports de test qui contiennent des informations utiles, les membres de l'équipe doivent effectuer les activités suivantes pour gérer des builds et des tests :

• Activités de build

  • 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 de build, qui peuvent être exécutées afin de produire le code pour une plateforme différente.En outre, elle peut exécuter chaque build pour une configuration différente.

    Pour plus d'informations, consultez Créer une définition de build.

  • (recommandé)Le passage de génère l'erreur 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 des builds en même temps ou des 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.

  Pour plus d'informations, consultez Activités Team Foundation Build.

• activités de gestion de test

  • Définir des cas de test, les plans de test, et les configurations de test.Pour rendre compte des cas de test et de plans de test, l'équipe des tests doit définir ces éléments.L'équipe des tests peut également définir des suites de tests et assigner des cas de test aux plans de test.

  • (Facultatif) assignez les zones de produit et des jalons aux tests, puis suivez l'état.L'équipe des tests peut spécifier les chemins d'accès de Zone et de Itération pour chaque cas de test et plan de test.Spécifiez État de chaque cas de test et État du plan de test de chaque plan de test.

  • (facultatif) Cas de test de liens vers des éléments de travail.Par exemple, l'équipe des tests peut surveiller la progression des tests pour chaque récit à l'aide de le type de lien de Testé par à des cas de test de liens aux récits utilisateur.

  • (Facultatif) marquer les résultats des tests.Pour les tests manuels, l'équipe des tests peut 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 chaque étape du test de validation avec un état.Le résultat total pour un test reflète l'état de toutes les étapes de test marquées.Par conséquent, le test présente un état de si un testeur marque n'importe quelle étape de test comme ayant échoué ou ne marque pas toutes les étapes.

    Chaque test automatisé est automatiquement marqué comme ayant réussi ou échoué.

  • (Facultatif) configurez des tests pour collecter des 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 pour la couverture du code, vous devez installer 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.

  • **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 automatisés pour exécuter dans le cadre de la génération et pour l'analyse de l'impact des modifications du code sur vos tests.

    Pour plus d'informations, consultez Définir un processus de build basé sur le modèle par défaut.

  • publiez les tests.Dans le cadre de les activités de build et de test, l'équipe de test doivent publier les résultats des tests dans le magasin de données pour Team Foundation Server.

    Pour plus d'informations, consultez Options de ligne de commande pour la publication des résultats de tests.

Retour au début

Voir aussi

Concepts

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

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