Beschreibung

Technisches Gebiet

Die Erfindung betrifft eine Testanordnung zum Testen eines Testobjekts. Die Erfindung kann beispielsweise eingesetzt werden, um Testobjekte oder technische Geräte auf Schwachstellen zu untersuchen. Darunter fallen unter anderem industrielle Automatisierungskomponenten, Internet-der-Dinge Geräte (Internet-of-Things-Geräte, loT-Geräte, lloT-Geräte) und Medizingeräte. Die Erfindung betrifft ein modellbasiertes Security-Testing für technische Geräte.

Technisches Problem

Technische Geräte erfüllen Aufgaben. Durch Angriffe können die technischen Geräte daran verhindert oder gehindert werden, ihre Aufgaben zu erfüllen. Die Angriffe, wie zum Beispiel virtuelle Angriffe oder Angriffe über das Netzwerk/Internet, nutzen dazu Schwachstellen des technischen Gerätes aus. Um die Angriffe zu verhindern, können die Schwachstellen entdeckt und behoben werden. Zur Entdeckung der Schwachstellen werden Sicherheits-Tests (Security-T ests) genutzt. Dabei testet eine T estumgebung oder ein „T est Environment“ (TE) das technische Gerät automatisiert als Gerät unter T est oder T estgegenstand oder „Subject under Test“ (SUT).

Technische Geräte werden selten vollumfänglich auf Schwachstellen getestet. Grund dafür ist zum einen die Komplexität der technischen Geräte, zum anderen die Tatsache, dass technische Geräte aus verschiedenen Komponenten zusammengesetzt sind. Diese Komponenten können von verschiedenen Zulieferern stammen und sind nicht immer in allen Details einsehbar.

Sofern die technische Geräte überhaupt getestet sind, erfolgt dies auf Grundlage von Erfahrungen aus früheren Tests. Diese Tests werden entweder manuell durch Menschen, zum Beispiel durch sogenannte „Penetration Tester“ bzw. Penetrations-Tester oder mittels Testumgebungen durchgeführt.

Manuelle Tests bedeuten einen hohen personellen Aufwand, insbesondere wenn die Tests regelmäßig durchgeführt werden sollen. Aus diesem Grund werden sie in der Praxis selten kontinuierlich bei allen Geräten unter Test oder Subjects under Test (SUT) durchgeführt.

Die Testfälle für automatisierte Tests können zum Beispiel anhand von Erfahrungen aus früheren Tests und Grammatiken erzeugt werden. Diese sind jedoch bis auf zufällige Eingabedaten statisch und berücksichtigen insbesondere nicht die internen Funktionsweisen des SlITs. Es wurde erkannt, dass die Ausfälle des SLITs nur als Ergebnis der Untersuchung dargestellt werden, jedoch nicht in die Erstellung neuer, spezialisierter Testfälle einfließen.

Es wurde festgestellt, dass die interne Funktionsweise des SUTs mittels eines Modells beschrieben werden kann. Dieses Modell beinhaltet alle Funktionalitäten des SUTs, nicht nur die Teile, die zur Erfüllung der Aufgaben des SUTs erforderlich sind. Es kann daher zur Konstruktion von Testfällen genutzt werden.

Bisherige Ansätze für das modellbasierte Testen von technischen Geräten setzen ein vollständiges Modell des SUTs voraus. Dieses Modell kann beispielsweise aus den Entwurfsdokumenten abgeleitet werden. Aus den oben genannten Gründen ist dieser Ansatz bei zusammengesetzten technischen Geräten nicht ohne Weiteres möglich. Beispiele für diese Ansätze sind die Arbeit von Bringmann et al. [1] und die Arbeit von Bauer et al. [2],

Eine manuelle Konstruktion des Modells ist sehr aufwendig und häufig auch nicht möglich. Auch bedeutet eine manuelle Konstruktion eines Modells einen hohen personellen Aufwand und es kann selten ein vollständiges Modell angegeben werden. Dies ist insbesondere dann der Fall, wenn einzelne Teile des Systems von Dritten zugekauft wurden.

Ansätze für eine Testumgebung für das automatisierte Testen von technischen Geräten wurden in verschiedenen Patenten festgehalten. Einige Ausführungsbeispiele beziehen sich auf die allgemeine Generierung von Testfällen auf Basis einer Grammatik und auf die Überwachung einer Rechteckwelle als Ausgabe der getesteten Komponente. Somit kann es überprüft werden, ob das untersuchte Gerät einen Fehlerzustand eingenommen hat oder ob allgemein ein Zustandswechsel durchgeführt wurde.

US 8,132,053 B2 und US 8,006,136 B2 beziehen sich auf das Testen eines Systems mit Software- und/oder Hardwarekomponenten. In den Ausführungsbeispielen wird eine Testumgebung bzw. ein Test-Framework vorgestellt, das Testfälle für ein zu prüfendes System anhand einer Grammatik erzeugt. Das Test- Framework prüft das System mit dem Testfall und erhält eine Antwort auf den Testfall von dem zu testenden System. Die Eingaben und Ausgaben werden dann mit den erwarteten Ergebnissen verglichen, um festzustellen, ob das zu testende System korrekt funktioniert.

US 8,433,542 B2 und US 9,026,394 B2 beziehen sich ebenso auf das Testen eines Systems mit Software- und/oder Hardwarekomponenten. Das Test- Framework der obengenannten Patente erzeugt Testfälle für ein zu prüfendes System anhand einer Grammatik. Das Test- Framework prüft das System mit dem Testfall und erhält eine Antwort auf den Testfall von dem zu testenden System. Die Eingaben und Ausgaben werden dann mit den erwarteten Ergebnissen verglichen. Die Daten können dann im Grammatiksystem interpretiert und/oder als Eingabe für ein Fehlerisolierungssystem verwendet werden. Damit kann es überprüft werden, ob das untersuchte Gerät einen Fehlerzustand eingenommen hat oder ob allgemein ein Zustandswechsel durchgeführt wurde.

Die verschiedenen Bestandteile, wie zum Beispiel eine Testfallgenerierung und/oder Überwachung, sind zudem zum Beispiel in dem gemeinsamen Patent US 9,400,725 B2 zusammengefasst. US 9,400,725 B2 bezieht sich allgemein auf ein automatisiertes Testen eines Systems mit Software- und/oder Hardwarekomponenten. Das Test- Framework erzeugt Testfälle für ein zu prüfendes System anhand einer Grammatik. Das Test-Framework prüft das System mit dem Testfall und erhält eine Antwort auf den Testfall von dem zu testenden System. Die Eingaben und Ausgaben werden dann mit den erwarteten Ergebnissen verglichen, um festzustellen, ob das zu testende System korrekt funktioniert. Insbesondere kann das zu prüfende System analysiert werden, um festzustellen, ob es in der Lage ist, Steueranweisungen und Eingangssignale ordnungsgemäß zu verarbeiten und/oder erwartete Ausgangssteuersignale und zusätzliche Steuer-/Rückmeldeinformationen zu erzeugen. Die Daten können dann im Grammatiksystem interpretiert und/oder als Eingabe für ein Fehlerisolierungssystem verwendet werden, um Anomalien im zu prüfenden System zu ermitteln. Die Aufgabe der vorliegenden Erfindung besteht darin, ein Konzept zum Test von Testobjekten zu schaffen, das einen verbesserten Kompromiss zwischen Testaufwand und Testumfang bzw. Test-Zuverlässigkeit liefert.

Diese Aufgabe wird durch eine Testanordnung oder Testumgebung (TE) nach Anspruch 1 , durch ein Verfahren nach Anspruch 43, oder durch ein Computerprogramm nach Anspruch 44 gelöst.

Zusammenfassung der Erfindung

Ausführungsbeispiele der Erfindung schaffen eine Testanordnung zum Testen eines Testobjekts, wie z. B. zum Testen eines technisches Gerätes oder eines industrielles Gerätes oder einer Komponente eines Gerätes oder einer Komponente mit einer Kommunikationsschnittstelle, beispielsweise mit einer drahtgebundenen oder drahtlosen Netzwerkschnittstelle und/oder mit einer Web-Oberfläche.

Die Testanordnung ist ausgelegt, um auf Basis einer Interaktion mit dem Testobjekt ein Modell zu erstellen, um einen oder mehrere Testfälle unter Verwendung des Modells zu erzeugen und um das Modell des Testobjekts anhand von realen Testergebnisse, die auf den erzeugten Testfällen basieren, zu verbessern.

