Teilen über

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

  • Artikel

Veröffentlichen sie Testergebnisse in Azure Pipelines.

Veröffentlichen sie Testergebnisse in Azure Pipelines/TFS.

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.

# Publish Test Results v2
# Publish Test Results to Azure Pipelines/TFS.
- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit' # 'JUnit' | 'NUnit' | 'VSTest' | 'XUnit'. 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.
    #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.

Eingaben

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

Gibt das Format der Ergebnisdateien 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.


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

Gibt das Format der Ergebnisdateien 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 - Testergebnisdateien
string. Erforderlich. Standardwert. **/TEST-*.xml.

Gibt mindestens eine Testergebnisdatei an.

  • Sie können einen Platzhalter für einzelne Ordner (*) und rekursive Platzhalter (**) verwenden. **/TEST-*.xml sucht beispielsweise nach allen XML-Dateien, deren Namen in allen Unterverzeichnissen mit TEST- beginnen. Wenn Sie VSTest als Testergebnisformat verwenden, sollte der Dateityp in .trx geändert werden, z. B. **/TEST-*.trx.
  • Es können mehrere Pfade angegeben werden, die durch eine neue Zeile getrennt werden.
  • Akzeptiert außerdem Minimatchmuster.

!TEST[1-3].xml schließt z. B. Dateien mit dem Namen TEST1.xml, TEST2.xml oder TEST3.xml aus.


searchFolder - ordner Search
string. Standardwert. $(System.DefaultWorkingDirectory).

Optional. Gibt den Ordner an, in dem nach den Testergebnisdateien gesucht werden soll.


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

Wenn der Wert dieses booleschen Werts ist, meldet trueder Task Testergebnisse aus allen Dateien für eine einzelne Testausführung. Wenn der Wert ist false, erstellt der Task einen separaten Testlauf für jede Testergebnisdatei.

Hinweis

Verwenden Sie die Einstellung Mergetestergebnisse, um Dateien aus demselben Testframework zu kombinieren, um sicherzustellen, dass die Ergebniszuordnung und -dauer ordnungsgemäß berechnet werden.


failTaskOnFailedTests - Fehler bei Testfehlern
boolean. Standardwert. false.

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


failTaskOnFailureToPublishResults - Fehler bei der Veröffentlichung von Testergebnissen
boolean. Standardwert. false.

Wenn true, schlägt die Aufgabe fehl, wenn bei der Veröffentlichung von Testergebnissen ein Fehler auftritt.


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

Führen Sie einen Fehler beim Task durch, wenn keine Ergebnisdateien gefunden werden.


testRunTitle - Titel der Testausführung
string.

Optional. Gibt einen Namen für die Testausführung an, für die die Ergebnisse gemeldet werden. In der Build- oder Releasepipeline deklarierte Variablennamen können verwendet werden.


buildPlatform - Plattform erstellen
Eingabealias: platform. string.

Optional. Gibt die Buildplattform an, auf der die Testausführung gemeldet werden soll. Zum Beispiel: x64 oder x86. Wenn Sie eine Variable für die Plattform in Ihrem Buildtask definiert haben, verwenden Sie sie hier.


buildConfiguration - Buildkonfiguration
Eingabealias: configuration. string.

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


publishRunAttachments - Hochladen von Testergebnisdateien
boolean. Standardwert. true.

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


Optionen für die Vorgangskontrolle

Alle Vorgänge verfügen zusätzlich zu ihren Eingaben über Steuerungsoptionen. Weitere Informationen finden Sie unter Steuerungsoptionen und allgemeine Aufgabeneigenschaften.

Ausgabevariablen

Keine.

Hinweise

Diese Aufgabe veröffentlicht Testergebnisse in Azure Pipelines oder TFS, wenn Tests ausgeführt werden, um eine umfassende Testberichterstellungs- und Analyseumgebung bereitzustellen. Sie können den Testrunner Ihrer Wahl verwenden, der das gewünschte Ergebnisformat unterstützt. Zu den unterstützten Ergebnisformaten gehören CTest, JUnit (einschließlich PHPUnit), NUnit 2, NUnit 3, Visual Studio Test (TRX) und xUnit 2.

