Analysieren und Erstellen von Berichten von Codeänderung und Codeabdeckung mit den Codeänderungs- und Laufabdeckungsperspektiven

Artikel
02/26/2013

Sie können über die Softwarequalität melden, indem Sie die Codeänderung verwenden und Abdeckungsperspektiven vom SQL Server Analysis Services-Cube für Visual Studio Team Foundation Server ausführen.Mit dieser Perspektiven verwenden, können Sie nur die Measures, die Dimensionen und Attribute anzeigen, die mit den Änderungen der Zeilen von Code und des Wertebereichs zugeordnet werden, auf denen hin Code in den Builds und in den Testläufen abgedeckt wird.

Diese Perspektiven basieren auf der relationalen Tabellen, die Sie verwenden können, um zu Codeänderungen und Abdeckung als Eigenschaft eines Builds, der Buildassemblys oder der-Plattform, des Testlaufs oder des Changesets zu melden.Weitere Informationen finden Sie unter Codeänderungstabellen und Ausführen von Abdeckungstabellen.

Mithilfe der Codeänderungsperspektive verwenden, können Sie Berichte erstellen, die die folgenden Fragen beantworten:

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 sind gesendet, und was sind die Details jeder Änderung?(beispielsweise, haben sie die Änderungen vornehmen, die Dateien geändert wurden und in welchem Datum die vorgenommene Änderung war)?

Mithilfe der Ausführungs-Abdeckungsperspektive verwenden, können Sie Berichte erstellen, die die folgenden Fragen beantworten:

Welche Assemblys verfügen über wenige Testabdeckung?
Welche Testläufe enthalten den meisten Code?
Welche Architekturen oder Build gibt haben die meisten Testabdeckung ein?

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, damit Sie nicht durch alle Dimensionen und Measuregruppen im gesamten Team System-Cube müssen.

In diesem Thema

Beispiel: Codeänderungs-Bericht
Codeänderungs-Measure
Ausführungs-Abdeckungs-Measure
Dimensionen und Attribute in der Codeänderungs-Perspektive, die Filterung unterstützen und Kategorisierung
Dimensionen und Attribute in der Ausführungs-Abdeckungs-Perspektive, die Filterung und Kategorisierung unterstützen
Erforderliche Aktivitäten zum Überwachen der Codeänderung und der Codeabdeckung

Beispiel: Codeänderungs-Bericht

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

Bericht über Codeänderung

Die Prozessvorlagen für Microsoft Solutions Framework (MSF) v5.0 stellen automatisch den Bericht Codeänderung in Excel.Weitere Informationen finden Sie unter Excel-Bericht Codeänderung.

Zurück nach oben

Pivot-Felder auswählen und Filtern

Pivotfelder für Bericht über Codeänderung

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

In Excel schließen Sie SQL Server an den Analysis Services-Cube für Visual Studio Team Foundation Server an, und fügen Sie einen PivotChart-Bericht ein.

Weitere Informationen finden Sie unter Erstellen eines Berichts in Microsoft Excel für Visual Studio ALM.
Klicken Sie mit der rechten Maustaste auf das Diagramm und wählen Sie dann Diagrammtyp ändern, Bereich, Gestapelte Fläche aus.
Für jeden Berichtsfilter öffnen Sie das Kontextmenü für jedes der folgenden Felder, geben Sie die Hierarchien, die Wochen oder andere relevanten Elemente an, und ziehen Sie dann das Feld das Bereich Berichtsfilter.
- Teamprojekthierarchie aus der Teamprojekt Dimension
- Work Item.Iteration Hierarchy aus der Arbeitsaufgabe Dimension
- Work Item.Area Hierarchy aus der Arbeitsaufgabe Dimension
- Jahr-Woche-Datum aus der Datum Dimension
In der Datum Dimension erweitern Sie Weitere Felder und ziehen Sie Datum, Woche oder Monat Felder mit dem Bereich Achsenfelder (Rubriken) auf Grundlage, wie präzise ein Bericht Sie generieren möchten.
Ziehen Sie Hinzugefügte Zeilen, Geänderte Zeilen und Gelöschte Zeilen Felder aus der Codeänderung Measuregruppe zum Bereich Werte.Sie müssen jedes Feld separat ziehen.

Zurück nach oben

Codeänderungs-Measure