Die Testanordnung (TE) erzeugt beispielsweise auf Basis von ihrer Interaktion mit dem Testgegenstand bzw. Testobjekt (SUT) aktiv und automatisiert ein Modell von dem SUT. Das Modell wird anschließend beispielsweise von der TE verwendet, um neue Testfälle gezielt zu erzeugen. Die erzeugten Testfälle oder Tests werden beispielsweise von der TE gegen das SUT ausgeführt. Die TE überprüft währenddessen und im Anschluss an den Test, ob das SUT seine Aufgabe erfüllt oder erfüllen kann. Dazu überwacht sie beispielsweise das SUT, überprüft dessen Ausgaben und setzt ebenfalls das Modell des SUTs ein. Das Modell des SUTs wird während der Tests fortlaufend aktualisiert. Ein besonderes technisches Merkmal ist beispielsweise, dass die TE aus der Interaktion mit einem intransparenten SUT automatisiert ein Modell erzeugt und dieses automatisiert für die adaptive Testfallerzeugung verwendet.

Die TE erstellt beispielsweise ein Anfangsmodell von dem SUT mithilfe von Interaktionen mit dem SUT. Anhand des Anfangsmodells erstellt die TE beispielsweise Testfälle. Die TE führt die Testfälle beispielsweise gegen das SUT aus, um reale Testergebnisse zu erzeugen. Das Modell wird beispielsweise anhand der Testergebnisse verbessert. Neue Testfälle werden beispielsweise fortlaufend anhand das neue Modell erstellt und das Modell des SLITs wird beispielsweise fortlaufend aktualisiert.

Die Wirkung einer automatisierten Ableitung eines Modells des SLITs ist beispielsweise, dass Wissen über das SUT abgeleitet wird, das vorher nicht explizit vorhanden war. Mit diesem zusätzlichen Wissen kann die TE beispielsweise effizienter und zielgerichteter neue Testfälle erzeugen. Damit kann der gesamte Test des SUTs effizienter und zielgerichteter durchgeführt werden. Zudem kann dieses Wissen beispielsweise dazu genutzt werden, um zu entscheiden, ob das Verhalten des SUTs eine Anomalie aufweist. Dies kann ein Indiz für eine Schwachstelle des SUTs sein.

Der wichtigste Vorteil ist beispielsweise, dass das Testen von Automatisierungskomponenten durch das automatisch erzeugte Modell effizienter und zielgerichteter durchgeführt werden kann. Somit erstellt die Testanordnung mehr und mehr Testfälle, die das Testobjekt möglichst vollumfänglich auf Schwachstellen testen.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um eine, mehrere oder keine auf einen erzeugten Testfall gegebene Antwort eines im Hinblick auf sein Verhalten unbekannten und/oder intransparenten Testobjekts über einen oder mehrere Kommunikationswege zu empfangen.

Die Testanordnung ist ausgebildet, um alle möglichen Antworten des Testobjekts zu detek- tieren. Durch einen möglichst umfangreichen Empfang der Antworten des Testobjekts wird das Modell des Testobjekts basierend auf den Testergebnissen genauer, obwohl das Testobjekt im Hinblick auf sein Verhalten unbekannt oder intransparent ist.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um die Funktionsfähigkeit des Testobjekts oder die Funktionsfähigkeit einer oder mehrerer Funktionen des Testobjekts mittels einem oder mehreren Monitoren und/oder Überwachungsmodulen zu überprüfen.

Das Testobjekt kann auf einen Testfall oder auf eine Anfrage zusätzlich oder alternativ zu einer Antwort mit einer Verhaltensänderung reagieren. Diese Verhaltensänderung kann die Testanordnung beispielsweise mittels einem oder mehreren Monitoren und/oder Überwachungsmodulen überwachen. Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um die empfangenen Antworten und/oder die Ergebnisse der Monitoren auszuwerten und anhand dieser Auswertung Testergebnisse zu erzeugen.

Alle auf einen Testfall gegebenen Verhaltensänderungen und/oder Antworten des Testobjekts werden beispielsweise unter einem Testergebnis zusammengefasst. Dadurch kann eine spätere Verarbeitung der Testergebnisse vereinfacht werden.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um die Güte des Testfalls anhand des Testergebnisses und/oder anhand einer Wahrscheinlichkeit einer Fehlfunktion des mit dem Testfall getesteten Testobjekts zu bewerten.

Die Testanordnung simuliert beispielsweise virtuelle Angriffe gegen das technische Gerät oder das Testobjekt um Schwachstellen des Gerätes zu entdecken. Je mehr Schwachstellen ein Testfall der Testanordnung entdeckt, bzw. je höher die Wahrscheinlichkeit ist, dass ein Testfall eine Schwachstelle entdeckt, desto besser ist ein Testfall bzw. desto besser wird ein Testfall bewertet. Die Güte eines Testfalls ist zum Beispiel anhand der Anzahl der unerwarteten Fehlermeldungen und/oder der Fehlfunktionen messbar. Aufgrund der Bewertung können beispielsweise (z.B. bevorzugt) solche Testfälle (z.B. für eine tatsächliche Anwendung an dem Testobjekt) ausgewählt werden, die mit hoher Wahrscheinlichkeit Schwachstellen des Testobjekts aufdecken, wodurch die Test- Effizienz verbessert wird.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um die Testergebnisse der Testfälle anhand des Modells vorauszusagen oder zu schätzen oderz. B. zu approximieren.

Die Testanordnung kann anhand des Modells die Testergebnisse eines Testfalls und somit die Güte des Testfalls voraussagen ohne den Testfall gegen das SUT auszuführen. Somit kann beispielweise durch geeignete Auswahl der tatsächlich ausgeführten Testfälle Testzeit gespart werden.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um selektiv die Testfälle, bei denen eine Fehlfunktion des Testobjekts oder eine Fehlfunktion einer oder mehreren Funktionen des Testobjekts vorausgesagt wurde, auszusuchen, und um das Testobjekt mit den ausgesuchten Testfälle zu testen, um Testfälle zu erzeugen, die möglichst viele Fehlfunktionen des Testobjekts als reales Testergebnis erzeugen.

Die Testanordnung kann anhand des Modells die Testergebnisse eines Testfalls und somit die Güte des Testfalls voraussagen. Dadurch soll die Testanordnung nicht alle Testfälle gegen das SUT ausführen. Mit einer Reduzierung der Anzahl der gegen das SUT ausgeführten Testfälle werden Ressourcen, wie z. B. Zeit gespart.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um unter Verwendung des Modells zu bestimmen, ob ein reales Testergebnis als anomal beurteilt wird.

Die Testanordnung kann anhand des Modells die Testergebnisse eines Testfalls voraussagen. Die Testergebnisse der ausgeführten Testfälle werden mit den erwarteten Ergebnissen verglichen. Bei einer Diskrepanz wird das Testergebnis als anomal beurteilt. Anomale Testergebnisse deuten auf Schwachstellen hin. Somit können beispielsweise als anormal beurteilte Testergebnisse selektiv oder bevorzugt (zum Beispiel markiert) an einen Benutzer der Testanordnung gemeldet bzw. ausgegeben werden.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um das reale Testergebnis als anormal zu beurteilen, wenn das reale Testergebnis eine Fehlfunktion des Testobjekts oder eine Fehlfunktion einer oder mehreren Funktionen des Testobjekts anzeigt, oder wenn das reale Testergebnis von dem anhand des Modells vorausgesagten Testergebnis abweicht.

Die Testanordnung kann anhand des Modells die Testergebnisse eines Testfalls voraussagen. Die Testergebnisse der ausgeführten Testfälle werden mit den erwarteten Ergebnissen verglichen. Bei einer Diskrepanz zwischen einem realen Testergebnis und einem erwarteten Testergebnis oder bei einer Fehlfunktion des Testobjekts wird das Testergebnis als anomal beurteilt. Anomale Testergebnisse deuten auf Schwachstellen des Models und/oder des Testobjekts hin und sind beispielsweise bei einer Fehleranalyse besonders wertvoll.

Bei Ausführungsbeispielen umfasst das Modell des SLITs einen Zustandsautomat.

Der Umgang mit einem Zustandsautomat ist einfach, da die Anzahl der Zustände eines Zustandsautomaten oft relativ gering ist oder oft in einem gut verarbeitbaren Rahmen liegt, die Zustände voneinander unabhängig sind und der Übergang zwischen den Zuständen einer logischen Regel folgt. Es wird beispielsweise davon ausgegangen, dass sich das Testobjekt so lange in einem Zustand befindet, bis eine zustandsverändernde Anfrage ausgeführt wird.

Bei Ausführungsbeispielen umfasst ein Zustand des Zustandsautomaten zumindest einen Testfall, der zu dem Zustand führt, und zumindest ein daraus folgendes Testergebnis. Bei Ausführungsbeispielen ist die Testanordnung beispielsweise ausgelegt, um mittels einer Hash-Funktion einen Wert für einen Zustand des T estobjekts zu berechnen und um den Zustand mit dem berechneten Wert zu identifizieren.

Beispielsweise ist die Testanordnung ausgelegt, um den Zustandsautomaten, der das Modell des Testobjekts bildet, um einen neuen Zustand zu ergänzen, wenn dieser Zustand noch nicht vorhanden ist.

