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.

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?)

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

• Beispiel: Bericht über Codeänderung

• Codeänderungsmeasures

• Laufabdeckungsmeasures

• Dimensionen und Attribute in der Codeänderungsperspektive, die die Filterung und Kategorisierung unterstützen

• Dimensionen und Attribute in der Laufabdeckungsperspektive, die die Filterung und Kategorisierung unterstützen

• Erforderliche Aktivitäten

Beispiel: Bericht über Codeänderung

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.

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.

Auswählen und Filtern von Pivotfeldern

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 von Excel-Berichten aus einer Arbeitsaufgabenabfrage.

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.

Codeänderungsmeasures

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

Laufabdeckungsmeasures

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.

Dimensionen und Attribute in der Codeänderungsperspektive, die die Filterung und Kategorisierung unterstützen

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.

Dimensionen und Attribute in der Laufabdeckungsperspektive, die die Filterung und Kategorisierung unterstützen

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

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.

Erforderliche Aktivitäten

Um Berichte mit Codeänderungs- und Codeabdeckungsdaten zu erstellen, sollten die Teammitglieder die Informationen in den folgenden Themen lesen:

• Ausführen von Testläufen im Buildprozess Bestimmen des Umfangs des zu testenden Codes mithilfe von Codeabdeckung

• Konfigurieren von Komponententests mithilfe einer .runsettings-Datei

Siehe auch

Konzepte

Excel-Bericht Codeänderung

Excel-Bericht Codeabdeckung

Codeänderungstabellen

Ausführen von Abdeckungstabellen

Im Analysis Services-Cube für Visual Studio verfügbare Perspektiven und Measuregruppen