Codeänderungsmeasure Bericht bestimmen, wie viel Änderung im Projekt auftritt.Im Allgemeinen weisen hohe Ebenen des Butterfasses Projektinstabilität an.Sie sollten hohes Maß an Butterfasses am Anfang eines Produktzyklus und, nachdem das Team viele Änderungen implementiert hat.Zum Ende einer Iteration oder eine Version, bevor Sie die Ebene des Butterfasses erwarten sollte tendenziell ab, das angibt, dass das Projekt stabiler ist.

Die folgende Tabelle beschreibt die Measures in der Codeänderungsmeasuregruppe.Mit dieser Measures verwenden, können Sie Berichte erstellen, die zeigen, wie viele Dateiversionen in Team Foundation-Versionskontrolle gespeichert werden und wie viel der Code geändert hat.Sie können Metriken durch Dateiverzeichnis, Build oder Teammitglied analysieren, das in Änderungen überprüfen, und Sie können bestimmen, wie diese Metriken im Zeitverlauf ändert.

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

Measure	Beschreibung
Codeänderungs-Anzahl	Die Häufigkeit, mit der das Team Dateien in der Versionskontrolle geändert hat.
Zeilen hinzugefügt	Die Anzahl von Codezeilen, die das Team in Dateien für die Dimensionen hinzufügen, die Sie angeben.
Zeilen gelöscht	Die Anzahl von Codezeilen, die das Team von den Dateien für die Dimensionen gelöscht, die Sie angeben.
Zeilen geändert	Die Anzahl von Codezeilen, die vom Team während des Zeitraums geändert, den Sie angeben.
Werden Gesamtes	Werden im Code, wie berechnet: [Zeilen hinzugefügt] + Zeilen gelöscht [] [] + Zeilen geändert.
Gesamte Zeilen	Die Anzahl von Zeilen im Teil der Dateipfadhierarchie, die Sie angeben.Sie müssen eine oder mehrere Builds auch angeben, um den Punkt oder die Punkte angeben, an denen diese Berechnung ausführen.Wenn Sie keine oder mehrere Builds 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 Die gesamten Zeilenmeasure können die OLAP-Abfrage ein Timeout verursachen.Wenn der Bericht zu lange dauert, um zu rendern, erwägen Sie, das Changeset, den Build, den Testlauf oder Datumsbereich zu verkürzen.

Zurück nach oben

Ausführungs-Abdeckungs-Measure

Die folgende Tabelle beschreibt die Measures in der Ausführungs-Abdeckungsmeasuregruppe.Mit dieser Measures verwenden, können Sie Berichte erstellen, die den Wertebereich anzeigen, in dem der Code durch Tests in einem Testlauf ausgeführt wurden.Informationen über ähnliche Metriken, die Sie für Builds erfassen können, finden Sie unter Analysieren und Erstellen von Berichten von Builddetails und Buildabdeckung mit der Buildperspektive.

Measure	Beschreibung
Run Coverage	Die Anzahl der Testläufe, denen Statistiken zur Codeabdeckung, das mit diesen zu.
Ausführungs-Abdeckungs-Blöcke abgedeckt	Die Anzahl von Blöcken die alle Tests in einer Ausführungsabdeckung.jedoch überschnitte Abdeckung möglicherweise über den Tests sich.
Ausführungs-Abdeckungs-Blöcke nicht abgedeckt	Die Anzahl von Blöcken, die nicht von allen Tests in einem Testlauf abgedeckt werden.jedoch überschnitte Abdeckung möglicherweise über den Tests sich.
Ausführungs-Abdeckungs-Zeilen abgedeckt	Die Anzahl von Zeilen die alle Tests in einer Ausführungsabdeckung.jedoch überschnitte Abdeckung möglicherweise über den Tests sich.
Ausführungs-Abdeckungs-Zeilen nicht abgedeckt	Die Anzahl von Zeilen, die nicht von allen Tests in einem Testlauf abgedeckt werden.jedoch überschnitte Abdeckung möglicherweise über den Tests sich.
Ausführungs-Abdeckungs-Zeilen teilweise abgedeckt	Die Anzahl von Zeilen, die in einer Abdeckung der Ausführung teilweise testet.jedoch überschnitte Abdeckung möglicherweise über den Tests sich.

Zurück nach oben

Dimensionen und Attribute in der Codeänderungs-Perspektive, die Filterung und Kategorisierung unterstützen

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

