Testdashboard (CMMI)

Das Testdashboard zeigt fünf Berichte an, mit denen Sie Testaktivitäten überwachen, Statusberichte erstellen, Lücken in der Testabdeckung suchen und Testbereiche identifizieren können, die ggf. genauer untersucht werden müssen. Die Daten umfassen Tests, die in den vergangenen vier Wochen durchgeführt wurden.

In diesem Thema

  • Im Dashboard angezeigte Daten

  • Erforderliche Aktivitäten zum Nachverfolgen von Tests

  • Überwachen des Teststatus

  • Ermitteln von Lücken in Tests

  • Überwachen von Testfehlern und Regressionen

  • Anpassen des Testdashboards

Sie können mit diesem Dashboard die folgenden Fragen beantworten:

  • Erfolgt die Erstellung von Testfällen nach Plan?

  • Hat das Team Testfälle für alle Anforderungen definiert?

  • Im welchem Verhältnis stehen erfolgreiche, fehlgeschlagene und blockierte Testfälle zueinander?

  • Weist die Testfehlermetrik auf ein Problem hin, das genauer untersucht werden muss?

  • Wie lautet der Status des Builds von letzter Nacht?

  • Was wurde zuletzt eingecheckt?

Anforderungen

  • Sie können auf das Testdashboard und alle anderen Dashboards nur zugreifen, wenn das Teamprojektportal aktiviert und für die Verwendung von SharePoint Server Enterprise Edition konfiguriert wurde. Weitere Informationen finden Sie unter Dashboards.

  • Zum Anzeigen des Dashboards müssen Sie einer Gruppe zugewiesen sein oder zu einer Gruppe gehören, der in SharePoint-Produkte die Berechtigung Lesen für das Teamprojekt zugewiesen wurde. Zum Ändern, Kopieren oder Anpassen eines Dashboards müssen Sie einer Gruppe zugewiesen sein oder zu einer Gruppe gehören, der in SharePoint-Produkte die Berechtigung Mitglieder für das Teamprojekt zugewiesen wurde.

    Zum Anzeigen einer Arbeitsaufgabe müssen Sie Mitglied der Gruppe Leser sein, oder die Berechtigung Arbeitsaufgaben in diesem Knoten anzeigen muss auf Zulassen festgelegt sein. Zum Erstellen oder Ändern einer Arbeitsaufgabe müssen Sie Mitglied der Gruppe Contributors sein, oder die Berechtigung Arbeitsaufgaben in diesem Knoten bearbeiten muss auf Zulassen festgelegt sein.

    Weitere Informationen finden Sie unter Hinzufügen von Benutzern zu Teamprojekten.

  • Um in Office Excel einen Bericht zu ändern, müssen Sie Mitglied der Sicherheitsrolle TfsWarehouseDataReaders in SQL Server Analysis Services sein, und Sie müssen einer Gruppe zugewiesen sein oder zu einer Gruppe gehören, der die Berechtigung Mitglieder in SharePoint-Produkte für das Teamprojekt zugewiesen wurde. Weitere Informationen finden Sie unter Gewähren von Zugriff auf die Datenbanken des Data Warehouse für Visual Studio ALM.

  • Zum Anzeigen einer Arbeitsaufgabe müssen Sie Mitglied der Gruppe Leser sein, oder die Berechtigung Arbeitsaufgaben in diesem Knoten anzeigen muss auf Zulassen festgelegt sein. Zum Erstellen oder Ändern einer Arbeitsaufgabe müssen Sie Mitglied der Gruppe Contributors sein, oder die Berechtigung Arbeitsaufgaben in diesem Knoten bearbeiten muss auf Zulassen festgelegt sein. Weitere Informationen finden Sie unter Hinzufügen von Benutzern zu Teamprojekten.

  • Die Berichte Testplanstatus, Testfallbereitschaft, Status des Anforderungstests und Testaktivität sind erst verfügbar, wenn das Team Testpläne erstellt und Tests wie unter Planen von manuellen Tests mit Team Web Access beschrieben ausführt.

Im Testdashboard angezeigte Daten

Mit dem Testdashboard können Sie nachvollziehen, wie gut das Team beim Testen der Anforderungen vorankommt. Informationen zu den den Webparts, die auf dem Testdashboard angezeigt werden, finden Sie in der Abbildung und der folgenden Tabelle.

