(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. Weitere Informationen
Übersetzung
Original

Analysieren von und Berichten über Codeänderungen und Codeabdeckung mit Codeänderungs- und Laufabdeckungsperspektiven

Sie können Berichte zur Softwarequalität erstellen, indem Sie die Codeänderungs- und Laufabdeckungsperspektive auf dem SQL Server Analysis Services-Cube für Visual Studio Team Foundation Server verwenden. Durch die Verwendung dieser Perspektiven können Sie die Anzeige auf die Measures, Dimensionen und Attribute beschränken, die von den Änderungen an Codezeilen und von den Ausmaß, in dem Code in Builds und Testläufen abgedeckt wird, betroffen sind.

Diese Perspektiven basieren auf den relationalen Tabellen, mithilfe derer Sie Berichte zu Codeänderungen und zur Abdeckung als Eigenschaft des Builds, der Buildassembly oder ‑plattform, des Testlaufs oder des Changesets erstellen können. Weitere Informationen finden Sie unter Codeänderungstabellen und Ausführen von Abdeckungstabellen.

Measuregruppe für Codeänderungen

Mithilfe der Codeänderungsperspektive können Sie Berichte zum Beantworten der folgenden Fragen erstellen:

  • Wie viele Dateien mit einer bestimmten Dateinamenerweiterung wurden in einem bestimmten Build geändert?

  • Wie viele Codezeilen befinden sich für einen bestimmten Build in der Quelldatenbank?

  • Welche Changesets wurden übermittelt, und was sind die Details der einzelnen Änderungen? (Z. B.: Wer hat die Änderung vorgenommen, welche Dateien wurden geändert und wann sind die Änderung erfolgt?)

Measuregruppe für Codeabdeckung

Mithilfe der Laufabdeckungsperspektive können Sie Berichte zum Beantworten der folgenden Fragen erstellen:

  • Welche Assemblys verfügen über die geringste Testabdeckung?

  • Welche Testläufe decken den meisten Code ab?

  • Welche Architekturen oder Buildtypen haben die größte Testabdeckung?

Hinweis 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.

In diesem Thema

Mit einem PivotChart-Bericht in Excel können Sie einen Trendbericht erstellen, der die Codeänderung im Zeitverlauf anzeigt, ähnlich dem Bericht in der folgenden Abbildung.

Bericht über Codeänderung

Die Prozessvorlagen für Microsoft Solutions Framework (MSF) Agile und CMMI stellen den Codeänderungsbericht in Excel bereit. Weitere Informationen finden Sie unter Excel-Bericht Codeänderung.

ms244661.collapse_all(de-de,VS.120).gifAuswählen und Filtern von Pivotfeldern

Pivotfelder für Bericht über Codeänderung

Sie können einen Codeänderungsbericht erstellen, indem Sie die folgenden Schritte ausführen:

  1. Stellen Sie in Excel eine Verbindung mit dem SQL Server Analysis Services-Cube für Visual Studio Team Foundation Server her, und fügen Sie einen PivotChart-Bericht ein.

    Weitere Informationen finden Sie unter Erstellen eines Berichts in Microsoft Excel für Visual Studio ALM.

  2. Klicken Sie mit der rechten Maustaste auf das Diagramm, und wählen Sie dann Diagrammtyp ändern, Bereich, Gestapelte Fläche.

  3. Öffnen Sie für jeden Berichtsfilter das Kontextmenü für jedes der folgenden Felder, geben Sie die Hierarchien, Wochen oder andere relevante Elemente an, und ziehen Sie das Feld dann in den Bereich Berichtsfilter.

    • Teamprojekthierarchie aus der Teamprojekt-Dimension

    • Arbeitsaufgabe.Iterationshierarchie aus der Dimension Arbeitsaufgabe

    • Arbeitsaufgabe.Bereichshierarchie aus der Dimension Arbeitsaufgabe

    • Jahr-Woche-Datum aus der Datum-Dimension

  4. Erweitern Sie in der Datum-Dimension Weitere Felder, und ziehen Sie die Felder Datum, Woche oder Monat in den Bereich Achsenfelder (Rubriken), um anzugeben, wie präzise ein generierter Bericht sein soll.

  5. Ziehen Sie Felder Hinzugefügte Zeilen, Geänderte Zeilen und Gelöschte Zeilen aus der Measuregruppe Codeänderung zum Bereich Werte. Sie müssen jedes Feld separat ziehen.

Zurück nach oben

Codeänderungsmeasures bestimmen, wie viele Änderungen im Projekt auftreten. Im Allgemeinen weisen viele Codeänderungen auf ein instabiles Projekt hin. Zu Beginn eines Produktzyklus und nachdem das Team eine Reihe von Änderungen implementiert hat, treten erwartungsgemäß viele Codeänderungen auf. Zum Ende einer Iteration oder vor einer Veröffentlichung sollte die Zahl der Codeänderungen jedoch sinken. Dies zeigt an, dass das Projekt stabiler und ausgereifter ist.

In der folgenden Tabelle sind die Measures beschrieben, die die Codeänderungs-Measuregruppe umfasst. Durch Verwendung dieser Measures können Sie Berichte erstellen, die zeigen, wie viele Dateiversionen in der Team Foundation-Versionskontrolle gespeichert sind und wie stark sich der Code geändert hat. Sie können Metriken nach Dateiverzeichnis oder nach Build analysieren, oder nach dem Teammitglied, das die Änderungen eingecheckt hat, und Sie können feststellen, wie sich diese Metriken im Zeitverlauf ändern.

Informationen über ähnliche Metriken, die Sie für Builds erfassen können, finden Sie unter Analysieren von und Berichten über Builddetails und Buildabdeckung mit der Buildperspektive.

Measure

Beschreibung

Codeänderung (Anzahl)

Wie häufig das Team Dateien in der Versionskontrolle geändert hat.

Hinzugefügte Zeilen

Die Anzahl der Codezeilen, die das Team in Dateien für die angegebenen Dimensionen hinzugefügt hat.

Gelöschte Zeilen

Die Anzahl der Codezeilen, die das Team aus Dateien für die angegebenen Dimensionen gelöscht hat.

Geänderte Zeilen

Die Anzahl der Codezeilen, die das Team während des angegebenen Zeitraums geändert hat.

Gesamte Änderungen

Änderungen am Code, berechnet als: [Hinzugefügte Zeilen] + [Gelöschte Zeilen] + [Geänderte Zeilen].

Gesamte Zeilen

Die Anzahl der Zeilen im angegebenen Bereich der Dateipfadhierarchie. Sie müssen außerdem einen oder mehrere Builds angeben, um den Punkt oder die Punkte zu spezifizieren, an dem oder denen diese Berechnung ausgeführt werden soll. Wenn Sie keinen Build angeben, wird NULL zurückgegeben. Die Anzahl der Zeilen wird berechnet, indem die hinzugefügten und gelöschten Zeilen, durch die eine bestimmte Kombination aus Buildtyp und Betriebssystem entstanden ist, aggregiert werden.

Tipp Tipp
Die Measure "Gesamte Zeilen" kann ein Timeout bei der OLAP-Abfrage verursachen. Wenn die Berichtswiedergabe zu lange dauert, sollten Sie erwägen, das Changeset, den Build, den Testlauf oder den Datumsbereich zu verkleinern.

Zurück nach oben

In der folgenden Tabelle sind die Measures beschrieben, die die Laufabdeckungs-Measuregruppe umfasst. Durch Verwendung dieser Maßeinheit können Sie Berichte erstellen, die zeigen, in welchem Ausmaß der Code durch Tests in einem Testlauf abgedeckt wurde. Informationen über ähnliche Metriken, die Sie für Builds erfassen können, finden Sie unter Analysieren von und Berichten über Builddetails und Buildabdeckung mit der Buildperspektive.

Measure

Beschreibung

Run Coverage

Die Anzahl der Testläufe, denen Statistiken zur Codeabdeckung zugeordnet sind.

Abgedeckte Laufabdeckungsblöcke

Die Anzahl der Blöcke, die von allen Tests in einer Ausführung abgedeckt werden. Die Abdeckung kann sich jedoch zwischen den Tests überschneiden.

Nicht abgedeckte Laufabdeckungsblöcke

Die Anzahl der Blöcke, die von den Tests in einem Testlauf nicht abgedeckt werden. Die Abdeckung kann sich jedoch zwischen den Tests überschneiden.

Abgedeckte Laufabdeckungszeilen

Die Anzahl der Zeilen, die von allen Tests in einer Ausführung abgedeckt werden. Die Abdeckung kann sich jedoch zwischen den Tests überschneiden.

Nicht abgedeckte Laufabdeckungszeilen

Die Anzahl der Zeilen, die von den Tests in einem Testlauf nicht abgedeckt werden. Die Abdeckung kann sich jedoch zwischen den Tests überschneiden.

Teilweise abgedeckte Laufabdeckungszeilen

Die Anzahl der Zeilen, die von den Tests in einer Ausführung teilweise abgedeckt werden. Die Abdeckung kann sich jedoch zwischen den Tests überschneiden.

Zurück nach oben

Die folgende Tabelle beschreibt die Dimensionen und Attribute in der Codeänderungsperspektive. Diese Attribute ergänzen die gemeinsamen Teamprojekt- und Datum-Dimensionen, die auf der Seite zum Arbeiten mit gemeinsamen Dimensionen beschrieben werden. Sie können die Measures entlang jedem dieser Attribute aggregieren.

Dimension

Attribut

Beschreibung

Build

Builddefinitionsname

Der Name, der der Builddefinition zugewiesen ist, für die ein Build ausgeführt wurde.

Build-ID

Die Nummer, die dem Build zugewiesen wird. Bei jeder Ausführung einer bestimmten Builddefinition wird dieses Attribut 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 Typen von Builds: 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

Die URL (Uniform Resource Locator) für den abgeschlossenen Build. Eine URL gibt das Protokoll an, mit dem Webbrowser Internetressourcen suchen. Jede URL enthält den Namen des Servers, auf dem sich die Details des Builds befinden. Sie können auch den Pfad zu einer Ressource einschließen.

Changeset der Versionskontrolle

Changeset-ID

Die Zahl, die dem Changeset zugewiesen ist, das die Dateiänderungen enthielt.

Eingecheckt von

Der Benutzername des Teammitglieds, welches das Changeset eingecheckt hat.

Beschreibung

Der Eincheckkommentar, der dem Changeset zugeordnet wird.

Kommentar zum Überschreiben der Richtlinie

Der Kommentar, der bereitgestellt wird, wenn eine Richtlinie überschrieben wird. Wenn mit diesem Changeset keine Richtlinie überschrieben wurde, ist dieses Feld NULL.

Versionskontrolldatei

Versionskontrolldatei.Dateihierarchie

Der vollständige Netzwerkpfad der Quelldatei.

Versionskontrolldatei.Dateierweiterung

Die Erweiterung des Quelldateinamens

Arbeitsaufgabe

Arbeitsaufgabentyp und mehr

Weitere Informationen finden Sie unter Analysieren und Erstellen von Berichten über Arbeitsaufgaben- und Testfalldaten mithilfe der Arbeitsaufgabenperspektive.

Zurück nach oben

Die folgende Tabelle beschreibt die Dimensionen und Attribute in der Laufabdeckungsperspektive. Diese Attribute ergänzen die gemeinsamen Teamprojekt- und Datum-Dimensionen, die im Abschnitt zum Arbeiten mit gemeinsamen Dimensionen weiter unten in diesem Thema beschrieben werden. Sie können die Measures entlang jedem dieser Attribute aggregieren.

Hinweis Hinweis

Bevor Sie die Assembly- oder Buildkonfiguration-Attribute verwenden können, muss das Testteam sie angeben und die Testergebnisse im Datenspeicher für Team Foundation Server veröffentlichen. Weitere Informationen finden Sie unter Erforderliche Aktivitäten weiter unten in diesem Thema.

Dimension

Attribut

Beschreibung

Assembly

Assembly

(Nur veröffentlichte Testergebnisse) Der Name des Codes der Anwendung, die als Teil des Builds getestet wird. Weitere Informationen finden Sie unter Ausführen von Testläufen im Buildprozess.

Build

Builddefinitionsname

Der Name, der der Builddefinition zugewiesen ist, für die ein Build ausgeführt wurde.

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

Datum und 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 Typen von Builds: 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

Die URL (Uniform Resource Locator) für den abgeschlossenen Build. 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 angeben.

Buildkonfiguration

Buildkonfiguration

(Nur veröffentlichte Testergebnisse) Ein Name, der die Kategorie kennzeichnet, die einem Satz von abgeschlossenen Builds zugewiesen ist, 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

(Nur veröffentlichte Testergebnisse) Der Name der Plattform, für die ein End-to-End-Build (kein Desktopbuild) erstellt wurde und der als Teil eines Testlaufs veröffentlicht wurde (beispielsweise x86 oder Any CPU). Ein Beispiel für einen Bericht, in dem dieses Attribut verwendet wird, finden Sie unter Bericht "Buildzusammenfassung".

Testlauf

Abschlussdatumshierarchie nach Monat bzw. nach Woche

Erstellungsdatumshierarchie nach Monat bzw. nach Woche

Datumsdimensionen, die auf dem Datum basieren, an dem der Testlauf erstellt und beendet wurde. Weitere Informationen finden Sie unter Freigegebene Dimensionen im Analysis Services-Cube.

Zurück nach oben

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft