Testberichte

Jede Berichtsoption erfordert das Erweiterungspaket, das in seinem Abschnitt benannt ist. Fügen Sie das Paket direkt hinzu, oder verwenden Sie eine Test-SDK-Konfiguration oder ein Profil, die es enthält. Berichtserweiterungen gehören nicht zum MTP-Kern, daher wird eine Option wie --report-trx nicht erkannt, wenn die Testanwendung ihre Erweiterung nicht registriert. Führen Sie die Testanwendung mit --helpoder führen Sie dotnet test --help sie im MTP-Modus aus, um zu bestätigen, dass eine Option verfügbar ist.

Tipp

Bei Verwendung von Microsoft.Testing.Platform.MSBuild (transitiv von MSTest, NUnit und xUnit runners eingeschlossen) werden diese Erweiterungen automatisch registriert, wenn Sie ihre NuGet-Pakete installieren – keine Codeänderungen erforderlich. Die in diesem Artikel angegebene manuelle Registrierung ist nur erforderlich, wenn Sie den automatisch generierten Einstiegspunkt durch Festlegen <GenerateTestingPlatformEntryPoint>false</GenerateTestingPlatformEntryPoint>deaktiviert haben.

Dateinamen von Berichten

Jede Berichtserweiterung schreibt die Datei in das Verzeichnis der Testergebnisse, das Sie mit der --results-directory Option festlegen können. Verwenden Sie die entsprechende --report-*-filename Option, um den Namen außer Kraft zu setzen. Jeder Berichtabschnitt listet den Standardnamen für diesen Bericht auf.

Ein Dateiname kann einen relativen Pfad enthalten, der im Verzeichnis der Testergebnisse verbleibt, und er kann die folgenden Ersetzungselemente (Platzhalter) verwenden:

Platzhalter	Description
{asm}	Name der Einstiegsassembly oder unknown, falls diese nicht verfügbar ist.
{tfm}	Zur Laufzeit erkannter Zielframeworkbezeichner, wie z. B. net9.0.
{arch}	Prozessarchitektur, wie x64, x86 oder arm64.
{pname}	Prozessname
{pid}	Prozess-ID.
{time}	Präziser Zeitstempel.

Beispielsweise gibt --report-trx-filename "{asm}_{tfm}_{arch}.trx" den Standardnamen „TRX“ wieder.

Wenn für eine Testquelle bereits ein standardmäßiger oder explizit angegebener TRX-, HTML- oder JUnit-Dateiname vorhanden ist, warnt die Erweiterung und überschreibt die Datei. Ab der MTP 2.4-Vorschau verwendet CTRF das gleiche Verhalten. Um den Berichtsverlauf beizubehalten, schließen Sie {time}ein.

Hinweis

Bei Platzhalternamen wird die Groß-/Kleinschreibung beachtet und Kleinbuchstaben verwendet. Platzhalterunterstützung für Berichtsdateinamen ist ab Version 2.3.0 in MTP verfügbar.

Berichtskonsolidierung

Ab MTP-Version 2.4.0 verarbeitet MTP Berichtsartefakte automatisch nach, nachdem ein dotnet test-Aufruf mehrere Testmodule ausgeführt hat oder nachdem die Wiederholungsfunktion mehrere Versuche durchgeführt hat. Das Feature ist experimentell in MTP 2.4.0.

Die TRX-, JUnit-, CTRF- und HTML-Erweiterungen gruppieren kompatible Artefakte nach Berichtsart und schreiben einen konsolidierten Bericht unter dem Unterverzeichnis des Testergebnisseverzeichnisses merged . CTRF-Konsolidierung kombiniert Modulergebnisse und klappt Wiederholungsversuche in das endgültige Testergebnis mit Wiederholungsverlauf ein. Die HTML-Konsolidierung erstellt eine zusammengeführte Zusammenfassung und bewahrt die ursprünglichen prozessspezifischen Berichte.

Bei benutzerdefinierten Berichtserweiterungen macht die experimentelle IArtifactPostProcessor API separate TestModules Und RetryAttempts Verarbeitungsmodi verfügbar. Weitere Informationen finden Sie unter Den IArtifactPostProcessor Erweiterungen.