Testdashboard

Burndown-, Status- und Trenddiagramme und die Berichte Schritt 1 bis Schritt 5 werden nicht angezeigt, wenn der Server, auf dem Analysis Services gehostet werden, nicht verfügbar ist.

Webpart

Angezeigte Daten

Verwandtes Thema

Schritt 1

Ein gestapeltes Flächendiagramm der Testergebnisse aller Tests, gruppiert nach dem letzten erfassten Ergebnis in den vergangenen vier Wochen. Mögliche Testergebnisse sind Nie ausgeführt, Blockiert, Fehler und Erfolgreich.

Excel-Bericht "Testplanstatus"

Bericht "Testplanstatus"

Schritt 2

Ein gestapeltes Flächendiagramm, das zeigt, wie viele Testfälle in den letzten vier Wochen den Zustand Entwurf oder Bereit hatten.

Excel-Bericht "Testfallbereitschaft"

Bericht "Testfallbereitschaft"

Schritt 3

Ein horizontales Balkendiagramm, das die Anzahl von Testergebnissen für jede Kombination aus Testfall und Testkonfiguration anzeigt, die für die einzelnen Anforderungen definiert wurde. Im Diagramm werden die Testergebnisse nach ihrem letzten Testlauf gruppiert, wobei die Optionen Erfolgreich (grün), Fehler (rot), Blockiert (lila) oder Nicht ausgeführt (grau) lauten.

Excel-Bericht "Status des Anforderungstests"

Excel-Bericht "Status des Anforderungstests" (CMMI)

Schritt 4

Ein Liniendiagramm, das die kumulierte Anzahl aller Ergebnisse anzeigt, die während der vergangenen vier Wochen für alle manuellen Testfälle erfasst wurden.

Excel-Bericht "Testaktivität"

Excel-Bericht Testaktivität

Schritt 5

Ein gestapeltes Flächendiagramm, das die kumulierte Anzahl aller fehlgeschlagenen Tests während der letzten vier Wochen nach Fehlertyp sortiert anzeigt. Die Fehlertypen sind Regression, Neues Problem und Bekanntes Problem.

Excel-Bericht "Fehleranalyse"

Excel-Bericht Fehleranalyse

Schritt 6

Liste bevorstehender Ereignisse. Diese Liste wird von einem SharePoint-Webpart abgeleitet.

Ereignisse-Webpart importieren

Nicht zutreffend

Schritt 7

Anzahl der aktiven, gelösten und geschlossenen Arbeitsaufgaben. Sie können die Liste der Arbeitsaufgaben öffnen, indem Sie eine Zahl auswählen. Diese Liste wird von einem Team Web Access-Webpart abgeleitet.

Projektarbeitsaufgaben

Arbeitsaufgabentypen und Workflow für CMMI-Prozessvorlagen

9

Liste der letzten Builds und ihrer Buildstatus. Sie können weitere Informationen anzeigen, indem Sie einen bestimmten Build wählen. Diese Liste wird von einem Team Web Access-Webpart abgeleitet.

Letzte Builds-Webpart

Legende:

Buildvorgang wird ausgeführt: Der Buildvorgang wurde nicht gestartet.

Buildvorgang nicht gestartet: Der Buildvorgang wird ausgeführt.

Der Buildvorgang war erfolgreich: Der Buildvorgang war erfolgreich.

Fehler beim Buildvorgang: Beim Buildvorgang ist ein Fehler aufgetreten.

Der Buildvorgang wurde beendet: Der Buildvorgang wurde beendet.

Buildvorgang teilweise erfolgreich: Der Buildvorgang war teilweise erfolgreich.

Managing and Reporting on Builds

10

Liste der letzten Eincheckvorgänge. Sie können weitere Informationen anzeigen, indem Sie einen bestimmten Eincheckvorgang wählen. Diese Liste wird von einem Team Web Access-Webpart abgeleitet.

Letzte Eincheckvorgänge-Webpart

Entwickeln von Code und Verwalten von ausstehenden Änderungen

Erforderliche Aktivitäten zum Nachverfolgen von Tests

