KI-Testselektion am HIL: Laufzeit senken, Abdeckung halten

KI-basierte Testselektion am HIL-Prüfstand: Laufzeit senken, Abdeckung halten

Ja, KI-basierte Testselektion kann die Regressionslaufzeit am Hardware-in-the-Loop-Prüfstand (HIL) deutlich senken, ohne die Abdeckung zu gefährden. Die Bedingung ist ein geordneter Rahmen: Das System wertet die Änderung aus, also den Quelltext-Diff, die Traceability zu Anforderungen und Testfällen sowie historische Fehlerdaten, und schlägt die Teilmenge der Regressionstests vor, die zur Änderung laufen muss. Der Testverantwortliche bestätigt jede Auswahl, eine periodische Voll-Regression dient als Sicherheitsnetz, und für jeden ausgelassenen Test existiert eine nachvollziehbare Begründung. Damit bleibt die Abdeckungs-Argumentation gegenüber Qualitätssicherung und Assessor tragfähig. sensified ordnet die Testselektion als vorbereitende Automatisierung mit Prüfpunkt beim Menschen ein und beschreibt den Freigabe- und Nachweispfad, der sie assessierbar hält.

Wer die Integrationstests eines Steuergeräte-Projekts nach Automotive SPICE (ASPICE) verantwortet, kennt die Rechnung: Die Regressionssuite wächst mit jedem Release, die Zahl der HIL-Prüfstände wächst nicht mit. Die vollständige Regression läuft über Nacht, bei größeren Ständen über mehrere Nächte, und jede Änderung vor einem Liefertermin konkurriert um dieselben Prüfstandsstunden. Hier setzt änderungsbasierte Testselektion an, und hier entsteht auch die berechtigte Gegenfrage der Software-Qualitätssicherung (SQA): Wer stellt sicher, dass die verkürzte Auswahl nichts übersieht? Dieser Beitrag beschreibt, wie ein Selektionssystem arbeitet, welche Datenbasis es braucht und wie die Abdeckungs-Argumentation gegenüber SQA und Assessor stehen bleibt. Er gehört zur Werkzeug-Ebene, deren Überblick der Beitrag zu KI in der Automotive-Softwareentwicklung gibt. Eine Einordnung vorweg: Aussagen zu Eignung und Einsparpotenzial sind typisierte Hypothesen aus Projekterfahrung, die je Kunde und Toolchain zu prüfen sind. Über Personen oder deren Leistung trifft dieser Beitrag keine Aussage.

Der Engpass: Prüfstandszeit ist das knappste Gut

Am HIL treffen zwei Kurven aufeinander. Die Regressionssuite wächst mit der Funktionsmenge des Steuergeräts, mit jedem gefundenen Fehler, der einen Absicherungstest erzeugt, und mit jeder Variantenkonfiguration. Die verfügbare Prüfstandszeit ist durch Hardware, Betreuungskapazität und Wartungsfenster begrenzt; ein zusätzlicher HIL-Aufbau ist eine Investitionsentscheidung, keine Konfigurationsänderung.

Warum die volle Regression nicht mehr skaliert

Solange die vollständige Regression in ein Nachtfenster passt, ist Selektion kein Thema; man lässt alles laufen. Das Problem beginnt, wenn der Voll-Lauf länger dauert als der Abstand zwischen zwei Integrationsständen. Dann entstehen Warteschlangen: Änderungen stapeln sich vor dem Prüfstand, Ergebnisse kommen zu spät, und in der Praxis wird ohnehin selektiert, nur eben informell. Ein Testverantwortlicher wählt unter Zeitdruck nach Erfahrung aus, was laufen soll, und diese Auswahl steht in keinem Dokument. Wie stark der Nachweisdruck auf der Teststrecke ist, zeigt eine Selbstauskunfts-Zahl aus der Branche: 46 % der Automotive-Teams fällt der Nachweis der ISO-26262-Konformität schwer (Quelle: Perforce, 2025).

Die informelle Selektion ist das eigentliche Risiko

Diese Beobachtung verschiebt die Diskussion. In vielen Projekten lautet die Frage gar nicht, ob selektiert wird; selektiert wird längst. Die Frage lautet, ob die Selektion einer dokumentierten Regel folgt oder dem Bauchgefühl unter Termindruck. Eine erfahrungsbasierte Auswahl kann gut sein, aber sie ist weder reproduzierbar noch prüfbar noch übergabefähig. Ein KI-gestütztes Selektionssystem macht aus der informellen Praxis eine geregelte: gleiche Datenbasis, gleiche Regel, dokumentierte Begründung.

