Aufgabe "Testergebnisse veröffentlichen"

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

Diese Aufgabe veröffentlicht Testergebnisse in Azure Pipelines oder TFS, wenn Tests ausgeführt werden, um eine umfassende Testberichterstellung und Analyseerfahrung bereitzustellen. Sie können den Testläufer Ihrer Wahl verwenden, der das gewünschte Ergebnisformat unterstützt. Unterstützte Ergebnisformate umfassen 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 veröffentlichen automatisch Testergebnisse in der Pipeline, während Aufgaben wie Ant, Maven, Gulp, Grunt, .NET Core und Xcode Veröffentlichungsergebnisse als Option innerhalb der Aufgabe oder Buildbibliotheken wie Cobertura und JaCoCo bereitstellen. Wenn Sie eine dieser Aufgaben verwenden, benötigen Sie keine separate Aufgabe zum Veröffentlichen von Testergebnissen in der Pipeline.

Die veröffentlichten Testergebnisse werden auf der Registerkarte "Tests" in der Pipelinezusammenfassung angezeigt und helfen Ihnen, die Pipelinequalität zu messen, die Ablaufverfolgung zu überprüfen, Fehler zu beheben und den Besitz von Fehlern zu fördern.

Das folgende Beispiel zeigt die Aufgabe, die zum Veröffentlichen von Testergebnissen konfiguriert ist.

Öffnen der Testverlaufsseite

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.

Überprüfen der Voraussetzungen

Wenn Sie einen selbst gehosteten Windows-Agent verwenden, stellen Sie sicher, dass Ihr Computer diese Erforderliche installiert hat:

Forderungen

[none]

YAML-Codeausschnitt

# Publish Test Results
# Publish test results to Azure Pipelines
- task: PublishTestResults@2
  inputs:
    #testResultsFormat: 'JUnit' # Options: JUnit, NUnit, VSTest, xUnit, cTest
    #testResultsFiles: '**/TEST-*.xml' 
    #searchFolder: '$(System.DefaultWorkingDirectory)' # Optional
    #mergeTestResults: false # Optional
    #failTaskOnFailedTests: false # Optional
    #testRunTitle: # Optional
    #buildPlatform: # Optional
    #buildConfiguration: # Optional
    #publishRunAttachments: true # Optional

Die Standardoption verwendet das JUnit-Format, um Testergebnisse zu veröffentlichen. Wenn Sie VSTest als testRunner verwenden, sollte die Option "testResultsFiles " in **/TEST-*.trx" geändert werden.

testResultsFormat ist ein Alias für den TestRunner-Eingabenamen . Die Ergebnisdateien können von mehreren Läufern erstellt werden, nicht nur einen 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 im Abschnitt "Python " in den Abschnitt "Ökosysteme " dieser Themen, die auch Beispiele für andere Sprachen enthalten.

Argumente

Hinweis

Die unten angegebenen Optionen gelten für die neueste Version des Vorgangs.

Argument Beschreibung
testRunner
Testergebnisformat
(Erforderlich) Geben Sie 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
Standardwert: JUnit
Argumentalias: testResultsFormat
testResultsFiles
Testergebnissedateien
(Erforderlich) Verwenden Sie dies, um eine oder mehrere Testergebnisdateien anzugeben.
- Sie können einen Einzelordner-Wildcard () und rekursive Wildcards (*) verwenden (**). Suchen Sie beispielsweise nach allen XML-Dateien, **/TEST-*.xml deren Namen in allen Unterverzeichnissen beginnen TEST- . Wenn VSTest als Testergebnisformat verwendet wird, sollte der Dateityp in .trx z.B. geändert werden. **/TEST-*.trx
- Mehrere Pfade können durch eine Neueline getrennt werden.
- Akzeptiert zusätzlich Minimatch-Muster.
Schließt z. B. !TEST[1-3].xml Dateien namens TEST1.xml, TEST2.xml, oder TEST3.xml.
Standardwert: **/TEST-*.xml
searchFolder
Suchordner
(Optional) Ordner, der nach den Testergebnisdateien sucht.
Standardwert: $(System.DefaultWorkingDirectory)
mergeTestResults
Zusammenführen von Testergebnissen
Wenn diese Option ausgewählt ist, werden Testergebnisse aller Dateien anhand einer einzelnen Testausführung gemeldet. Wenn diese Option nicht ausgewählt ist, wird für jede Testergebnisdatei eine separate Testausführung erstellt.
Hinweis: Verwenden Sie Seriendrucktestergebnisse, um Dateien aus demselben Testframework zu kombinieren, um sicherzustellen, dass die Ergebniszuordnung und die Dauer korrekt berechnet werden.
Standardwert: false
failTaskOnFailedTests
Fehler beim Auftreten von Testfehlern
(Optional) Wenn die Aufgabe ausgewählt ist, schlägt der Vorgang fehl, wenn eine der Tests in der Ergebnisdatei als fehlgeschlagen markiert ist. Der Standardwert ist "false", wodurch einfach die Ergebnisse aus der Ergebnisdatei veröffentlicht werden.
Standardwert: false
testRunTitle
Testlauftitel
(Optional) Verwenden Sie diese Option, um einen Namen für die Testausführung anzugeben, für die die Ergebnisse gemeldet werden. Variablennamen, die in der Build- oder Releasepipeline deklariert sind, können verwendet werden.
platform
Buildplattform
(Optional) Buildplattform, für die die Testausführung gemeldet werden soll.
Zum Beispiel: x64 oder x86. Wenn Sie eine Variable für die Plattform in Ihrer Buildaufgabe definiert haben, verwenden Sie dies hier.
Argumentalias: buildPlatform
configuration
Buildkonfiguration
Buildkonfiguration, für die die Testausführung gemeldet werden soll. Beispiel: Debuggen oder Release. Wenn Sie eine Variable für die Konfiguration in Ihrer Buildaufgabe definiert haben, verwenden Sie dies hier.
Argumentalias: buildConfiguration
publishRunAttachments
Hochladen von Testergebnissendateien
(Optional) Wenn die Aufgabe ausgewählt ist, lädt die Aufgabe alle Testergebnisdateien als Anlagen in die Testausführung hoch.
Standardwert: true

