Bericht "Buildqualitätsindikatoren"

Im Bericht "Buildqualitätsindikatoren" werden Testabdeckungs-, Codeänderungs- und Fehlerzahlen für eine angegebene Builddefinition angezeigt. Mithilfe dieses Berichts können Sie feststellen, wie weit Teile des Codes von der Veröffentlichungsqualität entfernt sind.

Im Idealfall führen Testraten, Fehler und Codeänderung zum gleichen Bild, dies ist jedoch nicht oft der Fall. Wenn Sie eine Diskrepanz feststellen, können Sie anhand des Berichts "Buildqualitätsindikatoren" die Details eines bestimmten Builds und einer Datenreihe untersuchen. Da in diesem Bericht Testergebnisse, die Codeabdeckung aus Tests, Codeänderungen und Fehler kombiniert werden, können Sie die Ergebnisse aus vielen Perspektiven betrachten.

Weitere Informationen zum Abrufen, Aktualisieren oder Verwalten von Berichten finden Sie unter Berichte (SQL Server Reporting Services).

Erforderliche Berechtigungen

Um den Bericht anzuzeigen, müssen Sie einer Gruppe zugewiesen sein oder zu einer Gruppe gehören, der die Rolle Browser in Reporting Services zugewiesen wurde. Weitere Informationen finden Sie unter Hinzufügen von Benutzern zu Teamprojekten.

Daten im Bericht

Die im Bericht "Buildqualitätsindikatoren" angezeigten Daten werden aus dem Data Warehouse abgeleitet. Auf der x-Achse werden basierend auf den Filtern, die Sie für die Plattform, Konfiguration und Builddefinition festgelegt haben, die spezifischen im Bericht enthaltenen Builds aufgeführt.

Jeder vertikale Balken stellt einen Satz von Daten dar, die aus einem oder mehreren Builds abgeleitet wurden. In der Codegrößenvariante des Berichts stellt die Länge jedes vertikalen Balkens die Größe des in die CodeBase eingecheckten Codes dar. Die Balken werden entsprechend der Höhe des Diagramms skaliert. Manuelle Tests können jederzeit nach dem Buildvorgang ausgeführt werden und werden diesem Build zugeordnet. Tests, die noch nicht ausgeführt wurden, werden als "nicht eindeutige Tests" gezählt.

Die folgende Abbildung zeigt ein Beispiel für den Bericht "Buildqualitätsindikatoren".

In der folgenden Tabelle werden die Informationen beschrieben, die für die einzelnen Qualitätsindikatoren im Bericht angezeigt werden:

Sie können den Bericht wie folgt filtern:

• Ändern Sie den Bereich der x-Achse, indem Sie die Anzahl von Builds und das Enddatum für den Bericht angeben. Das Datum des ersten angezeigten Builds hängt von der Häufigkeit der Buildvorgänge ab.

• Filtern Sie den im Bericht angezeigten Satz von Builds, indem Sie die in den Bericht einzuschließende Plattform, Konfiguration und Builddefinition angeben. Die Parameter müssen in dieser Reihenfolge festgelegt werden, da die verfügbaren Werte für die Builddefinition von der Plattform und Konfiguration abhängen.

• Filtern Sie die im Bericht gezählten Fehler, indem Sie die einzuschließenden Produktbereiche angeben. Dieser Filter hat keinen Einfluss auf die auf der x-Achse angezeigten Builds, die Codeänderung, die Codeabdeckung oder die Testergebnisse.

Weitere Informationen finden Sie unter Filtern des Berichts weiter unten in diesem Thema.

Erforderliche Test- und Buildverwaltungsaktivitäten

Damit der Bericht "Buildqualitätsindikatoren" hilfreich ist und alle verfügbaren Qualitätsindikatoren dargestellt werden, müssen Teammitglieder die folgenden Aktivitäten zum Verwalten von Tests und Builds ausführen:

