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.
.png "Tester le groupe de mesures") |
À 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 :
Rapports de tendance :
.gif "Remarque") 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.
.png "Rapport Excel État du test du récit utilisateur")
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
.gif "ms244708.collapse_all(fr-fr,VS.110).gif")
Spécifiant et le filtrage des champs de pivot
.png "Champs dynamiques pour la progression des tests de récits utilisateur")
En exécutant les étapes suivantes, vous pouvez créer un rapport d'avancement pour tester les récits utilisateur :
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.
Cliquez avec le bouton droit sur le graphique, cliquez sur Modifier le type du graphique, cliquez sur Zone, puis cliquez sur Barres empilées.
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.
Faites glisser le champ de Tendance du nombre de points : à partir de le groupe de mesures de Test à la zone de Valeurs .
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 :
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
Perspectives et groupes de mesures fournis dans le cube Analysis Services pour Team System