Eine Hashfunktion ist eine injektive Abbildung, die beispielsweise eine Eingabe mit unterschiedlichen Längen auf eine Zielmenge oder einen Hashwert, mit einer festen Länge abbildet. Die Länge des Hashwerts bleibt beispielsweise fest unabhängig von der Länge der Eingabewerte und/oder von der Länge der Testergebnisse. Ein Hashwert ist zur Anwendung als eine Identifikationsnummer gut geeignet und identifiziert beispielsweise einen Zustand in einer Speicherplatz-effizienten und dennoch typischerweise eindeutigen Form.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um das Testobjekt in einen vorgegebenen Zustand zu bringen und um das in dem vorgegebenen Zustand befindlichen Testobjekt auf einen oder mehrere verschiedene Testfälle zu testen.

Beispielsweise ist die Testanordnung ausgelegt, um eine oder mehrere Zustandsveränderungen ausgehend von dem vorgegebenen Zustand zu provozieren und/oder zu identifizieren. So wird das Modell des SUTs um die neu identifizierten Zustandsveränderungen und/oder um die neu identifizierten Zustände ergänzt.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um zustandsverändernde Testfälle, die zu einer Zustandsänderung des Testobjekts führen, zu identifizieren und um basierend darauf das Modell zu aktualisieren.

Mit einer kontinuierlichen Aktualisierung des Modells erschafft die Testanordnung eine positive Rückkopplungsschleife. Durch ein verbessertes Modell wird die Anzahl der zustandsverändernden Testfälle erhöht. Eine Vermehrung der zustandsverändernden Testfälle führt zu einem besseren SUT-Modell.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um die zustandsverändernden Testfälle unter Verwendung einer Heuristik zu identifizieren. Die Heuristik ist ausgelegt, um eine Häufigkeit einer Ausführung eines Testfalls und/oder eine Häufigkeit der Identifizierung eines/des Testfalls als zustandsverändernden Testfall und/oder eine Kategorie oder einen Typ eines/des Testfalls zu berücksichtigen. Mithilfe von einer Heuristik kann die Testanordnung neue zustandsverändernde Testfälle effizient identifizieren. Die Statistiken über und/oder Erfahrungen mit früheren Testfällen können zur Entdeckung bzw. Identifizierung neuer zustandsverändernder Testfälle führen.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um zu beurteilen, ob ein Zustand ausreichend erforscht ist. Die Testanordnung ist ausgelegt, um neue Testfälle, die diesen Zustand hervorrufen, zu erzeugen, wenn der Zustand nicht ausreichend erforscht ist, oder um neue Testfälle mit einem großen Unterschied zu den bereits bekannten Testfällen zu erzeugen, wenn der Zustand ausreichend erforscht ist. In diesem Fall ist der Unterschied beispielsweise bevorzugt groß genug, um beispielsweise eine oder mehrere Zustandsveränderungen zu provozieren und/oder zu identifizieren.

Dadurch kann die Testanordnung systematisch jeden Zustand ausreichend erforschen. Ist ein Zustand mit genügend Testfällen getestet, wird die Testanordnung beispielsweise eine Zustandsveränderung provozieren und neue Testfälle für den neuen Zustand erzeugen.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um eine Entscheidung, ob bekannte Zustände weiter untersucht werden sollen oder ob neue Zustände aufgefunden werden sollen, als ein Mehrarmiger-Bandit-Problem zu modellieren, und um das Mehrarmiger- Bandit-Problem anhand eines Verfahrens des bestärkenden Lernens, wie z. B. das Obere- Vertrauens-Grenze Verfahren bzw. das Upper Confidence Bound (UCB) Verfahren, zu lösen um die Entscheidung zu treffen.

Es wurde erkannt, dass ein Mehrarmiger-Bandit-Problem das Dilemma zwischen der weiteren Untersuchung bekannter Zustände und der Suche nach neuen Zuständen gut beschreiben kann. Ein Vorteil des Mehrarmiger-Bandit-Problems ist, dass dieses Problem mathematisch mit verschiedenen Verfahren lösbar ist.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um das Testobjekt mit einem Testfall wiederholt zu testen, um festzustellen ob sich das Testergebnis des Testfalles mit der Zeit ändert und um basierend darauf eine Zustandsveränderung zu identifizieren.

Somit kann die Testanordnung testen, ob die Zustände voneinander wirklich unabhängig sind und/oder ob die Zustände zeitabhängig sind. Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um Testfälle, mit denen das Testobjekt zwischen dem Testfall und dem wiederholten Testfall getestet wurde, als potenziell zustandsverändernden Testfälle zu identifizieren.

Die Testanordnung vermutet beispielsweise, dass die Zustände voneinander abhängig sind und bezeichnet alle ausgeführten Testfälle zwischen dem Testfall und dem wiederholten Testfall als potenziell zustandsverändernde Testfälle. Die potenziell zustandsverändernden Testfälle können beispielsweise durch die Testanordnung weiter untersucht werden.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um bei der Erzeugung der Testfälle ungültige und/oder unerwartete und/oder zufällige Eingaben zu erzeugen.

Die Testanordnung ist somit beispielsweise ausgebildet, um Schwachstellen des Testobjekts mithilfe von erzeugten Testfällen zu entdecken. Die Testanordnung ist beispielsweise erfolgreich, wenn sie Testfälle und/oder Eingaben findet, woran der Konstrukteur oder Designer des Testobjekts nicht gedacht hat, wie z. B. ungültige und/oder unerwartete und/oder zufällige Eingaben.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um bei der Erzeugung der Testfälle einen Mutationsalgorithmus zu verwenden, welcher neue Testfälle auf Basis alter Testfälle erzeugt. Somit können Testfälle beispielsweise sukzessive bzw. schrittweise weiterentwickelt werden, indem beispielsweise bei einer Mutation nur ein Teil eines Testfalls verändert wird.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um bei einer Mutation der Testfälle einen oder mehrere Algorithmen des maschinellen Lernens oder „machine learning algorithm“ zu verwenden.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um ausgehend von einem oder mehreren vordefinierten und/oder zufälligen Testfällen eine Mehrzahl von Zwischentestfällen, z. B. mittels einer Mutation zu erzeugen. Die Testanordnung ist ausgelegt, um den Zwischentestfällen jeweils einen Fitnesswert zuzuordnen, um die Zwischentestfälle abhängig von dem jeweiligen zugeordneten Fitnesswert auszusuchen und um die ausgesuchten Zwischentestfälle als neue Testfälle weiterzuverwenden.

Beispielsweise können z. B. die Zwischentestfälle mit den höchsten Fitnesswerten oder z.

B. die Zwischentestfälle mit einem Fitnesswert über einem vordefinierten Schwellenwert ausgesucht werden und als neue Testfälle weiterverwendet werden. Somit können beispielsweise Testfälle einerseits sukzessive verändert (z.B. nur teilweise bzw. in einzelnen Werten oder Teilmengen von Werten verändert) bzw. weiterentwickelt werden, und es können andererseits für die tatsächliche Testdurchführung solche Testfälle ausgewählt werden, die aufgrund ihres zugeordneten Fitnesswertes besonders fähig sind eine Fehlfunktion des Testobjekts zu verursachen.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um den Zwischentestfällen jeweils einen Fitnesswert anhand einer Wahrscheinlichkeit einer Fehlfunktion des mit dem Zwischentestfall getesteten Testobjekts zuzuordnen.

Die Testanordnung ist ausgebildet, um Schwachstellen des Testobjekts mithilfe von ausgewählten Zwischentestfällen zu entdecken. Die Zwischentestfälle werden anhand ihrer (z.B. erwarteten) Fähigkeit, eine Fehlfunktion des Testobjekts zu verursachen (die beispielsweise durch den Fitnesswert beschreiben wird), evaluiert. Dadurch werden möglichst viele Schwachstellen entdeckt.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um bei einer Bestimmung des Fitnesswerts einen oder mehrere Algorithmen des maschinellen Lernens zu verwenden.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um einen oder mehrere Algorithmen des maschinellen Lernens, wie Stützvektormaschine-Algorithmen, oder Support Vector Machine Algorithmen und/oder Zufallsbaum-Algorithmen, oder Random Tree Algorithmen und/oder neuronales Netz Algorithmen, zu verwenden.

Die Verwendung von bekannte Algorithmen vereinfacht die Verwendung von dem maschinellen Lernen Konzept. Bekannte Algorithmen sind einfach zu implementieren.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um den Algorithmus des maschinellen Lernens oder die Algorithmen des maschinellen Lernens anhand der Testergebnisse der ausgeführten Testfällen nachzutrainieren.

Ein fortlaufend lernender Algorithmus verbessert sich selbst mit der Zeit und bleibt immer auf dem neuesten Stand. Verbesserungen des Modells können somit ausgenutzt werden, beispielsweise zur Erzeugung neuer Testfälle und/oder zur Bewertung von Testergebnissen. Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um eine Sequenz von Testfällen auszuführen und deren Testergebnisse als eine Beobachtungssequenz für ein Training eines verdeckten Markovmodells (Hidden Markov Modells) zu verwenden, und um basierend auf einer Beobachtungssequenz Zustände eines Zustandsautomaten mit dem Hidden Markov Modell (HMM) zu schätzen oder zu approximieren.