Visual Studio Testberichte (TRX)

Die Visual Studio Testergebnisdatei (oder TRX) ist das Standardformat für die Veröffentlichung von Testergebnissen. Für diese Erweiterung ist das NuGet-Paket "Microsoft.Testing.Extensions.TrxReport " erforderlich.

Manuelle Registrierung

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddTrxReportProvider();

Hinweis

Wenn Sie die manuelle Registrierung verwenden, registrieren Sie den TRX-Berichtsanbieter zuletzt. Die aktuelle Implementierung hängt von der Registrierungsreihenfolge ab, sodass durch die Registrierung nach allen anderen Erweiterungen sichergestellt wird, dass alle Testdaten erfasst werden.

Hinweis

Verfügbar in MTP ab Version 1.9.0 enthält der TRX-Bericht das Testfeld Description .

Hinweis

In MTP ist ab Version 2.3.0 verfügbar, dass TRX-Ergebnisse im Verlauf der Ausführung auf den Datenträger geschrieben werden. Wenn der Testhost abstürzt, behält die TRX-Datei die gesammelten Ergebnisse vor dem Absturz bei.

Ab der MTP 2.4-Vorschau behält ein MTP-generiertes TRX MSTest [WorkItem] und [GitHubWorkItem] Metadaten bei.

Options

Option	Description
--report-trx	Generiert den TRX-Bericht.
--report-trx-filename	Der Name des generierten TRX-Berichts. Ab MTP 2.3.0 ist der Standardwert das deterministische {asm}_{tfm}_{arch}.trx Formular; vor MTP 2.3.0 war <UserName>_<MachineName>_<yyyy-MM-dd_HH_mm_ss.fffffff>.trxder Standardwert . Informationen zum Anpassen des Namens finden Sie unter Berichtsdateinamen.

Der Bericht wird im Standardordner TestResults gespeichert, der über das --results-directory Befehlszeilenargument angegeben werden kann.

HTML-Berichte

Der HTML-Bericht erstellt eine interaktive, eigenständige HTML-Datei für eine Testsitzung. Für diese Erweiterung ist das Microsoft.Testing.Extensions.HtmlReport-NuGet-Paket erforderlich.

Hinweis

Verfügbar in MTP ab Version 2.3.0. Diese Erweiterung ist experimentell, und die Optionen und das Ausgabeformat können sich in einer zukünftigen Version ändern.

Manuelle Registrierung

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddHtmlReportProvider();

Options

Option	Description
--report-html	Generiert den HTML-Bericht.
--report-html-filename	Der Name des generierten HTML-Berichts. Der Wert muss mit .html enden. Der Standardwert lautet {asm}_{tfm}_{arch}.html. Informationen zum Anpassen des Namens finden Sie unter Berichtsdateinamen. Erfordert --report-html.

JUnit-Berichte

Der JUnit-Bericht erstellt eine JUnit-kompatible XML-Datei für eine Testsitzung. Diese Erweiterung erfordert das NuGet-Paket Microsoft.Testing.Extensions.JUnitReport.

Hinweis

Verfügbar in MTP ab Version 2.3.0. Diese Erweiterung ist experimentell, und die Optionen und das Ausgabeformat können sich in einer zukünftigen Version ändern.

Aktivieren Sie ab MSTest.Sdk 4.3 diese Erweiterung mit <EnableMicrosoftTestingExtensionsJUnitReport>true</EnableMicrosoftTestingExtensionsJUnitReport>. Die Erweiterung ist nicht Teil der MSTest.Sdk-Profile Default oder AllMicrosoft.

Manuelle Registrierung

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddJUnitReportProvider();

Options

Option	Description
--report-junit	Generiert den JUnit-XML-Bericht.
--report-junit-filename	Der Name des generierten JUnit-XML-Berichts. Der Wert muss mit .xml enden. Der Standardwert lautet {asm}_{tfm}_{arch}.xml. Informationen zum Anpassen des Namens finden Sie unter Berichtsdateinamen. Erfordert --report-junit.