Andere integrierte Aufgaben, z. B . Visual Studio Test-Task und Dot NetCore CLI-Task , veröffentlichen Automatisch Testergebnisse in der Pipeline. Aufgaben wie Ant, Maven, Gulp, Grunt und Xcode bieten Veröffentlichungsergebnisse als Option innerhalb der Aufgabe oder erstellen Bibliotheken wie Cobertura und JaCoCo. 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. Die Ergebnisse helfen Ihnen dabei, die Qualität der Pipeline zu messen, die Rückverfolgbarkeit zu überprüfen, Fehler zu beheben und den Besitz von Laufwerksfehlern zu überprüfen.

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

Öffnen der Testverlaufsseite

Sie können diese Aufgabe auch in einer Buildpipeline verwenden, um Code Coverage-Ergebnisse zu veröffentlichen, die beim Ausführen von Tests in Azure Pipelines oder TFS erstellt wurden, um Berichte zur Abdeckung zu erhalten.

Voraussetzungen

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

Aufgabenstandardeinstellungen

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 Runnern und nicht nur von einem bestimmten Runner erstellt werden. Beispielsweise wird das jUnit-Ergebnisformat von vielen Runnern und nicht nur von jUnit unterstützt.

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

Zuordnung von Ergebnisformaten

In dieser Tabelle werden die Felder aufgelistet, die auf der Registerkarte „Tests“ in einer Build- oder Releasezusammenfassung gemeldet werden, und die entsprechende Zuordnung mit den Attributen in den unterstützten Testergebnisformaten.