Es wurde erkannt, dass das HMM beispielsweise für die Modellierung von Zuständen und Übergängen mit unterschiedlicher Wahrscheinlichkeit zwischen den Zuständen beispielsweise bei einem Testobjekt mit unbekanntem Verhalten gut geeignet ist.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um das Testobjekt in die einzelnen Zustände des Hidden Markov Modells zu bringen und um pro Zustand mehrere Testfälle zu erzeugen, die das Testobjekt ausgehend von dem aktuellen Zustand in die anderen Zustände des Hidden Markov Modells bringen, um eine gute Pfadabdeckung des Hidden Markov Modells zu erreichen.

Eine gute Pfadabdeckung hilft der Testanordnung, die interne Funktionsweise des Testobjekts zu verstehen und dadurch bessere Testfälle zu erzeugen. Bei jedem Zustandsübergang können Fehler und dadurch potentiale Angriffspunkte vorkommen, die so identifiziert werden können.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um den wahrscheinlichsten Ausführungspfad eines Testfalls in dem Hidden Markov Modell durch einen Viterbi-Algo- rithmus zu berechnen, und um basierend darauf die Pfadabdeckung der Testfälle zu berechnen.

Durch den Viterbi-Algorithmus kann in einem HMM der Pfad berechnet werden, der am wahrscheinlichsten bei einer Ausführung eines Testfalls durch das Modell genommen wurde. Dieser Pfad approximiert den Ausführungspfad des SLITs und wird zur Quantifizierung des Verhaltens des SLITs genutzt, was wiederum zur Erzeugung neuer Testfällege- nutzt wird. Die Pfadabdeckung kann im Übrigen beispielswiese als Kriterium bzw. als Maß für die Güte des Tests bzw. Testfalls bzw. für die Testabdeckung verwendet werden.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um das Modell und/oder die generierten Testfälle immer weiter zu verfeinern. Die Testanordnung schafft somit beispielsweise eine positive Rückkopplungsschleife, bei der die neuen Testfälle das Modell verbessern und anhand des verbesserten Modells wiederum neue Testfälle erzeugt werden.

Die Testanordnung kann unterschiedliche Testobjekte, wie zum Beispiel Webanwendungen, Netzwerkprotokolle oder Netzwerkschnittstellen testen. Diese konkreten Beispiele werden folgend erläutert.

Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um einen oder mehrere Testfälle für eine Webanwendung zu erzeugen, und um die Antwort der Webanwendung zu empfangen und/oder auszuwerten.

Die Testanordnung kann ausgelegt sein, um den Testfall oder die Testfälle in Form von Eingaben in ein oder mehrere Eingabefelder der Webanwendung und/oder Aktivierung von einer oder mehreren Schaltflächen der Webanwendung und/oder Aktivierung von einem oder mehreren Links der Webanwendung zu erzeugen.

Die Testanordnung kann ausgelegt sein, um die Antwort der Webanwendung zu empfangen und/oder auszuwerten. Die Antwort der Webanwendung kann in Form von Aktivierung oder Deaktivierung von einem oder mehreren Eingabefeldern der Webanwendung und/oder Aktivierung oder Deaktivierung von einer oder mehreren Schaltflächen der Webanwendung und/oder Aktivierung oder Deaktivierung von einem oder mehreren Links der Webanwendung und/oder Zufügung oder Entfernung von einem oder mehreren Eingabefeldern und/oder einer oder mehreren Schaltflächen und/oder einem oder mehreren Links, und/oder Änderung von einem oder mehreren Texten oder Zahlen vorkommen.

Bei anderen Ausführungsbeispielen ist die Testanordnung ausgelegt, um einen oder mehrere Testfälle für ein Testobjekt, das ein Netzwerkprotokoll verwendet, zu erzeugen, und um die Antwort des Testobjekts zu empfangen und/oder auszuwerten.

Die Testanordnung kann ausgelegt sein, um den Testfall oder die Testfälle in Form von einer oder mehreren Eingaben in einer Sequenz von einem oder mehreren Netzwerkpaketen zu erzeugen.

Die Testanordnung kann ausgelegt sein, um die Antwort des Testobjekts in Form von einer Sequenz von einem oder mehreren Netzwerkpaketen und/oder in Form von Informationen bezüglich einer Codeabdeckung der Eingabe zu empfangen und/oder auszuwerten. Als Codeabdeckung bezeichnet man beispielsweise das Verhältnis an tatsächlich getroffenen Aussagen eines Tests gegenüber den theoretisch möglich treffbaren Aussagen, oder auch den Anteil der durchlaufenen (und damit getesteten) Software-Blöcke.

Die Testanordnung kann ausgelegt sein, um basierend auf den Testfällen und darauf basierenden Codeabdeckungen einen Zustandsautomat aufzubauen, um mittels einer Hash- Funktion einen Wert für einen Zustand des Testobjekts zu berechnen, und um den Zustand mit dem berechneten Wert zu identifizieren.

Die Testanordnung kann ausgelegt sein, um eine Sequenz der Kommunikation zwischen der Testanordnung und dem Testobjekt als eine Beobachtungssequenz für ein Training eines verborgenen bzw. verdeckten Markov-Modells (Hidden Markov Modells) zu verwenden, und um basierend auf der Beobachtungssequenz die Codeabdeckung mit dem Hidden Markov Modell zu schätzen oder zu approximieren.

Die Testanordnung kann ausgelegt sein, um das Testobjekt in die einzelnen Zustände des Hidden Markov Modells als Ausgangszustand zu bringen und um pro Zustand mehrere Testfälle zu erzeugen, die das Testobjekt ausgehend von dem aktuellen Zustand in die anderen Zustände des Hidden Markov Modells bringen, um eine gute Pfadabdeckung des Hidden Markov Modells zu erreichen.

Die Testanordnung kann ausgelegt sein, um den wahrscheinlichsten Ausführungspfad eines Testfalls in dem Hidden Markov Modell durch einen Viterbi-Algorithmus zu berechnen und um basierend darauf die Pfadabdeckung der Testfälle zu berechnen.

Bei weiteren Ausführungsbeispielen ist die Testanordnung ausgelegt, um Testfälle in Form von Eingaben eines Netzwerkpakets oder einer Sequenz von Netzwerkpaketen für eine Netzwerkschnittstelle eines Testobjekts zu erzeugen, und um die Funktionsfähigkeit des Testobjekts oder die Funktionsfähigkeit einer oder mehrerer Funktionen des Testobjekts mittels Monitoren auszuwerten.

Weitere Ausführungsbeispiele gemäß der vorliegenden Erfindung schaffen entsprechende Verfahren bzw. Computerprogramme.

Figurenkurzbeschreibung Ausführungsbeispiele gemäß der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert.

Fig. 1 zeigt eine schematische Darstellung eines Ablaufs eines Ausführungsbeispiels einer Testanordnung;

Fig. 2 zeigt ein Ablaufdiagramm eines Ausführungsbeispiels einer positiven Rückkopplungsschleife;

Fig. 3 zeigt ein Ablaufdiagramm eines Ausführungsbeispiels eines Netzwerkprotokolls mit einem Zugriff auf Informationen bezüglich einer Codeabdeckung;

Fig. 4 zeigt eine schematische Darstellung eines Ausführungsbeispiels eines evolutionären Algorithmus.

Detaillierte Beschreibung der Ausführunqsbeispiele gemäß den Figuren

Im Folgenden werden Ausführungsbeispiele mit Bezug auf die Figuren näher beschrieben. Außerdem sind Verfahrensschritte, die ein bestimmtes Merkmal einer Vorrichtung betreffen mit ebendiesem Merkmal der Vorrichtung austauschbar, was ebenso anders herum gilt.

Figur 1 zeigt eine schematische Darstellung eines Ablaufs 100 eines Ausführungsbeispiels einer Testanordnung (TE) 101. Die TE 101 ist mit einem Testobjekt (SUT) 104 über einen oder mehrere Kommunikationswege 103 verknüpft. Die TE 101 weist einen oder mehrere Monitoren 106 oder Überwachungsmodule 106 auf, und ist zusätzlich mit einem Modell 107 des Testobjekts 104 verknüpft.

Das Modell 107 des SLITs 104 wird bzw. wurde beispielsweise von der TE 101 auf Basis einer Interaktion 108 oder einer initialen Interaktion 108 mit dem Testobjekt 104 erstellt.

