Analysieren von und Berichten über Testergebnissen mit der Testperspektive in der Analysis Services-Datenbank für Visual Studio ALM
Mithilfe der Testperspektive im SQL Server Analysis Services-Cube für Visual Studio Team Foundation Server können Sie nur die Measures, Dimensionen und Attribute anzeigen, die sich auf die Erstellung von Berichten zu Testergebnissen und Testläufen beziehen. Mit diesen Measures können Sie z. B. die Gesamtqualität der einzelnen Builds, die Tests, auf die sich ein bestimmter Build auswirkte, und die Anzahl der ausgeführten Testfälle bestimmen. Sie können auch Fragen zu Änderungen bei den Ergebnissen beantworten.
Die Testmeasuregruppe basiert auf der relationalen Tabelle der Testergebnisse, die die Erstellung von Berichten zu Testergebnissen als Eigenschaft der Tests oder als unabhängiges Ergebnis ermöglicht. Weitere Informationen finden Sie unter Testergebnistabellen.
Mithilfe der Testperspektive können Sie Berichte erstellen, die die folgenden Fragen beantworten: Statusberichte:
Trendberichte:
Hinweis Wenn für das Data Warehouse für Visual Studio Application Lifecycle Management (ALM) SQL Server Enterprise Edition verwendet wird, enthält die Liste der Cubes Team System und einen Perspektivensatz.Die Perspektiven bieten eine fokussierte Ansicht der Daten, sodass Sie nicht mehr im gesamten Team System-Cube durch Dimensionen und Measuregruppen navigieren müssen. |
Um viele Testmeasures und Dimensionsattribute verwenden zu können, muss das Testteam die Testergebnisse im Datenspeicher für Team Foundation Server veröffentlichen. Weitere Informationen finden Sie unter Erforderliche Aktivitäten zum Verwalten von Tests und Builds weiter unten in diesem Thema.
In diesem Thema
Beispiel: Statusbericht für das Testen von User Storys
Testmeasures
Dimensionen und Attribute in der Testperspektive, die die Filterung und Kategorisierung unterstützen
Build, Buildkonfiguration und Buildplattformdimensionen
Testfall, Testkonfiguration, Testplan und Testauflistungsdimensionen
Testergebnisdimension
Testausführungsdimension
Dimensionen für Arbeitsaufgaben und verknüpfte Arbeitsaufgaben
Erforderliche Aktivitäten
Beispiel: Statusbericht für das Testen von User Storys
Mithilfe der PivotTable- und PivotChart-Berichte in Excel können Sie einen Statusbericht erstellen, der den Teststatus für User Stories anzeigt, ähnlich dem Bericht in der folgenden Abbildung.
Die Prozessvorlagen für Microsoft Solutions Framework (MSF) Agile und CMMI enthalten den Excel-Bericht Teststatus des Benutzertextabschnitts (Agile) bzw. den Excel-Bericht "Status des Anforderungstests" (CMMI) in Excel.
Angeben und Filtern von Pivotfeldern
Durch Ausführen der folgenden Schritte können Sie einen Statusbericht für das Testen von User Stories erstellen:
Stellen Sie in Excel eine Verbindung mit dem Analysis Services-Cube für Team Foundation Server her, und fügen Sie dann einen PivotChart-Bericht ein.
Weitere Informationen finden Sie unter Erstellen von Excel-Berichten aus einer Arbeitsaufgabenabfrage.
Klicken Sie mit der rechten Maustaste auf das Diagramm, und wählen Sie dann Diagrammtyp ändern, Bereich, Gestapelte Balken.
Klicken Sie für jeden Berichtsfilter mit der rechten Maustaste auf jedes der folgenden Felder, geben Sie die Hierarchien oder relevanten Elemente an, und ziehen Sie das Feld dann in den Bereich Berichtsfilter.
Teamprojekthierarchie aus der Teamprojekt-Dimension
Bereichspfad aus der Dimension Teamprojekt
Iterationspfad aus der Dimension Testfall
Arbeitsaufgabentyp aus der Dimension Arbeitsaufgabe (verknüpft)
Geben Sie den Typ als User Story, Anforderung oder anderen Arbeitsaufgabentyp an, mit dem Testfälle verknüpft sind, für die Sie einen Bericht erstellen möchten.
Ziehen Sie das Feld Punktanzahl (Trend) unter der Measuregruppe Test in den Bereich Werte.
Ziehen Sie das Feld Ergebnis unter der Dimension Testergebnis in den Bereich Spaltenbezeichnungen.
Testmeasures
In der folgenden Tabelle sind die Measures beschrieben, die die Testmeasuregruppe umfasst. Sie können Testergebnisse anhand des Aggregats von Testergebnissen und des Ergebnisses für einen bestimmten Build oder anhand des geänderten Ergebnisses für ein Testergebnis analysieren.
Measure |
Beschreibung |
---|---|
Anzahl der Buildergebnisse (Trend) |
Zählt die neueste Version jedes Ergebnisses in einem bestimmten Build. Ein Beispiel für einen Bericht, in dem dieses Measure verwendet wird, finden Sie unter Excel-Bericht "Buildqualität". |
Punktanzahl (Trend) |
Anzahl der aktuellen Version der einzelnen Testergebnisse in einem bestimmten Build. Wenn ein Test mehrmals für einen Build ausgeführt wird, zählt "Punktanzahl (Trend)" das neueste Ergebnis für den Test mit diesem Build. Falls ein Testfall nicht im Build enthalten ist, wird er als "Nie ausgeführt" gezählt. Mit diesem Measure können Sie ermitteln, bei welchen Tests oder bei wie vielen Tests im aktuellen Build ein Fehler auftritt. |
Ergebnisanzahl |
Zählt die neueste Version jedes Testergebnisses. Verwenden Sie dieses Measure, wenn Sie die Gesamtanzahl von Tests ermitteln möchten. Ein Beispiel für einen Bericht, in dem dieses Measure verwendet wird, finden Sie unter Bericht "Buildqualitätsindikatoren". |
Anzahl der Ergebnisübergänge |
Zählt alle Ergebnisse, deren Ergebnis sich in einem bestimmten Build geändert hat. Mit diesem Measure können Sie ermitteln, welche Tests von einem bestimmten Build betroffen waren. |
Anzahl der Testfälle |
Die Anzahl der Testfälle. Mit diesem Measure können Sie ermitteln, wie viele Testfälle für einen bestimmten Testlauf oder Build ausgeführt wurden. |
Dimensionen und Attribute in der Testperspektive, die die Filterung und Kategorisierung unterstützen
Mit den in diesem Abschnitt beschriebenen Attributen können Sie ein Measure aggregieren, einen Bericht filtern oder eine Berichtsachse angeben. Diese Attribute ergänzen die gemeinsamen Teamprojekt- und Datum-Dimensionen, die auf der Seite zum Arbeiten mit gemeinsamen Dimensionen beschrieben werden.
Build, Buildkonfiguration und Buildplattformdimensionen
Sie können Testberichte nach Builddefinition, Buildkonfiguration oder Buildplattform filtern, indem Sie die in der folgenden Tabelle beschriebenen Attribute verwenden.
Dimension |
Attribut |
Beschreibung |
---|---|---|
Build |
Builddefinitionsname |
Der Name, der der Builddefinition zugewiesen wird, für die ein Build ausgeführt wurde. Ein Beispiel für einen Bericht, in dem dieses Attribut verwendet wird, finden Sie unter Excel-Bericht "Buildqualität". |
Build-ID |
Die Nummer, die dem Build zugewiesen wird. Bei jeder Ausführung einer bestimmten Builddefinition wird die Build-ID um 1 erhöht. |
|
Buildname |
Der Name oder der Ausdruck, der einen Build eindeutig identifiziert. Weitere Informationen finden Sie unter Verwenden von Buildnummern, um abgeschlossene Builds mit aussagekräftigen Namen zu versehen. |
|
Buildstartzeit |
Das Datum und die Uhrzeit des gestarteten Buildvorgangs. |
|
Buildtyp |
Der Grund, warum der Build ausgeführt wurde. Buildtypen werden dem Trigger zugeordnet, der für den Build definiert wurde. Team Foundation Server unterstützt die folgenden Buildtypen: manuell, fortlaufend (durch Eincheckvorgänge ausgelöst), parallel (Eincheckvorgänge werden gesammelt, bis der vorherige Build abgeschlossen ist), abgegrenzter Eincheckvorgang und geplant. Weitere Informationen finden Sie unter Angeben der Buildtrigger und -gründe. |
|
Ablageort |
Der Ablageordner, der für den Build definiert ist und der als URL (Uniform Resource Locator) angegeben wird. Eine URL gibt das Protokoll an, mit dem Webbrowser Internetressourcen suchen. Die URL enthält auch den Namen des Servers, auf dem sich die Ressource befindet. Sie können auch den Pfad zu einer Ressource einschließen. Weitere Informationen finden Sie unter Auswählen eines Stagingortes und Einrichten eines Ablageordners. |
|
Buildkonfiguration |
Buildkonfiguration |
(Nur veröffentlichte Testergebnisse) Ein Name, der die Kategorie von Builds kennzeichnet, die einem Satz von abgeschlossenen Builds zugewiesen sind, die als Teil eines Testlaufs veröffentlicht wurden. Eine Buildkonfiguration kann beispielsweise verwendet werden, um eine Betaversion oder eine endgültige Version zu kennzeichnen. |
Buildplattform |
Buildplattform |
Der Name der Computerplattform, für die ein End-to-End-Build (kein Desktopbuild) erstellt wurde (beispielsweise x86 oder Any CPU). Weitere Informationen finden Sie unter Verwenden der Standardvorlage für Ihren Buildprozess. |
Testfall, Testkonfiguration, Testplan und Testauflistungsdimensionen
Die Dimensionen für Testfälle, Testkonfigurationen, Testpläne und Testauflistungen entsprechen den Optionen zum Organisieren, Konfigurieren, Automatisieren und Ausführen von Tests mit Microsoft Test Manager von Visual Studio 2010 Ultimate oder Visual Studio Test Professional.
Der Testfall entspricht einem Arbeitsaufgabentyp, mit dem das Testteam manuelle und automatisierte Tests definiert, die Ihr Team mit Microsoft Test Manager ausführen und verwalten kann. Ein Testplan besteht aus Testkonfigurationen und Testauflistungen. Eine Testkonfiguration definiert die Software oder Hardware, auf der die Tests ausgeführt werden sollen. Eine Testauflistung definiert eine Hierarchie innerhalb des Plans, sodass Sie Testfälle gruppieren können.
Weitere Informationen finden Sie unter Testen der Anwendung.
Dimension |
Attribut |
Beschreibung |
---|---|---|
Testfall |
Bereichshierarchie und mehr |
Die Dimensionen für Arbeitsaufgaben und Testfälle enthalten alle Attribute in Bezug auf Arbeitsaufgaben, z. B. Zustand, Arbeitsaufgabentyp und Arbeitsaufgaben-ID. Informationen zur Struktur der Testfalldimension finden Sie unter Analysieren und Erstellen von Berichten über Arbeitsaufgaben- und Testfalldaten mithilfe der Arbeitsaufgabenperspektive. Eine Beschreibung der einzelnen Attribute finden Sie unter Arbeitsaufgabenfeld-Verweis für Visual Studio ALM. Informationen zum Arbeiten mit Datums-, Bereichs- und Iterationshierarchien finden Sie unter Freigegebene Dimensionen im Analysis Services-Cube. Diese Measuregruppe enthält zusätzliche Attribute, wenn benutzerdefinierte Felder in der Definition eines Arbeitsaufgabentyps Dimension als berichtsfähiges Attribut angeben. Weitere Informationen zur Verwendung des optionalen reportable-Attributs und dessen Werte finden Sie unter Hinzufügen und Ändern von Arbeitsaufgabenfeldern zum Unterstützen von Berichten. |
Testkonfiguration |
Konfigurations-ID und Konfigurationsname |
Die vom System zugewiesene Nummer und der Name einer Testkonfiguration. |
Testplan |
Bereichshierarchie, Bereichspfad, Iterationshierarchie und Iterationspfad |
Der Produktbereich und der Meilenstein, die dem Testplan zugewiesen sind. Weitere Informationen finden Sie unter Analysieren und Erstellen von Berichten über Arbeitsaufgaben- und Testfalldaten mithilfe der Arbeitsaufgabenperspektive. |
Enddatumshierarchie nach Monat bzw. nach Woche Startdatumshierarchie nach Monat bzw. nach Woche |
Optionale Werte, die der Besitzer eines Testplans dem Testplan zuweisen kann. Sie stellen das Datum dar, an dem der Testplan beginnen soll, und das Datum, an dem er enden soll. Weitere Informationen zum Arbeiten mit Datumshierarchien finden Sie unter Freigegebene Dimensionen im Analysis Services-Cube. |
|
Testplan-ID und Testplanname |
Die vom System zugewiesene Nummer und der Name, den der Testplanbesitzer zuweist. |
|
Testplanbesitzer |
Der Benutzername des Testteammitglieds, das den Testplan erstellt hat oder diesem derzeit als Besitzer zugewiesen ist. |
|
Testplan-ID und Zustand |
Die vom System zugewiesene Nummer und der Name des Zustands des Testplans. Inaktiv gibt beispielsweise an, dass der Testplan definiert wird, und Aktiv gibt an, dass der Testplan überprüft und ausgeführt werden kann. |
|
Testauflistung |
Testsammlungshierarchie |
Stellt einen Mechanismus zum Angeben mehrerer Filter auf Grundlage von Projektauflistung, Teamprojekt und Testauflistung bereit. |
Auflistungspfad |
Entspricht der Hierarchie von Testauflistungen, die für alle Teamprojekte in allen Teamprojektauflistungen konfiguriert sind. |
Testergebnisdimension
In der folgenden Tabelle sind alle Dimensionen und Attribute aufgeführt, die für die Testmeasures im Cube spezifisch sind. Bevor Sie Berichte zu Fehlertyp oder Auflösung erstellen können, muss das Testteam diese Informationen im Rahmen der Testaktivitäten eingeben.
Attribut |
Beschreibung |
---|---|
Fehlertyp und Fehlertyp-ID |
Entspricht einem der folgenden Gründe, warum bei einem Test ein Fehler aufgetreten ist: Keine, Bekanntes Problem, Neues Problem oder Regression. Microsoft Test Manager weist jedem Grund automatisch eine Nummer oder eine ID zu. Das Testteam kann bei Bedarf jedem Test, bei dem ein Fehler aufgetreten ist, einen Fehlertyp zuweisen. Hinweis Sie können keine Fehlertypen hinzufügen und diese nicht ändern. Ein Beispiel eines Trendberichts, der das Ergebnis von Testergebnissen auf Grundlage des Fehlertyp anzeigt, finden Sie unter Excel-Bericht Fehleranalyse. |
Ergebnis und Ergebnis-ID |
Das Ergebnis des Tests (z. B. Erfolgreich, Fehler oder Nicht eindeutig). Ein Beispiel eines Trendberichts, der das Ergebnis von Testplänen und Testkonfigurationen anzeigt, finden Sie unter Bericht "Testplanstatus". |
Bereitschaftszustand und Bereitschaftszustands-ID |
Der Zustand eines bestimmten Tests in einem Testlauf. Gültige Werte sind Abgeschlossen, InProgress, Keine, NotReady und Bereit. |
Auflösungszustand |
(Optional) Der Name der Auflösung, mit dem ein Tester die Ursache eines fehlerhaften Tests identifiziert. Standardmäßig verfügen alle MSF-Prozessvorlagen über die folgenden Auflösungszustände: Untersuchung erforderlich, Testproblem, Produktproblem und Konfigurationsproblem. Das Testteam kann bei Bedarf jedem Test, bei dem ein Fehler aufgetreten ist, einen Auflösungszustand zuweisen. Hinweis Mit dem Befehlszeilentool tcm können Sie diese Zustände ändern oder Zustände hinzufügen.Siehe Anpassen und Verwalten der Testerfahrung [tcm und Microsoft Test Manager]. |
Testergebnis ausgeführt von |
Der Name des Benutzers oder des Kontos, unter dem der Test ausgeführt wurde. Ein Beispiel für einen Bericht, in dem dieses Attribut verwendet wird, finden Sie unter Excel-Bericht "Produktivität des Testteams". |
Testergebnisbesitzer |
Der Name des Benutzers oder des Kontos, der bzw. das als Besitzer des Testergebnisses zugewiesen ist. Die Zuweisung entspricht dem Wert, der mithilfe des tcm /resultowner-Schalters festgelegt wird. |
Testergebnispriorität |
Die Priorität eines bestimmten Tests in einem Testlauf. |
Testausführungsdimension
In der folgenden Tabelle werden die Attribute beschrieben, die für die Testlaufdimension definiert sind. Viele dieser Attribute entsprechen Parametern, die das Testteam beim Ausführen von Tests angibt.
Attribut |
Beschreibung |
---|---|
Abschlussdatum, Erstellungsdatum, Erstellungsdatum, Startdatumshierarchie nach Monat bzw. nach Woche |
Datum, an dem der Testlauf erstellt, abgeschlossen bzw. gestartet wurde. Sie können diese Attribute verwenden, um einen Bericht zu filtern oder zu strukturieren. Weitere Informationen finden Sie unter Freigegebene Dimensionen im Analysis Services-Cube. |
Ist automatisiert |
Flag, das angibt, dass der Testlauf einen oder mehrere automatisierte Tests enthält. Ein Beispiel für einen Bericht, in dem dieses Attribut verwendet wird, finden Sie unter Excel-Bericht "Buildqualität". |
Ist Ausführung der Buildüberprüfung |
Flag, das angibt, ob der Testlauf Buildüberprüfungstests enthält, mit denen die grundlegenden Funktionen des Builds überprüft werden. Dieses Flag entspricht dem tcm /buildverification-Schalter. Ein Beispiel für einen Bericht, in dem dieses Attribut verwendet wird, finden Sie unter Excel-Bericht "Buildqualität". |
Testlauf-ID |
Die Nummer, die dem Testlauf vom System zugewiesen wurde. |
Besitzer des Testlaufs |
Entspricht dem Besitzer, der dem Testlauf zugewiesen ist, den das Testteam erstellt oder veröffentlicht hat. Entspricht dem tcm /owner-Schalter. |
Testlaufzustand und Testlaufzustands-ID |
Name oder Nummer, der bzw. die dem Zustand eines Testlaufs zugewiesen ist (z. B. Abgebrochen, Abgeschlossen, In Bearbeitung, Nicht gestartet oder Unbekannt). |
Testlauftitel |
Entspricht dem Titel, der dem Testlauf zugewiesen ist, den das Testteam erstellt oder veröffentlicht hat. Entspricht dem tcm /title-Schalter. |
Dimensionen für Arbeitsaufgaben und verknüpfte Arbeitsaufgaben
Sie können Testfälle mit anderen Arbeitsaufgaben wie User Stories, Anforderungen und Fehlern verknüpfen. Mithilfe der Dimension für verknüpfte Arbeitsaufgaben können Sie einen Bericht erstellen, der Testergebnisse bereitstellt, die sich auf die verknüpften Arbeitsaufgaben beziehen. Der Statusbericht für das Testen von User Stories, der weiter oben in diesem Thema beschrieben wurde, bietet ein Beispiel für die Verwendung der verknüpften Arbeitsaufgabe.
Eine Beschreibung der einzelnen Attribute finden Sie unter Arbeitsaufgabenfeld-Verweis für Visual Studio ALM.
Erforderliche Aktivitäten
Zum Erstellen von Berichten mit nützlichen Daten zu Tests und Testergebnissen sollten die Teammitglieder die Informationen in den folgenden Themen lesen:
Siehe auch
Konzepte
Im Analysis Services-Cube für Visual Studio verfügbare Perspektiven und Measuregruppen