Von der Anforderung zum Robot-Framework-Test: AI-gestützte Testautomatisierung (UDS/DoIP)

Von der Anforderung zum ausführbaren Test: Robot Framework, UDS und DoIP

Zwischen Anforderung und ausführbarem Test liegt viel Handarbeit. Testspezifikationen schreiben. Testfälle ableiten. Umgebungen aufsetzen. Ergebnisse auswerten. AI kann diese Kette deutlich verkürzen. Aber nur, wenn das Ergebnis deterministisch, wiederholbar und diagnosefähig bleibt.

Der Anspruch lautet einfach. Aus strukturierten Anforderungen werden deterministische Tests. Keine Zufallsprodukte. Genau darauf ist eine AI-gestützte Testautomatisierung ausgelegt. Sie setzt auf Robot Framework auf und kennt UDS und DoIP.

Aus strukturierten Anforderungen werden deterministische Tests.

Damit stehen für Sie als Verantwortliche im Engineering konkrete Fragen im Raum:

• Wie erzeugen wir Testspezifikationen und Testfälle konsistent über alle Ebenen?
• Wie bleiben generierte Tests deterministisch und wiederholbar?
• Wie binden wir Diagnose-Protokolle wie UDS und DoIP sauber ein?
• Wie beschleunigen wir die Fehlersuche, ohne Nachvollziehbarkeit zu verlieren?

Dieser Beitrag zeigt den Pfad von der Anforderung bis zur Robot-Framework-Suite. Und warum Determinismus im Audit zählt.

Der Testflaschenhals im SDV-Zeitalter

Mit dem softwaredefinierten Fahrzeug steigt die Zahl der Änderungen. Und damit die Zahl der nötigen Tests. Was früher ein abgeschlossener Testzyklus war, wird zur Daueraufgabe. Jede Änderung an einer Anforderung zieht neue oder angepasste Testfälle nach sich. Wird das von Hand getragen, wird das Testen zum Flaschenhals. Es frisst die gewonnene Software-Geschwindigkeit wieder auf.

AI kann diesen Flaschenhals lösen. Aber nur unter einer Bedingung. Das Ergebnis muss deterministisch und traceable sein. Ein Test, der mal so und mal anders reagiert, verlagert das Problem nur. Von langsam zu unzuverlässig. Der Anspruch ist nicht mehr Tests schneller. Der Anspruch sind reproduzierbare, ausführbare Tests aus strukturierten Anforderungen.

Der Pfad von der Anforderung zum Test

Spezifikation und Testfälle

AI leitet aus strukturierten Anforderungen Testspezifikationen und Testfälle ab. Das gilt über alle Ebenen. Sie schlägt auch passende Testumgebungen vor. Statt jede Spezifikation von Hand zu entwickeln, arbeitet der Engineer mit einem strukturierten Vorschlag weiter. Die fachliche Freigabe bleibt bei ihm.

Die Ableitung ist damit ein Vorschlag, keine Wahrheit. Der Engineer entscheidet, welche Fälle relevant sind. Wo Randbedingungen fehlen. Und welche Umgebung passt. Die Zeitersparnis liegt in der Zuarbeit, nicht in der Verantwortung.

Deterministisch und diagnosefähig

Der Kern ist die Überführung in ausführbare, deterministische Artefakte.

• Robot Framework. Ausführbare Testsuiten, deterministisch aus einer JSON-Testspezifikation erzeugt.
• UDS und DoIP. Service-IDs, DIDs und NRC-Erwartungen sind Teil der Spezifikation, nicht nachträgliche Handarbeit.
• Analyse. Auswertung der Testergebnisse mit Vorschlägen zur Ursache beschleunigt die Fehlersuche.

Warum Determinismus zählt

Ein Test, der bei gleicher Eingabe anders reagiert, ist im Audit wertlos. Und in der Serienreife gefährlich. Deshalb wird die AI-Zuarbeit in deterministische Artefakte überführt. Reproduzierbar, versioniert und traceable zur Anforderung. Aus einer JSON-Testspezifikation entsteht dieselbe Robot-Suite. Jedes Mal.

Damit schließt sich die Kette. Die Anforderung, aus der der Test abgeleitet wurde, ist über die Traceability-Matrix mit ihm verbunden. Ein durchgefallener Test verweist auf eine konkrete Anforderung. Nicht auf ein diffuses Modellverhalten.

Integration in die Testlandschaft

Die Testautomatisierung steht nicht isoliert. Sie greift in die bestehende Landschaft.

• Anforderungen kommen aus dem ALM, etwa Polarion, Jira oder ReqIF, inbound und read-only gespiegelt.
• Die Testspezifikation ist strukturiert als JSON und damit maschinell weiterverarbeitbar.
• Erzeugte Robot-Suiten sind prüfbare Artefakte, keine Chat-Ausgaben.

Häufige Fehler in der Testautomatisierung

• Nicht-deterministische Tests. Generierte Suiten, die bei gleicher Eingabe variieren.
• UDS und DoIP als Nachgedanke. Diagnose-Details erst nachträglich von Hand ergänzen.
• Test ohne Trace. Testfälle, die sich keiner Anforderung zuordnen lassen.

Der Schlüssel ist die strukturierte Testspezifikation als einzige Quelle. So gewinnen Sie Geschwindigkeit und Nachweisbarkeit zugleich. Aus ihr entsteht die Suite reproduzierbar. In ihr stecken die Diagnose-Details. Und über sie bleibt jeder Test mit seiner Anforderung verbunden. Wer die Spezifikation ernst nimmt, bekommt schnelle Tests, die im Audit standhalten.