Wie änderungsbasierte Testselektion arbeitet

Der Grundgedanke ist einfach: Nicht jede Änderung berührt jede Funktion, also muss auch nicht jede Änderung jeden Test auslösen. Damit aus diesem Gedanken eine belastbare Auswahl wird, braucht das System drei Datenquellen und eine Auswertungslogik, die sie zusammenführt.

Die Datenbasis: Diff, Traceability, Fehlerhistorie

Die erste Quelle ist der Änderungssatz selbst: der Quelltext-Diff, geänderte Kalibrierparameter, angepasste Konfigurations- und Netzwerkbeschreibungsdateien. Aus ihm leitet die Änderungsanalyse ab, welche Module, Schnittstellen und Signale betroffen sind, einschließlich der Abhängigkeiten über Aufrufketten und Buskommunikation. Die zweite Quelle ist die Traceability: die Verknüpfung von Anforderungen zu Testfällen im Anforderungs- und Testmanagement, etwa in DOORS, Polarion oder Codebeamer. Sie beantwortet die Frage, welche Testfälle die betroffenen Anforderungen überhaupt absichern; wie belastbar diese Kette sein muss, behandelt der Beitrag zur Traceability als Evidenz-Rückgrat. Die dritte Quelle ist die Historie: vergangene Testergebnisse, Fehlerberichte und die Frage, welche Tests bei ähnlichen Änderungen Fehler gefunden haben. Aus ihr entsteht die Priorisierung innerhalb der Auswahl.

Vom Änderungssatz zum Selektionsvorschlag

Die Auswertungslogik verbindet die drei Quellen zu einem Vorschlag: eine geordnete Liste der Regressionstests, die zur konkreten Änderung laufen sollen, mit einer Begründung je Testfall und, ebenso wichtig, je ausgelassenem Test. Maschinelles Lernen kommt vor allem in der Historien-Auswertung zum Einsatz, etwa wenn das System Muster zwischen Änderungsarten und späteren Fehlerfunden erkennt; Änderungsanalyse und Traceability-Auswertung sind überwiegend regelbasiert und damit gut erklärbar. Je größer der erklärbare Anteil der Selektionsregel, desto einfacher die spätere Argumentation gegenüber SQA und Assessor.

Selektionsansätze im Vergleich

In der Praxis trägt selten ein Ansatz allein; belastbar wird meist die Kombination, deren Gewichtung in der dokumentierten Selektionsregel festgehalten ist.

Die Tabelle zeigt zugleich, warum ein Selektionssystem ohne Absicherungs-Spalte unvollständig ist: Jeder Ansatz hat einen blinden Fleck, und die Nachweisführung beginnt damit, ihn zu benennen.

Die Abdeckungs-Argumentation gegenüber SQA und Assessor

Der technisch beste Selektionsvorschlag ist wertlos, wenn er das nächste Assessment nicht übersteht. Die Verifikationsprozesse SWE.4 bis SWE.6 nach ASPICE erwarten eine begründete Auswahl- und Regressionsstrategie, und ein Assessor fragt genau dort nach, wo Tests nicht gelaufen sind. Die Argumentation muss stehen, bevor das System in den Regelbetrieb geht.

Dokumentierte Selektionsregel und Begründung je ausgelassenem Test

Das erste Element ist die Selektionsregel selbst: ein versioniertes Dokument, das beschreibt, welche Datenquellen einfließen, wie sie gewichtet werden, welche Schwellen gelten und welche Testklassen grundsätzlich ausgenommen sind, etwa sicherheitsrelevante Kernszenarien, die in jedem Lauf bleiben. Das zweite Element ist die Begründung je ausgelassenem Test: Für jeden Testfall, der in einem selektierten Lauf nicht ausgeführt wurde, hält das System fest, warum die Regel ihn als nicht betroffen eingestuft hat. Diese Protokolle sind die Antwort auf die Assessor-Frage, die mit Sicherheit kommt. Wie die Nachweisführung für maschinell erzeugte Testartefakte insgesamt aussieht, vertieft der Beitrag zu KI-generierten Testfällen im ISO-26262-Assessment.

Die periodische Voll-Regression als Sicherheitsnetz