Damit die Berichte im Testdashboard hilfreich und genau sind, muss das Team die folgenden Aktivitäten ausführen:

  • Definieren Sie Testfälle und Anforderungen, und erstellen Sie Getestet von-Links zwischen Testfällen und Anforderungen.

  • Definieren Sie Testpläne, und weisen Sie Testplänen Testfälle zu.

  • Markieren Sie bei manuellen Tests die Ergebnisse jedes Validierungsschritts im Testfall als erfolgreich oder fehlgeschlagen.

    Wichtig

    Tester müssen einen Testschritt mit einem Status markieren, wenn es sich um einen Validierungstestschritt handelt.Das Gesamtergebnis für einen Test gibt den Status aller vom Tester markierten Testschritte wieder.Wenn der Tester einen Test als fehlgeschlagen oder gar nicht markiert hat, weist der Testfall daher den Status "Fehler" auf.

    Bei automatisierten Tests wird jeder Test automatisch als erfolgreich oder fehlgeschlagen markiert.

  • (Optional) Weisen Sie jedem Testfall die Pfade Iteration und Bereich zu, damit nach diesen Feldern gefiltert werden kann.

Überwachen des Teststatus

Mit den ersten drei Berichten im Testdashboard können Sie den Teststatus überwachen und die folgenden Fragen beantworten:

Bericht

Beantwortete Fragen

Hinweise

Testfallbereitschaft

  • Wie viele Testfälle hat das Testteam definiert?

  • Wie viele Testfälle können heute ausgeführt werden?

  • Wie viele Testfälle muss das Team noch schreiben und überprüfen?

  • Scheint die Gesamtanzahl von Testfällen hoch genug für die Anzahl der Anforderungen, die das Team implementiert?

  • Wie hoch ist der Prozentsatz von Testfällen, die das Testteam heute ausführen kann?

  • Kann das Team bis zum Ende der Iteration alle Testfälle erstellen?

  • Bei einer positiven Entwicklung sollte eine stetige Erhöhung der Anzahl von Testfällen zu beobachten sein, die vom Team entworfen und mit dem Zustand Bereit gekennzeichnet werden.

  • Bei einer falschen Entwicklung werden keine oder wenige Testfälle als einsatzbereit gemeldet.

    Wenn alle Testfälle über einen längeren Zeitraum hinweg in einem Entwurfszustand verbleiben, verhindert ein Problem ggf. den Fortschritt. Sie sollten die Ursache der Blockierung untersuchen.

  • Eine Lücke in den Tests kann entstehen, wenn die Anzahl von Testfällen ungenügend erscheint.

    Die für ein Projekt definierte Anzahl von Testfällen sollte der vom Team implementierten Anzahl von Anforderungen entsprechen oder höher sein. Die Anzahl der Testfälle ist offenbar zu niedrig.

Testplanstatus

  • Wie viele Testfälle sind erfolgreich?

  • Wie viele Testfälle schlagen fehl?

  • Wie viele Testfälle sind blockiert?

  • Wie viele Testfälle wurden nie ausgeführt?

  • Wie hoch ist der Prozentsatz erfolgreicher Testfälle (für alle Testpläne)?

  • Wie viele Tests hat das Team abgeschlossen?

  • Werden die Tests vom Team wahrscheinlich fristgerecht fertig gestellt?

  • Während der Entwicklungszyklus fortschreitet, sollten mehr und mehr Testfälle erfolgreich sein und weniger Testfälle mit anderen Zuständen vorhanden sein.

  • Zu viele fehlgeschlagene Testfälle weisen auf eine fehlerhafte Entwicklung hin. Je nachdem, in welcher Phase des Produktzyklus Sie sich befinden, können Sie überprüfen, warum so viele Testfälle fehlschlagen.

  • Wenn die Anzahl fehlerhafter oder nie ausgeführter Testfälle auf gleichem Niveau bleibt, können Sie bei Bedarf die spezifischen Ursachen für einzelne Bereiche untersuchen.

Status des Anforderungstests

  • Werden Testfälle für jede Anforderung ausgeführt?

  • Falls Testfälle blockiert sind oder nicht ausgeführt werden: Versteht das Team die blockierenden Probleme, und werden die Probleme behandelt?

  • Bei einer fehlerfreien Entwicklung sind die meisten Testfälle für jede Anforderung erfolgreich.

  • Eine falsche Entwicklung liegt vor, wenn zu viele Testfälle für eine bestimmte Anforderung den Zustand Nie ausgeführt, Blockiert oder Fehler aufweisen. In diesem Fall können Sie die Ursachen untersuchen, die die erfolgreiche Ausführung der definierten Testfälle für eine Anforderung verhindern.

