-
Stand der Technik
-
Die vorliegende Offenbarung bezieht sich auf Verfahren zum Testen von Computerprogrammen.
-
Ein wesentlicher Bestandteil der Entwicklung von Softwareanwendungen ist das Testen. Insbesondere sollten Fehler, die zum Versagen einer Anwendung führen, identifiziert und korrigiert werden. Ein Beispiel für das Testen von Software ist das dynamische Software-Testverfahren Fuzzing. Beim Generator-basierten Fuzzing werden dabei Test-Eingaben für eine zu testende Software unter Verwendung von Vorwissen, insbesondere der Eingabegrammatik der zu testenden Software, verwendet.
-
In bestimmten Anwendungsfällen liegt jedoch die Eingabegrammatik nicht vor, z.B. weil für sie selbst nicht sicher ist, dass sie wie vorgesehen (fehlerfrei) implementiert wurde, sie nicht genau spezifiziert wurde oder der Quellcode der Softwareanwendung nicht vorliegt (z.B. weil die Software von einem anderen Hersteller geliefert wurde).
-
Die Veröffentlichung „Mining input grammars from dynamic control flow“ von Rahul Gopinath, Björn Mathis und Andreas Zeller, in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, Seiten 172-183, 2020, im Folgenden als Referenz 1 bezeichnet, beschreibt ein Verfahren zur Ermittlung einer Eingabe-Grammatik eines Programms aus dem dynamischen Kontrollfluss des Programms. Es wird dort gezeigt, dass die Beobachtung, welche Anweisungen auf den Eingabepuffer des Programms zugreifen, ausreicht, um eine Eingabegrammatik des Programms abzuleiten, und es wird für diese Beobachtung statische Instrumentierung verwendet. In manchen Anwendungsfällen, wie z.B. zum Testen von Software für eingebettete System, ist die Anwendung von statischer Instrumentierung jedoch nicht oder nur schlecht möglich.
-
Für eine Anwendung von Generator-basiertem Fuzzing aber auch der Validierung, dass die Eingabe-Grammatik korrekt implementiert wurde, sind deshalb Herangehensweisen wünschenswert, die es ermöglichen die Eingabegrammatik eines Programms effizient zu ermitteln, insbesondere unter schwierigen Umständen, wie z.B. für Software für eingebettete Systeme, die auf einem anderen System als dem eingebetteten System selbst getestet werden müssen, z.B. weil auf dem eingebetteten System die Ressourcen beschränkt sind.
-
Offenbarung der Erfindung
-
Gemäß verschiedenen Ausführungsformen wird ein Verfahren zum Testen eines Computerprogramms bereitgestellt, aufweisend Senden von Eingabedaten für das Computerprogramm an einen Speicher, auf den das Computerprogramm zugreift, Setzen von Daten-Watchpoints an Positionen in einem Speicherbereich im Speicher, in dem die Eingabedaten gespeichert sind, Ausführen des Computerprogramms und dabei Überwachen, welche Teile eines Eingabeparsers des Computerprogramms auf die Positionen des Speicherbereichs zugreifen, Ermitteln einer Eingabegrammatik des Computerprogramms aus Ergebnissen des Überwachens und Testen des Computerprogramms unter Verwendung der ermittelten Eingabegrammatik.
-
Das oben beschriebene Verfahren das Ermitteln einer Eingabegrammatik auf Systemen mit beschränktem Zugriff und Transparenz wie eingebettete System und damit das Testen eines Computerprogramms für ein solches System unter Verwendung der Eingabegrammatik. Beispielsweise kann das Programm mittels Generator-basiertem Fuzzing unter Verwendung der Eingabegrammatik getestet werden.
-
Im Folgenden werden verschiedene Ausführungsbeispiele angegeben.
-
Ausführungsbeispiel 1 ist ein Verfahren zum Testen eines Computerprogramms, wie oben beschrieben.
-
Ausführungsbeispiel 2 ist ein Verfahren nach Ausführungsbeispiel 1, wobei das Computerprogramm ein Computerprogramm für ein eingebettetes System ist und das Computerprogramm auf dem eingebetteten System ausgeführt wird.
-
Damit wird erreicht, dass die Ausführung des Computerprogramms in einem realistischen Umfeld erfolgt und das Computerprogramm einem Ablauf folgt, wie er in der Praxis auftritt.
-
Ausführungsbeispiel 3 ist das Verfahren nach Ausführungsbeispiel 1 oder 2, aufweisend Senden unterschiedlicher Sätze von Eingabedaten, Setzen von Daten-Watchpoints an unterschiedlichen Kombinationen von Positionen im Speicherbereich und Ausführen des Computerprogramms für die unterschiedlichen Sätze von Eingabedaten und Kombinationen von Speicherbereich-Positionen und dabei jeweils Überwachen, welche Teile eines Eingabeparsers des Computerprogramms auf die Positionen des Speicherbereichs zugreifen, wobei die Eingabegrammatik des Computerprogramms aus Ergebnissen des Überwachens für die unterschiedlichen Sätze von Eingabedaten und Kombinationen von Speicherbereich-Positionen ermittelt wird.
-
Durch die unterschiedlichen Sätze von Eingabedaten kann erreicht werden, dass alle oder zumindest ein großer Teil der Verzweigungen des Eingabeparsers erfasst werden. Die unterschiedlichen Kombinationen von Daten-Watchpoints ermöglichen eine vollständige Überdeckung der Eingabedaten auch dann, wenn die Anzahl der Daten-Watchpoints, die gesetzt werden können, aufgrund von Einschränkungen des Systems, auf dem das Computerprogramm ausgeführt wird (z.B. des eingebetteten Systems) beschränkt ist.
-
Ausführungsbeispiel 4 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 3, aufweisend Testen des Computerprogramms mittels Generator-basiertem Fuzzing unter Verwendung der ermittelten Eingabegrammatik.
-
Fuzzing erlaubt insbesondere ein zuverlässiges Testen von Software für ein eingebettetes System, wenn eine Eingabegrammatik zur Verfügung steht, was wiederum durch das oben beschriebene Verfahren erreicht wird.
-
Ausführungsbeispiel 5 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 4, aufweisend Testen des Computerprogramms durch Vergleichen der ermittelten Eingabegrammatik mit einer Referenz-Eingabegrammatik für das Computerprogramm.
-
Die Referenz-Eingabegrammatik kann beispielsweise eine gewünschte oder spezifizierte Eingabegrammatik des Computerprogramms sein. Es kann so verifiziert werden, dass das Computerprogramm Eingabedaten korrekt (wie vorgesehen) verarbeitet.
-
Ausführungsbeispiel 6 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 5, wobei das Computerprogramm ein Steuerprogramm für eine Robotervorrichtung ist und die Robotervorrichtung abhängig von einem Ergebnis des Testens des Computerprogramms mit dem Computerprogramm gesteuert wird.
-
In anderen Worten kann ein Verfahren zum Steuern einer Robotervorrichtung bereitgestellt werden, bei dem mittels Ermitteln und Verwendung einer Eingabegrammatik des Steuerprogramms überprüft wird, ob das Steuerprogramm Eingabedaten (z.B. Sensordaten verschiedener Art wie Bilddaten, Messdaten physikalischer Größen) korrekt erfasst, d.h. Werte und Datentypen z.B. korrekt erfasst wie z.B. mehrere Bytes korrekt zu Werten zusammenfasst.
-
Ausführungsbeispiel 7 ist ein Testsystem, das eingerichtet ist, ein Verfahren nach einem der Ausführungsbeispiele 1 bis 6 durchzuführen.
-
Ausführungsbeispiel 8 ist ein Computerprogramm mit Befehlen, die, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor ein Verfahren nach einem der Ausführungsbeispiele 1 bis 6 durchführt.
-
Ausführungsbeispiel 9 ist ein Computerlesbares Medium, das Befehle speichert, die, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor ein Verfahren nach einem der Ausführungsbeispiele 1 bis 6 durchführt.
-
In den Zeichnungen beziehen sich ähnliche Bezugszeichen im Allgemeinen auf dieselben Teile in den ganzen verschiedenen Ansichten. Die Zeichnungen sind nicht notwendigerweise maßstäblich, wobei die Betonung stattdessen im Allgemeinen auf die Darstellung der Prinzipien der Erfindung gelegt wird. In der folgenden Beschreibung werden verschiedene Aspekte mit Bezug auf die folgenden Zeichnungen beschrieben.
- 1 zeigt einen Computer für die Entwicklung und/oder das Testen von Softwareanwendungen.
- 2 zeigt ein Datenflussdiagramm für ein Debugger-basiertes Verfahren zum Ermitteln einer Eingabegrammatik eines Computerprogramms.
- 3 zeigt ein Ablaufdiagramm, das ein Verfahren zum Testen eines Computerprogramms gemäß einer Ausführungsform darstellt.
-
Die folgende ausführliche Beschreibung bezieht sich auf die begleitenden Zeichnungen, die zur Erläuterung spezielle Details und Aspekte dieser Offenbarung zeigen, in denen die Erfindung ausgeführt werden kann. Andere Aspekte können verwendet werden und strukturelle, logische und elektrische Änderungen können durchgeführt werden, ohne vom Schutzbereich der Erfindung abzuweichen. Die verschiedenen Aspekte dieser Offenbarung schließen sich nicht notwendigerweise gegenseitig aus, da einige Aspekte dieser Offenbarung mit einem oder mehreren anderen Aspekten dieser Offenbarung kombiniert werden können, um neue Aspekte zu bilden.
-
Im Folgenden werden verschiedene Beispiele genauer beschrieben.
-
1 zeigt einen Computer 100 für die Entwicklung und/oder das Testen von Softwareanwendungen.
-
Der Computer 100 weist eine CPU (Central Processing Unit) 101 und einen Arbeitsspeicher (RAM) 102 auf. Der Arbeitsspeicher 102 wird zum Laden von Programmcode verwendet, z.B. von einer Festplatte 103, und die CPU 101 führt den Programmcode aus.
-
Im vorliegenden Beispiel wird davon ausgegangen, dass ein Benutzer beabsichtigt, mit dem Computer 100 eine Softwareanwendung zu entwickeln und/oder zu testen.
-
Dazu führt der Benutzer eine Softwareentwicklungsumgebung 104 auf der CPU 101 aus.
-
Die Softwareentwicklungsumgebung 104 ermöglicht es dem Benutzer, eine Anwendung 105 für verschiedene Geräte 106, also ein Ziel-Hardware, wie eingebettete Systeme zum Steuern von Robotervorrichtungen, inklusive Roboterarme und autonome Fahrzeuge, oder auch für mobile (Kommunikations-)Geräte, zu entwickeln und zu testen. Dazu kann die CPU 101 als Teil der Softwareentwicklungsumgebung 104 einen Emulator ausführen, um das Verhalten des jeweiligen Geräts 106 zu simulieren, für das eine Anwendung entwickelt wird oder wurde. Wird sie nur zum Testen einer Software aus anderer Quelle eingesetzt, kann die Softwareentwicklungsumgebung 104 auch als Softwaretestumgebung angesehen werden bzw. ausgestaltet sein.
-
Der Benutzer kann die fertige Anwendung über ein Kommunikationsnetzwerk 107 an entsprechende Geräte 106 verteilen. Statt über ein Kommunikationsnetzwerk 107 kann dies auch auf andere Weise erfolgen, beispielsweise mittels eines USB-Sticks.
-
Bevor dies geschieht, sollte der Benutzer jedoch die Anwendung 105 testen, um zu vermeiden, dass eine nicht ordnungsgemäß funktionierende Anwendung an die Geräte 106 verteilt wird. Dies kann auch der Fall sein, wenn der Benutzer die Anwendung 105 nicht selbst auf dem Computer 100 geschrieben hat. Insbesondere kann der Fall auftreten, dass der Benutzer nicht über den Quellcode der Anwendung, sondern lediglich über ihren ausführbaren Code (d.h. das Binärprogramm) verfügt.
-
Ein Testverfahren ist das sogenannte Fuzzing. Fuzzing oder Fuzz-Testing ist ein automatisiertes Software-Testverfahren, bei dem einem zu testenden Computerprogramm ungültige, unerwartete oder zufällige Daten als Eingaben zugeführt werden. Das Programm wird dann auf Ausnahmen wie Abstürze, fehlende fehlgeschlagene integrierte Code-Assertions oder potenzielle Speicherlecks hin überwacht.
-
Typischerweise werden Fuzzers (d.h. Testprogramme, die Fuzzing verwenden) zum Testen von Programmen verwendet, die strukturierte Eingaben verarbeiten. Diese Struktur ist z. B. in einem Dateiformat oder einem Dateiformat oder Protokoll spezifiziert und unterscheidet zwischen gültigen und ungültigen Eingaben. Ein effektiver Fuzzer erzeugt halb-gültige Eingaben die „gültig genug“ sind, um nicht direkt vom Eingabeparser des zu testenden Programms zurückgewiesen zu werden, aber „ungültig genug“ sind, um unerwartete Verhaltensweisen und Grenzfälle aufzudecken, die im zu testenden Programm nicht richtig behandelt werden.
-
Im Folgenden wird im Zusammenhang mit Fuzzing verwendete Terminologie beschrieben:
- • Fuzzing oder Fuzz-Testing ist der automatisierte Test-Prozess, zufällig generierte Eingaben an ein Zielprogramm (zu testendes Programm) zu senden und seine Reaktion zu beobachten.
- • Ein Fuzzer oder eine Fuzzing-Engine ist ein Programm, das automatisch Eingaben generiert. Sie ist also nicht mit der zu testenden Software verknüpft, und es wird auch keine Instrumentierung durchgeführt. Es hat jedoch die Fähigkeit, Code zu instrumentieren, Testfälle zu erzeugen und zu testende Programme auszuführen. Bekannte Beispiele sind afl und libfuzzer.
- • Ein Fuzz-Target ist ein Softwareprogramm oder eine Funktion, die durch Fuzzing getestet werden soll. Ein Hauptmerkmal eines Fuzz-Targets sollte sein, dass es potenziell nicht vertrauenswürdige Eingaben annimmt, die vom Fuzzer während des während des Fuzzing-Prozesses erzeugt wird.
- • Ein Fuzz-Test ist die kombinierte Version eines Fuzzers und eines Fuzz-Targets. Ein Fuzz-Target kann dann instrumentierter Code sein, bei dem ein Fuzzer mit seinen Eingaben verknüpft ist (d.h. diese liefert). Ein Fuzz-Test ist ausführbar. Ein Fuzzer kann auch mehrere Fuzz-Tests starten, beobachten und stoppen (normalerweise Hunderte oder Tausende pro Sekunde), jeder mit einer etwas anderen Eingabe, die vom Fuzzer erzeugt wird.
- • Ein Testfall ist eine bestimmte Eingabe und ein bestimmter Testdurchlauf aus einem Fuzz-Test. Normalerweise werden für die Reproduzierbarkeit interessante Läufe (Finden von neuen Codepfaden oder Abstürzen) gespeichert. Auf diese Weise kann ein bestimmter Testfall mit der entsprechenden Eingabe auch auf einem Fuzz-Target ausgeführt werden, das nicht mit einem Fuzzer verbunden ist, z.B. die Release-Version eines Programms.
- • Abdeckungsgesteuertes Fuzzing (engl. coverage-guided fuzzing) verwendet Code-Abdeckungsinformationen als Feedback während des Fuzzings, um zu erkennen, ob eine Eingabe die Ausführung neuer Code-Pfade oder Blöcke verursacht hat.
- • Generator-basiertes Fuzzing (engl. generation-based fuzzing) verwendet vorheriges Wissen über das Zielprogramm (Fuzz-Target), um Testeingaben zu erstellen. Ein Beispiel für ein solches Vorwissen ist eine Grammatik, die der Eingabespezifikation des Fuzz-Targets entspricht, d.h. die Eingabe-Grammatik des Fuzz-Targets (d.h. des zu testenden Programms).
- • Statische Instrumentierung ist das Einfügen von Anweisungen in ein (zu testendes) Programm, um Feedback über die Ausführung zu erhalten. Sie wird meist durch den Compiler realisiert und kann zum Beispiel die erreichten Codeblöcke während der Ausführung angeben.
- • Dynamische Instrumentierung ist die Steuerung der Ausführung eines (zu testenden) Programms während der Laufzeit, um Feedback aus der Ausführung zu generieren. Sie wird meist durch Betriebssystem-Systemfunktionalitäten oder durch die Verwendung von Emulatoren realisiert.
- • Ein Debugger ist eine Vorrichtung oder ein Programm, das ein Zielgerät oder Zielprogramm steuern kann und Funktionen bereitstellen kann, z.B. zum Abrufen von Register- oder Speicherwerten und zum Pausieren und Ausführen es Zielprogramms in Einzelschritten.
- • Ein Breakpoint wird über einen Debugger auf eine Anweisung des Zielprogramms oder Geräts gesetzt, um die Ausführung bei Erreichen zu stoppen und den steuernden Prozess darüber zu informieren.
- • Ein Daten-Watchpoint wird über einen Debugger auf eine Speicheradresse eines Zielprogramms oder Zielgeräts gesetzt, um die Ausführung anzuhalten, wenn auf die Speicheradresse zugegriffen wird, und den steuernden Prozess darüber zu informieren, indem ein Interrupt ausgelöst wird.
-
Wenn ein Debugger an ein eingebettetes Gerät angeschlossen ist, können Anweisungs-Breakpoints verwendet werden, um die Ausführung an einer gewünschten Codestelle anzuhalten, und Daten-Watchpoints können verwendet werden, um die Ausführung anzuhalten, wenn auf eine bestimmte Speicherstelle zugegriffen wird. Die Anzahl der Break- und Watchpoints ist jedoch typischerweise begrenzt und hängt von dem verwendeten System ab, beispielsweise ist die maximale Anzahl für einen typischen Mikrocontroller vier Breakpoints und zwei Daten-Watchpoints.
-
Abdeckungsgesteuertes Fuzzing für eingebettete Systeme kann in Emulatoren durchgeführt werden. Dabei wird die Transparenz des Emulators ausgenutzt, um die erforderlichen Erkenntnisse über die Ausführung zu gewinnen. Allerdings kann das Einrichten eines Emulators für ein bestimmtes Zielsystem einen enormen Aufwand erfordern. Dies liegt daran, dass Software für ein eingebettetes System in der Regel auf die Verfügbarkeit von externen Komponenten wie Sensoren und Aktoren angewiesen ist. Wenn diese Komponenten im Emulator fehlen, durchläuft die Software bei ihrer Ausführung höchstwahrscheinlich andere Pfade, als wenn die Komponenten vorhanden sind, und ihre Ausführung im Test kann daher nicht mit realen Ausführungen verglichen werden.
-
Aus diesen Gründen ist es schwierig, Feedback über die Software-Ausführung von einem eingebetteten Gerät zu erhalten, um ein zuverlässiges abdeckungsgesteuertes Fuzzing zu ermöglichen.
-
Generator-basiertes Fuzzing hat nicht die Anforderung eines unmittelbaren Feedbacks, sondern verwendet einen Generator, von dem bekannt ist, dass er die Eingabespezifikation des Ziels erfüllt. Zum Beispiel können kontextfreie Grammatiken zur Generierung von Eingabedaten verwendet werden. Für erfolgreiche Fuzz-Tests ist jedoch eine Grammatik erforderlich, die die Eingabespezifikation des Ziels erfüllt (d.h. dieser entspricht). Eine manuelle Erstellung einer solchen Grammatik kann mühsam und fehleranfällig sein.
-
Die Ableitung einer Grammatik aus einem Programm mit dem Verfahren aus Referenz 1 erfordert den Kontrollflussgraphen des Eingabeparsers des zu testenden Programms und Informationen darüber, welcher Programmteil auf welchen Teil des Eingabepuffers zuletzt zugegriffen hat. In Referenz 1 wird statische Instrumentierung verwendet, um die Anweisungen zu verfolgen, die auf den Eingabepuffer zugreifen. Ist das zu testende Programm ein Programm für ein eingebettetes System, so ist die statische Instrumentierung aus folgenden Gründen jedoch schwieriger zu realisieren:
- • Normalerweise läuft der Fuzzer auf einem anderen Computer als die zu testende Software, wie z.B. auf dem Computer 100, während das eingebettete System einem der Geräte 106 entspricht (bzw. darin eingebettet ist). Daher müssen die Daten nach jedem Testzyklus zwischen diesem Computer und dem eingebetteten System übertragen werden.
- • Die zu testende Software kann Bibliotheken von Drittanbietern und Software-Komponenten von anderen Herstellern oder Entwicklern enthalten. Wenn diese Komponenten als Binärdateien geliefert werden, können sie als Closed Source betrachtet werden, ohne dass eine einfache Möglichkeit besteht, ihren Quellcode zu ändern. Closed-Source-Komponenten können daher nicht durch den Compiler instrumentiert werden.
- • Die statische Instrumentierung erhöht die Codegröße, was auf eingeschränkten eingebetteten Systemen kritisch sein kann, d.h. es ist eventuell nicht genügend Speicher für die Instrumentierung vorhanden.
-
Es wird deshalb gemäß verschiedenen Ausführungsformen eine Herangehensweise bereitgestellt, bei dem eine Eingabegrammatik eines Programms (insbesondere für ein eingebettetes System) ohne Zugriff auf den Quellcode ermittelt werden kann, indem Daten-Watchpoints verwendet werden, um festzustellen, welche Teile des Eingabeparsers zuletzt auf einen bestimmten Teil der Eingabedaten zugegriffen haben. (Dies kann auch als dynamische Taint-Analyse angesehen werden.) Gemäß verschiedenen Ausführungsformen erfolgt dies mittels eines Debuggers.
-
2 zeigt ein Datenflussdiagramm 200 für ein Debugger-basiertes Verfahren zum Ermitteln (oder auch „Mining“) einer Eingabegrammatik eines (Binär-)Programms 201.
-
Die breiten Pfeile symbolisieren die Übertragung bzw. den Austausch von Nutzdaten (d.h. insbesondere zu verarbeitende Testdaten und Ergebnisse der Verarbeitung) und die dünnen Pfeile symbolisieren den Kontrollfluss des Verfahrens. Interaktionen zwischen dem System 202, das den Test durchführt (und das z.B. dem Computer 101 entspricht) und dem Zielsystem (Zielhardware) 203 (z.B. einem eingebetteten System, beispielsweise einem Zielgerät 106) erfolgen über eine Debug-Verbindung, die beispielsweise von einer dedizierten Debugger-Hardware-Vorrichtung 204 bereitgestellt wird. Die TestEingabedaten werden in Form eines Eingabevektors, z.B. über WiFi oder einen CAN-Bus (je nach Typ des Zielgeräts 106) an das Zielsystem 203 übertragen.
-
Das Programm 201 wird sowohl im System 202 als auch im Zielsystem 201 gespeichert (damit das Programm 201 das Programm im Zielsystem 201 ausführen kann). Das System steuert die Ausführung des Programms im Zielsystem 201 über die Debug-Verbindung, d.h. startet die Ausführung und nimmt die Ausführung nach einem Interrupt (insbesondere einen Interrupt, der durch einen Daten-Watchpoint ausgelöst wurde) wieder auf.
-
Ist die Debug-Verbindung zu der Zielhardware hergestellt, beschafft sich das (testende) System 202 in 205 zunächst den Kontrollflussgraphen des Eingabeparsers des Binärprogramms 201 und den Eintrittspunkt in den Eingabeparser. Dies kann halbautomatisch erfolgen, z.B. mittels einer Reverse-Engineering-Software wie Ghidra.
-
In 206 ermittelt das System 202 den Ort von Eingabedaten (d.h. die Position des Eingabepuffers) im Speicher des Zielsystems 203. Dazu startet das System 202 das Programm 201 auf dem Zielsystem 203, sendet Eingabedaten an das Zielsystem 203, pausiert das Programm 201 am Eintrittspunkt des Eingabeparsers des Programms 201 and durchsucht den Speicher 211 des Zielsystems nach den gesendeten Eingabedaten.
-
Nun führt das System 202 einen iterativen Prozess durch, wobei das System 202 sicherstellt, dass sie Ausführung deterministisch ist, d.h. der sich der Eingabepuffer in jeder Iteration (d.h. jedem Testzyklus) an derselben Position im Speicher 211 des Zielsystems 203 befindet.
-
In jeder Iteration setzt das System 202 in 207 Daten-Watchpoints, um Zugriff auf den Eingabepuffer durch das Programm 201 zu beobachten. Wenn der Eingabepuffer nicht durch die Anzahl der verfügbaren Watchpoints abgedeckt werden kann, führt das System 202 mehrere Iterationen durch, in denen sie die Position der Watchpoints verschiebt, aber die Testeingabedaten gleich lässt.
-
In 208 sendet das System 202 Testeingabedaten (das heißt einen Satz oder Vektor von Testeingabedaten von der Größe, wie es das Zielsystem 203 erwartet) an das Zielsystem 203. Dies kann in der allerersten Iteration entfallen, weil dort die in 206 zum Finden der Position des Eingabepuffers gesendeten Eingabedaten verwendet werden können und entfällt in Iterationen, in denen, wie oben erwähnt, nur die Watchpoints verschoben werden, aber die Testeingabedaten gleich bleiben (außer das Programm oder das Zielsystem 203 erfordert, dass die Testeingabedaten erneut gesendet werden).
-
Das System 202 führt Iterationen für mehrere unterschiedliche Sätze von Testeingabedaten durch, z.B. mit Sätze von Testeingabedaten, die es unter Verwendung unterschiedlicher Seeds zufällig erzeugt.
-
In jeder Iteration führt das System 202 das Programm auf dem Zielsystem 203 aus und zeichnet in 209 bei jedem Interrupt, der durch einen Daten-Watchpoint ausgelöst wird, die Befehlsadresse des Befehls des Programms 201 auf, bei dem der Interrupt ausgelöst wurde. Damit weiß das System 202 insbesondere für jeden Teil der Testeingabedaten, welche Funktion des Eingabeparsers des Programms 201 zuletzt auf den Teil der Testeingabedaten zugegriffen hat.
-
Die Iteration endet, wenn das Programm 201 den Satz von Testeingabedaten abgearbeitet hat.
-
Wurden alle Iterationen durchgeführt (d.h. alle Sätze von Testeingabedaten vollständig mit Daten-Watchpoints abgedeckt), extrahiert das System 202 in 210 den Parser-Baum des Eingabeparsers des Programms 201 unter Verwendung der Ergebnisse der Iterationen und ermittelt daraus die Eingabegrammatik des Programms 201.
-
Dazu kann das System 202 zunächst für jeden Satz von Testeingabedaten einen Parser-Baum ermitteln (aus den Ergebnissen der Iterationen, die für diesem Satz von Testeingabedaten durchgeführt wurden) und diese Parser-Bäume (für die mehreren Sätze von Testeingabedaten) dann zusammenfügen und die Eingabegrammatik verallgemeinern und vereinfachen.
-
Das Ermitteln der Parser-Bäume und die Ermittlung der Eingabegrammatik können beispielsweise analog zu Referenz 1 erfolgen. Insbesondere kann dabei das System 202 aus dem Wissen, welche Funktion des Eingabeparsers des Programms 201 zuletzt auf einen bestimmten Teil der Testeingabedaten zugegriffen hat, ableiten, als was der Eingabeparser diesen Teil der Testeingabedaten erkannt hat. Dies liegt daran, dass typischerweise der Eingabeparser den Teil der Testeingabedaten nicht weiter betrachtet, wenn er darauf eine Funktion ausgeführt hat, die diesen Teil als von einem bestimmten Typ erkannt hat. Aus der Information, welcher Teil des Eingabeparsers (z.B. welche Funktion, z.B. eingeteilt in Hierarchieebenen der Funktionen gegebenen durch den ermittelten Kontrollflussgraphen) zuletzt auf einen Teil der Eingabedaten zugegriffen hat, kann deshalb gefolgert werden, als was der Eingabeparser den Teil der Eingabedaten erkannt hat und so den gesamten Satz von Testeingabedaten in der Form eines jeweiligen Parser-Baums darstellen.
-
Um die Eingabegrammatik vollständig zu erfassen, verwendet das System 202 einen Menge von Sätzen von Testeingabedaten, die (möglichst) alle Verzweigungen des Eingabeparsers abdeckt, da Verzweigungen des Eingabeparsers, die in keinem Satz der Testeingabedaten erreicht werden, sich nicht in der ermittelten Eingabegrammatik widerspiegeln.
-
Die ermittelte Eingabegrammatik für das Programm 201 kann das System 202 zum Beispiel für folgende Testaufgaben verwenden:
- • Identifizierung von Unterschieden zwischen dem Programm (wie implementiert) und seiner Spezifikation
- • Durchführung von Generator-basierten Fuzz-Tests.
- • Finden von Abweichungen zwischen verschiedenen Implementierungen oder Versionen (z.B. Aktualisierungen) des Programms
-
Zusammengefasst wird gemäß verschiedenen Ausführungsformen ein Verfahren bereitgestellt, wie in 3 dargestellt.
-
3 zeigt ein Ablaufdiagramm, das ein Verfahren zum Testen eines Computerprogramms gemäß einer Ausführungsform darstellt.
-
In 301 werden Eingabedaten für das Computerprogramm an einen Speicher gesendet, auf den das Computerprogramm zugreift (d.h. z.B. einen Arbeitsspeicher des Systems, auf dem das Computerprogramm ausgeführt wird).
-
In 302 werden Daten-Watchpoints an Positionen in einem Speicherbereich im Speicher, in dem die Eingabedaten gespeichert sind, gesetzt.
-
In 303 wird das Computerprogramm ausgeführt und dabei überwacht, welche Teile eines Eingabeparsers des Computerprogramms auf die Positionen des Speicherbereichs zugreifen.
-
In 304 wird eine Eingabegrammatik des Computerprogramms aus Ergebnissen des Überwachens ermittelt.
-
In 305 wird das Computerprogramm unter Verwendung der ermittelten Eingabegrammatik getestet.
-
Das Verfahren von 3 kann durch einen oder mehrere Computer mit einer oder mehreren Datenverarbeitungseinheiten durchgeführt werden. Der Begriff „Datenverarbeitungseinheit“ kann als irgendein Typ von Entität verstanden werden, die die Verarbeitung von Daten oder Signalen ermöglicht. Die Daten oder Signale können beispielsweise gemäß mindestens einer (d.h. einer oder mehr als einer) speziellen Funktion behandelt werden, die durch die Datenverarbeitungseinheit durchgeführt wird. Eine Datenverarbeitungseinheit kann eine analoge Schaltung, eine digitale Schaltung, eine Logikschaltung, einen Mikroprozessor, einen Mikrocontroller, eine Zentraleinheit (CPU), eine Graphikverarbeitungseinheit (GPU), einen Digitalsignalprozessor (DSP), eine integrierte Schaltung einer programmierbaren Gatteranordnung (FPGA) oder irgendeine Kombination davon umfassen oder aus dieser ausgebildet sein. Irgendeine andere Weise zum Implementieren der jeweiligen Funktionen, die hierin genauer beschrieben werden, kann auch als Datenverarbeitungseinheit oder Logikschaltungsanordnung verstanden werden. Es können ein oder mehrere der im Einzelnen hier beschriebenen Verfahrensschritte durch eine Datenverarbeitungseinheit durch eine oder mehrere spezielle Funktionen ausgeführt (z. B. implementiert) werden, die durch die Datenverarbeitungseinheit durchgeführt werden.
-
Die Herangehensweise von 3 dient zum Testen eines Programms, beispielsweise einer Steuersoftware für eine Robotervorrichtung. Der Begriff „Robotervorrichtung“ kann als sich auf irgendein technisches System beziehend verstanden werden, wie z. B. eine computergesteuerte Maschine, ein Fahrzeug, ein Haushaltsgerät, ein Elektrowerkzeug, eine Fertigungsmaschine, einen persönlichen Assistenten oder ein Zugangssteuersystem. Die Steuersoftware kann auch für datenverarbeitende Systeme wie z.B. ein Navigationsgerät verwendet werden.
-
Obwohl spezielle Ausführungsformen hier dargestellt und beschrieben wurden, wird vom Fachmann auf dem Gebiet erkannt, dass die speziellen Ausführungsformen, die gezeigt und beschrieben sind, gegen eine Vielfalt von alternativen und/oder äquivalenten Implementierungen ausgetauscht werden können, ohne vom Schutzbereich der vorliegenden Erfindung abzuweichen. Diese Anmeldung soll irgendwelche Anpassungen oder Variationen der speziellen Ausführungsformen abdecken, die hier erörtert sind.
-
Daher ist beabsichtigt, dass diese Erfindung nur durch die Ansprüche und die Äquivalente davon begrenzt ist.