CTRF-Berichte

Der CTRF-Bericht erstellt eine JSON-Datei, die das Allgemeine Testberichtsformat für eine Testsitzung verwendet. Diese Erweiterung erfordert das Microsoft.Testing.Extensions.CtrfReport-NuGet-Paket.

Hinweis

Verfügbar in MTP ab Version 2.3.0. Diese Erweiterung ist experimentell, und die Optionen und das Ausgabeformat können sich in einer zukünftigen Version ändern.

Manuelle Registrierung

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddCtrfReportProvider();

Options

Option	Description
--report-ctrf	Generiert den CTRF JSON-Bericht.
--report-ctrf-filename	Der Name des generierten CTRF JSON-Berichts. Der Wert muss mit .json enden. Der Standardwert lautet <UserName>_<MachineName>_<assembly>_<tfm>_<timestamp>.ctrf.json. Informationen zum Anpassen des Namens finden Sie unter Berichtsdateinamen. Erfordert --report-ctrf.

Ab der MTP 2.4-Vorschau behält CTRF jedes Ergebnis bei, wenn mehrere Tests dieselbe UID verwenden. Es umfasst auch Anhänge für jeden Test sowie Anhänge aus früheren Versuchen und leitet deren MIME-Typen anhand der Dateinamen ab.

Bei wiederholten Tests korreliert CTRF Versuche nur, wenn der Zusammenhang eindeutig ist. Anschließend zeichnet es frühere Versuche in retryAttempts auf, setzt retries und markiert ein späteres erfolgreiches Ergebnis als flaky: true. Mehrdeutige Ergebnisse der gleichen UID bleiben getrennt, sodass der Bericht keine Diagnose mit dem falschen Test verknüpft.

Die Zusammenfassung im Terminal identifiziert instabile und erneut ausgeführte Tests. TRX- und JUnit-Berichte behalten ein Endergebnis pro Test bei, anstatt jeden Versuch aufzuzeichnen.

Azure DevOps Berichte

Azure DevOps Berichts-Plug-In verbessert die Testausführung für Entwickler, die ihren Code auf GitHub hosten, aber auf Azure DevOps Build-Agents aufbauen. Es fügt zusätzliche Informationen zu Fehlern hinzu, um Fehler direkt in GitHub PR anzuzeigen.

Für diese Erweiterung ist das NuGet-Paket "Microsoft.Testing.Extensions.AzureDevOpsReport NuGet" erforderlich.

Manuelle Registrierung

var builder = await TestApplication.CreateBuilderAsync(args);
builder.TestHost.AddAzureDevOpsProvider();

Options

