Analysieren und Erstellen von Berichten von Testergebnissen mit der Testperspektive in der Analysis Services-Datenbank für Visual Studio ALM
Indem Sie die Perspektive im SQL Server Analysis Services-Cuben für Visual Studio Team Foundation Serververwenden, können Sie nur die Measures, die Dimensionen und Attribute anzeigen, die Berichterstellung auf Testergebnissen und Testläufe gehören.Beispielsweise können Sie diese Measures verwenden, die Gesamtqualität jedes Builds, Tests dass eine bestimmte betroffene Erstellung und der Anzahl der Testfälle zu ermitteln, die ausgeführt wurden.Sie können Fragen zu beantworten auch Änderungen in den Ergebnissen.
Die Test measuregruppe basiert auf die relationale Tabelle der Testergebnisse für die Berichterstellung Testergebnisse entweder als Eigenschaft der Test- oder unabhängiges Ergebnis aktiviert.Weitere Informationen finden Sie unter Testergebnistabellen.
.png "Testmeasuregruppe") |
Indem Sie die Perspektive verwenden, können Sie Berichte erstellen, die auf die folgenden Fragen beantworten: Berichte " Status des Anforderungstests ":
Trendberichte:
.gif "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 über alle Dimensionen und Measuregruppen im Ganzen Team System-Cube Bildlauf ausführen müssen.
|
Um Die Dimensionsattribute und viele Tests verwenden zu können, muss das Testteam die Testergebnisse in den Datenspeicher für Team Foundation Serververöffentlichen.Weitere Informationen finden Sie Erforderliche Aktivitäten zum Verwalten von Builds und Tests weiter unten in diesem Thema.
In diesem Thema
Beispiel: Zwischenbericht für das Testen von User Storys
Test-Measure
Dimensionen und Attribute in der Test-Perspektive, die Filterung und Kategorisierung unterstützen
Builds Buildkonfiguration und Erstellungs-Plattform-Dimensionen
Testfall und Testkonfiguration, Testplan Testsammlungs-Dimensionen
Testergebnis-Dimension
Testlauf-Dimension
Arbeitsaufgabe und Arbeitsaufgabe verknüpfte Dimensionen
Erforderliche Aktivitäten zum Verwalten von Builds und Tests
Beispiel: Zwischenbericht für das Testen von User Storys
Mit PivotTable- und PivotChart-Berichte in Excel verwenden, können Sie einen Bericht " Status des Anforderungstests " erstellen, der auf den Teststatus der User Storys auf den Bericht anzeigt, ähnlich wie in der folgenden Abbildung.
.png "Excel-Bericht \"Teststatus der User Story\"")
Die Prozessvorlagen für Microsoft Solutions Framework (MSF) v5.0 enthalten den Bericht " Teststatus der User Story " und den Bericht " Status des Anforderungstests " in Excel.Weitere Informationen finden Sie unter Excel-Bericht Teststatus des Benutzertextabschnitts (Agile) und Excel-Bericht "Status des Anforderungstests" (CMMI).
Zurück nach oben
.gif "ms244708.collapse_all(de-de,VS.110).gif")
Pivot-Felder angeben und Filterung
.png "Pivot-Felder für User Storys-Testfortschritt")
Indem Sie die folgenden Schritte ausführen, können Sie einen Zwischenbericht für das Testen von User Storys erstellt werden:
In Excel stellen Sie eine Verbindung mit der Analysis Services-Cuben für Team Foundation Server, und fügen Sie anschließend 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, Diagrammtyp ändern, klicken Sie auf Bereich, und klicken Sie dann auf Gestapelte Balken.
Für jeden Filter geben Bericht mit der rechten Maustaste auf einen der folgenden Felder, die Hierarchien oder die relevanten Elemente an dem das Feld und ziehen anschließend Berichtsfilter Bereich.
Teamprojekthierarchie aus der Teamprojekt Dimension
Bereichspfad aus der Teamprojekt Dimension
Iterationspfad aus der Testfall Dimension
Arbeitsaufgabentyp aus der Arbeitsaufgabe verknüpft wird Dimension
Geben Sie den Typ als User Story, eine Anforderung oder ein anderer Typ von Arbeitsaufgabe an, die die Testfälle verfügt, die verknüpft sind, dass Sie melden möchten.
Ziehen Sie das Feld aus Punktanzahl (Trend) unterhalb der Test Measuregruppe auf den Werte Bereich.
Ziehen Sie das Feld aus Ergebnis unterhalb der Testergebnis Dimension zum Spaltenbezeichnungen Bereich.
Zurück nach oben
Test-Measure
Die folgende Tabelle beschreibt die Measures, die die Tests measuregruppe enthält.Sie können Testergebnisse durch das Aggregat von Testergebnissen und ihrer Ergebnis für einen bestimmten Build oder vom geänderten Ergebnis für ein Testergebnis analysieren.
Measure |
Beschreibung |
|---|---|
Anzahl der Buildergebnisse (Trend) |
Zählt die neueste Version jedes Ergebnis in einem bestimmten Build. Ein Beispiel eines Berichts, in dem diese Measures verwendet, finden Sie Excel-Bericht "Buildqualität"unter. |
Punkt-Anzahl-Trend |
Anzahl der letzten Version jedes Testergebnisses in einem bestimmten Build.Wenn ein Test mehrmals für einen Build ausgeführt wird, zählt "Punktanzahl (Trend)" das neueste Ergebnis für den Test mit diesem Build.Wenn ein Testfall nicht im Build enthalten ist, wird der Testfall als „Nie ausgeführt“ gezählt. Verwenden Sie diese Measures zu ermitteln, die testet, oder wie viele Tests in der aktuellen Build fehlschlagen. |
Ergebnis-Anzahl |
Zählt die neueste Version jedes Testergebnisses.Verwenden Sie diese Measures, wenn Sie das allgemeine Umfang der Tests ermitteln möchten. Ein Beispiel eines Berichts, in dem diese Measures verwendet, finden Sie Bericht "Buildqualitätsindikatoren"unter. |
Ergebnis-Übergangs-Anzahl |
Zählt alle Ergebnisse, deren Ergebnis in einem bestimmten Build geändert wurde.Verwenden Sie diese Measures, wenn Sie bestimmen möchten, welche Tests nach einer bestimmten Build betroffen sind. |
Testfall-Anzahl |
Die Anzahl der Testfälle.Verwenden Sie diese Measures, wenn Sie bestimmen möchten, wie viele Testfälle für einen bestimmten Testlauf oder einen Build ausgeführt wurden. |
Dimensionen und Attribute in der Test-Perspektive, die Filterung und Kategorisierung unterstützen
Indem Sie die Attribute verwenden, die in diesem Abschnitt wird beschrieben, können Sie Measures aggregieren, filtern Sie einen Bericht oder eine Achsen Berichts angeben.Diese Attribute sind zusätzlich zu den Teamprojekt und Datum gemeinsamen Dimensionen, die Das allgemeine Funktionsweise von Dimensionen beschreibt.
In diesem Abschnitt
Builds Buildkonfiguration und Erstellungs-Plattform-Dimensionen
Testfall und Testkonfiguration, Testplan Testsammlungs-Dimensionen
Testergebnis-Dimension
Testlauf-Dimension
Arbeitsaufgabe und Arbeitsaufgabe verknüpfte Dimensionen
Zurück nach oben
Builds Buildkonfiguration und Erstellungs-Plattform-Dimensionen
Sie können basierend auf Testberichte Builddefinition Buildkonfiguration oder Buildplattform filtern, indem Sie die Attribute verwenden, die in der folgenden Tabelle beschrieben.
Dimension |
Attribut |
Beschreibung |
|---|---|---|
Build |
Builddefinitionsname |
Der Name, der der Builddefinition zugeordnet wird, für die ein Build ausgeführt wurde. Ein Beispiel für einen Bericht, der dieses Attribut verwendet wird, finden Sie Excel-Bericht "Buildqualität"weitere Informationen. |
Erstellen Sie auf IDs |
Die Zahl, die der Erstellung zugewiesen wird.Jedes Mal, wenn eine bestimmte Builddefinition ausgeführt wird, wird Build-ID um 1 erhöht. |
|
Buildname |
Der Name oder der Ausdruck a Build, die eindeutig identifiziert.Weitere Informationen finden Sie unter Arbeiten mit Buildnummern. |
|
Erstellungs-Startzeit |
Das Datum und die Uhrzeit, als der Build gestartet hat. |
|
Erstellungs-Typ |
Der Grund, weshalb 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: Starten (kontinuierlich, die Führungslinie von jedem Eincheckvorgang (Rollen), dem Einchecken von werden, bis die vorherige Buildvorgang), der abgegrenzte Eincheckvorgang und planten.Weitere Informationen finden Sie unter Angeben der Buildtrigger und Gründe. |
|
Ablagespeicherort |
Der Ablageordner, der für den Build definiert wird, und der als URL (Uniform Resource Locator) angegeben wird.Eine URL gibt das Protokoll an, mit dem Webbrowser Internetressourcen suchen.Die URL enthält auch den Namen des Servers ein, auf dem sich die Ressource befindet.Sie können auch den Pfad einer Ressource einfügen. Weitere Informationen finden Sie unter Auswählen eines Stagingortes und Einrichten eines Ablageordners. |
|
Buildkonfiguration |
Buildkonfiguration |
(Nur veröffentlichte Testergebnisse) a-Name, der die Kategorie von Builds festlegt, einen Satz von abgeschlossenen Builds zugewiesen wurden, die als Teil eines Testlaufs veröffentlicht wurden.Beispielsweise kann eine Buildkonfiguration verwendet werden, um eine Betaversion oder eine endgültige Version verwendet.Weitere Informationen finden Sie unter Befehlszeilenoptionen zum Veröffentlichen von Testergebnissen. |
Buildplattform |
Buildplattform |
Der Name der Plattform Computer, für die eine (nicht mit Desktop) Build ausgeführt wurde (z. B. x86 oder Beliebige CPU).Weitere Informationen finden Sie unter Definieren eines auf der Standardvorlage basierenden Buildprozesses. |
Zurück nach oben
Testfall und Testkonfiguration, Testplan Testsammlungs-Dimensionen
Der Testfall und Testkonfiguration, Testplan dimensionen Testsammlungen organisieren entsprechen, wie Sie können Tests automatisiert konfigurieren und ausführen, indem sie Microsoft Test-Manager von Visual Studio 2010 Ultimate oder aus Visual Studio Test Professional.
Der Testfall entspricht einem Arbeitsaufgabentyp, der das Testteam verwendet, um manuelle und automatisierte Tests zu definieren, die das Team ausführen und verwalten kann, indem Microsoft Test-Manager verwendet.Ein Testplan besteht. Testsammlungen und TestkonfigurationenEine Testkonfiguration definiert die Software oder Hardware, in der Sie die Tests ausführen möchten.Eine Testsammlung definiert eine Hierarchie innerhalb des Plans, sodass Sie die Testfälle in Gruppen zusammenfassen können.
Weitere Informationen finden Sie unter den folgenden Themen:
Dimension |
Attribut |
Beschreibung |
|---|---|---|
Test Case (Testfall) |
Weitere Informationen und - Bereichshierarchie |
Die Arbeitsaufgaben- und Testfälle dimensionen enthalten alle Attribute, die an Arbeitsaufgaben, z. B. Zustand Arbeitsaufgabentyp verknüpft und Arbeitsaufgaben-IDWeitere Informationen zur Struktur der Testfall dimension, finden Sie Analysieren und Erstellen von Berichten von Arbeitsaufgaben- und Testfalldaten mithilfe der Arbeitsaufgabenperspektiveweitere Informationen. Eine Beschreibung der einzelnen Attributs finden Sie unter Arbeitsaufgabenfeldverweis für Visual Studio ALM. Weitere Informationen zum Arbeiten mit Datums-, Bereich und Iteration hierarchien funktioniert, finden Arbeiten mit freigegebenen Dimensionen im Analysis Services-Cube. Diese Measuregruppe enthält zusätzliche Attribute, wenn benutzerdefinierte Felder in der Definition für einen Arbeitsaufgabentyp Dimension als Reportable-Attribut angeben.Weitere Informationen dazu, wie Sie das optionale reportable Attribut und ihre Werte finden Sie unter veranschaulicht Hinzufügen und Ändern von Arbeitsaufgabenfeldern zum Unterstützen von Berichten. |
Testkonfiguration |
Konfigurations-ID-und Konfigurations-Name |
Die Zahl, die das System zugewiesen wird und der Name einer Testkonfiguration. |
Testplan |
Bereichshierarchie, Bereichspfad, Iterationshierarchie und Iterationspfad |
Der Produktbereich und - meilenstein, der dem Testplan zugewiesen wird. Weitere Informationen finden Sie unter Analysieren und Erstellen von Berichten von Arbeitsaufgaben- und Testfalldaten mithilfe der Arbeitsaufgabenperspektive. |
Enddatums-Hierarchie bis zu dem von Woche oder Monat Startdatums-Hierarchie bis zu dem von Woche oder Monat |
Optionale Werte, die Besitzer ein Testplan für den Testplan zuweisen kann.Sie stellen das Datum, an dem der Testplan beginnen soll und das Datum an, an dem der Testplan beendet werden soll. Weitere Informationen zum Arbeiten mit Datums- hierarchien finden Sie unter funktioniert Arbeiten mit freigegebenen Dimensionen im Analysis Services-Cube. |
|
Testplan ID und Testplan-Name |
Die Zahl, die das System zugewiesen wird und der Name, den Besitzer der Testplan zuweisen. |
|
Testplan-Besitzer |
Der Benutzername des Teammitglieds, das Test erstellt wurde oder einfach als Besitzer des Testplans zugewiesen wird. |
|
Status und Testplan-ID |
Die SYSTEM-zugewiesene Zahl und der Name des Zustands des Testplans.Beispielsweise gibt Inaktiv an, dass der Testplan definiert ist, und Aktiv gibt an, dass der Testplan zu wiederholende bereit ist und ausgeführt. |
|
Testauflistung |
Testsammlungshierarchie |
Stellt einen Mechanismus bereit, um mehrere Filter auf Grundlage der Projektauflistung Teamprojekt und Testsammlung anzugeben. |
Suite-Pfad |
Entspricht der Hierarchie von Testsammlungen, die für alle Teamprojekte in allen Teamprojektauflistungen konfiguriert werden. |
Zurück nach oben
Testergebnis-Dimension
In der folgenden Tabelle sind alle Dimensionen und Attribute, die für den Test spezifisch sind, misst im Cube.Bevor Sie über Fehlertyp oder Auflösungmelden können, muss das Testteam diese Informationen als Teil ihrer Testaktivitäten auffüllen.
Attribut |
Beschreibung |
|---|---|
Fehler-Typ und Fehler-Typ ID |
Entspricht einem der folgenden Gründe, warum ein Test fehlgeschlagen: Kein, Bekanntes Problem, Neues Problemoder Regression. Microsoft Test-Manager weist automatisch eine ID oder eine Nummer an jedem Grund.Das Testteam kann, ist aber nicht zuweisen, wird ein Fehlertyp für jeden fehlgeschlagenen Test erforderlich. Hinweis
Sie können nicht hinzufügen oder den Satz von Die Fehlertypen ändern.
Ein Beispiel für einen Trend ", der das Ergebnis von Testergebnissen auf Fehlertyp anzeigt, finden Sie Excel-Bericht Fehleranalyseweitere Informationen. |
Ergebnis und Ergebnis ID |
Das Ergebnis des Tests (beispielsweise Erfolgreich, Fehleroder Nicht eindeutig). Ein Beispiel für einen Trend ", der das Ergebnis von Testplänen und Testkonfigurationen anzeigt, finden Sie Bericht "Testplanstatus"weitere Informationen. |
Erklärung Bereitschafts-Zustand Bereitschaft und IDs |
Der Zustand eines bestimmten Tests in einem Testlauf.Gültige Werte sind Abgeschlossen, In Bearbeitung, Kein, NotReadyund Bereit. |
Auflösungs-Zustand |
(Optional) Der Name Auflösung , mit denen ein Tester die Ursache eines fehlgeschlagenen Tests identifiziert.Standardmäßig haben alle MSF-Prozessvorlagen Auflösungs die folgenden Bedingungen: Untersuchung erforderlich, Testproblem, Produktproblemund Konfigurationsproblem.Das Testteam kann, ist aber nicht zuweisen, wird ein Auflösungsstatus für jeden fehlgeschlagenen Test erforderlich. Hinweis
Nach dem Erstellen des Teamprojekts können diese Zustände nicht mehr geändert werden, oder es können keine Zustände hinzugefügt werden.Weitere Informationen finden Sie unter Defining Resolution States for Test.
|
Ausführen von Testergebnissen |
Der Name eines Benutzers oder eines anderen Konto, unter dem der Test ausgeführt wurde. Ein Beispiel für einen Bericht, der dieses Attribut verwendet wird, finden Sie Excel-Bericht "Produktivität des Testteams"weitere Informationen. |
Testergebnis-Besitzer |
Der Name eines Benutzers oder eines anderen Kontos, das als Besitzer des Testergebnisses zugewiesen wird.Die Zuweisung entspricht dem Wert, der festgelegt wird, indem Sie den tcm /resultowner Schalter verwendet. |
Testergebnis-Priorität |
Die Priorität eines bestimmten Tests in einem Testlauf. |
Zurück nach oben
Testlauf-Dimension
In der folgenden Tabelle werden die Attribute beschrieben, die für den Testlauf dimension definiert sind.Viele dieser Attribute entsprechen den Parametern, die das Testteam angibt, wann die Tests ausgeführt werden und veröffentlicht.Weitere Informationen finden Sie unter tcm: Running Tests from a Test Plan Using the Command Line Utility.
Attribut |
Beschreibung |
|---|---|
Vollständiges Datum, Erstellungsdatum, bis Startdatums-Hierarchie von Woche oder Monat |
Datum, an dem der Testlauf erstellt wurde, gestartet oder abgeschlossen.Diese Attribute können, um zu filtern oder Struktur verwenden ein Bericht.Weitere Informationen finden Sie unter Arbeiten mit freigegebenen Dimensionen im Analysis Services-Cube. |
Ist automatisiert |
Flag, das angibt, dass der Testlauf ein oder mehrere automatisierte Tests enthält. Ein Beispiel für einen Bericht, der dieses Attribut verwendet wird, finden Sie Excel-Bericht "Buildqualität"weitere Informationen. |
Ist Erstellungs-Überprüfungs-Ausführung |
Ein Flag, das angibt, ob der Testlauf Buildüberprüfungstests enthält, die die grundlegende Funktionalität des Builds überprüfen.Dieses Flag entspricht dem Schalter tcm /buildverification . Ein Beispiel für einen Bericht, der dieses Attribut verwendet wird, finden Sie Excel-Bericht "Buildqualität"weitere Informationen. |
bereitgestellten Testlauf-ID |
Die Zahl, die das System auf den Testlauf zuwies. |
Besitzer des Testlaufs |
Entspricht dem Besitzer zugewiesen wird, der auf den Testlauf, den das Testteam erstellte oder veröffentlicht hat.Entspricht dem tcm /owner Schalter. |
Testlauf-Zustand und IDs |
Der Name oder die Anzahl, Zustand eines Testlaufs zugewiesen werden (z. B. Abgebrochen, Abgeschlossen, In Bearbeitung, Nicht gestartetoder Unbekannt). |
Testlauf-Name |
Entspricht dem Namen, der dem Testlauf zugewiesen wird, den das Testteam erstellte oder veröffentlicht hat.Entspricht dem tcm /title Schalter. |
Zurück nach oben
Arbeitsaufgabe und Arbeitsaufgabe verknüpfte Dimensionen
Sie können Testfälle mit anderen Arbeitsaufgaben wie Benutzerberichte, Anforderungen und Fehler verknüpfen.Indem Sie die Arbeitsaufgabe verknüpfte Dimension verwenden, können Sie einen Bericht erstellen, der Testergebnisse bereitstellt, die den verknüpften Arbeitsaufgaben verknüpfen.Der Zwischenbericht für das Testen von User Storys weiter oben in diesem Thema beschrieben und ein Beispiel für die Verwendung der verknüpften Arbeitsaufgabe.
Eine Beschreibung der einzelnen Attributs finden Sie unter Arbeitsaufgabenfeldverweis für Visual Studio ALM.
Erforderliche Aktivitäten zum Verwalten von Builds und Tests
Um Testberichte zu erstellen, die nützliche Daten enthalten, müssen die Teammitglieder die folgenden Aktivitäten ausführen, um Builds und Tests zu erreichen:
Erstellungs-Aktivitäten
Konfigurieren Sie ein Buildsystem.Um Team Foundation Buildverwenden zu können, muss das Team ein Buildsystem eingerichtet werden.
Weitere Informationen finden Sie unter Configure Your Build System.
Erstellen Sie Builddefinitionen.Das Team muss mindestens eine Builddefinition erstellen.Das Team kann mehrere Builddefinitionen erstellen, die jeweils ausgeführt werden kann, um Code für eine andere Plattform zu erzeugen.Außerdem kann das Team jeden Build für eine andere Konfiguration ausführen.
Weitere Informationen finden Sie unter Erstellen einer Builddefinition.
Empfehlung: Legen Sie regelmäßig Builds ausgeführt.Das Team kann in Abständen automatisch Builds ausführen oder nach jedem Einchecken angeben.Mit dem Zeitplan " kann das Team Builds oder Uhrzeiten am selben Tag oder die Tage automatisch gleichzeitig ausgeführt werden, in der sie angegeben werden.
Weitere Informationen finden Sie unter Angeben der Buildtrigger und Gründe und Ausführen, Überwachen und Verwalten von Builds.
Weitere Informationen finden Sie unter Team Foundation Build-Aktivitäten.
Test-Verwaltungs-Aktivitäten
Definieren Sie Testfälle und Testpläne, Testkonfigurationen.Um zu Testfällen und Testplänen zu melden, muss das Testteam diese Elemente definieren.Das Testteam kann auch Testsammlungen und Testfälle definieren Testplänen zuweisen.
(Optional) Weisen Sie Produktbereiche und - meilensteine mit Tests, und verfolgen Sie den Statusauf.Das Testteam kann die Bereich und Iteration Pfade für die einzelnen Testfälle und Testplan angeben.Geben Sie Zustand jedem Testfall und Testplanzustand jedes Testplans aufgeführt.
(Optional) verknüpfen Sie Testfälle mit Arbeitsaufgaben.Beispielsweise kann das Testteam zum Teststatus für jede Story überwachen, indem Sie den Linktyp Getestet von verwendet, um Testfälle mit User Storys verknüpfen.
(Optional) Markieren Sie die Ergebnisse von Tests.Das Testteam kann bei manuellen Tests die Ergebnisse jedes Validierungsschritts im Testfall als erfolgreich oder fehlgeschlagen markiert.
.gif "Wichtiger Hinweis")
WichtigTester müssen jeden Validierungstestschritt mit einem Status markieren.Das Gesamtergebnis für einen Test gibt den Status aller vom Tester markierten Testschritte wieder.Daher hat der Test einen Status ", wenn eine Tester einen Testfall als fehlerhaft gekennzeichnet oder nicht gekennzeichnet. alle Schritte
Jeder automatisierte Test wird automatisch als erfolgreich oder fehlgeschlagen markiert.
(Optional) Konfigurieren von Tests, die Codeabdeckungsdaten erfasst werden.Damit Codeabdeckungsdaten im Bericht angezeigt werden, müssen Teammitglieder Tests zum Erfassen dieser Daten instrumentieren.
WichtigUm Daten für die Codeabdeckung gesammelt werden, müssen Sie Visual Studio Premium oder Visual Studio Ultimate auf dem Build-Agent-Computer installieren.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.
Definieren Sie Tests, die automatisch als Teil des Builds ausgeführt werden.Als Teil der Builddefinition Sie können automatisierte Tests definieren, die als Teil des Builds und die Auswirkungen von Codeänderungen auf Tests zur Analyse ausgeführt werden soll.
Weitere Informationen finden Sie unter Definieren eines auf der Standardvorlage basierenden Buildprozesses.
Veröffentlichen Sie Tests.Im Rahmen der Erstellung und der Testaktivitäten muss das Testteam Testergebnisse in den Datenspeicher für Team Foundation Serververöffentlichen.
Weitere Informationen finden Sie unter Befehlszeilenoptionen zum Veröffentlichen von Testergebnissen.
Zurück nach oben
Siehe auch
Konzepte
Analysieren und Erstellen von Berichten von Builddetails und Buildabdeckung mit der Buildperspektive
Im Analysis Services-Cube für Team System verfügbare Perspektiven und Measuregruppen