• Konfigurieren Sie ein Buildsystem. Für die Verwendung von Team Foundation Build muss ein Buildsystem eingerichtet werden.

  Weitere Informationen finden Sie unter Konfigurieren und Verwalten des Buildsystems.

• Erstellen Sie Builddefinitionen. Sie können eine Reihe von Builddefinitionen erstellen, von denen jede ausgeführt werden kann, um Code für eine andere Plattform zu erzeugen. Zudem können Sie jeden Build für eine andere Konfiguration ausführen.

  Weitere Informationen finden Sie unter Definieren des Buildprozesses.

• Definieren Sie Tests, die automatisch als Teil des Builds ausgeführt werden. Sie können im Rahmen der Builddefinition Tests definieren, die als Teil des Builds ausgeführt werden oder einen Fehler auslösen sollen, wenn die Tests fehlschlagen.

  Weitere Informationen finden Sie unter Verwenden der Standardvorlage für Ihren Buildprozess.

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

• Regelmäßiges Ausführen von Builds. Sie können Builds in festgelegten Intervallen oder nach jedem Einchecken ausführen. Mit dem Zeitplantrigger können regelmäßige Builds erstellt werden.

  Weitere Informationen finden Sie unter Erstellen oder Bearbeiten einer Builddefinition und Ausführen, Überwachen und Verwalten von Builds.

  Hinweis

  Teammitglieder können Builds zwar manuell mit Build Explorer bewerten, diese Bewertung wird im Bericht "Buildqualitätsindikatoren" jedoch nicht wiedergegeben.Die Buildbewertung wird im Bericht "Buildzusammenfassung" angezeigt.Weitere Informationen finden Sie unter Beurteilen der Qualität eines abgeschlossenen Builds und Bericht "Buildzusammenfassung".

Ändern der Buildanzahl im Bericht

Die Anzeige des Berichts "Buildqualitätsindikatoren" variiert abhängig von der im Bericht enthaltenen Anzahl von Builds und anderen Filtern, die Sie auf den Bericht anwenden. Sie können den Bericht auf einen bestimmten Bereich von Builds begrenzen, indem Sie die im Bericht angezeigte Anzahl von Builds ändern.

So legen Sie die im Bericht dargestellte Anzahl von Builds fest

1. Geben Sie im Feld Buildanzahl die gewünschte Anzahl ein.

2. Klicken Sie neben Ende (Datum) auf das Kalendersymbol, und klicken Sie dann auf das Datum des letzten Tags, an dem in den Bericht einzuschließende Builds ausgeführt wurden.

3. Klicken Sie auf Bericht anzeigen.

Interpretieren des Berichts

Die folgenden Fragen können mithilfe des Berichts für beliebige Builddefinitionen beantwortet werden:

• Wie ist die Qualität der Software?

• Ist der Anteil des vom Team getesteten Codes ausreichend?

• Werden die Tests bestanden?

• Wie wahrscheinlich ist es ausgehend vom Code und von der Testmetrik, dass das Team die geplante Arbeit fertig stellt?

• Wie oft werden Tests bestanden, und wie groß ist der getestete Codeanteil?

  Hinweis

  Das Verhältnis zwischen farbigen und grauen Segmenten gibt den von den Tests abgedeckten Anteil des Codes wieder. Die Codeanteile innerhalb der farbigen Segmente, für die Tests bestanden werden oder fehlschlagen, werden jedoch nur ungefähr wiedergegeben.Diese Mehrdeutigkeit ist darauf zurückzuführen, dass der Anteil von Grün innerhalb des farbigen Segments eigentlich die Anzahl bestandener Tests darstellt.Ein einzelner Fehler in einem Teil des Codes kann dazu führen, dass viele Tests fehlschlagen. Desgleichen kann ein einzelner fehlgeschlagener Test einen weitreichenden Entwurfsfehler darstellen, der sich auf die gesamte CodeBase auswirkt.