`Scope` Feld Visual Studio Test (TRX)
Testlauf Titel In der Aufgabe angegebener Testlauftitel
Startdatum /TestRun/Times.Attributes["start"].Value
Abschlussdatum /TestRun/Times.Attributes["finish"].Value
Duration Abschlussdatum – Startdatum
Attachments Weitere Informationen finden Sie weiter unten im Abschnitt Anlagenunterstützung.
Testergebnis Titel /TestRun/Results/UnitTestResult.Attributes["testName"].Value Oder /TestRun/Results/WebTestResult.Attributes["testName"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["testName"].Value
Startdatum /TestRun/Results/UnitTestResult.Attributes["startTime"].Value Oder /TestRun/Results/WebTestResult.Attributes["startTime"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["startTime"].Value
Abschlussdatum /TestRun/Results/UnitTestResult.Attributes["startTime"].Value + /TestRun/Results/UnitTestResult.Attributes["duration"].Value Oder /TestRun/Results/WebTestResult.Attributes["startTime"].Value + /TestRun/Results/WebTestResult.Attributes["duration"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["startTime"].Value + /TestRun/Results/TestResultAggregation.Attributes["duration"].Value
Duration /TestRun/Results/UnitTestResult.Attributes["duration"].Value Oder /TestRun/Results/WebTestResult.Attributes["duration"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["duration"].Value
Besitzer /TestRun/TestDefinitions/UnitTest/Owners/Owner.Attributes["name"].Value
Ergebnis /TestRun/Results/UnitTestResult.Attributes["outcome"].Value Oder /TestRun/Results/WebTestResult.Attributes["outcome"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["outcome"].Value
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
Attachments Weitere Informationen finden Sie weiter unten im Abschnitt Anlagenunterstützung.
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
Agent-Name /TestRun/Results/UnitTestResult.Attributes["computerName"].Value Oder /TestRun/Results/WebTestResult.Attributes["computerName"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["computerName"].Value
Testdatei /TestRun/TestDefinitions/UnitTest.Attributes["storage"].Value
Priority /TestRun/TestDefinitions/UnitTest.Attributes["priority"].Value

Hinweis

Dauer wird nur verwendet, wenn Startdatum und Abschlussdatum 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 aufweist, enthält das Zeichenlimit die Parameter.

Beim Veröffentlichen des Testergebnisses erhalten Sie möglicherweise folgende Fehlermeldung: Fehler beim Veröffentlichen von Testergebnissen: Ungültige Priorität angegeben

Dieser Fehler tritt auf, wenn für eine der Testmethoden die Priorität über 255 festgelegt ist, die Testmethodenpriorität im Code behoben und die Tests erneut ausgeführt werden. Sie können die generierte trx-Datei überprüfen, um zu sehen, dass alle Tests die Priorität größer als 255 haben.

Anlagenunterstützung

Die Aufgabe „Testergebnisse veröffentlichen“ bietet Unterstützung für Anlagen für Testläufe und Testergebnisse für die folgenden Formate. Für öffentliche Projekte unterstützen wir insgesamt 2 GB Anlagen.

Visual Studio Test (TRX)

`Scope` type Pfad
Testlauf Datensammler /TestRun/ResultSummary/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"].Value
Testergebnis /TestRun/ResultSummary/ResultFiles/ResultFile.Attributes["path"].Value
Code Coverage /TestRun/TestSettings/Execution/AgentRule/DataCollectors/DataCollector/Configuration/CodeCoverage/Regular/CodeCoverageItem.Attributes["binaryFile"].Value Und /TestRun/TestSettings/Execution/AgentRule/DataCollectors/DataCollector/Configuration/CodeCoverage/Regular/CodeCoverageItem.Attributes["pdbFile"].Value
Testergebnis Datensammler /TestRun/Results/UnitTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"].Value Oder /TestRun/Results/WebTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"].Value Oder /TestRun/Results/TestResultAggregation/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"].Value
Testergebnis /TestRun/Results/UnitTestResult/ResultFiles/ResultFile.Attributes["path"].Value Oder /TestRun/Results/WebTestResult/ResultFiles/ResultFile.Attributes["path"].Value Oder /TestRun/Results/TestResultAggregation/ResultFiles/ResultFile.Attributes["path"].Value

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

Erstellen, Testen und Veröffentlichen von Ergebnissen mit einem Dockerfile

Bei diesem Ansatz erstellen Sie Ihren Code und führen Tests im Container mithilfe eines Dockerfiles aus. Die Testergebnisse werden dann auf den Host kopiert, um in der Pipeline veröffentlicht zu werden. 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.

Abrufen des Codes

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

    # 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 zum Ausführen von Tests. Die Tests werden dann in eine Datei testresults.trx im Container kopiert.

  2. Um das endgültige Image, das nur die Laufzeit- und Bereitstellungsartefakte enthält, so klein wie möglich zu machen, ersetzen Sie den Inhalt des 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 per Push an Ihre Docker-Registrierung übertragen möchten, ersetzen Sie den Inhalt der Datei .vsts-ci.docker.yml 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 alternativ eine Azure Container Registry konfigurieren und das Image per Push in diese Registrierung übertragen möchten, ersetzen Sie den Inhalt der Datei .vsts-ci.yml 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 Mainbranch 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 der Administratorin/des Administrators, die im Abschnitt Zugriffsschlüssel der Registrierungseinstellungen im Azure-Portal angezeigt werden.

  4. Aktualisieren Sie Ihre Buildpipeline wie folgt:

    • Agent-Pool: 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 für Azure Container Registry fest.
    • YAML-Dateipfad: /.vsts-ci.docker.yml

  5. Stellen Sie einen neuen Build in eine Warteschlange, und beobachten Sie, wie er ein Docker-Image erstellt und an Ihre Registrierung pusht und die Testergebnisse an Azure DevOps pusht.

Anforderungen

Anforderung BESCHREIBUNG
Pipelinetypen YAML, Klassischer Build, klassisches Release
Wird ausgeführt auf Agent, DeploymentGroup
Forderungen Keine
Capabilities Diese Aufgabe erfüllt keine Anforderungen an nachfolgende Aufgaben im Auftrag.
Befehlseinschränkungen Any
Setzbare Variablen Any
Agent-Version 2.0.0 oder höher
Aufgabenkategorie Testen