In modernen Entwicklungsumgebungen müssen DevSecOps-Teams Testergebnisse aus CI/CD-Pipelines konsistent in Testmanagement-Plattformen übertragen, um Transparenz, Nachvollziehbarkeit und Compliance über den gesamten Entwicklungszyklus zu gewährleisten.
Teams, die GitLab für CI/CD und SmartBear QMetry für das Testmanagement einsetzen, verbringen Zeit mit manuellem Export und Import von Testergebnissen – das verzögert Feedback und erschwert eine zuverlässige, zentrale Testsicht.
Der QMetry GitLab Component automatisiert diesen Prozess. Die wiederverwendbare CI/CD-Komponente, verfügbar im GitLab CI/CD Catalog, überträgt Testausführungsdaten nach jeder Pipeline-Ausführung automatisch nach QMetry – einer KI-gestützten, unternehmenstauglichen Testmanagement-Plattform, die Testplanung, -ausführung, -nachverfolgung und -reporting in einer Lösung vereint.
Als zentrales System der Aufzeichnung für Tests hilft QMetry Teams dabei, Abdeckung und Ausführung nachzuverfolgen und fundiertere Release-Entscheidungen zu treffen.
Vorteile der Integration
Manuelle Uploads entfallen, Nachvollziehbarkeit steigt
DevSecOps-Engineers und QA-Teams müssen Testergebnisse nicht mehr manuell exportieren und importieren – die Komponente übernimmt das automatisch nach jeder Pipeline-Ausführung. Zugleich erhalten Teams vollständige Nachvollziehbarkeit von Anforderungen über Testfälle bis hin zu tatsächlichen Ausführungsergebnissen.
Compliance- und Audit-Anforderungen erfüllen
Für Organisationen in regulierten Branchen ist lückenlose Testdokumentation nicht verhandelbar. Die Integration stellt sicher, dass jede Testausführung in QMetry mit Verknüpfungen zur jeweiligen GitLab-Pipeline, zum Commit und zum Build dokumentiert wird – ohne zusätzlichen manuellen Aufwand.
KI-gestützte Test-Insights nutzen
QMetry analysiert mithilfe von KI Testausführungsmuster, identifiziert instabile Tests, prognostiziert Testfehler und empfiehlt Optimierungsmöglichkeiten. Echtzeit-Daten aus GitLab-Pipelines maximieren den Wert dieser Funktionen.
Über die GitLab-SmartBear-Partnerschaft
Diese Komponente steht für die wachsende Partnerschaft zwischen GitLab und SmartBear, CI/CD-Ausführung und Testmanagement in einem Workflow zu verbinden. Gemeinsam helfen sie Teams, Testing in den Entwicklungszyklus zu integrieren und dabei die Qualitäts-, Sicherheits- und Compliance-Standards ihrer Branchen einzuhalten.
Praxisbeispiele
Finanzdienstleistungen: Enterprise-Banking-Plattformen
Führende Finanzinstitute stehen vor besonderen Herausforderungen beim Skalieren von Testautomatisierung:
- Regulatorische Compliance: Detaillierte Audit-Trails für alle Testaktivitäten erforderlich
- Mehrere Compliance-Frameworks: BaFin BAIT, PSD2, DSGVO und interne Risikomanagement-Richtlinien
- Hochfrequente Deployments: Mehrere Produktions-Deployments täglich über Microservices
- Verteilte Teams: Echtzeit-Transparenz über globale Engineering-Teams hinweg erforderlich Finanzdienstleister, die den QMetry GitLab Component einsetzen, automatisieren Testergebnis-Uploads für Unit-Tests, API-Contract-Tests, End-to-End-Tests für Transaktionsabläufe sowie Security- und Performance-Testergebnisse.
Mögliche Ergebnisse:
- Deutliche Reduzierung des manuellen Test-Reporting-Aufwands
- Vollständige Audit-Trail-Abdeckung für Regulierungsprüfungen
- Echtzeit-Transparenz für verteilte QA-Teams
- Verbesserte Compliance-Position durch vollständige Nachvollziehbarkeit von Anforderungen bis zur Testausführung
Flugregelungssoftware in der Luft- und Raumfahrt
Die Softwareentwicklung in der Luft- und Raumfahrt unterliegt besonderen Anforderungen:
- DO-178C-Compliance: Avioniksoftware muss strikte Zertifizierungsstandards erfüllen
- Vollständige Nachvollziehbarkeit: Jede Anforderung verknüpft mit Testfällen und Ausführungsergebnissen
- Audit-Trails: Zertifizierungsbehörden verlangen detaillierte Aufzeichnungen aller Testaktivitäten
- Mehrere Teststufen: Unit-, Integrations-, System- und Zertifizierungstests Durch die Integration von GitLab CI/CD mit QMetry automatisiert das Aerospace-Engineering-Team Testausführung und Reporting über alle Teststufen hinweg.
Vor der Integration:
- Manueller Export aus GitLab, Import in QMetry über UI-Uploads
- Prozess dauerte 2–3 Stunden pro Testzyklus
- Fehlerrisiko bei der Dateneingabe, verzögerte Rückmeldung an Stakeholder
Nach der Integration:
- Testergebnisse fließen automatisch von GitLab nach QMetry
- Vollständiger Audit-Trail vom Commit über den Test bis zum Ergebnis
- Kein manueller Eingriff, Echtzeit-Transparenz für Zertifizierungsprüfer
- Compliance-Reports werden automatisch erstellt
Beispiel-Dashboard in QMetry nach der Integration:
╔════════════════════════════════════════════════════════════╗
║ Flight Control System v2.4 - Test Execution Dashboard ║
╠════════════════════════════════════════════════════════════╣
║ ║
║ 📊 Test Execution Summary (Last 7 Days) ║
║ ───────────────────────────────────────────────────────── ║
║ ✓ Total Tests Executed: 1,247 ║
║ ✓ Passed: 1,241 (99.5%) ║
║ ✗ Failed: 6 (0.5%) ║
║ ⏸ Skipped: 0 ║
║ ║
║ 📁 Test Suite Organization ║
║ ───────────────────────────────────────────────────────── ║
║ └─ Certification/ ║
║ └─ DO-178C/ ║
║ ├─ Unit/ (487 tests, 100% pass) ║
║ ├─ Integration/ (623 tests, 99.2% pass) ║
║ └─ System/ (137 tests, 100% pass) ║
║ ║
║ 🔗 Traceability ║
║ ───────────────────────────────────────────────────────── ║
║ Requirements Covered: 342/342 (100%) ║
║ Test Cases Linked: 1,247/1,247 (100%) ║
║ GitLab Pipeline Executions: 47 (automated) ║
║ ║
║ ⚠️ Action Items ║
║ ───────────────────────────────────────────────────────── ║
║ • 6 failed tests require investigation ║
║ • Last execution: 2 minutes ago (Pipeline #1543) ║
║ • GitLab Commit: a7f8c23 "Fix altitude hold logic" ║
║ ║
╚════════════════════════════════════════════════════════════╝
Compliance- und Audit-Vorteile
Für Finanzdienstleister (BaFin BAIT, PSD2, SOX):
- Automatische Nachvollziehbarkeit: Regulatorische Anforderungen → Testfälle → Ausführungsergebnisse → GitLab-Commits verknüpft
- Auditfähige Dokumentation: Vollständige Testausführungshistorie mit Zeitstempeln und Pipeline-Referenzen
- Regulatorisches Reporting: Compliance-Reports direkt aus QMetry-Testdaten generieren
Für die Luft- und Raumfahrt-Zertifizierung (DO-178C, DO-254):
- Automatische Nachverfolgbarkeitsmatrix: Anforderungen → Testfälle → Ausführungsergebnisse → GitLab-Commits
- Unveränderlicher Audit-Trail: Pipeline-ID, Commit-SHA und Ausführer für jede Testausführung gestempelt
- Zertifizierungspaket-Generierung: Konforme Dokumentation aus GitLab-Pipeline-Daten
Technische Umsetzung
Dieser Abschnitt orientiert Teams, die die Integration einrichten möchten. Die vollständige Schritt-für-Schritt-Anleitung mit allen Konfigurationsdetails – API-Credentials, CI/CD-Variablen, Testformate, erweiterte Optionen und Fehlerbehebung – ist im englischen Originalbeitrag verfügbar.
Voraussetzungen
- GitLab-Account mit einem Projekt, das automatisierte Tests enthält und Testergebnisdateien erzeugt (JUnit XML, TestNG XML usw.)
- QMetry Test Management Enterprise-Account mit aktiviertem API-Zugriff und generiertem API-Key
- QMetry-Projekt, bereits angelegt, in das Testergebnisse hochgeladen werden sollen
- Kenntnisse in GitLab CI/CD, einschließlich grundlegender
.gitlab-ci.yml-Syntax
Ablauf der Testergebnis-Übertragung
- Testausführung: Die GitLab CI/CD-Pipeline führt automatisierte Tests aus.
- Ergebnisgenerierung: Tests erzeugen Ausgabedateien (JUnit XML, TestNG XML usw.).
- Komponentenaufruf: Die QMetry-Komponente wird als Job in der Pipeline ausgeführt.
- Automatischer Upload: Die Komponente liest die Testergebnisdateien und lädt sie via API nach QMetry hoch.
- QMetry-Verarbeitung: QMetry empfängt die Ergebnisse und stellt sie für Reporting und Analyse bereit.
Basisintegration
Die Komponente in der .gitlab-ci.yml-Datei einbinden. Die Komponente sollte nach dem Abschluss der Tests ausgeführt werden:
include:
- component: gitlab.com/sb9945614/qtm-gitlab-component/[email protected]
inputs:
stage: test
project: "Aerospace Flight Control System"
file_name: "results.xml"
testing_type: "JUNIT"
instance_url: ${INSTANCE_URL}
api_key: ${QMETRY_API_KEY}
| Parameter | Beschreibung | Beispiel |
|---|---|---|
stage | CI/CD-Stage für den Upload-Job | test |
project | QMetry-Projektname oder -Schlüssel | "Aerospace Flight Control System" |
file_name | Pfad zur Testergebnisdatei | "results.xml" |
testing_type | Format der Testergebnisse | "JUNIT" (auch: TESTNG, NUNIT usw.) |
instance_url | QMetry-Instanz-URL | ${INSTANCE_URL} (aus CI/CD-Variablen) |
api_key | QMetry API-Key zur Authentifizierung | ${QMETRY_API_KEY} (aus CI/CD-Variablen) |
Vollständiges Pipeline-Beispiel
stages:
- test
- report
variables:
NODE_VERSION: "18"
unit-tests:
stage: test
image: node:${NODE_VERSION}
script:
- npm ci
- npm run test:unit -- --reporter=junit --reporter-options=output=results.xml
artifacts:
reports:
junit: results.xml
paths:
- results.xml
when: always
tags:
- docker
include:
- component: gitlab.com/sb9945614/qtm-gitlab-component/[email protected]
inputs:
stage: test
project: "Aerospace Flight Control System"
file_name: "results.xml"
testing_type: "JUNIT"
instance_url: ${INSTANCE_URL}
api_key: ${QMETRY_API_KEY}
Vollständige Konfigurationsreferenz
| Eingabeparameter | Pflichtfeld | Standard | Beschreibung |
|---|---|---|---|
stage | Nein | test | GitLab CI/CD-Stage für den Upload-Job |
runner_tag | Nein | "" | Spezifischer Runner-Tag (leer = beliebiger verfügbarer Runner) |
project | Ja | – | QMetry-Projektname oder -Schlüssel |
file_name | Ja | – | Pfad zur Testergebnisdatei (relativ zum Projektstamm) |
testing_type | Ja | – | Testergebnisformat: JUNIT, TESTNG, NUNIT usw. |
skip_warning | Nein | "1" | Warnungen beim Import überspringen ("1" = überspringen, "0" = anzeigen) |
is_matching_required | Nein | "false" | Bestehende Testfälle nach Name abgleichen ("true" oder "false") |
testsuite_name | Nein | "" | Name für die Test-Suite in QMetry |
testsuite_id | Nein | "" | Bestehende Test-Suite-ID, an die Ergebnisse angehängt werden |
testsuite_folder_path | Nein | "" | Ordnerpfad für die Test-Suite-Organisation (z. B. /Regression/Sprint-23) |
automation_hierarchy | Nein | "" | Hierarchieebene für die Testorganisation ("1", "2", "3" usw.) |
testcase_fields | Nein | "" | Benutzerdefinierte Felder für Testfälle (kommagetrennt: field1=value1,field2=value2) |
testsuite_fields | Nein | "" | Benutzerdefinierte Felder für Test-Suites (kommagetrennt: field1=value1,field2=value2) |
instance_url | Ja | – | QMetry-Instanz-URL (in CI/CD-Variablen speichern) |
api_key | Ja | – | QMetry API-Key (in CI/CD-Variablen speichern, maskiert) |
Dokumentation und Support
- Komponentendokumentation: GitLab CI/CD Catalog
- Komponenten-Repository: gitlab.com/sb9945614/qtm-gitlab-component
- QMetry-Dokumentation: QMetry Support Portal
- SmartBear-Ressourcen: SmartBear Academy
- GitLab CI/CD-Dokumentation: GitLab CI/CD Documentation
- QMetry-Support: [email protected] – QMetry Community Forum
