-
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 „konkolische Ausführung“ (engl. concolic execution), auch als konkolisches Testen bezeichnet. Dieses sieht eine symbolische Ausführung entlang eines konkreten Ausführungspfads (d.h. für konkrete Eingaben) vor. Um bei der Ausführung neue Zweige in dem Programm zu erreichen, werden bei konkreten Ausführungen (d.h. mit konkreten Eingaben) symbolisch Bedingungen gesammelt und dahingehend gelöst, dass Eingaben ermittelt werden, um die neuen Zweige zu erreichen. Dies ist jedoch insbesondere dann schwierig, wenn das Zielsystem, auf dem das Programm (mit konkreten Eingaben) ausgeführt wird hinsichtlich des Zugriffs durch die Test- bzw. Softwareentwicklungsumgebung, durch die das Programm getestet wird, und seiner Transparenz eingeschränkt ist. Darüber hinaus kann das getestete Programm bei seiner Ausführung konkrete Werte von externen Komponenten (z.B. Sensoren) erhalten.
-
Es sind deshalb Herangehensweisen wünschenswert, die ein konkolisches Testen von Software für in solcher Hinsicht beschränkter Systeme, insbesondere eingebettete Systeme, ermöglichen.
-
Offenbarung der Erfindung
-
Gemäß verschiedenen Ausführungsformen wird ein Verfahren zum Testen eines Computerprogramms bereitgestellt, aufweisend Auswählen einer Verzweigung in dem Computerprogramm mit mehreren Programmzweigen, in die die Verzweigung führen kann, wobei der Programmzweig der mehreren Programmzweige, in den die Verzweigung führt, davon abhängt, ob eine der Verzweigung zugeordnete Verzweigungsbedingung erfüllt ist, Auswählen eines Programmzweiges der mehreren Programmzweige, in den die Verzweigung führen soll, schrittweises Ausführen des Computerprogramms mittels eines Debuggers für eine Eingabe, wobei für jede ausgeführte Instruktion geprüft wird, ob sie auf Werte der Eingabe zugreift und, wenn die Instruktion auf Werte der Eingabe zugreift, die Instruktion erfasst wird, wobei, wenn bei der Ausführung des Computerprogramms die Verzweigung erreicht wird, ein oder mehrere Eingabewerte, von der die Verzweigungsbedingung abhängt, ermittelt werden, sodass die Verzweigung in den ausgewählten Programmzweig führt, wobei berücksichtigt wird, wie die erfassten Instruktionen die Eingabewerte verarbeiten; und Ausführen des Computerprogramms für eine geänderte Eingabe, die die ein oder mehreren Eingabewerte aufweist, wobei das Computerprogramm auf Fehler bei der Ausführung überprüft wird.
-
Das oben beschriebene Verfahren ermöglicht das konkolische Testen auf (Ziel-)Systemen mit beschränktem Zugriff und Transparenz wie eingebetteten Systemen durch Verwendung des Debuggers auf dem jeweiligen Zielsystem.
-
Im Folgenden werden verschiedene Ausführungsbeispiele angegeben.
-
Ausführungsbeispiel 1 ist ein Verfahren zum Testen eines Computerproramms, wie oben beschrieben.
-
Ausführungsbeispiel 2 ist das Verfahren nach Ausführungsbeispiel 1, aufweisend Senden der Eingabe an ein System, das das Computerprogramm ausführt und Ermitteln, mittels des Debuggers, wo das System die Eingabe speichert.
-
Mittels des Debuggers kann so auch für ein (Ziel-)System, dass für das System, das das Testen durchführt (z.B. die Verzweigung und den Programmzweig auswählt und die Eingabedaten zuführt) wenig transparent ist, festgestellt werden, welche Instruktionen auf Eingabewerte zugreifen (auch bei indirekten Zugriffen). Dies kann dadurch erfolgen, dass mittels des Debuggers die Ausführung des Programms pausiert wird, wenn das Programm beginnt, die Eingabe zu verarbeiten.
-
Ausführungsbeispiel 3 ist das Verfahren nach Ausführungsbeispiel 1 oder 2, wobei mittels der erfassten Instruktionen symbolisch Bedingungen an die ein oder mehreren Eingabewerte erstellt werden, die die Eingabewerte erfüllen müssen, um den ausgewählten Programmzweig zu erreichen.
-
In Hinblick auf Eingabewerte oder Variablen, von der die Verzweigungsbedingung abhängt, erfolgt also eine symbolische Ausführung. Dies ermöglicht eine effiziente Ermittlung von Eingabewerten, um den ausgewählten Programmzweig zu erreichen.
-
Ausführungsbeispiel 4 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 3, wobei ermittelt wird, von welchen Werten der Eingabe die Verzweigungsbedingung abhängt und die Werte der Eingabe, von der die Verzweigungsbedingung nicht abhängt, zumindest teilweise in der geänderten Eingabe beibehalten werden.
-
Es wird somit eine konkolisches Testen durchgeführt, bei der konkrete Eingabewerte verwendet und beibehalten werden, aber hinsichtlich eines gewünschten Verarbeitungspfads Bedingungen symbolisch ermittelt werden, um den Verarbeitungspfad zu erreichen. Dies ermöglicht ein effizientes Testen, da nicht der gesamte Satz von Eingabewerten oder Variablen symbolisch behandelt werden braucht.
-
Ausführungsbeispiel 5 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 4, wobei für jede Instruktion, die auf Werte der Eingabe zugreift, ermittelt wird, ob sie Werte der Eingabe verändert und/oder sie abhängig von Werten der Eingabe den Programmfluss ändert, und beim Ermitteln der ein oder mehreren Eingabewerte berücksichtigt wird, wie die erfassten Instruktionen die Werte der Eingabe und den Programmfluss ändern.
-
Es werden also bei der schrittweisen Ausführung sowohl Instruktionen berücksichtigt, die sich auf Werte (z.B. Variable) auswirken, von der die betrachtete (ausgewählte) Verzweigung abhängt, als auch solche, die ggf. schon vor der ausgewählten Verzweigung den Programmfluss ändern könnten. Beispielsweise werden die ein oder mehreren Eingabewerte so ermittelt, dass die ausgewählte Verzweigung selbst auch bei der erneuten Ausführung (mit der geänderten Eingabe) erreicht wird.
-
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.
-
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 einen Datenfluss für ein konkolisches Testen gemäß einer Ausführungsform.
- 3 zeigt einen Ablauf zum Testen eines Programms, das auf einem Zielsystem ausgeführt wird.
- 4 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 konkolisches Ausführen (engl. concolic execution). „Konkolisch“ ist ein Kofferwort aus „konkret“ und symbolisch (bzw. concolic aus „concrete“ und „symbolic“)
-
Konkolische Ausführung wird auch als konkolisches Testen oder dynamische symbolische Ausführung (engl. dynamic symbolic execution) bezeichnet. Konkolisches Testen ist eine hybride Software-Verifikationstechnik, bei der eine symbolische Ausführung, die Programmvariablen als symbolische Variablen behandelt, entlang eines konkreten Ausführungspfads (Testen auf bestimmte Eingaben) erfolgt.
-
Symbolische Ausführung ist ein Mittel zur Analyse eines Programms, um festzustellen, welche Eingaben zur Ausführung welcher Teile eines Programms führen. Dabei folgt ein Interpreter dem Programm und nimmt symbolische Werte für die Eingaben des Programms an, anstatt tatsächliche Eingaben anzunehmen, wie es die die normale Ausführung des Programms tun würde. So kommt er zu Ausdrücken dieser Symbole für Ausdrücke und Variablen im Programm sowie Einschränkungen (Bedingungen) dieser Symbole für die möglichen Zweige, die das Programm an Verzweigungen nimmt, indem für eine Ausführung, die zu einer Position im Programm führt, die Bedingungen an die Symbole gesammelt (aufgezeichnet) werden, die zu dieser Position führen. Schließlich können die möglichen Eingaben, die an einer Verzweigung zu einem bestimmten Zweig führen, aus den Bedingungen ermittelt werden.
-
Im Folgenden wird im Zusammenhang mit konkolischem Testen verwendete Terminologie beschrieben:
- • Konkrete Ausführung ist die Ausführung eines Programms mit konkreten Werten. Das Programm kann dazu z.B. auf realer Hardware oder in einem Emulator ausgeführt werden.
- • Ein Ausführungspfad ist ein möglicher Lauf (Kontrollfluss) durch ein Programm.
- • Ein symbolischer Wert ist ein mathematisches Symbol, das einen beliebigen Wert, der einer Variablen zugewiesen werden kann, repräsentiert.
- • Das Zielprogramm ist die zu testende Software.
- • Das Zielsystem ist das System, auf dem das Zielprogramm laufen soll.
- • 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 oder Debuggern 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.
-
Für eine konkolische Ausführung ist eine vollständige Verfolgung der Verarbeitung einer Eingabe erforderlich. Die Symbolische-Ausführungs-Komponente der Testumgebung, d.h. die Komponente, die die Bedingungen für die Verzweigungen des Programms in symbolischer Form ermittelt, erfordert Informationen aus der konkreten Ausführung. Diese Informationen bestehen mindestens aus dem Ausführungspfad einer Eingabe für das Programm, die konkrete Werte enthält. Solche konkreten Werte beinhalten insbesondere solche Werte, die das Zielsystem für die Ausführung des Programms von externen Komponenten wie Sensoren und Aktoren liest.
-
Um die Information aus der konkreten Ausführung zu bekommen und symbolisch Bedingungen von Verzweigungen des Programms zu ermitteln, können Emulatoren verwendet werden. Allerdings kann die Einrichtung eines Emulators für ein eingebettetes System einen enormen Arbeitsaufwand bedeuten. 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. Wenn außerdem eine externe Komponente im Emulator fehlt, erhält die Testumgebung 104 keine konkrete Werte von dieser externen Komponente für den symbolischen Ausführungsteil.
-
Außerdem ist es typischerweise schwierig, für eine konkolische Ausführung Feedback aus einer konkreten Software-Ausführung von einem eingebetteten Gerät zu erhalten. Beispielsweise ist die statische Instrumentierung aus folgenden Gründen für Software, die auf einem eingebetteten System ausgeführt wird, schwierig zu realisieren:
- • In diesem Fall läuft die Testumgebung 104 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 (insbesondere das Feedback) 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.
-
Auch eine dynamische binäre Übersetzung (dynamic binary translation) für eine Instrumentierung ist im Falle von Software für ein eingebettetes System schwierig, da die Testumgebung auf einem anderen Computer läuft als die Software und die Instrumentierung die Größe des Programms erhöht. Außerdem läuft das Programm, das die dynamische binäre Übersetzung durchführt, auf demselben System wie das Zielprogramm. Dies erhöht auch die Programmcodegröße. Darüber hinaus sind Werkzeuge für dynamische binäre Übersetzung nur für Betriebssysteme verfügbar, die von eingebetteten System typischerweise nicht verwendet werden. Auch das Hinzufügen einer statische Instrumentierung mittels statischem binären Umschreiben (engl. static binary rewriting) ist oftmals nicht möglich. Tracing-basierte Herangehensweisen können oftmals ebenfalls nicht eingesetzt werden, da viele eingebettete Systeme kein Hardware-Tracing unterstützen und Hardware-Tracing-Mechanismen nicht dazu verwendet werden können, um konkrete Werte von externen Komponenten zu erhalten. Diese müssten wiederum durch andere Herangehensweisen beschafft werden.
-
Gemäß verschiedenen Ausführungsformen beschafft sich die Testumgebung 104 die Werte, die die Symbolische-Ausführungs-Komponente von der konkreten Ausführung benötigt, über eine Debugger-Schnittstelle. Damit sind kein Emulator, keine dynamische binäre Übersetzung, keine statische Instrumentierung oder Hardware-Tracing-Mechanismen für das konkolische Testen erforderlich.
-
Die Symbolische-Ausführungs-Komponente kann außerhalb des Zielgeräts ausgeführt werden, z.B. als Teil der Testumgebung 104 auf dem Computer 100 außerhalb eines Zielgeräts 106. Die Information, die die Symbolische-Ausführungs-Komponente benötigt, kann von einem Debugger erhalten werden und von dem Zielgerät an die Symbolische-Ausführungs-Komponente über eine Debugger-Schnittstelle ausgegeben werden. Eine Debugger-Schnittstelle ist bei eingebetteten Systemen üblicherweise vorhanden (im Gegensatz zu beispielsweise Hardware-Tracing). Außerdem sind keine Änderungen des Zielprogramms erforderlich.
-
2 zeigt einen Datenfluss für ein konkolisches Testen gemäß einer Ausführungsform.
-
Eine Symbolische-Ausführungs-Komponente (z.B. Symbolische-Ausführungs-Engine) 201 wird auf einem Host-System 202 (entspricht z.B. dem Computer 101) ausgeführt. Sie ist beispielsweise Teil der Testumgebung 104. Das Host-System 202 sendet über eine Debugger-Schnittstelle 203 Debugging-Befehle 204 an ein Zielsystem 206, das ein Zielprogramm 207 ausführt und z.B. einem der Zielgeräte 106 entspricht, und erhält Debugging-Antworten 205 von diesem über die Debugger-Schnittstelle 203.
-
Ein Debugging-Befehl 204 ist beispielsweise einen Programmschritt (d.h. einen Befehl des Programms 207) auszuführen oder eine Instruktion des Programms, eine Stelle im Speicher 208 des Zielsystems 206 oder ein Register 209 des Zielsystems 206 zu lesen. Die Debugging-Antworten 205 sind entsprechende Antworten, wie z.B. ein Speicherinhalt, eine Angabe einer Instruktion, etc.
-
Das Host-System 202 liefert außerdem Eingabedaten 210 an das Zielsystem 206, beispielsweise über eine serielle Schnittstelle, Wi-Fi, Bluetooth oder einen anderen Kommunikationskanal. Dies hängt davon ab, in welcher Form das Zielprogramm 207 Eingaben erwartet.
-
3 zeigt einen Ablauf zum Testen des Programms 207, das auf dem Zielsystem 206 ausgeführt wird.
-
In 301 werden Operationen für ein Setup bzw. eine Initialisierung durchgeführt. Dies beinhaltet Folgendes:
- • Das Host-System 202 spezifiziert (z.B. gemäß einer Benutzereingabe) eine Zielverzweigung im Zielsystem 206, deren Ausgang umgeschaltet werden soll, indem die Werte, von der sie abhängt, modifiziert werden. Typischerweise ist das Ziel dabei, einen Zweig im Programm 207 zu erreichen, der beim bisherigen Testen (z.B. bisher beim Fuzzing) noch nicht erreicht wurde. Eine Verzweigung ist eine Programminstruktion, die eine Verzweigungsbedingung beinhaltet, wobei je nachdem, ob die Verzweigungsbedingung erfüllt ist oder nicht, das Programm 207 anders verläuft (d.h. in einen anderen Programmzweig verzweigt, d.h. zu einem anderen Prorammzweig führt, und damit einen anderen Ausführungspfad folgt). Ein Benutzer spezifiziert beispielsweise die Adresse dieser Instruktion.
- • Ein Debugger wird mit dem Zielsystem 206 verknüpft (d.h. die Debugger-Schnittstelle 203 bereitgestellt). Das Zielsystem 206 kann beispielsweise einen On-Board-Debugger aufweisen. In diesem Fall kann das Host-System 201 mit diesem On-Board-Debugger verbunden werden.
- • Das Host-System 202 sendet eine Eingabe 210 an das Zielprogramm.
- • Das Zielprogramm wird mittels des Debuggers ausgeführt, wobei die Ausführung angehalten wird, wenn das Zielprogramm damit beginnt, die Eingabe 210 zu verarbeiten. Dazu kann das Host-System 202 einen Hardware-Breakpoint auf die Instruktion, die dem Lesen der Eingabe 210 folgt, setzen (z.B. gemäß einer Benutzereingabe).
- • Das Host-System 202 beschafft (mittels der Debugger-Schnittstelle 203) die Adresse (oder den Adressbereich) im Speicher 208, an der die Eingabe 210 auf dem Zielsystem 206 gespeichert ist und gibt diese Adresse(n) an die Symbolische-Ausführungs-Komponente 201. Eine Symbolische-Ausführungs-Engine wie Angr erfordert die Information, wo Eingaben in dem Zielsystem gespeichert sind, um später Bedingungen für die Eingaben zu beschaffen.
-
In 302 befiehlt das Host-System 202 dem Zielsystem 206 einen Programmschritt (eine Instruktion) des Zielprogramms 207 auszuführen und hält die Ausführung danach an. Dies kann mittels einer Debug-Funktion zur Ausführung in Einzelschritten oder Hardware-Breakpoints realisiert werden.
-
Das Host-System liest in 303 mittels der Debugger-Schnittstelle 203 aus, welche Instruktion das Zielsystem 206 gerade ausgeführt hat und ermittelt die Adresse dieser Instruktion (im Programmspeicherbereich des Zielsystems 206).
-
In 304 ermittelt das Host-System 202, ob die Instruktion eine Instruktion ist, die ein oder mehrere Werte aus den Registern 209 oder dem Speicher 208 des Zielsystems 206 liest. Ist dies der Fall, beschafft es den oder die gelesenen Wert(e) (mittels der Debugger-Schnittstelle 203) und fährt dann mit 306 fort. Hat die Instruktion keine Werte gelesen, fährt es direkt mit 306 fort.
-
In 306 gibt das Host-System 202 die gelesene Instruktion und seine Adresse sowie ggf. den gelesenen Wert oder die (konkreten) gelesenen Werte an die Symbolische-Ausführungs-Komponente 201. Wie oben erwähnt benötigt eine Symbolische-Ausführungs-Engine wie Angr die Information, wo Eingaben in dem Zielsystem gespeichert sind, um später Bedingungen für die Eingaben zu beschaffen
-
In 307 ermittelt das Host-System 202, ob die in 301 spezifizierte Zielverzweigung erreicht wurde. Ist dies der Fall fährt es mit 308 fort. Ansonsten kehrt es zu 302 zurück, d.h. steuert das Zielsystem 206 an, die nächste Instruktion des Programms 207 durchzuführen. In anderen Worten führt das Host-System 201 mittels der Debugger-Schnittstelle 203 das Programm 207 auf dem Zielsystem 206 schrittweise (Instruktion für Instruktion) auf dem Zielsystem 206 aus, bis die spezifizierte Verzweigung erreicht ist. Dabei bedeutet, dass die spezifizierte Verzweigung „erreicht“ wurde, dass die Verzweigungsinstruktion ausgeführt wurde, d.h. insbesondere die Verzweigungsbedingung geprüft wurde. In 301 wurde die Adresse der Verzweigung spezifiziert und in 303 wurde die Adresse der zuletzt ausgeführten Instruktion ermittelt. Die spezifizierte Verzweigung wurde erreicht, wenn die Adresse der zuletzt ausgeführten Instruktion gleich der in 301 spezifizierten Adresse ist.
-
Ist die spezifizierte Verzweigung erreicht, erzeugt in 308 die Symbolische-Ausführungs-Komponente Bedingungen auf der Grundlage der erhaltenen Informationen (Speicheradressen, Befehle und konkrete Werte), negiert ein oder mehrere Bedingungen und ermittelt, z.B. unter Verwendung eines SMT(Satisfiability Modulo Theories)-Lösers eine neue Eingabe 210, die die Bedingungen erfüllt. Wie gesagt sind dabei ein oder mehrere Bedingungen negiert, insbesondere beispielsweise die der betrachteten (d.h. in 301 ausgewählten) Verzweigung, sodass bei einer Ausführung, bei der dem Zielsystem 206 bzw. dem Programm 207 die neue Eingabe zugeführt wird, die Verzweigung in einen anderen Programmzweig führt, also z.B. ein bisher noch nicht erreichter Zweig (und damit Ausführungspfad) erreicht wird, der auf diese Weise getestet werden kann.
-
Zusammengefasst wird gemäß verschiedenen Ausführungsformen ein Verfahren bereitgestellt, wie in 4 dargestellt.
-
4 zeigt ein Ablaufdiagramm 400, das ein Verfahren zum Testen eines Computerprogramms gemäß einer Ausführungsform darstellt.
-
In 401 wird eine Verzweigung in dem Computerprogramm mit mehreren Programmzweigen, in die die Verzweigung führen kann, ausgewählt. Der Programmzweig (der mehreren Programmzweige), in den die Verzweigung führt, hängt davon ab, ob eine der Verzweigung zugeordnete Verzweigungsbedingung erfüllt ist.
-
In 402 wird ein Programmzweig der mehreren Programmzweige, in den die Verzweigung führen soll, ausgewählt.
-
In 403 wird das Computerprogramms schrittweise mittels eines Debuggers für eine Eingabe ausgeführt, wobei für jede ausgeführte Instruktion geprüft wird, ob sie auf Werte der Eingabe zugreift und, wenn die Instruktion auf Werte der Eingabe zugreift, die Instruktion erfasst wird. Wenn bei der Ausführung des Computerprogramms die Verzweigung erreicht wird (in 404), werden ein oder mehrere Eingabewerte, von der die Verzweigungsbedingung abhängt, ermittelt, sodass die Verzweigung in den ausgewählten Programmzweig führt, wobei berücksichtigt wird, wie die erfassten Instruktionen die Eingabewerte verarbeiten.
-
In 405 wird das Computerprogramm für eine geänderte Eingabe, die die ein oder mehreren Eingabewerte aufweist, ausgeführt und auf Fehler bei der Ausführung überprüft.
-
Es sollte beachtet werden, dass die Auswahl des Programmzweiges, in den die Verzweigung führen soll, nicht notwendigerweise vor Beginn der Ausführung des Programms erfolgen muss. Beispielsweise kann ein Programmzweig ausgewählt werden, der bei der Ausführung nicht erreicht wurde, sodass im Laufe mehrerer Ausführungen verschiedene mögliche Ausführungspfade des Computerprogramms getestet werden.
-
Das Verfahren von 4 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 4 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.
