Teilen über

PublishTestResults@2 – Aufgabe "Testergebnisse v2 veröffentlichen"

  • Artikel

Veröffentlichen Sie Testergebnisse in Azure Pipelines.

Syntax

# Publish Test Results v2
# Publish test results to Azure Pipelines.
- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit' # 'JUnit' | 'NUnit' | 'VSTest' | 'XUnit' | 'CTest'. Alias: testRunner. Required. Test result format. Default: JUnit.
    testResultsFiles: '**/TEST-*.xml' # string. Required. Test results files. Default: **/TEST-*.xml.
    #searchFolder: '$(System.DefaultWorkingDirectory)' # string. Search folder. Default: $(System.DefaultWorkingDirectory).
    #mergeTestResults: false # boolean. Merge test results. Default: false.
    #failTaskOnFailedTests: false # boolean. Fail if there are test failures. Default: false.
    #failTaskOnFailureToPublishResults: false # boolean. Fail if there is failure in publishing test results. Default: false.
    #failTaskOnMissingResultsFile: false # boolean. Fail if no result files are found. Default: false.
    #testRunTitle: # string. Test run title. 
  # Advanced
    #buildPlatform: # string. Alias: platform. Build Platform. 
    #buildConfiguration: # string. Alias: configuration. Build Configuration. 
    #publishRunAttachments: true # boolean. Upload test results files. Default: true.

# Publish Test Results v2
# Publish test results to Azure Pipelines.
- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit' # 'JUnit' | 'NUnit' | 'VSTest' | 'XUnit' | 'CTest'. Alias: testRunner. Required. Test result format. Default: JUnit.
    testResultsFiles: '**/TEST-*.xml' # string. Required. Test results files. Default: **/TEST-*.xml.
    #searchFolder: '$(System.DefaultWorkingDirectory)' # string. Search folder. Default: $(System.DefaultWorkingDirectory).
    #mergeTestResults: false # boolean. Merge test results. Default: false.
    #failTaskOnFailedTests: false # boolean. Fail if there are test failures. Default: false.
    #testRunTitle: # string. Test run title. 
  # Advanced
    #buildPlatform: # string. Alias: platform. Build Platform. 
    #buildConfiguration: # string. Alias: configuration. Build Configuration. 
    #publishRunAttachments: true # boolean. Upload test results files. Default: true.

Eingänge

testResultsFormat - Testergebnisformat
Eingabealias: testRunner. string. Erforderlich. Zulässige Werte: JUnit, NUnit, VSTest, XUnit, CTest. Standardwert: JUnit.

Gibt das Format der Ergebnissedateien an, die Sie veröffentlichen möchten. Die folgenden Formate werden unterstützt: CTest, JUnit, NUnit 2, NUnit 3, Visual Studio Test (TRX) und xUnit 2.


testResultsFiles - Testergebnisse
string. Erforderlich. Standardwert: **/TEST-*.xml.

Gibt mindestens eine Testergebnisdatei an.

  • Sie können einen Einzelordner-Wildcard (*) und rekursive Wildcards (**) verwenden. Beispielsweise sucht **/TEST-*.xml nach allen XML-Dateien, deren Namen mit TEST- in allen Unterverzeichnissen beginnen. Wenn VSTest als Testergebnisformat verwendet wird, sollte der Dateityp in .trx geändert werden, z. B. **/TEST-*.trx
  • Mehrere Pfade können durch eine neue Zeile getrennt angegeben werden.
  • Darüber hinaus werden Minimatchmusterakzeptiert.

Beispielsweise schließt !TEST[1-3].xml Dateien mit dem Namen TEST1.xml, TEST2.xmloder TEST3.xmlaus.


searchFolder - Suchordner
string. Standardwert: $(System.DefaultWorkingDirectory).

Wahlfrei. Gibt den Ordner an, der nach den Testergebnisdateien gesucht werden soll.


mergeTestResults - Zusammenführen von Testergebnissen
boolean. Standardwert: false.