Die TE 101 ist ausgelegt, um eine oder mehrere Testfälle 102 anhand des Modells 104 zu erstellen und eine, mehrere oder keine auf den erzeugten Testfall 102 gegebenen Antwort 105 zu empfangen. Die TE 101 ist ferner ausgelegt, um die Funktionsfähigkeit einer oder mehrerer Funktionen des SLITs mittels einem oder mehreren Monitoren 106 zu überprüfen. Die empfangenen Antworten 105 und/oder die Ergebnisse der Monitoren 106 werden ausgewertet, um Testergebnisse 109 zu erstellen. Anhand der Testergebnisse 109 verbessert die TE 101 das Modell 107 des SLITs 104. Dadurch werden die neu generierten Testfälle 102 verbessert und die darauf gegebenen Ergebnisse 109 werden wiederum das Modell 107 verfeinert.

Mit anderen Worten stellt Figur 1 den schematischen Ablauf eines Ausführungsbeispiels dar. Die Testanordnung (TE) 101 generiert einen oder mehrere neue Testfälle 102 und schickt diese über einen Kommunikationsweg 103 an das Testobjekt (SUT) 104. Das SUT 104 reagiert daraufhin mit einer, mehreren oder keiner Antwort 105 über einen oder mehrere Kommunikationswege 103. Die TE 101 wertet die empfangenen Antworten 105 sowie die Ergebnisse der Monitoren 106 aus. Aus den gesendeten Testfällen 102, den empfangenen Antworten 105 und den Ergebnissen der Monitoren 106 wird das Modell 107 des SLITs 104 abgeleitet und beispielsweise ständig aktualisiert. Auf Basis des (gegebenenfalls verbesserten) Modells 107 sowie der Auswertung der empfangenen Antworten 105 und/oder der Ergebnisse der Monitoren 106 erzeugt die TE 101 einen oder mehrere neue Testfälle 102 und schickt diese wiederum an das SUT 104.

Die Testanordnung 101 simuliert mit den Testfällen 102 virtuelle Angriffe, um Schwachstellen des Testobjekts 104 zu entdecken und protokolliert zudem die Testfälle 102, die zu einer Anomalie im Verhalten des SUTs 104 geführt haben. Die Entscheidung, ob eine Anomalie vorliegt, wird beispielsweise auf Basis des Modells 107 getroffen. Durch die Nutzung des Modells 107 können die Sicherheits-Tests (Security-Tests) vollumfänglich durchgeführt werden.

Zudem erfolgt die Erstellung und Aktualisierung des Modells 107 automatisiert ohne die Notwendigkeit, manuell einzugreifen bzw. die interne Funktionalität des SUTs 104 analysieren zu müssen. Dadurch können Sicherheits-Tests (Security-Tests) mit weniger Aufwand durchgeführt werden. Dies ermöglicht eine höhere Testabdeckung zur Entdeckung oder Beseitigung von mehrere Schwachstellen und damit die Erhöhung der Robustheit gegenüber virtuellen Angriffen.

Die Testanordnung schafft eine positive Rückkopplungsschleife, bei der die neue Testfälle 102 das Modell 107 verbessern und anhand des verbesserten Modells 107 wiederum neue verbesserte Testfälle 102 erzeugt. Diese Rückkopplungsschleife wird noch in Figur 2 erläutert werden. Figur 2 zeigt ein Ablaufdiagramm eines Ausführungsbeispiels einer positiven Rückkopplungsschleife 200, die beispielsweise optional in Testanordnungen gemäß Ausführungsbeispielen der vorliegenden Erfindung eingesetzt werden kann. Die Rückkopplungsschleife 200 weist beispielsweise fünf Schritte auf.

Der erste Schritt 210 weist eine Ausführung einer Anfrage oder einen Testfall, wie z. B. der Testfall 102 in Figur 1 , auf. Der erste Schritt 210 ist beispielsweise mit dem zweiten Schritt 220 und dem fünften Schritt 250 verknüpft.

Der zweite Schritt 220 weist eine Zusammenfassung der Antworten, wie z. B. der Antwort 105 in Figur 1 , oder der Testergebnisse auf. Der zweite Schritt 220 ist beispielsweise mit dem ersten Schritt 210 und mit dem dritten Schritt 230 verknüpft.

Der dritte Schritt 230 weist eine Identifikation von zustandsverändernden Anfragen oder Testfälle auf. Der dritte Schritt 230 ist beispielsweise mit dem zweiten Schritt 220 und mit dem vierten Schritt 240 verknüpft.

Der vierte Schritt 240 weist eine Ableitung oder eine Verbesserung des Zustandsautomaten auf. Der vierte Schritt 240 ist beispielsweise mit dem dritten Schritt 230 und mit dem fünften Schritt 250 verknüpft.

Der fünfte Schritt 250 weist eine Auswahl der nächsten Anfrage oder des nächsten Testfalls, wie z. B. der Testfall 102 in Figur 1 , auf. Der fünfte Schritt 250 ist mit dem vierten Schritt 240 und mit dem ersten Schritt 210 verknüpft.

Die TE führt in dem ersten Schritt 210 einen Testfall oder eine Anfrage aus. Die Ausführung 210 des Testfalls provoziert ein Testergebnis, das in dem zweiten Schritt 220 aus einer, mehreren oder keiner Antwort und/oder einer Verhaltensänderung erzeugt oder zusammengefasst wird bzw. wurde. Die zustandsverändernden Testfälle werden in dem dritten Schritt 230 anhand der provozierten Testergebnissen identifiziert. Das Modell des SLITs oder der Zustandsautomat wird in dem vierten Schritt 240 mithilfe von den identifizierten zustandsverändernden Testfällen aktualisiert oder abgeleitet. In dem fünften Schritt 250 werden neue Testfälle anhand der schon ausgeführten Testfälle und mithilfe von dem aktualisierten Modell erzeugt. Die neu erzeugten Testfälle werden wiederum in dem ersten Schritt 210 ausgeführt und somit fängt die Rückkopplungsschleife 200 von vorne an. Bis eine aussagekräftige Menge von Anfragen oder Testfällen nicht erreicht wird, kann die TE noch keine fundierte Aussage über das Verhalten des Testobjekts treffen und haben die drei Schritte auf der rechten Seite der Darstellung noch keine Wirkung. Dieser Fall ist durch den gestrichelten Pfeil dargestellt.

Konkrete Umsetzungen

Die konkrete Umsetzung des oben genannten Lösungswegs kann auf verschiedene Arten erfolgen. Im Folgenden werden verschiedene beispielhafte Umsetzungen dargestellt. Dies ist keine abschließende Liste und insbesondere sind Kombinationen der Umsetzungen möglich. Die Verschiedenartigkeit der Beispiele illustriert, dass die Erfindung auf viele Arten umgesetzt werden kann.

Eine Umsetzung der Erfindung stellt ein sogenanntes „Fuzzing“ (Robustheits-Testen) einer Webanwendung auf Basis eines Zustandsautomaten dar bzw. umfasst ein Fuzzing. In diesem Fall entspricht das SUT einer Webanwendung, die auf einem technischen Gerät oder Testobjekt zur Verfügung gestellt wird, das Modell wird durch einen Zustandsautomaten gebildet und die Teststrategie basiert auf „Fuzzing“. „Fuzzing“ bezeichnet in diesem Fall das Einsetzen von vielen verschiedenen Werten und die Reaktion des SUTs auf diese, möglicherweise unerwarteten Werte. Im konkreten Fall einer Webanwendung kann dies beispielsweise die Eingabe von Sonderzeichen oder Programmcode, wie z. B. Java Script Code in ein Textfeld sein. In dem Fall dieser Umsetzung wird das SUT als sogenannte „Blackbox“ (also beispielsweise als ein geschlossenes System unter Vernachlässigung des inneren Aufbaus) betrachtet, es sind also keine Informationen über die Interna des SUTs bekannt. Ein Testfall besteht in dieser Umsetzung beispielsweise aus einer HTTP-Anfrage.

Das konkrete Vorgehen wird anhand Figur 2 veranschaulicht. Der Kreislauf beginnt in der Darstellung oben links. Zunächst wird beispielsweise die initiale Anfrage an die Webanwendung gesendet, es wird also beispielsweise die Startseite der Webanwendung aufgerufen. Bis eine aussagekräftigen Menge an Anfragen gestellt wurde, kann noch keine fundierte Aussage über das Verhalten der Webanwendung getroffen werden. Deshalb bleiben die drei Schritte auf der rechten Seite der Darstellung beispielsweise zunächst ohne Wirkung. Dieser Fall ist durch den gestrichelten Pfeil dargestellt. Auf Basis der abgefragten Startseite werden nun die nächsten Anfragen abgeleitet. So werden beispielsweise neu gefundene Hyperlinks gewählt oder Buttons betätigt. Die jeweiligen Antworten werden beispielsweise in sogenannte Antwortcluster zusammengefasst. Dabei werden beispielsweise ähnliche Antworten in einem Cluster oder in einer Gruppe zusammengefasst. Dies ist beispielsweise für Webseiten der Fall, die sich nur durch die aktuelle Uhrzeit unterscheiden, aber ansonsten inhaltlich identisch sind.