Ermitteln von Lücken in Tests

Mit dem Bericht Status des Anforderungstests können Sie feststellen, ob die Tests den gesamten Code abdecken, und die folgenden Fragen prüfen:

  • Bei welchen Anforderungen ist die Gesamtanzahl von Testfällen gering?

  • Welche Anforderungen weisen eine hohe Gesamtanzahl von Testfällen auf, die blockiert sind oder nie ausgeführt wurden?

  • Entspricht die Testfallabdeckung für die einzelnen Anforderungen den Erwartungen?

  • Welche Anforderungen weisen einen hohen Anteil an fehlgeschlagenen Tests auf?

  • Wie viele Testfälle werden durchschnittlich für jede Anforderung definiert?

Überwachen von Testfehlern und Regressionen

Indem Sie Testfehler überwachen, können Sie Probleme im Code früh identifizieren und behandeln. Die letzten zwei Berichte im Testdashboard geben Ihnen einen besseren Einblick in die Anzahl der fehlgeschlagenen Tests.

Bericht

Beantwortete Fragen

Hinweise

Manuelle Testaktivität

  • Sinkt die Anzahl der Tests, die vom Team niemals ausgeführt wurden?

  • Minimiert das Team die Gesamtanzahl blockierter Tests?

  • Schlagen im Laufe der Zeit weniger Tests fehl?

  • Werden mehr Tests bestanden?

  • Zeigt die Testaktivität Spitzen, die Sie sich nicht erklären können?

Der Bericht Manuelle Testaktivität enthält die Ergebnisse jeder Testfallausführung für jede Testkonfiguration und für alle Testpläne. Spitzen können erste Anzeichen für Probleme mit der Testaktivität oder der Qualität des vom Team eingecheckten Codes sein.

Sie können in diesem Fall die Metriken für die letzten Builds, den Fehlerstatus und die Codeänderung überprüfen, um festzustellen, ob sich die Änderungen durch diese Werte erklären lassen.

Testfehleranalyse

  • Wie viele Tests ergeben eine Regression?

  • Bleibt die Gesamtanzahl von Regressionen oder Testfehlern innerhalb des erwarteten Bereichs oder der Ziele des Teams?

  • Behandelt das Team bekannte und neue Probleme unmittelbar nach der Identifizierung?

Ein fehlerfreier Bericht "Testfehleranalyse" zeigt eine moderate Anzahl von neuen Problemen, bekannten Problemen und Regressionen an. Wenn in diesen Bereichen Spitzen auftreten, muss das Team ggf. eine genauere Untersuchung durchführen. Spitzen weisen möglicherweise auf Probleme mit der Testaktivität oder der Qualität des vom Team eingecheckten Codes hin.

Sie können auch die Metriken für die letzten Builds, den Fehlerstatus und die Codeänderung überprüfen, um festzustellen, ob sich die Änderungen durch einen dieser Werte erklären lassen.

Anpassen des Testdashboards

Im Folgenden wird gezeigt, wie Sie das Testdashboard anpassen können:

  • Ändern Sie die Filter für jeden Bericht in Office Excel, um bestimmte Produktbereiche oder Iterationen in den Fokus zu rücken.

  • Filtern Sie den Bericht Manuelle Testaktivität in Office Excel nach bestimmten Testplänen oder nach manuellen oder automatisierten Testfällen.

  • Fügen Sie vorhandene Excel-Berichte zum Dashboard hinzu, z. B. Fehlerstatus, Codeänderung oder Codeabdeckung.

  • Erstellen und fügen Sie Berichte in Office Excel hinzu, die den Fortschritt nach Teammitgliedern anzeigen. Ein Beispiel finden Sie unter Excel-Bericht Fehler nach Zuweisung.

Weitere Informationen zum Arbeiten mit Berichten in Office Excel und zum Anpassen dieser Berichte finden Sie auf den folgenden Seiten der Microsoft-Website:

Siehe auch

Konzepte

Ausführen von manuellen Tests mit Team Web Access

Bericht "Testfallbereitschaft"

Bericht "Testplanstatus"

Weitere Ressourcen

Dashboards (CMMI)