Veröffentlicht am: 7. April 2026
7 Minuten Lesezeit
Der QMetry GitLab Component überträgt Testergebnisse automatisch aus CI/CD-Pipelines in QMetry – ohne manuelle Schritte, mit vollständigem Audit-Trail.

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.

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.

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.

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.

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.
Führende Finanzinstitute stehen vor besonderen Herausforderungen beim Skalieren von Testautomatisierung:
Mögliche Ergebnisse:
Die Softwareentwicklung in der Luft- und Raumfahrt unterliegt besonderen Anforderungen:
Vor der Integration:
Nach der Integration:
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" ║
║ ║
╚════════════════════════════════════════════════════════════╝
Für Finanzdienstleister (BaFin BAIT, PSD2, SOX):
Für die Luft- und Raumfahrt-Zertifizierung (DO-178C, DO-254):
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.
.gitlab-ci.yml-SyntaxDie 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) |
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}
| 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) |
Hat dir dieser Blogbeitrag gefallen? Hast du Fragen oder Feedback? Erstelle ein neues Diskussionsthema im GitLab-Community-Forum und lass andere an deinen Eindrücken teilhaben.
Feedback teilen