Wenn der Wert dieses booleschen Werts trueist, werden die Testergebnisse aller Dateien anhand eines einzelnen Testlaufsgemeldet. Wenn der Wert falseist, erstellt die Aufgabe für jede Testergebnisdatei eine separate Testausführung. Um eine bessere Leistung zu erzielen, werden die Ergebnisse immer in einer einzigen Ausführung zusammengeführt, wenn mehr als 100 Ergebnisdateien vorhanden sind, auch wenn diese Option auf falsefestgelegt ist.

Hinweis

Verwenden Sie die Einstellung zum Zusammenführen von Testergebnissen, um Dateien aus demselben Testframework zu kombinieren, um sicherzustellen, dass die Ergebniszuordnung und -dauer korrekt berechnet werden.


failTaskOnFailedTests - Fehlschlagen, wenn testfehler
boolean. Standardwert: false.

Wahlfrei. Wenn der Wert dieses booleschen Werts trueist, schlägt die Aufgabe fehl, wenn eines der Tests in der Ergebnisdatei als fehlgeschlagen gekennzeichnet ist. Der Standardwert ist false, wodurch einfach die Ergebnisse aus der Ergebnisdatei veröffentlicht werden.


failTaskOnFailureToPublishResults - Fehlschlagen, wenn beim Veröffentlichen von Testergebnissen fehler
boolean. Standardwert: false.

Wenn true, schlägt die Aufgabe fehl, wenn beim Veröffentlichen von Testergebnissen ein Fehler auftritt.


failTaskOnMissingResultsFile - Fehler, wenn keine Ergebnisdateien gefunden werden
boolean. Standardwert: false.

Schlägt die Aufgabe fehl, wenn keine Ergebnisdateien gefunden werden.


testRunTitle - Titel der Testausführung
string.

Wahlfrei. Gibt einen Namen für die Testausführung an, für die die Ergebnisse gemeldet werden. Variablennamen, die in der Build- oder Releasepipeline deklariert sind, können verwendet werden.


buildPlatform - Build platform
Eingabealias: platform. string.

Wahlfrei. Gibt die Buildplattform an, für die die Testausführung gemeldet werden soll. Beispiel: x64 oder x86. Wenn Sie eine Variable für die Plattform in Ihrer Buildaufgabe definiert haben, verwenden Sie sie hier.


buildConfiguration - Buildkonfiguration
Eingabealias: configuration. string.

Wahlfrei. Gibt die Buildkonfiguration an, für die die Testausführung gemeldet werden soll. Beispiel: Debug oder Release. Wenn Sie eine Variable für die Konfiguration in Ihrer Buildaufgabe definiert haben, verwenden Sie sie hier.


publishRunAttachments - Hochladen von Testergebnissen
boolean. Standardwert: true.

Wahlfrei. Wenn der Wert dieses booleschen Werts trueist, lädt die Aufgabe alle Testergebnisdateien als Anlagen in die Testausführung hoch.


Aufgabensteuerungsoptionen

Alle Aufgaben verfügen zusätzlich zu ihren Aufgabeneingaben über Steuerungsoptionen. Weitere Informationen finden Sie unter Steuerelementoptionen und allgemeinen Aufgabeneigenschaften.

Ausgabevariablen

Keiner.

Bemerkungen

Diese Aufgabe veröffentlicht Testergebnisse in Azure Pipelines oder TFS, wenn Tests ausgeführt werden, um eine umfassende Testberichterstattung und Analyseerfahrung bereitzustellen. Sie können den Testläufer Ihrer Wahl verwenden, der das gewünschte Ergebnisformat unterstützt. Unterstützte Ergebnisformate sind CTest, JUnit (einschließlich PHPUnit), NUnit 2, NUnit 3, Visual Studio Test (TRX) und xUnit 2.