Fehlerfreie Version des Berichts

Ein fehlerfreier Bericht "Buildqualitätsindikatoren" enthält folgende Indikatoren:

• Die meisten Tests werden bestanden (große grüne Bereiche), und wenige Tests schlagen fehle (wenig rot).

• Der Prozentsatz des roten Anteils ist kleiner als 20 bis 30 Prozent.

Wie die folgende Abbildung zeigt, sind die Codeabdeckung und die Erfolgsrate der Tests hoch und nehmen im Zeitverlauf zu. Die Zahlen für Codeänderung, aktive Fehler, nicht eindeutige Tests und fehlgeschlagene Tests sind niedrig und nehmen ab.

Fehlerhafte Versionen des Berichts "Buildqualitätsindikatoren"

Eine fehlerhafte Version des Berichts "Buildqualitätsindikatoren" enthält mindestens einen der folgenden Indikatoren. Sie können die Ursache ggf. anhand der folgenden Anweisungen untersuchen.

• Wenig Codeabdeckung und mehr Codeänderung. Die folgende Abbildung zeigt eine Abnahme der Codeabdeckung und eine Zunahme der Codeänderung. Diese Daten weisen eindeutig darauf hin, dass neuer Code ohne entsprechende Komponententests eingecheckt wird.

  

• Niedrige Anzahl ausgeführter Tests. Die folgende Abbildung zeigt eine niedrige Anzahl ausgeführter Tests. Diese Daten können darauf hinweisen, dass das Team nicht genügend Tests ausführt. Diese Blockierung kann auf einen Mangel an Ressourcen zurückzuführen sein oder darauf, dass die Tester anderen Aufgaben nachgehen (z. B. dem Schreiben einer Testautomatisierung), anstatt die aktuelle Funktion zu testen. In beiden Fällen kann ein Ressourcenausgleich gerechtfertigt sein.

  

• Hohe Codeänderung, geringe Codeabdeckung. Eine hohe Codeänderung weist darauf hin, dass als Nebeneffekt von Änderungen Fehler eingeführt werden. Bei einem perfekt umgestalteten Projekt ändern sich bei einer Codeänderung weder die Codeabdeckung noch die Erfolgsrate der Tests. Andernfalls ist eine hohe Codeänderung möglicherweise ein Indikator für eine verringerte Abdeckung und die Notwendigkeit, die Tests umzuschreiben.

  Die folgende Abbildung zeigt eine hohe Codeänderung und geringe Codeabdeckung durch Tests bei weiterhin hoher Erfolgsrate der Tests. Diese Daten weisen darauf hin, dass die ausgeführten Tests den neuen Code nicht betreffen.

  

• Viele fehlgeschlagene Tests. Die folgende Abbildung zeigt, dass viele Tests mit geeigneter Codeabdeckung ausgeführt werden, die Tests aber fehlschlagen. Diese Daten können auf ungenaue Entwicklungsverfahren hinweisen. In frühen Iterationen ist es auch möglich, dass die Tests für die jeweilige Produktphase zu hart sind.

  

  Fehlgeschlagene Tests sollten so schnell wie möglich behandelt werden. Wenn der Code nicht korrigiert werden kann, sollten die fehlgeschlagenen Tests vorübergehend deaktiviert und Fehler protokolliert werden. Obwohl es in frühen Phasen des Projekts akzeptabel sein kann, Codeanalysefehler weniger dringlich zu behandeln, sollten Sie darauf achten, dass die roten Abschnitte nicht zu groß werden.

• Viele bestandene Tests und viele aktive Fehler. Die folgende Abbildung zeigt eine hohe Erfolgsrate der Tests bei weiterhin hoher Anzahl eingehender Fehler. Diese Situation kann aus mehreren Gründen auftreten. Die Tests sind möglicherweise nicht strikt genug für diese Produktphase.

  

  In frühen Iterationen sind einfache Tests gut. Mit zunehmender Reife des Produkts sollten die Tests jedoch umfassendere Szenarien und Integrationen abdecken. Die Tests sind möglicherweise veraltet oder testen die falsche Funktion. Möglicherweise müssen die Testtechniken geändert werden.