Zuordnung von Ergebnisformaten

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

`Scope` Feld Visual Studio-Test (TRX)
Testausführung Titel Testlauftitel , der in der Aufgabe angegeben ist
Startdatum /TestRun/Times.Attributes["start"]. Wert
Abschlussdatum /TestRun/Times.Attributes["finish"]. Wert
Duration Datum abgeschlossen - Datum gestartet
Attachments Weitere Informationen finden Sie im Abschnitt " Anlagenunterstützung " unten
Testergebnis Titel /TestRun/Results/UnitTestResult.Attributes["testName"]. Wert oder /TestRun/Results/WebTestResult.Attributes["testName"]. Wert oder /TestRun/Results/TestResultAggregation.Attributes["testName"]. Wert
Startdatum /TestRun/Results/UnitTestResult.Attribute["startTime"]. Wert oder /TestRun/Results/WebTestResult.Attribute["startTime"]. Wert oder /TestRun/Results/TestResultAggregation.Attribute["startTime"]. Wert
Abschlussdatum /TestRun/Results/UnitTestResult.Attribute["startTime"]. Wert + /TestRun/Results/UnitTestResult.Attribute["duration"]. Wert oder /TestRun/Results/WebTestResult.Attribute["startTime"]. Wert + /TestRun/Results/WebTestResult.Attribute["duration"]. Wert oder /TestRun/Results/TestResultAggregation.Attribute["startTime"]. Wert + /TestRun/Results/TestResultAggregation.Attribute["duration"]. Wert
Duration /TestRun/Results/UnitTestResult.Attribute["duration"]. Wert oder /TestRun/Results/WebTestResult.Attribute["duration"]. Wert oder /TestRun/Results/TestResultAggregation.Attribute["duration"]. Wert
Besitzer /TestRun/TestDefinitions/UnitTest/Owner.Attribute["name"]. Wert
Ergebnis /TestRun/Results/UnitTestResult.Attribute["result"]. Wert oder /TestRun/Results/WebTestResult.Attribute["result"]. Wert oder /TestRun/Results/TestResultAggregation.Attribute["result"]. Wert
Fehlermeldung /TestRun/Results/UnitTestResult/Output/ErrorInfo/Message.InnerText oder /TestRun/Results/WebTestResultOutput/ErrorInfo/Message.InnerText oder /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
Attachments Siehe Abschnitt "Anlagenunterstützung" 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 /TestResultAggregation/Output/StdErr.InnerText
Agent-Name /TestRun/Results/UnitTestResult.Attribute["computerName"]. Wert oder /TestRun/Results/WebTestResult.Attribute["computerName"]. Wert oder /TestRun/Results/TestResultAggregation.Attribute["computerName"]. Wert
Testdatei /TestRun/TestDefinitions/UnitTest.Attribute["storage"]. Wert
Priorität /TestRun/TestDefinitions/UnitTest.Attribute["priority"]. Wert

Hinweis

Die Dauer wird nur verwendet, wenn Datum gestartet und Datum abgeschlossen ist, nicht verfügbar.

