JUnit-XML-Integration in Aqua

Zweck: Automatisieren Sie den Ablauf vom Ausführen lokaler/Unit-Tests über die Erstellung von JUnit-XML-Dateien bis hin zur Integration in Aqua als gruppierte Testausführungen (nach Aqua-Test-Szenario) mit erfolgreich/fehlgeschlagenen Ergebnissen, um CI/CD-Sichtbarkeit und Governance zu ermöglichen.

High-Level Flow

1

Entwickler schreiben Tests

Entwickler schreibt/pflegt Tests (CodeceptJS / Playwright) und verwendet dabei Namenskonventionen mit eingebetteten Aqua-IDs.

2

Die Tests ausführen

Tests werden (lokal oder in GitLab CI) ausgeführt und erzeugen dabei eine JUnit-XML-Datei bei output/result.xml.

3

Artefakt erfassen

GitLab CI erfasst das XML als Artefakt und optional einen JUnit-Bericht.

4

Veröffentlichungs-/Importstufe

Ein Veröffentlichungsstadium führt einen Importer aus, der Folgendes tut:

• Authentifizierung bei Aqua (AQUA_URL, AQUA_USER, AQUA_PASSWORD).

• Parsen der JUnit XML.

• Extrahieren von Aqua Test-Szenario-IDs (TS…) und Testfall-IDs (TC…).

• Gruppieren der Fälle nach Szenario-ID.

• Durchführung eines REST API-Aufrufs pro Szenario zur Erstellung von Ausführungen und Ergebnissen.

• Beendet mit dem entsprechenden Statuscode, damit die Pipeline bestehen/nicht bestehen kann.

Testautoring Konventionen

Verwenden Sie IDs innerhalb der Testsuite/Testnamen, damit sie analysiert werden können:

• Szenario (Suite/Klassenname/Titel) Präfix: TS<Ziffern> (z.B. TS1132748 - GitHub)

• Testfall (einzelner Test) Präfix: TC (z.B. TC1132533 - Lade die GitHub-Startseite)

Regex-Muster:

• Szenario-ID: /(TS\d+)/

• Fall-ID: /(TC\d+)/

Wenn eine ID fehlt, behandeln Sie diesen Test als ungültig (Richtlinie: Importfehler oder Überspringen—konfigurierbar, empfohlenes Versagen für Datenintegrität).

Generieren von JUnit XML (CodeceptJS + mocha-junitreporter)

Typisches Skript (bereits konfiguriert):

npm ci
npx playwright install --with-deps
npm run test # Produces output/result.xml

Stellen Sie sicher, dass codecept.conf.ts eine Mocha-Reporter-Konfiguration enthält, die auf output/result.xml verweist (z. B. über mocha-junit-reporter).

Struktur der GitLab CI/CD-Pipeline (.gitlab-ci.yml)

Stufen (empfohlen):

stages:
  - test
  - upload

Beispiel für die Testphase:

execute_tests:
  stage: test
  image: node:20
  script:
    - npm ci
    - npx playwright install --with-deps
    - npm run test
  artifacts:
    when: always
    expire_in: 1 week
    paths:
      - output/
    reports:
      junit: output/result.xml

Hochladen/Importieren: Beispielstufe

upload_to_aqua:
  stage: upload
  image: mcr.microsoft.com/powershell
  dependencies: [execute_tests]
  script:
    - pwsh ./upload.ps1

(Alternativ verwenden Sie ein .NET-Bild / eine benutzerdefinierte Importer-Binärdatei, falls erforderlich.)

Umgebungsvariablen (CI/CD-Geheimnisse)

Einstellungen in GitLab → Einstellungen → CI/CD → Variablen (maskiert & geschützt nach Bedarf):

• AQUA_URL (z. B. https://workshop.aqua-cloud.io/aquaWebNG)

• AQUA_USER

• AQUA_PASSWORD

• OptionalREPORT_FILE (Standard./output/result.xml)

Importeurpflichten (Detailliert)

Für jeden Durchlauf:

1. JUnit XML lesen (REPORT_FILE).

2. Authentifizieren: POST Token-Endpoint → Bearer-Token erhalten.

3. <testsuite> / <testcase>-Knoten parsen.

4. Für jedes <testcase>: a. Szenario-ID extrahieren (in classname oder Parent-Suite-Namen suchen). b. Case-ID extrahieren (in name suchen). c. Status bestimmen: i. Bestanden: Fehlen von <failure> und <error>. ii. Fehlgeschlagen: Vorhandensein von <failure> oder <error> (Nachricht + Stack erfassen, falls vorhanden).

5. Testfälle per Szenario-ID gruppieren (alle mit gleichem TS... zusammen).

6. Pro Szenario JSON-Payload bauen, die alle enthaltenen Fallausführungen enthält.

7. POST an Aqua Project / Execution-Endpoint (je ein Aufruf pro Szenario).

8. Fehlgeschlagene POSTs verfolgen.

9. Mit entsprechendem Code beenden (siehe unten).

Beenden-Codes (Vorgeschlagene Zuordnung)

Code — Bedeutung

• 0 —Erfolg (alle Szenarien gepostet)

• 2 — Authentifizierungsfehler

• 3 — Netzwerk / Endpunkt nicht erreichbar

• 4 — Teilweiser Ausfall (einige Szenarien sind fehlgeschlagen)

• 5 — Ungültiges oder unlesbares XML

• 6 — Eingabefehler: Fehlende erforderliche IDs / Validierungsfehler

• 7 —Unerwartete interne Ausnahme

CI schlägt fehl, wenn der Exit-Code != 0 ist (Standardverhalten in GitLab), was möglicherweise die Pipeline zum Fehlschlagen bringt.

JUnit XML Beispiel

<testsuite name="CodeceptJS" tests="2" failures="0">
  <testcase classname="TS1132748 - GitHub" name="TC1132533 - Load the GitHub homepage" time="2.131" />
  <testcase classname="TS1132748 - GitHub" name="TC1132534 - Load the Google homepage" time="1.842" />
</testsuite>

Troubleshooting

Leer result.xml

Symptom: Leere result.xml Wahrscheinliche Ursache: Tests wurden nicht ausgeführt oder Reporter falsch konfiguriert Aktion: Erneut mit --verbose ausführen, Reporter-Konfiguration überprüfen

401 Unauthorized

Symptom: 401 Unauthorized Wahrscheinliche Ursache: Ungültige Anmeldedaten oder URL Aktion: Überprüfen Sie Umgebungsvariablen und Token-Endpunktpfad

Missing IDs error

Symptom: Fehlende IDs Fehler Wahrscheinliche Ursache: Testnamen folgen nicht der Konvention Aktion: Tests umbenennen, um TS / TC-Präfixe einzuschließen

Partial posting

Symptom: Teilweises Posten Wahrscheinliche Ursache: Netzwerk/API intermittierend Aktion: Wiederholungslogik oder Exit-Code 4 markieren

Pipeline green but no data in Aqua

Symptom: Pipeline grün, aber keine Daten in Aqua Wahrscheinliche Ursache: Importphase übersprungen Aktion: Sicherstellen, dass Phase nicht when: manual ist und Abhängigkeiten korrekt sind

Summary

Diese Einrichtung erzwingt Nachverfolgbarkeit zwischen der automatisierten Testausführung und von Aqua verwalteten Testszenarien/-fällen, indem IDs in Testnamen eingebettet werden. Sie erzeugt standardmäßige JUnit-XML und wandelt diese in strukturierte Aqua-Ausführungen innerhalb der CI/CD-Pipeline um, mit robusten Exit-Codes, die den Pipeline-Ausgang steuern.