Das dritte Element ist das Sicherheitsnetz: eine vollständige Regression in festen Abständen, etwa je Integrationsstand, je Release oder in einem definierten Kalenderrhythmus, zusätzlich verpflichtend vor jeder Lieferung mit Sicherheitsrelevanz. Die Voll-Regression hat zwei Funktionen. Sie fängt Fehler, die durch die Maschen der Selektionsregel gefallen sind, bevor sie ein Release erreichen. Und sie kalibriert die Regel: Findet der Voll-Lauf einen Fehler, den ein selektierter Lauf hätte finden müssen, ist das ein dokumentierter Befund, der eine Regelanpassung auslöst. So entsteht ein geschlossener Verbesserungskreis: Die Selektion spart Laufzeit im Tagesgeschäft, die Voll-Regression sichert die Abdeckungsaussage, und jeder Befund verbessert die Regel nachweisbar.

Flaky-Tests: der Nebenaspekt mit eigenem Ertrag

Wer die Ausführungshistorie ohnehin systematisch auswertet, bekommt ein zweites Ergebnis fast geschenkt: die Erkennung instabiler Tests. Am HIL entsteht Flakiness aus Quellen, die es im reinen Software-Test so nicht gibt: Einschwingverhalten der Restbussimulation, Timing-Abhängigkeiten beim Prüfstandsstart, Umgebungszustände aus vorherigen Tests, alternde Hardware im Kabelbaum. Ein Test, der ohne Codeänderung mal besteht und mal fehlschlägt, kostet doppelt: Prüfstandszeit für Wiederholungsläufe und Vertrauen in rote Ergebnisse.

Die Historien-Auswertung macht diese Kandidaten sichtbar: auffälliger Wechsel zwischen Bestehen und Fehlschlagen bei unverändertem Prüfling, gehäufte Fehlschläge zu bestimmten Tageszeiten oder nach bestimmten Vorgänger-Tests. Wichtig ist die Grenze der Automatisierung: Das System markiert Kandidaten und liefert die Indizien, die Entscheidung über Quarantäne, Reparatur oder Neuentwurf trifft der Testverantwortliche. Ein automatisch stummgeschalteter Test wäre eine unbemerkte Abdeckungslücke, also genau das, was die gesamte Argumentation dieses Beitrags verhindern soll.

Der Freigabepfad: Vorschlag durch das System, Bestätigung durch den Menschen

Testselektion greift in die Nachweiskette der Verifikation ein und gehört deshalb in eine klar benannte Verantwortungsarchitektur. In unserem Vorgehensmodell ist sie Triage-Klasse A2: vorbereitende Automatisierung mit Prüfpunkt beim Menschen. Der rote Faden gilt wörtlich: KI assistiert, der Mensch verantwortet.

Was Klasse A2 in der Praxis bedeutet

Das System erstellt je Änderung den Selektionsvorschlag samt Begründungen. Der Testverantwortliche prüft und bestätigt jede Selektion, bevor der Lauf startet, und kann die Auswahl erweitern, wenn seine Einschätzung von der Regel abweicht; jede Erweiterung wird protokolliert und fließt in die Regel-Kalibrierung ein. Eine automatische Ausführung ohne Bestätigung, also der Schritt in Richtung autonomer Fallabwicklung, startet als nicht zulässig und würde erst nach expliziter Prüfung geöffnet. Was diese Verschiebung für das Rollenbild bedeutet, beschreibt der Rollen-Deep-Dive zum Test-Ingenieur mit KI in SWE.4 bis SWE.6: Die Routine der Zusammenstellung wandert ins System, das Urteil über Auswahl und Abdeckung bleibt beim Menschen.

Werkzeug-Ordnung und Betrieb

Zum Freigabepfad gehört schließlich die Werkzeug-Frage: Ein Selektionssystem beeinflusst, welche Verifikationsergebnisse entstehen, und gehört damit in die Tool-Vertrauensbetrachtung nach ISO 26262 wie jedes andere Werkzeug der Kette; der Prüfpunkt beim Menschen und die Voll-Regression sind dabei Teil der Argumentation für das Vertrauensniveau. Dazu kommt die Ordnung des Betriebs: versionierte Selektionsregel, lückenlose Protokollierung von Vorschlag, Bestätigung und Abweichung, ein definierter Rückholweg auf die Voll-Regression bei Systemausfall und eine benannte Zuständigkeit für die Regelpflege. Ein Selektionssystem ohne diese Ordnung senkt die Laufzeit im ersten Quartal und erhöht den Assessment-Aufwand im zweiten.

Nächste Schritte

Ob änderungsbasierte Testselektion in Ihrem Projekt trägt, hängt von der Qualität der Traceability, der Tiefe der Ausführungshistorie und den Evidenzpflichten Ihrer Lieferungen ab; das lässt sich nur am konkreten Stand beurteilen. Der geordnete Einstieg sieht so aus:

