Testfälle entstehen dort, wo Anforderungen, Architektur und Code im Zusammenhang stehen. Die App generiert sie systematisch aus dem Product Knowledge Graph, mit kontinuierlichen Coverage-Berichten für ISO 26262, DO-178C und IEC 62304.
In klassischen Projekten entstehen Tests typischerweise spät, von Hand und aus dem Gedächtnis. Ein Test-Engineer liest die Anforderungsdokumente, überlegt sich geeignete Testfälle, schreibt sie auf, hinterlegt sie in einem Test-Management-Werkzeug und stellt eine Beziehung zur Anforderungs-ID her, sofern überhaupt eine solche existiert. Bei wenigen hundert Anforderungen ist das machbar. Bei mehreren tausend, die ein modernes Embedded-System oder eine ECU-Steuerung mit sich bringt, ist es eine Sisyphusarbeit.
Das ist keine Frage des Engagements, sondern der schieren Skalierung. Ein Mensch kann zehntausende Beziehungen zwischen Anforderungen, Architektur, Schnittstellen und Tests nicht im Kopf aktuell halten.
Voraussetzung ist, dass Anforderungen, Architekturelemente und Code-Komponenten im Product Knowledge Graph explizit verknüpft sind. Sobald diese Verbindungen vorliegen, leitet die App Testfälle systematisch ab, statt sie aus dem Gedächtnis zu konstruieren.
Strukturierte Anforderungen, zugeordnete Architekturelemente, Interface-Spezifikationen und (sofern vorhanden) implementierte Code-Units werden gemeinsam eingelesen.
Welche Eingangs-Wertebereiche müssen abgedeckt werden, welche Fehler-Szenarien sind relevant, welche Zustandsübergänge in der Architektur lösen das Verhalten aus.
Mit Eingangsdaten, erwarteten Ausgaben, Vorbedingungen und Test-Assertions. Akzeptanzkriterien aus der Anforderung werden direkt zu prüfbaren Aussagen.
Welche Anforderungen sind durch generierte Tests abgedeckt, wo bleiben Lücken, welche Tests sind redundant. Die App liefert nicht nur Prozentzahlen, sondern konkrete Lücken-Pfade.
Vector CANoe, MATLAB/Simulink, GitHub Actions, Jenkins, Azure DevOps oder ausführbarer Skript-Code (Python, Robot Framework) für Hardware-in-the-Loop und CI/CD-Pipelines.
Für jede funktionale Anforderung Tests, die das spezifizierte Verhalten unter normalen Bedingungen prüfen. Akzeptanzkriterien werden zu Test-Assertions; bei mehreren Eingangs-Wertebereichen werden repräsentative Werte, Grenzwerte und Off-by-One-Fälle generiert.
Wo Architektur-Schnittstellen mit Datentypen, Wertebereichen und Zeitverhalten beschrieben sind, entstehen Tests, die genau diese Schnittstellen prüfen. Deckt einen Bereich ab, der manuell oft unterversorgt bleibt.
Erkennt die App im Code mehr Entscheidungsknoten als durch Anforderungs-Tests abgedeckt, schlägt sie zusätzliche Tests vor, um MC/DC-Coverage für ISO-26262-relevante Software zu erreichen. Besonders relevant für ASIL-C und ASIL-D.
Aus in FMEA und Gefährdungsanalyse dokumentierten Gefährdungen werden Tests abgeleitet, die das Verhalten unter Fehlerbedingungen prüfen: defekte Sensoren, unplausible Eingaben, Timing-Verletzungen. Strukturierte Sicherheits-Verifikation statt Bauchgefühl.
Auf der Eingangsseite: Polarion, DOORS Next Generation, Codebeamer für strukturierte Anforderungen, Cameo Systems Modeler und Enterprise Architect für Architekturmodelle, Word, Excel, PDF für klassische Lastenhefte. Sobald Anforderungen und Architektur im Knowledge Graph vorliegen, greift der Test Case Generator direkt darauf zu.
Auf der Zielseite: Vector CANoe für Bus- und Restbus-Simulation, MATLAB/Simulink für modellbasierte Tests, GitHub Actions, Jenkins, Bitbucket, Azure DevOps für CI/CD-Pipelines, Jira oder Polarion-Test-Module fürs Test-Management. Auf Wunsch auch als ausführbarer Test-Script-Code in Python oder Robot Framework.
Die App pflegt für jede Komponente und jede Anforderung die aktuelle Coverage automatisch mit, getrennt nach den für ISO 26262 relevanten Stufen: Statement-Coverage, Decision-Coverage und Modified Condition/Decision-Coverage (MC/DC).
Wo Lücken bestehen, werden sie konkret angezeigt: nicht „Komponente X hat 73 % Coverage", sondern „diese drei Entscheidungspfade in Funktion Y sind durch keinen vorhandenen Test abgedeckt; hier sind drei vorgeschlagene Testfälle, die die Lücke schließen". Die gleichen Coverage-Argumente lassen sich für DO-178C (DAL A/B mit MC/DC, DAL C mit Decision-Coverage), IEC 61508 und IEC 62304 aufbereiten. Die Compliance-Check-Applikation nutzt dieselbe Datenbasis und macht aus Coverage-Daten direkt Audit-Nachweise.
Generierte Testfälle sind Vorschläge, keine Verifikations-Wahrheiten. Ein KI-generierter Test kann technisch korrekt sein, aber an der eigentlichen Intention der Anforderung vorbeigehen. Er kann eine implizite Annahme treffen, die ein Mensch sofort als falsch erkennen würde. Und er kann nichts darüber wissen, ob ein bestimmtes Risiko in Ihrem konkreten Einsatzkontext relevant ist. Der Test Case Generator ist deshalb als Erstellungs- und Konsistenz-Werkzeug konzipiert, nicht als Verifikations-Instanz. Die fachliche Freigabe (entspricht dieser Test der Intention der Anforderung, ist diese Coverage in diesem Kontext ausreichend) trifft das Test-Team. Jeder Test trägt im Graphen seine Herkunft (KI-generiert, menschlich erstellt, KI-vorgeschlagen und menschlich angepasst), was die spätere Audit-Argumentation und die Tool-Qualifikation nach ISO 26262 vereinfacht.
Idealerweise liegen die Anforderungen schon im Knowledge Graph. Wenn sie heute noch als Word-Lastenheft oder Excel-Liste existieren, ist die Requirements-Gen-App der natürliche vorgelagerte Schritt.
In den ersten Wochen generiert die App Tests für das ausgewählte Subsystem, das Team validiert die Vorschläge und passt sie an. Der erste Coverage-Bericht entsteht.
Häufig wird sichtbar, wo Anforderungen selbst noch zu schwammig formuliert sind. Unklare Anforderungen führen zu unbrauchbaren Tests. Die Rückkopplung verbessert beide Seiten gleichzeitig.
Auf weitere Subsysteme, weitere Test-Stufen (Komponenten, Integration, System) und tiefere Automatisierung in der CI/CD-Pipeline.
Die Qualität der generierten Tests hängt direkt an der Qualität der Anforderungen. Wer im Anforderungswesen heute noch in Word und Excel arbeitet, schafft mit Requirements Gen die Voraussetzung für die Test-Generierung.
Mehr zum AnforderungsmanagementJa. Bestehende Tests werden in den Knowledge Graph importiert und ihren zugehörigen Anforderungen zugeordnet, soweit eine Zuordnung herstellbar ist. Der Test Case Generator schlägt anschließend ergänzende Tests vor, wo Lücken bestehen, und ersetzt vorhandene Tests nicht. Sie behalten die Hoheit über Ihren bestehenden Test-Bestand.
Für Embedded- und Automotive-Tests sind Vector CANoe und MATLAB/Simulink direkt angebunden, für CI/CD-Pipelines GitHub Actions, Jenkins, Bitbucket und Azure DevOps. Tests lassen sich zusätzlich als ausführbare Skripte (Python, Robot Framework) generieren und in eigene Test-Frameworks einbinden.
Statement-, Decision- und MC/DC-Coverage werden pro Komponente und pro Anforderung kontinuierlich berechnet und mit der ASIL-Anforderung der Komponente abgeglichen. Lücken werden mit konkreten Testvorschlägen zum Schließen der Lücke angezeigt. Die gleichen Reports lassen sich für DO-178C (DAL), IEC 61508 (SIL) und IEC 62304 erzeugen.
Ja. Aus den in FMEA und Gefährdungsanalyse dokumentierten Gefährdungen werden Tests abgeleitet, die das Verhalten unter Fehlerbedingungen prüfen (defekte Sensoren, unplausible Eingaben, Timing-Verletzungen). Das deckt einen Bereich ab, der manuell oft unterversorgt ist, weil Sicherheitstests aufwendig zu schreiben sind.
Ein abgegrenzter Pilot (ein Subsystem, ein Team) liefert in der Regel innerhalb von vier bis sechs Wochen die ersten produktiv nutzbaren Tests inklusive Coverage-Berichten. Voraussetzung ist, dass die Anforderungen für den Pilot-Bereich bereits strukturiert vorliegen.
Der Test Case Generator ist als Unterstützungswerkzeug konzipiert: Er generiert Tests, die anschließend menschlich geprüft und freigegeben werden. Jeder Test trägt im Graphen seine Herkunft und Freigabe-Historie. Damit sind die Voraussetzungen für die TCL-Klassifikation gegeben; die konkrete Qualifikation im Projektkontext begleiten wir gemeinsam.
Sehen Sie in einer 30-minütigen Demo, wie der Test Case Generator aus einem Ihrer Subsysteme heraus arbeitet. Bringen Sie gerne einen anonymisierten Anforderungs-Auszug mit, dann wird die Demo direkt an Ihrem Beispiel konkret.