Das vollqualifizierte Nameformat für testName istNamespace.Testclass.Methodname mit einem Zeichenlimit von 512. Wenn der Test datengesteuert ist und Parameter aufweist, enthält die Zeichengrenze die Parameter.

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: Build- und Tests, die in der Pipeline ausgeführt werden, und Testergebnisse werden mithilfe der Aufgabe " Testergebnisse veröffentlichen" veröffentlicht.
  • Erstellen und Testen mit einer mehrstufigen Dockerfile: Build- und Tests werden innerhalb des Containers mit einer mehrstufigen Docker-Datei ausgeführt, z. B. Testergebnisse werden nicht in der Pipeline veröffentlicht.
  • Erstellen, Testen und Veröffentlichen von Ergebnissen mit einer Dockerfile: Build- und Tests werden innerhalb des Containers ausgeführt und Ergebnisse werden wieder in der Pipeline veröffentlicht. Betrachten Sie das folgende Beispiel.

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

In diesem Ansatz erstellen Sie Ihren Code und führen Tests im Container mithilfe einer Docker-Datei aus. Die Testergebnisse werden dann in den Host kopiert, der in die 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 Bild wird in Docker oder Azure Container Registry veröffentlicht.

Abrufen des Codes

  1. Erstellen Sie eine Dockerfile.build Datei im Stammverzeichnis Ihres Projekts mit folgenden Aktionen:

    # 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 Bild so klein wie möglich zu machen, das nur die Laufzeit- und Bereitstellungsartefakte enthält, ersetzen Sie den Inhalt des vorhandenen Dockerfile Elements 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 verschieben 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 ein Azure Container Registry konfigurieren und das Bild an diese Registrierung verschieben 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 die Registrierung im Azure-Portal vorab erstellt haben. Kopieren Sie den Administratorbenutzernamen und das Kennwort im Abschnitt "Zugriffsschlüssel" der Registrierungseinstellungen in Azure-Portal.

  4. Aktualisieren Der Buildpipeline mit folgendem Beispiel

    • 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. Warteschlange eines neuen Builds und überwachen Sie es, um ein Docker-Image in Ihre Registrierung und die Testergebnisse auf Azure DevOps zu verschieben.

YAML-Builds sind noch nicht auf TFS verfügbar.

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)

`Scope` type `Path`
Testlauf Datensammler /TestRun/ResultSummary/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attribute["href"]. Wert
Testergebnis /TestRun/ResultSummary/ResultFiles/ResultFile.Attribute["path"]. Wert
Code Coverage /TestRun/TestSettings/Execution/AgentRule/DataCollectors/DataCollector/Configuration/CodeCoverage/Regular/CodeCoverageItem.Attribute["binaryFile"]. Wert und /TestRun/TestSettings/Execution/AgentRule/DataCollectors/DataCollector/Configuration/CodeCoverageItem.Attribute["pdbFile"]. Wert
Testergebnis Datensammler /TestRun/Results/UnitTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attribute["href"]. Wert oder /TestRun/Results/WebTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attribute["href"]. Wert oder /TestRun/Results/TestResultAggregation/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attribute["href"]. Wert
Testergebnis /TestRun/Results/UnitTestResult/ResultFiles/ResultFile.Attribute["path"]. Wert oder /TestRun/Results/WebTestResult/ResultFiles/ResultFile.Attribute["path"]. Wert oder /TestRun/Results/TestResultAggregation/ResultFiles/ResultFile.Attribute["path"]. Wert

NUnit 3

`Scope` `Path`
Testlauf /test-suite/attachments/attachment/filePath
Testlauf /test-suite[@type='Assembly']/test-case/attachments/attachment/filePath

Hinweis

Die Option zum Hochladen der Testergebnissedatei als Anlage ist eine Standardoption in der Aufgabe, die auf alle Formate anwendbar ist.

Häufig gestellte Fragen

Was ist die maximale zulässige Grenze von FQN?

Die maximale FQN-Grenze beträgt 512 Zeichen.

Enthält die FQN-Zeichengrenze auch Eigenschaften und deren Werte bei datengesteuerten Tests?

Ja, die FQN-Zeichengrenze enthält Eigenschaften und deren Werte.

Unterscheidet sich der FQN für Unterergebnisse?

Derzeit werden Unterergebnisse aus den datengesteuerten Tests nicht in den entsprechenden Daten angezeigt.

Beispiel: Ich habe einen Testfall: Hinzufügen eines Produkts zum Einkaufswagen Data 1: Product = Bekleidungsdaten 2: Produkt = Fußzeilen

Alle veröffentlichten Testunterergebnisse verfügen nur über den Testfallnamen und die Daten der ersten Zeile.

Quelle öffnen

Diese Aufgabe wird auf GitHub Open Source. Feedback und Beiträge sind willkommen.

Hilfe und Support