• Zunehmende Erfolgsrate der Tests und keine Zunahme der Codeabdeckung. Normalerweise sollte die Codeabdeckung mit der Anzahl von Tests zunehmen. Wenn die Anzahl und Erfolgsrate der Tests jedoch ohne entsprechende Zunahme der Codeabdeckung zunehmen, sind die inkrementellen Tests möglicherweise redundant.

• Zunehmende Anzahl aktiver Fehler ohne Zunahme der Anzahl fehlgeschlagener Tests. Wenn die Anzahl aktiver Fehler zunimmt und in den Testergebnissen keine entsprechenden fehlgeschlagenen Tests angezeigt werden, betreffen die Tests wahrscheinlich nicht dieselbe Funktion wie die Fehler.

• Abnahme der Anzahl aktiver Fehler ohne Zunahme der Anzahl bestandener Tests. Wenn die Anzahl aktiver Fehler abnimmt und die Erfolgsrate der Tests nicht zunimmt, besteht die Gefahr, dass die Reaktivierungsrate zunimmt.

• Große graue Bereiche. Graue Segmente stellen Code dar, der innerhalb des angegebenen Builds nicht erstellt oder getestet wurde. Diese Daten werden nur in einem regelmäßigen Bericht angezeigt, bei dem mindestens einer der angegebenen Builds nicht innerhalb des Zeitraums ausgeführt wurde.

Filtern des Berichts

Sie können den Bericht "Buildqualitätsindikatoren" wie folgt filtern:

• Ändern Sie das Zeitintervall, indem Sie die Anzahl von Builds und das Enddatum für den Bericht angeben.

• Filtern Sie den im Bericht dargestellten Satz von Builds, indem Sie die in den Bericht einzuschließende Plattform, Konfiguration und Builddefinition angeben.

  Hinweis

  Sie können eine Builddefinition so konfigurieren, dass keine Tests, einige Tests oder alle Tests ausgeführt werden.Der Bericht variiert erheblich entsprechend der Konfiguration der Builddefinitionen.

• Filtern Sie die im Bericht gezählten Fehler, indem Sie die einzuschließenden Produktbereiche angeben.

Die folgende Abbildung zeigt die verfügbaren Filter:

Wenden Sie die Filter in der im folgenden Verfahren genannten Reihenfolge an. Die Optionen, die für einige Filter verfügbar sind, hängen von den bereits festgelegten Filtern ab.

So filtern Sie die im Bericht angezeigten Builds

1. Geben Sie im Feld Buildanzahl die gewünschte Anzahl ein.

2. Klicken Sie neben Enddatum auf das Kalendersymbol, und klicken Sie dann auf das letzte Datum, für das Builds eingeschlossen werden sollen.

3. Aktivieren Sie in der Liste Plattform die Kontrollkästchen für jede zu berücksichtigende Plattform.

4. Aktivieren Sie in der Liste Konfiguration die Kontrollkästchen für jede zu berücksichtigende Konfiguration.

5. Aktivieren Sie in der Liste Builddefinition die Kontrollkästchen für jede zu berücksichtigende Builddefinition.

6. Klicken Sie auf Bericht anzeigen.

So filtern Sie die im Bericht angezeigte Fehleranzahl

1. Aktivieren Sie in der Liste Bereich die Kontrollkästchen für jedes zu berücksichtigende Testergebnis.

   In diesem Schritt wird der Bericht anhand der Hierarchie von Testergebnissen gefiltert.

2. Klicken Sie auf Bericht anzeigen.

Siehe auch

Weitere Ressourcen

Berichte (SQL Server Reporting Services)