Dimension	Attribut	Beschreibung
Build	Builddefinitions-Name	Der Name, der der Builddefinition zugeordnet wird, für die ein Build ausgeführt wurde.
	Build-ID	Die Zahl, die zum Build zugewiesen wird.Bei jedem Start eine bestimmte Builddefinition ausgeführt wird, wird dieses Attribut von 1. erhöht.
	Buildname	Der Name oder der Ausdruck, die eindeutig einen Build identifiziert.Weitere Informationen finden Sie unter Arbeiten mit Buildnummern.
	Build-Startzeit	Das Datum und die Uhrzeit, als der Build gestartet hat.
	Typ "Teambuild"	Der Grund, warum der Build ausgeführt wurde.Buildtypen werden mit 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) (Eincheckvorgänge werden gesammelt, bis der vorherige Build abgeschlossen), abgegrenzter Eincheckvorgang und geplant.Weitere Informationen finden Sie unter Angeben der Buildtrigger und Gründe.
	Ablagespeicherort	Der URL (Uniform Resource Locator) für den abgeschlossenen Build.Eine URL gibt das Protokoll an, mit dem Webbrowser Internetressourcen suchen.Jedes URL enthält den Namen des Servers ein, auf dem die Details des Builds befinden.Sie können den Pfad zu einer Ressource auch einschließen.
Changeset der Versionskontrolle	Changeset ID	Die Zahl, die dem Changeset zugewiesen wird, das die Datei enthielt, ändert.
	Eingecheckt von	Der Benutzername des Teammitglieds, das in das Changeset eingecheckt hat.
	Beschreibung	Der Eincheckkommentar auf, der dem Changeset zugeordnet wird.
	Richtlinien-Überschreibungs-Kommentar	Der Kommentar, der bereitgestellt wird, wenn eine Richtlinie überschrieben wird.Wenn eine Richtlinie nicht mit diesem Changeset überschrieben wurde, ist dieses Feld NULL.
Versionskontrolldatei	Hierarchie der Versionskontrollen-File.File	Der vollständige Netzwerkpfad der Quelldatei.
	Erweiterung der Versionskontrollen-File.File	Die Erweiterung des Quelldateinamens
Arbeitsaufgabe	Arbeitsaufgabentyp und mehr	Weitere Informationen finden Sie unter Analysieren und Erstellen von Berichten von Arbeitsaufgaben- und Testfalldaten mithilfe der Arbeitsaufgabenperspektive.

Zurück nach oben

Dimensionen und Attribute in der Ausführungs-Abdeckungs-Perspektive, die Filterung und Kategorisierung unterstützen

Die folgende Tabelle beschreibt die Dimensionen und Attribute in der Ausführungs-Abdeckungsperspektive.Diese Attribute ergänzen die Teamprojekt und Datum gemeinsamen Dimensionen, die Arbeiten mit gemeinsamen Dimensionen weiter unten in diesem Thema beschrieben werden.Sie können die Measures auf jedem dieser Attribute aggregieren.

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 zum Verwalten von Builds und Tests weiter unten in diesem Thema.

Dimension	Attribut	Beschreibung
Assembly	Assembly	(Nur veröffentlichte Testergebnisse) der Name des Codes der Anwendung, die als Teil des Build getestet wird.Weitere Informationen finden Sie unter Ausführen von Testläufen im Buildprozess.
Build	Builddefinitions-Name	Der Name, der der Builddefinition zugeordnet wird, für die ein Build ausgeführt wurde.
	Build-ID	Die Zahl, die zum Build zugewiesen wird.Bei jedem Start eine bestimmte Builddefinition ausgeführt wird, wird Build-ID . um 1 erhöht.
	Buildname	Der Name oder der Ausdruck, die eindeutig einen Build identifiziert.Weitere Informationen finden Sie unter Arbeiten mit Buildnummern.
	Build-Startzeit	Das Datum und die Uhrzeit, als der Build gestartet hat.
	Typ "Teambuild"	Der Grund, warum der Build ausgeführt wurde.Buildtypen werden mit 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) (Eincheckvorgänge werden gesammelt, bis der vorherige Build abgeschlossen), abgegrenzter Eincheckvorgang und geplant.Weitere Informationen finden Sie unter Angeben der Buildtrigger und Gründe.
	Ablagespeicherort	Der 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 ein, auf dem die Ressource auf.Sie können den Pfad zu einer Ressource auch angeben.