Andere integrierte Aufgaben wie Visual Studio Test-Aufgabe und Dot NetCore CLI-Aufgabe testergebnisse automatisch in der Pipeline veröffentlichen. Aufgaben wie Ant, Maven, Gulp, Gruntund Xcode Veröffentlichungsergebnisse als Option innerhalb der Aufgabe oder Erstellen von Bibliotheken wie Cobertura und JaCoCo. Wenn Sie eine dieser Aufgaben verwenden, benötigen Sie keine separate Aufgabe "Testergebnisse veröffentlichen" Aufgabe in der Pipeline.

Die veröffentlichten Testergebnisse werden auf der Registerkarte Tests in der Pipelinezusammenfassung angezeigt. Die Ergebnisse helfen Ihnen, die Pipelinequalität zu messen, die Rückverfolgbarkeit zu überprüfen, Fehler zu beheben und den Besitz von Laufwerksfehlern zu steuern.

Das folgende Beispiel zeigt, dass die Aufgabe für die Veröffentlichung von Testergebnissen konfiguriert ist.

Öffnen der Seite

Sie können diese Aufgabe auch in einer Buildpipeline verwenden, um Codeabdeckungsergebnisse zu veröffentlichen, die beim Ausführen von Tests an Azure Pipelines oder TFS erstellt werden, um Die Abdeckungsberichte zu erhalten.

Voraussetzungen

Wenn Sie einen selbst gehosteten Windows-Agent verwenden, muss auf Ihrem Computer die folgende Voraussetzung installiert sein:

Standardaufgaben

Die Standardoption verwendet das JUnit-Format, um Testergebnisse zu veröffentlichen. Bei Verwendung von VSTest als testRunner-sollte die option testResultsFiles in **/TEST-*.trxgeändert werden.

testResultsFormat- ist ein Alias für den eingabenamen testRunner. Die Ergebnisdateien können von mehreren Läufern erstellt werden, nicht nur von einem bestimmten Läufer. Beispielsweise wird das jUnit-Ergebnisformat von vielen Läufern und nicht nur jUnit unterstützt.

Informationen zum Veröffentlichen von Testergebnissen für Python mithilfe von YAML finden Sie unter Python- im Abschnitt Ökosysteme dieser Themen, die auch Beispiele für andere Sprachen enthalten.

Zuordnung von Ergebnisformaten

In dieser Tabelle sind die Felder aufgeführt, die auf der Registerkarte Tests in einer Build- oder Versionszusammenfassung und die entsprechende Zuordnung mit den Attributen in den unterstützten Testergebnisformaten angegeben werden.