Bei der Untersuchung werden beispielsweise die gleichen Anfragen gezielt häufiger gestellt. Darüber ist es möglich festzustellen, ob sich die Antwort der Webanwendung auf die gleiche Anfrage mit der Zeit ändert. Sollte sich beispielsweise eine Antwort auf eine Anfrage von der vorherigen Antwort auf die gleiche Anfrage unterscheiden, wird beispielsweise davon ausgegangen, dass zwischen diesen beiden Anfragen ein interner Zustandsübergang der Webanwendung stattgefunden hat.

Anschaulich wird das beispielsweise bei einem Online-Shop. Habe ich noch kein Element in meinen Warenkorb gelegt und klicke dennoch auf „Mein Warenkorb“, erreiche ich eine Webseite, die meinen leeren Warenkorb anzeigt. Lege ich jedoch ein Element in meinen Warenkorb und ändere somit den internen Zustand der Webanwendung, erreiche ich bei der gleichen Anfrage nach meinem Warenkorb eine andere Antwort. Beispielsweise könnte nun die Möglichkeit bestehen, den Knopf, oder Button „Zur Kasse“ zu betätigen, was zuvor mit einem leeren Warenkorb nicht möglich war.

Alle Anfragen, die zwischen den beiden betrachteten Anfragen liegen, wie z. B. zwischen den zwei Aufrufen von der „Mein Warenkorb“ Seite, können ein Auslöser für die Zustandsveränderung sein bzw. als Auslöser für eine Zustandsveränderung identifiziert. Beispielsweise auf Basis von einer Heuristik werden diese zustandsverändernden Anfragen identifiziert. In diese Heuristik wird beispielsweise einbezogen, wie oft die Anfrage in der Vergangenheit bereits als zustandsverändernd identifiziert wurde, wie oft die Anfrage schon ausgeführt wurde, und der Typ der Antwort oder Nachricht, wie z. B. GET, POST.

Auf Basis der so erhaltenen Informationen wird der aktuelle Zustandsautomat erstellt oder verbessert. Dabei wird davon ausgegangen, dass sich die Webanwendung so lange in einem Zustand befindet, bis eine zustandsverändernde Anfrage ausgeführt wird.

Nun wird der Kreislauf weitergeführt. Es werden immer weiter mögliche Anfragen ausgewählt und der Zustandsautomat wird immer weiter verfeinert. Sind die über die Webseite erreichbaren Hyperlinks, Eingabefelder und Buttons erschöpft, übernimmt der Robustheitstest-Algorithmus bzw. Fuzzing-Algorithmus die Auswahl der nächsten Anfrage. Dafür werden nun beispielsweise verfügbare URL-Parameter und Eingabewerte eine große Auswahl von Werten ausprobiert. Die Reaktion der Webanwendung wird beispielsweise mit dem Zustandsautomaten abgeglichen. Verhält sich die Webanwendung beispielsweise anders als das Modell, wird dies als Anomalie bewertet, die auf eine Schwachstelle hindeuten kann.

Eine andere Umsetzung der Erfindung basiert ebenfalls auf einem Zustandsautomaten, hat als Ziel jedoch die Implementierung eines Netzwerkprotokolls. Ein Testfall besteht in dieser Umsetzung aus einer Sequenz von einem oder mehreren Netzwerkpaketen. Zudem wird in dieser Umsetzung vorausgesetzt, dass Zugriff auf Informationen bezüglich der Codeabdeckung einer bestimmten Eingabe vorliegt. Das bedeutet im konkreten Fall, dass die TE oder der Algorithmus nach der Eingabe einer bestimmten Sequenz an Netzwerkpaketen Informationen darüber bekommt, welche Codeblöcke das SUT als Reaktion auf diese Sequenz an Netzwerkpaketen durchlaufen hat. Diese Information wird verwendet um die Güte eines Testfalls zu bewerten. So wird beispielsweise ein Testfall, der viele neue Stellen im Code auslöst, mit einer hohen Güte bewertet. Der Ablauf dieses Beispiels wird in Figur 3 veranschaulicht.

Figur 3 zeigt ein Ablaufdiagramm 300 einer Implementierung eines Netzwerkprotokolls mit einem Zugriff auf Informationen bezüglich einer Codeabdeckung. Das Ablaufdiagramm 300 weist eine Schleife mit beispielsweise vier Schritten auf.

Der erste Schritt 310 weist beispielsweise eine Bereitstellung oder Ausführung einer Sequenz von Netzwerkpaketen oder eines Testfalls, wie z. B. der Testfall 102 in Figur 1 , auf. Der erste Schritt 310 ist mit dem zweiten Schritt 320 und dem vierten Schritt 340 verknüpft.

Der zweite Schritt 320 weist beispielsweise eine Berechnung des Verhaltens des SUTs oder eine Codeabdeckungsanalyse auf. Der zweite Schritt 320 ist beispielsweise mit dem ersten Schritt 310 und mit dem dritten Schritt 330 verknüpft.

Der dritte Schritt 330 weist beispielsweise eine Überprüfung und ggf. Aktualisierung des Zustandsautomaten auf. Der dritte Schritt 330 ist beispielsweise mit dem zweiten Schritt 320 und mit dem vierten Schritt 340 verknüpft. Der vierte Schritt 340 weist beispielsweise eine Auswahl der nächsten Sequenz von Netzwerkpaketen auf. Der vierte Schritt 340 ist beispielsweise mit dem dritten Schritt 330 und mit dem ersten Schritt 310 verknüpft.

Die TE führt in dem ersten Schritt 310 einen Testfall aus. Der Testfall besteht in dieser Umsetzung aus einer Sequenz von einem oder mehreren Netzwerkpaketen. Nach der Eingabe einer bestimmten Sequenz an Netzwerkpaketen (beispielsweise in das SUT) bekommt die TE (beispielsweise von dem SUT) Informationen darüber, welche Codeblöcke das SUT als Reaktion auf die Sequenz an Netzwerkpaketen durchlaufen hat. Anhand dieser Informationen oder dieser Codeabdeckung wird beispielsweise in dem zweiten Schritt 320 das Verhalten des SUTs analysiert oder berechnet. Diese Analyse führt beispielsweise in dem dritten Schritt 330 zu einer Überprüfung und ggf. Aktualisierung des Zustandsautomaten des SUT-Modells. Anhand des aktualisierten Modells wird beispielsweise in dem vierten Schritt 340 die nächsten Sequenz von Netzwerkpaketen erzeugt oder ausgewählt, die wiederum in dem ersten Schritt ausgeführt wird.

Das konkrete Vorgehen des Beispiels ist in Figur 3 dargestellt. Der Kreislauf beginnt hier auch oben links. Die initiale Sequenz von Netzwerkpaketen wird in diesem Fall von einem Startwert bzw. einem sogenannten „Seed“ vorgegeben. Dieser kann beispielsweise ein einzelnes gültiges Netzwerkpaket sein, eine Sequenz von Netzwerkpaketen oder auch eine leere Menge. Dieser Beginn wird also beispielsweise an das SUT gesendet und die Informationen über die Codeabdeckung werden erhalten. Auf Basis von dieser Codeabdeckung wird beispielsweise mittels einer Hash-Funktion ein Wert für das Verhalten des SUTs berechnet. Auf Basis dieses Verhaltens wird nun beispielsweise ein Zustandsautomat aufgebaut. Dabei wird beispielsweise solange davon ausgegangen, dass sich das System in einem Zustand befindet, bis ein dazu widersprüchliches Verhalten beobachtet wird. Dies basiert beispielsweise auf einem L*-Algorithmus.

Die Auswahl der nächsten Sequenz basiert auf einem sogenannten Startwert-Auswahl-Al- gorithmus bzw. „Seed-Selection-Algorithmus“. In dieser Auswahl ist beispielsweise auch ein Mutationsalgorithmus enthalten, welcher neue Testfälle auf Basis der alten Testfälle generiert und/oder ausführt. Zudem bezieht die Auswahl des nächsten Testfalles beispielsweise den Zustandsautomaten ein.

Ist beispielsweise ein Zustand noch nicht ausreichend erforscht, werden beispielsweise neue Sequenzen generiert, die genau diesen Zustand hervorrufen, um zu lernen, wie sich das SUT in diesem Zustand verhält. Sind alle aktuell bekannten Zustände ausreichend untersucht, werden beispielsweise neue Testfälle mit größerem Unterschied zu bereits bekannten Testfällen erzeugt. Diese sollen dazu beitragen, neue Zustände zu erreichen.

Alternativ kann die Entscheidung zwischen Exploitation und Exploration, d. h. ob bekannte Zustände weiter untersucht werden sollen oder ob neue Zustände gefunden werden sollen, als ein Mehrarmiger-Bandit-Problem (Multi-Armed-Bandit-Problem) modelliert werden. So können beispielsweise etablierte Verfahren aus dem Bestärkenden Lernen (Reinforcement Learning) wie der Obere-Vertrauensschwelle-Algorithmus (Upper Confidence Bound (UCB) Algorithmus) eingesetzt werden, um diese Entscheidung zu treffen.