Buildkonfiguration	Buildkonfiguration	(Nur veröffentlichte Testergebnisse) a-Name, der die Kategorie festlegt, einem Satz von abgeschlossenen Builds die zugewiesen wird, die als Teil eines Testlaufs veröffentlicht wurden.Beispielsweise können Sie eine Buildkonfiguration verwenden, um eine Betaversion oder eine definitive Version festzulegen.Weitere Informationen finden Sie unter Befehlszeilenoptionen zum Veröffentlichen von Testergebnissen.
Buildplattform	Buildplattform	(Nur veröffentlichte Testergebnisse) wurde der Name der Computer Plattform, für die ein aufeinander folgender (nicht Desktop) Build erstellt wurde und der deren als Teil eines Testlaufs veröffentlicht (beispielsweise, x86 oder Any CPU).Ein Beispiel für einen Bericht, der dieses Attribut verwendet, finden Sie unter Bericht "Buildzusammenfassung". Weitere Informationen finden Sie unter Befehlszeilenoptionen zum Veröffentlichen von Testergebnissen.
Testlauf	Schließen Sie Datums-Hierarchie bis auf Monat oder in Woche ab Erstellungsdatums-Hierarchie bis auf Monat oder in Woche	Datumsdimensionen, die auf dem Datum sind, als der Testlauf erstellt und beendet wurde.Weitere Informationen finden Sie unter Arbeiten mit freigegebenen Dimensionen im Analysis Services-Cube.

Zurück nach oben

Erforderliche Aktivitäten zum Überwachen der Codeänderung und der Codeabdeckung

Um Buildberichten zu erstellen die nützliche Daten enthalten, müssen Teammitglieder die folgenden Aktivitäten ausführen um Builds und Tests zu erreichen:

Konfigurieren Sie ein Buildsystem.Um Team Foundation Build zu verwenden, muss das Team ein Buildsystem installieren.

Weitere Informationen finden Sie unter Configure Your Build System.
Erstellen Sie Builddefinitionen.Das Team muss mindestens eine Builddefinition erstellen.Das Team kann mehrere Definitionen erstellen, von denen jede um Code für eine andere Plattform oder eine andere Konfiguration ausgeführt werden kann.

Weitere Informationen finden Sie unter Erstellen einer Builddefinition.
Empfohlenes () Ausführungsbuilds regelmäßig.Das Team kann Builds automatisch in Abständen ausführen, die sie oder nach jedem Einchecken angeben.Mithilfe des Zeitplantrigger verwendet, kann das Team Builds oder Uhrzeiten am selben Tag oder Tage automatisch gleichzeitig ausführen, die sie angeben.Weitere Informationen finden Sie unter Angeben der Buildtrigger und Gründe und Ausführen, Überwachen und Verwalten von Builds.
(Optional) Definieren Sie Tests, die als Teil des Build automatisch ausgeführt werden.Als Teil der Builddefinition kann das Team automatisierte Tests definieren, die als Teil des Build und die Auswirkungen von Codeänderungen zu analysieren auf den Tests ausgeführt werden.

Weitere Informationen finden Sie unter Ausführen von Testläufen im Buildprozess.

Konfigurieren Sie Tests zum Erfassen von Codeabdeckungsdaten.Damit Codeabdeckungsdaten im Bericht angezeigt werden, müssen Teammitglieder Tests zum Erfassen dieser Daten instrumentieren.

Wichtig
Um Daten zu Codeabdeckung gesammelt werden, muss das Team Visual Studio Premium oder Visual Studio Ultimate auf dem Computer mit dem Build-Agent installiert haben.Weitere Informationen finden Sie unter Bereitstellen und Konfigurieren eines Build-Agents.

Weitere Informationen finden Sie unter Konfigurieren von Codeabdeckung mit Testeinstellungen ist veraltet und How to: Gather Code-Coverage Data with Generic Tests.

Veröffentlichen Sie Tests.Als Teil des Build und der Testaktivitäten muss das Testteam Testergebnisse im Datenspeicher für Team Foundation Server veröffentlichen.

Weitere Informationen finden Sie unter Team Foundation Build-Aktivitäten und Befehlszeilenoptionen zum Veröffentlichen von Testergebnissen.