Umfang Feld Visual Studio Test (TRX)
Testausführung Titel Titel der Testausführung in der Aufgabe angegeben
Startdatum /TestRun/Times.Attributes[""]. Wert
Abschlussdatum /TestRun/Times.Attributes[""]. Wert
Dauer Datum abgeschlossen - Startdatum
Anlagen Weitere Informationen finden Sie im Abschnitt Unterstützung von Anlagen weiter unten.
Testergebnis Titel /TestRun/Results/UnitTestResult.Attributes["testName"]. Value Or /TestRun/Results/WebTestResult.Attributes["testName"]. Value Or /TestRun/Results/TestResultAggregation.Attributes["testName"]. Wert
Startdatum /TestRun/Results/UnitTestResult.Attributes["startTime"]. Value or /TestRun/Results/WebTestResult.Attributes["startTime"]. Value or /TestRun/Results/TestResultAggregation.Attributes["startTime"]. Wert
Abschlussdatum /TestRun/Results/UnitTestResult.Attributes["startTime"]. Wert + /TestRun/Results/UnitTestResult.Attributes["Dauer"]. Value oder /TestRun/Results/WebTestResult.Attributes["startTime"]. Wert + /TestRun/Results/WebTestResult.Attributes["Dauer"]. Wert oder /TestRun/Results/TestResultAggregation.Attributes["startTime"]. Wert + /TestRun/Results/TestResultAggregation.Attributes["Dauer"]. Wert
Dauer /TestRun/Results/UnitTestResult.Attributes["Dauer"]. Wert oder /TestRun/Results/WebTestResult.Attributes["Dauer"]. Wert oder /TestRun/Results/TestResultAggregation.Attributes["Dauer"]. Wert
Besitzer /TestRun/TestDefinitions/UnitTest/Owners/Owner.Attributes["Name"]. Wert
Ergebnis /TestRun/Results/UnitTestResult.Attributes["Ergebnis"]. Wert oder /TestRun/Results/WebTestResult.Attributes["Ergebnis"]. Wert oder /TestRun/Results/TestResultAggregation.Attributes["Ergebnis"]. Wert
Fehlermeldung /TestRun/Results/UnitTestResult/Output/ErrorInfo/Message.InnerText oder /TestRun/Results/WebTestResultOutput/ErrorInfo/Message.InnerText oder /TestRun/Results/TestResultAggregation/Output/ErrorInfo/Message.InnerText
Stapelüberwachung /TestRun/Results/UnitTestResult/Output/ErrorInfo/StackTrace.InnerText oder /TestRun/Results/WebTestResultOutput/ErrorInfo/StackTrace.InnerText oder /TestRun/Results/TestResultAggregation/Output/ErrorInfo/StackTrace.InnerText
Anlagen Weitere Informationen finden Sie im Abschnitt Unterstützung von Anlagen weiter unten.
Konsolenprotokoll /TestRun/Results/UnitTestResult/Output/StdOut.InnerText oder /TestRun/Results/WebTestResultOutput/Output/StdOut.InnerText oder /TestRun/Results/TestResultAggregation/Output/StdOut.InnerText
Konsolenfehlerprotokoll /TestRun/Results/UnitTestResult/Output/StdErr.InnerText oder /TestRun/Results/WebTestResultOutput/Output/StdErr.InnerText oder /TestRun/Results/TestResultAggregation/Output/StdErr.InnerText
Agentname /TestRun/Results/UnitTestResult.Attributes["computerName"]. Wert oder /TestRun/Results/WebTestResult.Attributes["computerName"]. Value or /TestRun/Results/TestResultAggregation.Attributes["computerName"]. Wert
Testdatei /TestRun/TestDefinitions/UnitTest.Attributes["Speicher"]. Wert
Priorität /TestRun/TestDefinitions/UnitTest.Attributes["Priorität"]. Wert

Hinweis

Dauer wird nur verwendet, wenn Datum gestartet und Abgeschlossen nicht verfügbar sind.

Das vollqualifizierte Namensformat für testName- ist Namespace.Testclass.Methodname mit einem Zeichenlimit von 512. Wenn der Test datengesteuert ist und Parameter enthält, enthält der Zeichengrenzwert die Parameter.

Beim Veröffentlichen des Testergebnisses wird möglicherweise dieser Fehler angezeigt: Fehler beim Veröffentlichen von Testergebnissen: Ungültige Priorität angegeben

Dieser Fehler tritt auf, wenn eine der Testmethoden vorrang vor 255 hat, die Priorität der Testmethode im Code beheben und die Tests erneut ausführen. Sie können die generierte TRX-Datei überprüfen, um alle Tests mit einer Priorität von mehr als 255 anzuzeigen.

Unterstützung von Anlagen

Die Aufgabe "Testergebnisse veröffentlichen" bietet Unterstützung für Anlagen für Testausführungen und Testergebnisse für die folgenden Formate. Für öffentliche Projekte unterstützen wir 2 GB Gesamtanlagen.

Visual Studio Test (TRX)

Umfang Typ Pfad
Testausführung Datensammler /TestRun/ResultSummary/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"]. Wert
Testergebnis /TestRun/ResultSummary/ResultFiles/ResultFile.Attributes["Pfad"]. Wert
Codeabdeckung /TestRun/TestSettings/Execution/AgentRule/DataCollectors/DataCollector/Configuration/CodeCoverage/Regular/CodeCoverageItem.Attributes["binaryFile"]. Wert und /TestRun/TestSettings/Execution/AgentRule/DataCollectors/DataCollector/Configuration/CodeCoverage/Regular/CodeCoverageItem.Attributes["pdbFile"]. Wert
Testergebnis Datensammler /TestRun/Results/UnitTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"]. Wert oder /TestRun/Results/WebTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"]. Wert oder /TestRun/Results/TestResultAggregation/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"]. Wert
Testergebnis /TestRun/Results/UnitTestResult/ResultFiles/ResultFile.Attributes["Pfad"]. Wert oder /TestRun/Results/WebTestResult/ResultFiles/ResultFile.Attributes["Pfad"]. Value or /TestRun/Results/TestResultAggregation/ResultFiles/ResultFile.Attributes["path"]. Wert