Während der Tests wird das SUT ständig überwacht. Wird während der Tests beispielsweise ein Absturz des Programms festgestellt wird diese Information zusammen mit dem zuvor gesendeten Testfall abgespeichert.

Figur 3 kann auch eine weitere Umsetzung der Erfindung illustrieren, bei der die Codeabdeckung auf Basis eines verdeckten Markow-Modells (Hidden Markov Modell (HMM)) illustriert ist.

In der zuletzt genannten Umsetzung wurde beispielsweise vorausgesetzt, dass Zugriff auf Informationen zur Codeabdeckung möglich war. So kann das Verhalten des SUTs quantifiziert werden und zum Aufbau eines Zustandsautomaten verwendet werden. Eine Alternative hierzu ist die im Folgenden beschriebene Umsetzung. Dabei bleibt beispielsweise die Zielsetzung, das SUT, der Algorithmus zur Erstellung des Zustandsautomaten sowie die Mutation und Auswahl der nächsten Sequenz von Netzwerkpaketen gleich. Anders ist die Berechnung des Verhaltens des SUTs. Nun wird davon ausgegangen, dass die Informationen über die Codeabdeckung nicht mehr direkt zur Verfügung stehen. Deshalb wird diese Information ebenfalls über ein Modell approximiert. Als Modelltyp wird hierfür beispielsweise ein verdecktes Markow-Modell (Hidden Markov Modell (HMM)) eingesetzt.

Zu Beginn des Testprozesses werden beispielsweise die ersten Testfälle ohne den Einsatz eines Zustandsautomaten durchgeführt. Hierzu wird beispielsweise der oben beschriebene Startwert bzw. das oben beschriebene Seed und beispielsweise die zur Verfügung stehenden Mutationen verwendet. Der dabei entstehende Netzwerkverkehr wird beispielsweise verwendet, um das HMM zu trainieren. Dabei wird beispielsweise eine Sequenz von Netz- werkpaketen der Kommunikation zwischen dem Testgerät und dem SUT als eine Beobachtungssequenz für das HMM betrachtet. Eine Sequenz von Netzwerkpaketen bezeichnet bzw. beschreibt beispielsweise die Kommunikation zwischen einem TCP Verbindungsaufbau und einem TCP Verbindungsabbau. Jedes Netzwerkpaket wird dabei beispielsweise als eine einzelne Beobachtung angesehen, was beispielsweise in manchen Fällen den Einsatz eines multivariaten HMMs notwendig macht.

Eine gute Wahl für die Anzahl der intern verwendeten Zustände kann beispielsweise über das wiederholte Trainieren das HMMs mit unterschiedlicher Knotenanzahl und einer anschließenden Gütebewertung, z. B. über das Bayessche Informationskriterium getroffen werden. Das trainierte HMM stellt nun beispielsweise ein Modell der internen Abläufe des SUT s dar und kann aus diesem Grund beispielsweise wie folgt dafür verwendet werden um die Codeabdeckung zu approximieren. Beispielsweise kann in einem HMM der Pfad, der am wahrscheinlichsten bei der letzten Ausführung durch das Modell genommen wurde, durch den Viterbi-Algorithmus berechnet (oder abgeschätzt) werden. Dieser Pfad approximiert beispielsweise den Ausführungspfad des SUTs. Dadurch kann diese Information beispielsweise so verwendet werden, wie die Information über die Codeabdeckung in der vorherigen Umsetzung. Sie wird beispielsweise wieder zur Quantifizierung des Verhaltens des SUTs genutzt, was wiederum zur Erstellung oder Aktualisierung des Zustandsautomaten genutzt wird.

Die Auswahl der nächsten Sequenz von Netzwerkpaketen basiert ebenso auf dem sogenannten Startwert-Auswahl-Algorithmus bzw. Seed-Selection-Algorithmus. In dieser Auswahl ist beispielsweise auch ein Mutationsalgorithmus enthalten, welcher neue Testfälle auf Basis der alten Testfälle generiert und/oder ausführt. Dieser Algorithmus wird folgend erläutert.

Evolutionäre Testfallbestimmung gemäß Figur 4

Figur 4 zeigt eine schematische Darstellung eines Ausführungsbeispiels eines evolutionären Algorithmus 400, der beispielsweise einzeln oder in Verbindung mit den hierin beschriebenen Ausführungsbeispielen verwendet werden kann.

Eine Population der Testfälle 420 des Algorithmus 400 ist beispielsweise mit dem SUT 410 verknüpft. Der Algorithmus weist beispielsweise einen Algorithmus des maschinellen Lernens 460 und eine Schleife von der Population der Testfälle 420, einer Mutation 430, Nachwuchstestfälle oder „Offsprings“ 440 und einer Selektion 450 auf. In anderen Worten, es kann beispielsweise in der Schleife eine Population der Testfälle erzeugt werden, und es kann dann eine Mutation erfolgen, es können somit Nachwuchstestfälle erhalten werden und es kann dann eine Auswahl bzw. Selektion erfolgen.

Der Algorithmus des maschinellen Lernens 460 ist beispielsweise mit der Population der Testfälle 420, der Mutation 430 und der Selektion 450 verknüpft.

Die Population der Testfälle 420 werden beispielsweise gegen das SUT 410 ausgeführt, um Testergebnisse, zum Beispiel mithilfe von Monitoren, zu sammeln. Anhand der Testfälle 420 und der Testergebnisse wird beispielsweise der Algorithmus des maschinellen Lernens 460 trainiert.

Durch Mutation 430 wird beispielsweise der Algorithmus des maschinellen Lernens 460 anhand der Population der Testfälle 420 neue Testfälle, die sogenannten „Offsprings“ 440 erstellen. Jeder Testfall wird beispielsweise von dem Algorithmus des maschinellen Lernens 460 mittels eines Fitnesswerts bewertet. Anhand des Fitnesswerts wird beispielsweise eine neue Population der Testfälle selektiert 450, die wiederum gegen das SUT 410 ausgeführt wird, um Testergebnisse zu sammeln.

In anderen Worten, es wird beispielsweise der evolutionäre Algorithmus verwendet um neue Testfälle zu erzeugen. Dafür wird wieder von einem Startwert (Seed) ausgegangen, der bzw. das die erste Population der Evaluation darstellt. Nun werden aus den Individuen dieser Population durch Mutation neue Individuen erzeugt. Diese werden „Offspring“ bzw. Nachkomme genannt. Nun wird zu diesen Individuen im „Offspring“ (beispielsweise zu den Nachkommen) durch eine Fitnessfunktion jeweils ein Fitnesswert zugeordnet. Im Anschluss werden beispielsweise diejenigen Individuen mit den höchsten Fitnesswerten in die neue Generation der Population aufgenommen. Bei diesem Verfahren entspricht beispielsweise jedes Individuum einem Testfall für das Testverfahren. Die neue Generation an Testfällen wird beispielsweise gegen das SUT ausgeführt und die Reaktion beispielsweise durch Mo- nitore beobachtet. Diese Umsetzung der Erfindung besteht beispielsweise aus einer Kombination von einem evolutionären Algorithmus und einem Machinelles-Lernen-Algorithmus (Machine Learning (ML) Algorithmus). Als ML-Algorithmus kann beispielsweise eine Stützvektormaschine (Support Vector Machine (SVM)), ein Zufallsbaum (Random Tree (RT)) oder ein neuronales Netz (NN) verwendet werden.

In dieser Umsetzung kann z. B. die Netzwerkschnittstelle einer Automatisierungskomponente getestet werden. Die Testfälle bestehen beispielsweise aus einem Netzwerkpaket (oder mehreren Netzwerkpaketen). Grundsätzlich ist es beispielsweise auch möglich, den Ansatz so zu erweitern, dass ein Testfall aus einer Sequenz von Netzwerkpaketen besteht. Das Modell der Automatisierungskomponente wird beispielsweise durch den jeweiligen ML Algorithmus repräsentiert und modelliert beispielsweise das Verhalten der Automatisierungskomponente in Reaktion auf einen Testfall. Das Verhalten wird beispielsweise durch die jeweils ausgefallenen Monitoren beschrieben. Im Fall einer Automatisierungskomponente bestehen diese Monitore beispielsweise unter anderem aus der Überprüfung, ob die Automatisierungskomponente noch auf Ping-Anfragen reagiert und/oder ob der Webserver der Automatisierungskomponente noch erreichbar ist.

Der gewählte ML Algorithmus kann beispielsweise in dem oben genannten evolutionären Algorithmus zur Bestimmung des Fitnesswerts eingesetzt werden. Der ML Algorithmus wird beispielsweise so trainiert, dass er eine Funktion approximiert, die einen Testfall auf die Ausgaben der Monitoren abbildet. Er schätzt also beispielsweise, welche Monitoren bei einem gegebenen Testfall wahrscheinlich fehlschlagen werden.