So gehen wir vor: Build, Operate, Transfer

AI-gestützte, deterministische Testautomatisierung bauen wir nicht als Folienkonzept. Wir bauen es als produktive Fähigkeit. Das folgt dem Prinzip Build, Operate, Transfer. Unsere Beteiligung nimmt über die Phasen ab. Ihre Capability wächst ins eigene Haus. Der Wissenstransfer ist vertragliches Erfolgskriterium, kein Zusatz. Sonst entsteht genau der Lock-in, den wir vermeiden wollen.

1. Build. Setup, Guardrails und erste Workflows entlang Ihres realen Prozesses.
2. Operate. Betrieb mit KPI-Verantwortung auf Wertstrom-Ebene. Nie auf Personen-Telemetrie.
3. Transfer. Dokumentierte Übergabe. Ihr Team übernimmt Tooling, Wissen und Betrieb.

Getragen wird das von drei Modulen. Erstens ein Strategic Engineering Lead. Das ist ein Senior-Embedded-Architekt zusammen mit einem Strategic AI Lead. Zweitens die auditierbare Tooling-Plane sensified AI-OS. Drittens die Automotive-Playbooks. Sie beschreiben die Methodik für AI in Embedded-, ASIL-, ASPICE- und AUTOSAR-Kontexten. Die Leitplanke, was AI nicht entscheidet, ist darin fest verankert.

Die vier Mandat-Typen sind kombinierbar. Sie passen sich Ihrem Reifegrad an. Es gibt den Strategic Engineering Lead für den breiten Aufbau. Es gibt die BOT Engineering-Capability als Programm-Paket je Domäne. Es gibt den ASPICE- oder ASIL-Workflow-Pilot zur Validierung vor dem Mandat. Und es gibt das Modul Tooling, MCP und AI-Governance mit Schlüssel-Isolation und Kosten-Transparenz. Der Einstieg ist bewusst risikoarm. Zuerst ein Qualifying-Call zum Fit-Check. Dann NDA und Discovery-Workshop. Danach der Workflow-Pilot. Erst dann das BOT-Mandat mit Governance-Plane. Kommerzielle Details klären wir im Discovery-Workshop, nicht über öffentliche Preislisten.

Gemessen wird auf Wertstrom-Ebene, nie an Personen. Wir messen Kosten je Wertstrom, den Produktivitäts-Zuwachs und die reale Nutzung. So bleibt jederzeit belegbar, ob sich die Fähigkeit rechnet. Das entscheidet über den nächsten Ausbauschritt. Der Betrieb erzeugt keine Chat-Historie als Ergebnis. Er erzeugt prüfbare Artefakte, die in Ihren Prozess passen. Dazu gehören Reports, Traceability-Matrizen und ausführbare Testsuiten.

Der Pilot ist bewusst klein gehalten. Er dauert wenige Wochen. Er nimmt sich einen realen Ausschnitt Ihres Prozesses vor, nicht ein Laborbeispiel. Am Ende steht ein belastbarer Beleg. Sie sehen, ob die Kette hält und ob sich der Aufwand lohnt. Erst auf dieser Basis entscheiden wir gemeinsam über das volle Mandat. So bleibt jedes Investment an ein sichtbares Ergebnis gebunden.

Dieser Beitrag fokussiert das Tooling. Was der Wandel für die Rolle der Test-Ingenieure in SWE.4 bis SWE.6 bedeutet, zeigt der Beitrag Test-Ingenieure und AI in SWE.4 bis SWE.6.

Die Anforderungsseite dieser Kette beschreibt Requirements-Engineering mit AI in SWE.1.

Fazit

Es gibt einen Unterschied zwischen zwei Sätzen. Der erste lautet: Wir nutzen AI-Tools. Der zweite lautet: Wir besitzen eine beherrschte, auditierbare AI-Engineering-Capability. Dieser Unterschied entscheidet, ob AI im Serienprogramm trägt oder im Pilot versandet. Genau diese Entscheidungen hat sensified für den eigenen Betrieb getroffen. Sie sind in einem realen ASPICE-Serienprogramm gebaut. Deshalb kommt sensified mit einer Position, nicht mit Fragen.

Drei Dinge unterscheiden diesen Ansatz. Es gibt einen klaren Plan, belegt durch eigenes, produktives IP. Wir bauen es mit, bis es ASPICE-konform in Produktion läuft. Und es gibt keinen Vendor-Lock-in, abgesichert durch modell-agnostische Architektur und Transfer als Erfolgskriterium. Zwei Tiefen treffen dabei in einem Partner zusammen. Das ist etabliertes Automotive- und SDV-Wissen. Und es ist AI-Engineering-Tiefe aus eigener Plattform.

Wie dieser Baustein in eine beherrschte Gesamt-Capability passt, zeigt unsere Seite zur AI-Transformation im Automotive-Engineering. Den strategischen Rahmen erklärt der Beitrag AI im Engineering ist ein Capability-Thema, kein Tool-Thema. Der nächste Schritt ist ein Discovery-Workshop. Dort ordnen wir Ihren Prozess, Ihre Compliance-Lage und den ersten sinnvollen Use-Case gemeinsam ein.

Das Wichtigste in Kürze

• Aus strukturierten Anforderungen werden deterministische Robot-Framework-Tests.
• UDS und DoIP sind Teil der Testspezifikation, nicht Handarbeit danach.
• Determinismus macht Tests audit-fest und serienreif.
• Jeder Test bleibt über die Traceability-Matrix mit seiner Anforderung verbunden.