Hinweis

Die Option zum Hochladen der Testergebnisdatei als Anlage ist eine Standardoption in der Aufgabe, die für alle Formate gilt.

Beispiele

Docker

Für Docker-basierte Apps gibt es viele Möglichkeiten, Ihre Anwendung zu erstellen und Tests auszuführen:

  • Erstellen und Testen in einer Buildpipeline: Builds und Tests, die in der Pipeline ausgeführt werden, und Testergebnisse werden mit der aufgabe Veröffentlichen von Testergebnissen veröffentlicht.
  • Erstellen und Testen mit einer mehrstufigen Dockerfile-: Builds und Tests werden innerhalb des Containers mithilfe einer mehrstufigen Docker-Datei ausgeführt, da testergebnisse nicht wieder in der Pipeline veröffentlicht werden.
  • Erstellen, Testen und Veröffentlichen von Ergebnissen mit einer Dockerfile-: Builds und Tests, die im Container ausgeführt werden, und Ergebnisse werden wieder in der Pipeline veröffentlicht. Sehen Sie sich das folgende Beispiel an.

Erstellen, Testen und Veröffentlichen von Ergebnissen mit einer Docker-Datei

Bei diesem Ansatz erstellen Sie Ihren Code und führen Tests innerhalb des Containers mithilfe einer Docker-Datei aus. Die Testergebnisse werden dann auf den Host kopiert, der in der Pipeline veröffentlicht werden soll. Um die Testergebnisse in Azure Pipelines zu veröffentlichen, können Sie die aufgabe "Testergebnisse veröffentlichen" verwenden. Das endgültige Image wird in Docker oder Azure Container Registry veröffentlicht.

Code abrufen

  1. Erstellen Sie eine Dockerfile.build Datei im Stammverzeichnis Ihres Projektverzeichnisses mit folgendem Code:

    # Build and run tests inside the docker container
FROM mcr.microsoft.com/dotnet/sdk:2.1
WORKDIR /app
# copy the contents of agent working directory on host to workdir in container
COPY . ./
# dotnet commands to build, test, and publish
RUN dotnet restore
RUN dotnet build -c Release
RUN dotnet test dotnetcore-tests/dotnetcore-tests.csproj -c Release --logger "trx;LogFileName=testresults.trx"
RUN dotnet publish -c Release -o out
ENTRYPOINT dotnet dotnetcore-sample/out/dotnetcore-sample.dll

    Diese Datei enthält die Anweisungen zum Erstellen von Code und Ausführen von Tests. Die Tests werden dann in eine Datei testresults.trx innerhalb des Containers kopiert.

  2. Um das endgültige Image so klein wie möglich zu machen, das nur die Laufzeit- und Bereitstellungsartefakte enthält, ersetzen Sie den Inhalt der vorhandenen Dockerfile durch Folgendes:

    # This Dockerfile creates the final image to be published to Docker or
# Azure Container Registry
# Create a container with the compiled asp.net core app
FROM mcr.microsoft.com/dotnet/aspnet:2.1
# Create app directory
WORKDIR /app
# Copy only the deployment artifacts
COPY /out .
ENTRYPOINT ["dotnet", "dotnetcore-sample.dll"]
Definieren der Buildpipeline

  1. Wenn Sie über ein Docker Hub-Konto verfügen und das Image an Ihre Docker-Registrierung übertragen möchten, ersetzen Sie den Inhalt der .vsts-ci.docker.yml Datei durch Folgendes:

    # Build Docker image for this app, to be published to Docker Registry