Ein mögliches Ergebnis der Schätzung könnte sein, dass die Automatisierungskomponente nach Ausführung des Testfalls noch auf Ping reagiert, der Webserver aber nicht mehr erreichbar ist. Über diese Schätzung kann beispielsweise die Güte, also die Fitness, eines Testfalls bzw. eines „Individuums“ bestimmt werden. Je mehr Monitore durch den Testfall ausfallen (bzw. je mehr Ausfälle als wahrscheinlich bestimmt werden), desto höher ist die Güte. So kann also eine Vorhersage gemacht werden, ob (bzw. mit welcher erwarteten Wahrscheinlichkeit) der Testfall zu einem Ausfall der Monitoren führen wird. Dies ist beispielsweise gerade im Fall von Automatisierungskomponenten sinnvoll, da hier die Ausführung eines Testfalls relativ viel Zeit in Anspruch nimmt. Die Schätzung des ML Algorithmus zur wahrscheinlichen Reaktion der Automatisierungskomponente kann beispielsweise deutlich schneller berechnet werden. Trainiert wird der ML Algorithmus beispielsweise zunächst auf der Reaktion des SUTs auf die Testfälle, die sich in den Anfangswerten bzw. im „Seed“ befinden. Im Anschluss wird es beispielsweise immer weiter auf den tatsächlich ausgeführten Testfällen nachtrainiert. Hier liegen beispielsweise durch das anschließend gemessene Verhalten der Monitoren ebenfalls die notwendigen Bewertungen bzw. Markierungen bzw. „Labels“ für die Testfälle vor.

Zudem wirkt der ML Algorithmus beispielsweise auch auf die Mutation der Testfälle ein. Wie diese Einwirkung konkret aussieht, hängt beispielsweise von dem gewählten ML Algorithmus ab. Bei einem NN kann beispielsweise der Gradient berechnet werden, der in die Richtung eines (lokalen) Maximums der approximierten Funktion zeigt. Dieses lokale Maximum entspricht dann beispielsweise einem Testfall, der eine möglichst hohe Anzahl von Monitoren betreffen wird. Durch eine Anpassung der Testfälle entsprechend diesem Gradienten, können beispielsweise neue Testfälle erzeugt werden, die eine hohe Wahrscheinlichkeit dafür haben, viele Monitoren ausfallen zu lassen. Ähnlich ist es bei der SVM, auch hier können beispielsweise Vektoren berechnet werden, die auf die Testfälle zeigen, die eine hohe Anzahl von Monitoren ausfallen lassen.

Bei einem RT können keine Gradienten oder Vektoren berechnet werden, aber dennoch kann er für die Mutation verwendet werden. Durch die Nachverfolgung des Pfads, den ein Testfall durch den Baum genommen hat, können beispielsweise Rückschlüsse auf notwendige Änderungen in einem Testfall gezogen werden. So kann beispielsweise überprüft werden welche Entscheidungen im RT zu der Schätzung geführt haben, dass der Testfall nicht viele Monitore zum Ausfall bringen wird. Diese Entscheidungen basieren beispielsweise auf Schwellenwerten von bestimmten Eigenschaften des Testfalls. Nun können beispielsweise neue Testfälle erzeugt werden, die über bzw. unter diesen Schwellenwert kommen. Diese Testfälle haben dann beispielsweise eine höhere Wahrscheinlichkeit dafür, dass sie eine hohe Anzahl an Monitoren ausfallen lassen.

Wie es in Figur 4 dargestellt ist, beginnt der gesamte Prozess mit einem Startwert bzw. „Seed“, der beispielsweise als initiale Population eingesetzt wird. Die Testfälle dieser Population werden gegen das SUT ausgeführt und die Reaktionen beispielsweise der Monitore werden aufgenommen. So erhält der Algorithmus die Bewertungen bzw. Markierungen bzw. „Label“ für die Testfälle in der Population. Die Kombination aus Testfällen und zugehörigen Labels werden nun beispielsweise verwendet, um ein erstes Training des ML Algorithmus durchzuführen. Dieser wird im Anschluss beispielsweise verwendet um die Mutation und die Selektion durchzuführen. So entsteht beispielsweise eine neue Population, die wiederum gegen das SUT ausgeführt wird. Es werden beispielsweise wieder die Reaktionen der Monitore aufgenommen und der ML Algorithmus wird beispielsweise mit dem so neu erzeugten Datensatz nachtrainiert. So wird ein Robustheitstest-Prozess bzw. Fuzzing- Prozess etabliert, bei dem die Testfallerzeugung beispielsweise durch Mutation und die Auswahl von den erzeugten Testfällen durch einen ML Algorithmus unterstützt wird. Dieser ML Algorithmus stellt beispielsweise ein Modell des SUTs dar, indem er eine Funktion approximiert, die das Verhalten des SUTs in Reaktion auf einen Testfall beschreibt.

Alternative Ausführungsbeispiele

Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Testanordnung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Testanordnung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.

Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, sodass ein Block oder ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden Blocks oder Details oder Merkmals einer entsprechenden Vorrichtung dar. Einige oder alle der Verfahrensschritte können durch einen Hardware-Apparat (oder unter Verwendung eines Hardware-Apparats), ausgeführt werden. Bei einigen Ausführungsbeispielen können einige oder mehrere der wichtigsten Verfahrensschritte durch einen solchen Apparat ausgeführt werden.

Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einem programmierbaren Computersystem derart Zusammenwirken können oder Zusammenwirken, dass das jeweilige Verfahren durchgeführt wird. Deshalb kann das digitale Speichermedium computerlesbar sein.

Manche Ausführungsbeispiele gemäß der Erfindung umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird.

Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Computerprogrammprodukt mit einem Programmcode implementiert sein, wobei der Programmcode dahingehend wirksam ist, eines der Verfahren durchzuführen, wenn das Computerprogrammprodukt auf einem Computer abläuft.

Der Programmcode kann beispielsweise auch auf einem maschinenlesbaren Träger gespeichert sein.

Andere Ausführungsbeispiele umfassen das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren, wobei das Computerprogramm auf einem maschinenlesbaren Träger gespeichert ist.

Mit anderen Worten ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens somit ein Computerprogramm, das einen Programmcode zum Durchführen eines der hierin beschriebenen Verfahren aufweist, wenn das Computerprogramm auf einem Computer abläuft.

Ein weiteres Ausführungsbeispiel der erfindungsgemäßen Verfahren ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.

Ein weiteres Ausführungsbeispiel des erfindungsgemäßen Verfahrens ist somit ein Datenstrom oder eine Sequenz von Signalen, der bzw. die das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom oder die Sequenz von Signalen kann bzw. können beispielsweise dahingehend konfiguriert sein, über eine Datenkommunikationsverbindung, beispielsweise über das Internet, transferiert zu werden.

Ein weiteres Ausführungsbeispiel umfasst eine Verarbeitungseinrichtung, beispielsweise einen Computer oder ein programmierbares Logikbauelement, die dahingehend konfiguriert oder angepasst ist, eines der hierin beschriebenen Verfahren durchzuführen.

Ein weiteres Ausführungsbeispiel umfasst einen Computer, auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren installiert ist.

Ein weiteres Ausführungsbeispiel gemäß der Erfindung umfasst eine Vorrichtung oder ein System, die bzw. das ausgelegt ist, um ein Computerprogramm zur Durchführung zumindest eines der hierin beschriebenen Verfahren zu einem Empfänger zu übertragen. Die Übertragung kann beispielsweise elektronisch oder optisch erfolgen. Der Empfänger kann beispielsweise ein Computer, ein Mobil gerät, ein Speichergerät oder eine ähnliche Vorrichtung sein. Die Vorrichtung oder das System kann beispielsweise einen Datei-Server zur Übertragung des Computerprogramms zu dem Empfänger umfassen.

Bei manchen Ausführungsbeispielen kann ein programmierbares Logikbauelement (beispielsweise ein feldprogrammierbares Gatterarray, ein FPGA) dazu verwendet werden, manche oder alle Funktionalitäten der hierin beschriebenen Verfahren durchzuführen. Bei manchen Ausführungsbeispielen kann ein feldprogrammierbares Gatterarray mit einem Mikroprozessor Zusammenwirken, um eines der hierin beschriebenen Verfahren durchzuführen. Allgemein werden die Verfahren bei einigen Ausführungsbeispielen seitens einer beliebigen Hardwarevorrichtung durchgeführt. Diese kann eine universell einsetzbare Hardware wie ein Computerprozessor (CPU) sein oder für das Verfahren spezifische Hardware, wie beispielsweise ein ASIC.

Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei. Literatur

[1] Bringmann, Eckard, and Andreas Krämer. "Model-based testing of automotive sys- terns." 2008 1st international conference on software testing, verification, and validation. IEEE, 2008.

[2] Bauer, Thomas, et al. "Combining combinatorial and model-based test approaches for highly configurable safety-critical systems." Model-based Testing in Practice (2009): 9.