Automatische Testergebnisse übernehmen¶

Die Web-Anwendung unterstützt den Import von JUnit-XML, TRX und NUnit-3-XML. Damit werden Ergebnisse automatisierter Tests normalen geplanten Testfallvarianten zugeordnet. Manuelle und importierte Ergebnisse erscheinen gemeinsam in den vorhandenen Testlauf- und Release-Auswertungen. Die Herkunft des Imports bleibt nachvollziehbar.

Vorbereiten¶

Legen Sie die benötigten Testfälle, Varianten und den Testlauf vorher an. Ein eigener Testlauf für einen automatisierten Build erleichtert die Zuordnung und schützt manuelle Arbeit. Sie benötigen die normalen Lese- und Ergebnisbearbeitungsrechte für den gewählten Lauf und seine Varianten.

Der Import startet keine Programme und ruft keinen CI-Server auf. Er verarbeitet ausschließlich die ausgewählte XML-Ergebnisdatei. Das Format wird anhand des Inhalts erkannt; TRX-Dateien dürfen die Endung .trx haben. Vorhandene Windows-Skripte und MCP-Ergebnisaktionen bleiben verfügbar.

Vorschau und Übernahme¶

1. Öffnen Sie den gewünschten Testlauf und den Einstieg für automatische Testergebnisse im Web.
2. Wählen Sie die Ergebnisdatei aus und geben Sie eine verständliche Quelle und eine Build-Kennung an. Laden Sie keine Zugangsdaten oder vertraulichen Protokolle hoch.
3. Ordnen Sie jeden zu übernehmenden externen Test ausdrücklich einer geplanten Variante und einer passenden Ergebnisdefinition des Projekts zu. Ähnliche Titel werden nicht automatisch als identisch behandelt.
4. Prüfen Sie die Vorschau. Nicht zugeordnete, übersprungene und blockierte Zeilen sind keine erfolgreichen Tests.
5. Bestätigen Sie erst danach die Übernahme und kontrollieren Sie den Ergebnisstatus jeder Zeile. Bei einem Teilfehler wurden möglicherweise bereits andere Zeilen übernommen.

Die Datei darf höchstens 2 MiB und 1000 Testfälle enthalten. Doppelte externe Identitäten, widersprüchliche Statusangaben, ungültige Dauer und XML mit externen Entitäten werden abgewiesen. Ein übersprungener externer Test erzeugt kein ausgeführtes oder erfolgreiches Ergebnis. Quick-Testzeilen werden durch diesen Import nicht unterstützt.

Unterstützte Formate und Grenzen¶

• JUnit-XML: unter anderem aus pytest, PHPUnit und Playwright. Für diese drei Reporter liegen dauerhaft geprüfte Beispielexporte vor. JUnit ist hier ein Austauschformat, keine Beschränkung auf Java oder Unit-Tests.
• TRX: Visual-Studio-Testberichte im TeamTest-2010-XML-Format. Passed wird erfolgreich, Failed, Error und Timeout werden fehlgeschlagen, NotExecuted wird übersprungen zugeordnet. Verschachtelte Datenzeilen (InnerResults) werden noch nicht unterstützt.
• NUnit-3-XML: Ergebnisse aus dem NUnit-Format mit test-run als Wurzel. Parametrisierte Fälle bleiben anhand ihres vollständigen Namens getrennt. Passed, Failed und Skipped werden übernommen.

Unklare, abgebrochene oder nicht unterstützte Status werden abgewiesen. Erkannte Wiederholungs-/Flaky-Markierungen, doppelte Testidentitäten und widersprüchliche Erfolgsangaben werden nicht still als Erfolg importiert. Liefert ein Reporter nur das letzte Ergebnis ohne Wiederholungsnachweis, lässt sich ein früherer Fehlversuch daraus nicht rekonstruieren. Anhänge, Konsolenausgaben und Laufumgebungen werden nicht automatisch übernommen; Fehlerdiagnosen werden begrenzt als Ergebnisbeschreibung importiert. Der Quellbericht ersetzt keine Vollständigkeitsprüfung des Testumfangs.

Schutz vorhandener Arbeit¶

Vor der Übernahme werden Rechte, Laufstatus, Voraussetzungen und Zielergebnisse erneut geprüft. Abgeschlossene Läufe und bereits manuell bearbeitete Ergebnisse werden nicht überschrieben. Notizen, Dauer und Anhänge zählen ebenfalls zur vorhandenen Arbeit. Erforderliche Zusatzfelder und Testfall-Abhängigkeiten behalten ihre normalen Prüfungen.

Eine identische Wiederholung derselben Importkennung und Zuordnung erzeugt keine doppelten Ergebnisse. Eine bereits verwendete Kennung mit verändertem Inhalt oder zwischenzeitlich geänderten Ergebnissen führt zu einem Konflikt. Prüfen Sie die betroffenen Zeilen, statt einen fehlgeschlagenen Import als vollständig übernommen anzusehen. Für einen erneuten Versuch nach einem Teilfehler erstellen Sie eine neue Vorschau mit derselben Importkennung und Zuordnung. Das erneute Bestätigen derselben Vorschau liefert nur deren bisherige Quittung.

Herkunft und Aussagegrenzen¶

Quelle, Build-Kennung, Importeur und Importzeit beschreiben die Erfassung. Sie beweisen nicht, wer den automatisierten Test tatsächlich ausgeführt hat oder wann dies geschah. Eine unbekannte Ausführungszeit bleibt unbekannt. Ein importiertes Ergebnis belegt außerdem nicht automatisch, welche Fassung der Testbeschreibung der externe Test geprüft hat.

Deshalb können im Release-Vergleich und in der Release-Ampel weiterhin Nachweislücken erscheinen. Ein erfolgreiches importiertes Ergebnis allein ersetzt weder einen vollständigen Prüfumfang noch eine fachliche Abnahme. Nach manueller Änderung ist die ursprüngliche Importherkunft kein Nachweis für den aktuellen Ergebnisinhalt.

Windows und MCP¶

Windows liest die normalen Ergebnisse und bietet am passenden Testlauf einen Link zur Webfunktion. Der gemeinsame Webstart übernimmt die bestätigte Windows-Sitzung; nur wenn die Übergabe nicht gelingt, ist eine Anmeldung erforderlich. Die Importoberfläche selbst ist im Web.

MCP verwendet dieselben Vorschau-, Zuordnungs- und Übernahmeprüfungen über ztm_automation_import_read, ztm_automation_import_preview und ztm_automation_import_commit. Es gelten die normalen Projektrechte; für die Übernahme muss zusätzlich project.automation-import.commit als Schreibfähigkeit freigegeben sein. Für MCP gilt außerdem die bestehende Grenze von 1 MiB für den gesamten JSON-Anfragekörper einschließlich XML und JSON-Escaping; größere Dateien bis 2 MiB können Sie im Web importieren. Verwenden Sie die Werkzeugbeschreibungen des verbundenen Servers und bewahren Sie Importkennungen für sichere Wiederholungen auf.