pool:
  vmImage: 'ubuntu-latest'
variables:
  buildConfiguration: 'Release'
steps:
- script: |
    docker build -f Dockerfile.build -t $(dockerId)/dotnetcore-build:$BUILD_BUILDID .
    docker run --name dotnetcoreapp --rm -d $(dockerId)/dotnetcore-build:$BUILD_BUILDID
    docker cp dotnetcoreapp:app/dotnetcore-tests/TestResults $(System.DefaultWorkingDirectory)
    docker cp dotnetcoreapp:app/dotnetcore-sample/out $(System.DefaultWorkingDirectory)
    docker stop dotnetcoreapp

- task: PublishTestResults@2
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'
    failTaskOnFailedTests: true

- script: |
    docker build -f Dockerfile -t $(dockerId)/dotnetcore-sample:$BUILD_BUILDID .
    docker login -u $(dockerId) -p $pswd
    docker push $(dockerId)/dotnetcore-sample:$BUILD_BUILDID
  env:
    pswd: $(dockerPassword)

    Wenn Sie eine Azure Container-Registrierung konfigurieren und das Image an diese Registrierung übertragen möchten, ersetzen Sie den Inhalt der .vsts-ci.yml Datei durch Folgendes:

    # Build Docker image for this app to be published to Azure Container Registry
pool:
  vmImage: 'ubuntu-latest'
variables:
  buildConfiguration: 'Release'

steps:
- script: |
    docker build -f Dockerfile.build -t $(dockerId)/dotnetcore-build:$BUILD_BUILDID .
    docker run --name dotnetcoreapp --rm -d $(dockerId)/dotnetcore-build:$BUILD_BUILDID
    docker cp dotnetcoreapp:app/dotnetcore-tests/TestResults $(System.DefaultWorkingDirectory)
    docker cp dotnetcoreapp:app/dotnetcore-sample/out $(System.DefaultWorkingDirectory)
    docker stop dotnetcoreapp

- task: PublishTestResults@2
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'
    failTaskOnFailedTests: true

- script: |
    docker build -f Dockerfile -t $(dockerId).azurecr.io/dotnetcore-sample:$BUILD_BUILDID .
    docker login -u $(dockerId) -p $pswd $(dockerid).azurecr.io
    docker push $(dockerId).azurecr.io/dotnetcore-sample:$BUILD_BUILDID 
  env:
    pswd: $(dockerPassword)

  2. Pushen Sie die Änderung an den Hauptzweig in Ihrem Repository.

  3. Wenn Sie Azure Container Registry verwenden, stellen Sie sicher, dass Sie im Azure-Portal die Registrierung vorab erstellt haben. Kopieren Sie den Benutzernamen und das Kennwort des Administrators, der im Abschnitt Zugriffstasten abschnitt der Registrierungseinstellungen im Azure-Portal angezeigt wird.

  4. Aktualisieren Der Buildpipeline mit den folgenden Schritten

    • Agentpool-: Hosted Ubuntu 1604
      • dockerId: Legen Sie den Wert auf Ihre Docker-ID für DockerHub oder den Administratorbenutzernamen für Azure Container Registry fest.
      • dockerPassword: Legen Sie den Wert auf Ihr Kennwort für DockerHub oder das Administratorkennwort Azure Container Registry fest.
    • YAML-Dateipfad: /.vsts-ci.docker.yml

  5. Stellen Sie einen neuen Build in die Warteschlange, und schauen Sie sich an, wie ein Docker-Image erstellt und an Ihre Registrierung übertragen wird, und die Testergebnisse an Azure DevOps.

Anforderungen

Anforderung BESCHREIBUNG
Pipelinetypen YAML, Classic Build, Classic Release
Läuft auf Agent, DeploymentGroup
Anforderungen Nichts
Funktionen Dieser Vorgang erfüllt keine Anforderungen für nachfolgende Vorgänge im Auftrag.
Befehlseinschränkungen Jegliche
Settable-Variablen Jegliche
Agentversion 2.0.0 oder höher
Vorgangskategorie Testen