Option	MTP-Version	Description
--report-azdo	1.9.0	Aktiviert den Azure DevOps Berichtsgenerator. Fehler und Warnungen werden in ein Format geschrieben, das Azure DevOps versteht.
--report-azdo-severity	1.9.0	Schweregrad, der für gemeldete Ereignisse verwendet werden soll. Gültige Werte sind error (Standard) und warning.
--report-azdo-groups	2.4.0	Aktiviert oder deaktiviert Protokollgruppen pro Baugruppe. Bei Aktivierung wird die Ausgabe jeder Testassembly in einem einklappbaren Abschnitt des Azure Pipelines-Protokolls angezeigt. Gültige Werte sind on und off. MTP 2.4.0-Vorschau-Builds sind standardmäßig auf on eingestellt; die stabile MTP 2.4.0-Version ist standardmäßig auf off eingestellt. Erfordert --report-azdo.
--report-azdo-annotations	2.4.0	Aktiviert oder deaktiviert Anmerkungen für fehlgeschlagene und übersprungene Tests. Gültige Werte sind on (Standard) und off. Erfordert --report-azdo.
--report-azdo-flaky-history	2.3.0	Abfragen Azure DevOps Testergebnisverlauf für die letzten N Tage (1-90) und kommentieren gemeldete Fehler mit Flakiness-Kontext. Erfordert --report-azdo.
--report-azdo-demote-known-flaky	2.3.0	Stuft Fehlschläge, die im Azure DevOps-Verlaufsfenster häufig genug instabil sind (der Standardschwellenwert beträgt 25 %), von Fehlern zu Warnungen herab. Erfordert --report-azdo und --report-azdo-flaky-history.
--report-azdo-quarantine-file	2.3.0	Pfad zu einer Textdatei, die in Quarantäne befindliche Testnamen oder Globmuster auflistet. Abgleichsfehler werden als Warnungen gemeldet. Erfordert --report-azdo.
--report-azdo-summary	2.3.0	Schreibt am Ende des Testlaufs eine Markdown-Auftragsübersicht und lädt sie über ##vso[task.uploadsummary] hoch. Ein optionales Dateipfadargument setzt den Standardspeicherort ({testResultsDir}/azdo-summary-{tfm}.md) außer Kraft. Erfordert --report-azdo.
--report-azdo-stackframe-filter	2.3.0	Fügt Regex-Muster hinzu, die mit dem vollqualifizierten Typpräfix jedes Stack-Frames abgeglichen werden und beim Ermitteln der Aufrufstelle des Benutzers, die von der Erweiterung annotiert werden soll, übersprungen werden. Die Option ist wiederholbar, bis zu 16 Muster und jedes Muster wird mit einem Timeout von 500 ms kompiliert. Diese Muster kommen zusätzlich zu den integrierten Präfixen der Erweiterung für die Implementierung von MSTest-Assertionen hinzu. Erfordert --report-azdo.
--report-azdo-upload-artifacts	2.3.0	Lädt Testergebnisdateien hoch und/oder fügt Buildtags zu Azure DevOps hinzu. Gültige Werte sind off (Standard), tags-only, , filesund all.
--report-azdo-upload-artifact-include	2.3.0	Schließt Dateien beim Azure-DevOps-Artefaktupload mithilfe von Glob-Mustern ein, die relativ zum Verzeichnis der Testergebnisse angegeben sind. Wird standardmäßig auf **/* festgelegt. Erfordert --report-azdo-upload-artifacts einen anderen Wert als off.
--report-azdo-upload-artifact-exclude	2.3.0	Schließt Dateien vom Azure-DevOps-Artefaktupload mithilfe von Glob-Mustern aus, die relativ zum Verzeichnis der Testergebnisse angegeben sind. Erfordert --report-azdo-upload-artifacts einen anderen Wert als off.
--report-azdo-upload-artifact-name	2.3.0	Überschreibt den Namen des Azure DevOps-Artifactcontainers. Wird standardmäßig auf TestResults_{assemblyName}_{tfm} festgelegt. Erfordert --report-azdo-upload-artifacts einen anderen Wert als off.
--publish-azdo-test-results	2.3.0	Überträgt Testergebnisse an einen Azure-DevOps-Testlauf, sobald Tests abgeschlossen sind. Auf der Registerkarte "Tests " des Builds wird die abgeschlossene Ausführung aufgelistet.
--publish-azdo-run-name	2.3.0	Legt einen benutzerdefinierten Azure DevOps Testausführungsnamen für die Livetestergebnisveröffentlichung fest. Erfordert --publish-azdo-test-results.

Warning

Aktivieren Sie keine Gruppen, wenn mehrere Testassemblys parallel ausgeführt werden. ##[group] Azure DevOps- und ##[endgroup] Formatierungsbefehle sind sequenziell und anonym. Die Ausgabe bei parallelem Assembly kann sich verschachteln, zu einer falschen Gruppenverschachtelung führen und Zeilen dem falschen Assembly-Vorgang zuordnen. Wenn Sie einen MTP 2.4.0-Vorschaubuild verwenden, übergeben Sie die Option --report-azdo-groups off zum Deaktivieren von Gruppen. Die stabile MTP 2.4.0-Version deaktiviert Standardmäßig Gruppen. Übergeben Sie --report-azdo-groups on nur für die Ausführung einer einzelnen Assembly oder einer serialisierten Assembly-Ausführung.

Hinweis

In der Spalte "MTP-Version " wird die erste MTP-Version aufgeführt, die jede Option enthält. Die Azure DevOps Erweiterung selbst wurde in MTP 1.9.0 stabil mit --report-azdo und --report-azdo-severity; die verbleibenden Optionen wurden in MTP 2.3.0 oder 2.4.0 hinzugefügt.

Die Erweiterung erkennt automatisch, dass sie in einer CI-Umgebung (Continuous Integration) ausgeführt wird, indem sie die TF_BUILD Umgebungsvariable überprüft.

Ab MTP 2.4.0 fasst Azure DevOps Markdown aggregierte Ergebnisse in jedem Testmodul in einem dotnet test Aufruf zusammen. Wenn Sie auch die Codeabdeckung aktivieren, enthält die Zusammenfassung die Anzahl der abgedeckten und der Gesamtwerte, Prozentsätze, Ergebnisse der Schwellenwertprüfung sowie einen Hinweis darauf, dass die Abdeckungsdaten nur teilweise vorliegen.

In der MTP 2.4-Vorschau lädt die Liveveröffentlichung Dateianhänge für fehlgeschlagene Ergebnisse automatisch in die Azure-DevOps-Testergebnisse hoch. Zu den nicht erfolgreichen Ergebnissen gehören fehlgeschlagene, fehlerhafte, wegen Zeitüberschreitung beendete und abgebrochene Ergebnisse.

Wenn ein Ergebnis eine Standardausgabe oder einen Standardfehler bereitstellt, kann die Erweiterung bis zu 256 KiB von jedem Inline-Datenstrom anhängen. Jeder dateibasierte Anhang hat eine Größenbeschränkung von 16 MiB.

Die Erweiterung lädt außerdem die Dateien .coverage, .cobertura.xml und .opencover.xml auf Ausführungsebene als Anhänge zur Codeabdeckung hoch. Diese Anhänge für Testläufe und Ergebnisse sind von --report-azdo-upload-artifacts getrennt, mit dem ausgewählte Dateien als Buildartefakte in Azure Pipelines hochgeladen werden.

Bei erneut ausgeführten Tests veröffentlicht Azure DevOps frühere Versuche als Unterergebnisse und hängt die Artefakte jedes Versuchs an das Unterergebnis an, von dem sie erzeugt wurden. Wenn keine sichere Wiederholungskorrelation verfügbar ist, veröffentlicht die Erweiterung ein separates Ergebnis, anstatt sie abzuwerfen.

Wenn bei der Live-Veröffentlichung der Lauf erstellt wird, wird die URL des Laufs ausgegeben, sodass Sie die Ergebnisse schon vor dem Abschluss verfolgen können. Es übermittelt auch pipelineReference und das Startdatum, wenn die Pipeline-Umgebung diese bereitstellt. Auf der Registerkarte "Tests " des Builds wird keine laufende Ausführung aufgeführt. sie listet die Ausführung nach Abschluss auf.

GitHub Actions Berichte

Der GitHub-Actions-Bericht gibt GitHub Actions-eigene Workflowbefehle aus, sodass Testläufe für eine erstklassige Erfahrung auf dem Runner sorgen: Loggruppen pro Assembly, Annotationen zu fehlgeschlagenen und übersprungenen Tests (sichtbar auf der Registerkarte Annotations des Workflows und, wenn der Quellspeicherort ermittelt werden kann, im Diff der Dateien geändert-Ansicht des Pull Requests), eine Markdown-Auftragszusammenfassung, die an die durch GITHUB_STEP_SUMMARY referenzierte Datei angehängt wird, sowie Hinweise auf langsame Tests.

Diese Erweiterung erfordert das Microsoft.Testing.Extensions.GitHubActionsReport-NuGet-Paket.

Die Erweiterung wird nur aktiviert, wenn die Ausführung auf GitHub Actions ausgeführt wird (die GITHUB_ACTIONS Umgebungsvariable isttrue) und der --report-gh Schalter festgelegt ist. Andernfalls wird nichts ausgeführt. Wenn sie aktiv ist, ist jedes Feature standardmäßig aktiviert und kann einzeln mit seiner --report-gh-* Option deaktiviert werden.

Important

Die --report-gh Option gehört zu Microsoft.Testing.Extensions.GitHubActionsReport. Das GitHubActionsTestLogger-Paket bietet eine andere Option, --report-github. Die Optionen sind keine Aliase und funktionieren nur, wenn das Testprojekt das Paket registriert, das die Option besitzt.

Hinweis

Die Erweiterung ist ab MTP 2.3.0 verfügbar. Ab MTP 2.4.0 sind ihre öffentlichen Einstiegspunkte nicht mehr experimentell.

Manuelle Registrierung

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddGitHubActionsProvider();

Options

Option	MTP-Version	Description
--report-gh	2.3.0	Aktiviert den GitHub Actions Berichtsgenerator, sodass testausführung Workflowbefehle ausgibt. Erfordert, dass die Ausführung auf GitHub Actions ist.
--report-gh-groups	2.3.0	Aktiviert oder deaktiviert Protokollgruppen pro Baugruppe. Gültige Werte sind on (Standard) und off. Erfordert --report-gh.
--report-gh-annotations	2.3.0	Aktiviert oder deaktiviert Anmerkungen für fehlgeschlagene und übersprungene Tests. Gültige Werte sind on (Standard) und off. Erfordert --report-gh.
--report-gh-step-summary	2.3.0	Steuert, ob die Erweiterung eine Markdown-Auftragszusammenfassung in die Datei schreibt, auf die verwiesen wird GITHUB_STEP_SUMMARY. Gültige Werte sind on (Standard), offund, beginnend mit MTP 2.4.0, on-failure. Erfordert --report-gh.
--report-gh-step-summary-sections	2.4.0	Wählt Den Zusammenfassungsinhalt aus. Gültige Werte sind test-results, , slow-tests, coverageund all (Standard). Erfordert --report-gh und einen anderen Zusammenfassungsmodus als off.
--report-gh-failure-details	2.4.0	Aktiviert oder deaktiviert die Anzeige begrenzter Fehlerdetails in der Auftragszusammenfassung. Verwenden Sie on (Standard) oder off. Details umfassen die Meldung, den Ausnahmetyp, den Quellspeicherort und die Stapelverfolgung, sofern verfügbar. Erfordert --report-gh.
--report-gh-history	2.4.0	Liest und aktualisiert eine begrenzte lokale Momentaufnahme des Testverlaufs unter dem angegebenen Dateipfad. Der Workflow muss die vorherige Momentaufnahme vor der Ausführung herunterladen und die aktualisierte Datei danach hochladen. Erfordert --report-gh.
--report-gh-history-window	2.4.0	Legt das beibehaltene Verlaufsfenster von 1 bis 90 Tagen fest. Der Standardwert ist 30 Tage. Erfordert --report-gh-history.
--report-gh-slow-test-notices	2.3.0	Aktiviert oder deaktiviert Hinweise zu langsamen Tests. Gültige Werte sind on (Standard) und off. Erfordert --report-gh.
--report-gh-slow-test-threshold	2.3.0	Die Dauer, die ein Test laufen kann, bevor ein Hinweis auf einen langsamen Test ausgegeben wird. Akzeptiert eine bloße Anzahl von Sekunden oder einen Wert mit einem Einheitensuffix wie 90s, oder 2m1.5h. Der Standardwert lautet 60s. Erfordert --report-gh.

Ab MTP 2.4.0 fasst GitHub Actions Markdown aggregierte Ergebnisse in jedem Testmodul in einem dotnet test Aufruf zusammen. Wenn Sie auch die Codeabdeckung aktivieren, wählen Sie coverage oder all, um abgedeckte und Gesamtanzahlen, Prozentsätze, Schwellenwertergebnisse und einen Indikator einzuschließen, wenn die Abdeckungsdaten unvollständig sind.

Fehlerdetails bleiben innerhalb der begrenzten Nachricht, des Stapels, der Fehleranzahl und des Gesamtzusammenfassungsbudgets. Wenn der Inhalt ein Limit überschreitet, kürzt oder verdichtet der Bericht ihn und weist in der Zusammenfassung auf diese Kürzung hin.