KI-gestützte Testautomatisierung in der Fahrzeugsoftware-Entwicklung: Testomat
Testteams werten hunderte Protokolle manuell aus, pflegen Regressionssuiten von Hand und ordnen Fehlermeldungen in langen Abstimmungsrunden zu. Wir bauen den Assistenten Testomat, der fünf wiederkehrende Testaufgaben automatisiert – die Freigabe bleibt in jedem Baustein beim Testingenieur.
Ausgangslage
Der Test von Fahrzeugsoftware erzeugt laufend Arbeit, die kein Ingenieurwissen braucht, aber Ingenieurzeit kostet: Protokolle aus Unit-, Integrations- und HiL-Ebene sichten, Regressionssuiten an jede Änderung anpassen, eingehende Fehlermeldungen der richtigen Komponente zuordnen, Reports nach Vorlage schreiben.
Gleichzeitig bleibt die eigentliche Substanz oft liegen: Die Verknüpfung zwischen Tests und Anforderungen ist lückenhaft, und welche Tests eine konkrete Änderung wirklich braucht, entscheidet mangels Analyse die Vorsicht – es läuft die ganze Suite.
Typische Datengrundlage
Anforderungen und deren Verknüpfung zu bestehenden Testfällen – Traceability-Daten, soweit gepflegt. Bestehende Testfälle, Testskripte, Testprotokolle und Logs aus Unit-, Integrations- und HiL-Ebene. Die Fehlerdatenbank, etwa Jira, mit historischen Tickets und deren Zuordnung zu Komponenten.
Dazu die Änderungshistorie der Software – Commits, Change Requests, Abhängigkeiten zwischen Modulen – und die Angaben zur Testabdeckung aus den automatisierten CI-Tests.
Woran solche Vorhaben scheitern
Heterogene Formate. Protokolle und Logs aus unterschiedlichen Testebenen folgen keinem gemeinsamen Schema. Ohne saubere Vereinheitlichung wertet niemand automatisiert aus.
Lückenhafte Traceability. Die Verknüpfung zwischen Tests und Anforderungen muss teilweise erst rekonstruiert werden, bevor Testfallgenerierung und Regressionsauswahl darauf aufbauen können.
Regressionsauswahl ohne Änderungsanalyse. Welche Tests relevant sind, hängt davon ab, welche Komponenten von einer Änderung betroffen sind. Ohne belastbare Analyse bleibt nur die volle Suite.
Mehrdeutige Fehlerbilder. Dieselbe Symptomatik kann mehrere Ursachen haben – und eine falsche Zuordnung kostet mehr Zeit als gar keine. Stille Fehlzuweisungen sind das teuerste Ergebnis.
Vorgehen
Testfallvorschläge. Aus Anforderungen erzeugt ein Sprachmodell Testfallentwürfe in einem festen Schema, das die Zielstruktur des ALM-Systems abbildet – die Vorschläge sind ohne Nacharbeit importierbar. Für HiL-Testfälle ruft das System vor der Generierung vergleichbare Bestandstestfälle und die zugehörige Prüfstandsdokumentation ab, damit die Entwürfe die Konventionen des Kunden treffen. Eine zweite Instanz prüft jeden Entwurf gegen die Ursprungsanforderung und markiert Vorschläge, die nichts Neues abdecken. Der Testingenieur übernimmt oder verwirft.
Traceability-Rekonstruktion. Fehlende Verknüpfungen stellen wir in drei Schritten wieder her: Zuordnung über Namens- und Nummernkonventionen, semantischer Abgleich der Testbeschreibung gegen den Anforderungstext, Bestätigung der verbleibenden unsicheren Fälle durch die Testingenieure. Das Ergebnis ist eine dokumentierte Trace-Matrix, die auch für den ASPICE-Nachweis nutzbar ist.
Regressionsauswahl. Eine Änderungsanalyse bestimmt die betroffenen Module über den Aufrufgraphen und die Historie gemeinsam geänderter Dateien. Ein Ranking-Modell bewertet darauf und auf den historischen Fehlerdaten, welche Tests für eine konkrete Änderung die höchste Relevanz haben. Die Auswahl läuft in der CI-Kette; sicherheitsrelevante Tests bleiben unabhängig vom Ranking immer im Umfang.
Protokollauswertung und Fehlerklassifikation. Ein Parser überführt die Logformate der Testebenen in ein gemeinsames Ergebnisschema und markiert Abweichungen. Eingehende Fehlermeldungen ordnet ein Klassifikator Komponente und Fehlerklasse zu – mit Konfidenz. Unterhalb einer vereinbarten Schwelle ordnet das System nicht zu, sondern legt dem Triage-Team die drei wahrscheinlichsten Zuordnungen mit den ähnlichsten Alttickets vor.
Reporting. Testreports entstehen automatisiert aus den strukturierten Ergebnissen nach den Vorlagen des Kunden.
Was dabei entsteht
Auffälligkeiten statt Protokollberge: Die Auswertung läuft weitgehend automatisiert – Testingenieure konzentrieren sich auf die Ergebnisse, die wirklich Aufmerksamkeit brauchen.
Gezielter testen: Regressionsläufe fokussieren auf relevante Tests und reduzieren unnötige Prüfstands- und Rechenzeit.
Fehler schneller am richtigen Ort: Auffälligkeiten landen früher beim zuständigen Team. Traceability inklusive: Die rekonstruierte Trace-Matrix schließt eine bestehende Lücke und stärkt die Nachweisführung im ASPICE-Assessment.
Messbar machen wir das über drei Größen, die im Pilot erhoben werden: Anteil übernommener Testfallvorschläge, eingesparte Prüfstandszeit je Regressionslauf bei gleichbleibender Fehlerfindung und Trefferquote der Fehlerklassifikation oberhalb der Konfidenzschwelle.
Woher unsere Erfahrung kommt
Wir haben für Automotive-Kunden Prüfstands- und Fehlerdaten modelliert – von der Vorhersage von Prüfstandzeiten bis zur Fehlerprognose in laufenden Fahrzeugprojekten.
Zuletzt aktualisiert: 13. August 2026