1. Werkzeug-Ebene einordnen: Der Überblick zu KI in der Automotive-Softwareentwicklung zeigt, wo die Testselektion neben Code-Assistenz, Requirements-Prüfung und Doku-RAG steht.
2. Vorgehen prüfen: Die Seite zur AI-Transformation im Automotive Engineering beschreibt, wie aus einzelnen Bausteinen ein geführtes Transformationsvorhaben mit Freigabe- und Nachweispfad wird.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, ob Toolchain, Datenlage und Prüfstandssituation Ihres Projekts zum Vorgehen passen.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zur KI-basierten Testselektion am HIL zusammen. Sie beschreiben typisierte Muster und Freigabepfade; wie die Selektion in einem konkreten Projekt aufgesetzt wird, ist je Kunde und Toolchain zu prüfen.

Kann KI die Regressionslaufzeit am HIL senken, ohne die Abdeckung zu gefährden?

Ja, wenn drei Absicherungen stehen: eine dokumentierte, versionierte Selektionsregel, eine periodische Voll-Regression als Sicherheitsnetz und eine nachvollziehbare Begründung je ausgelassenem Test. Das System schlägt die Auswahl vor, der Testverantwortliche bestätigt sie je Selektion. Ohne diese drei Elemente senkt Selektion nur die Laufzeit und verlagert das Risiko in Richtung Assessment.

Wie funktioniert änderungsbasierte Testselektion?

Das System analysiert den Änderungssatz, also Quelltext-Diff, Kalibrier- und Konfigurationsänderungen, ermittelt über die Traceability die betroffenen Anforderungen und Testfälle und priorisiert die Auswahl anhand historischer Fehlerdaten. Ergebnis ist ein Selektionsvorschlag mit Begründung je aufgenommenem und je ausgelassenem Test, den der Verantwortliche vor dem Lauf bestätigt.

Welche Datenbasis braucht ein Selektionssystem?

Drei Quellen: den Änderungssatz mit Abhängigkeitsinformationen, eine gepflegte Traceability von Anforderungen zu Testfällen, etwa in DOORS, Polarion oder Codebeamer, und die Ausführungs- und Fehlerhistorie der Regressionssuite. Die Traceability-Qualität ist ein Eingangskriterium: Lückenhafte Verknüpfungen führen zu falscher Auswahl und müssen vor dem Einsatz geprüft werden.

Akzeptiert ein ASPICE-Assessor eine selektierte Regression?

Assessoren bewerten die Erreichung der Prozess-Outcomes, und die Verifikationsprozesse erwarten eine begründete Regressionsstrategie. Eine selektierte Regression ist vertretbar, wenn die Selektionsregel dokumentiert und versioniert ist, jeder ausgelassene Test begründet wird und eine periodische Voll-Regression die Abdeckungsaussage stützt. Riskant ist der umgekehrte Fall: informelle Auswahl unter Termindruck ohne dokumentierte Regel.

Was passiert mit Tests, die die Selektion auslässt?

Sie entfallen nicht, sie werden verschoben: Die periodische Voll-Regression führt sie in festen Abständen aus, zusätzlich gilt vor Lieferungen mit Sicherheitsrelevanz ein vollständiger Lauf. Für jeden ausgelassenen Test protokolliert das System die Begründung der Regel. Findet der Voll-Lauf einen Fehler, den ein selektierter Lauf hätte finden müssen, wird die Regel angepasst und der Befund dokumentiert.

Was bringt Flaky-Test-Erkennung am HIL?

Die Auswertung der Ausführungshistorie markiert Tests, die bei unverändertem Prüfling zwischen Bestehen und Fehlschlagen wechseln, etwa durch Timing-Abhängigkeiten, Einschwingverhalten der Restbussimulation oder Umgebungszustände. Das spart Prüfstandszeit für Wiederholungsläufe und schützt das Vertrauen in rote Ergebnisse. Die Entscheidung über Quarantäne oder Reparatur eines markierten Tests trifft der Testverantwortliche, ein automatisches Stummschalten findet nicht statt.

Wer verantwortet die Auswahl und muss das Werkzeug qualifiziert werden?

Die Verantwortung für jede ausgeführte Selektion liegt beim Testverantwortlichen, der den Vorschlag des Systems prüft und bestätigt; das entspricht der Triage-Klasse A2, vorbereitende Automatisierung mit Prüfpunkt beim Menschen. Da das System beeinflusst, welche Verifikationsergebnisse entstehen, gehört es in die Tool-Vertrauensbetrachtung nach ISO 26262. Der menschliche Prüfpunkt und die Voll-Regression sind dabei zentrale Argumente für das begründete Vertrauensniveau.