-
Stand der Technik
-
Die vorliegende Offenbarung bezieht sich auf Verfahren zur Software-Fehlerbereinigung.
-
Ein wesentlicher Bestandteil der Entwicklung von Softwareanwendungen ist das Testen und, wenn Fehler gefunden werden, eine entsprechende Fehlerbereinigung. Insbesondere sollten Fehler, die zum Versagen einer Anwendung führen, identifiziert und korrigiert werden. Ein Beispiel für das Testen von Software ist die das dynamische Software-Testverfahren Fuzzing. Bei größeren Programmen ist Fuzzing jedoch aufwändig und es kann vorkommen, dass Fehler nicht erkannt werden, weil sie sich gegenseitig aufheben, also ausmaskiert werden.
-
Es sind deshalb Herangehensweisen wünschenswert, die eine zuverlässige und effiziente Fehlerbereinigung von Programmen, die aus mehreren Software-Komponenten bestehen, ermöglichen.
-
Offenbarung der Erfindung
-
Gemäß verschiedenen Ausführungsformen wird Verfahren zur Software-Fehlerbereinigung bereitgestellt, aufweisend Extrahieren mindestens einer Software-Komponente aus einem zu testenden Computerprogramm, wobei die Software-Komponente eine Schnittstelle hat, über die sie bei einer Ausführung des Computerprogramms Eingabedaten empfängt, Testen der extrahierten Software-Komponente auf der Schnittstelle der Software-Komponente zum Finden von Fehlern und, für jeden Fehler, Ermitteln von Eingabedaten, die, wenn sie über die Schnittstelle der Software-Komponente zugeführt werden, zu dem Fehler führen, Überprüfen, für jeden gefundenen Fehler der Software-Komponente, ob der Software-Komponente bei einer Ausführung des Computerprogramms die ermittelten Eingabedaten zugeführt werden und Anpassen des Computerprogramms in Hinblick auf den Fehler abhängig davon, ob der Software-Komponente bei einer Ausführung des Computerprogramms die ermittelten Eingabedaten zugeführt werden.
-
Das oben beschriebene Verfahren ermöglicht es, komplexe Programme, insbesondere Steuerprogramme für Robotervorrichtungen wie autonome Fahrzeuge, zuverlässig von Fehlern zu bereinigen. Bei solchen Programmen ist der Einsatz von Testverfahren wie Fuzzing in Hinblick auf Geschwindigkeit und Abdeckung schwierig und Fehler, die beispielsweise in unterschiedlichen Softwarekomponenten auftreten, können sich aufheben und Fehler somit ausmaskiert werden. Gemäß verschiedenen Ausführungsformen können Fehler trotz eines solchen Ausmaskierens gefunden werden, da die Softwarekomponenten einzeln auf Fehler getestet werden. Dies ermöglicht insbesondere ein effizienteres Testen mittels Fuzzing (einfacher, schneller und mit größerer Abdeckung im Vergleich zur Anwendung auf die Gesamtsoftware), weil das Fuzzing auf den Schnittstellen der einzelnen Software-Komponenten durchgeführt wird.
-
Außerdem wird ein effizientes Testen und eine effiziente Fehlerbereinigung (und damit insgesamt eine effiziente Softwareentwicklung z.B. für eine Steuerung im Falle einer Steuersoftware) erreicht, da Fehler von Softwarekomponenten, die bei Eingaben auftreten, die in der Gesamtsoftware jedoch nicht den Softwarekomponenten zugeführt werden, entsprechend behandelt und beispielsweise toleriert werden können. Solche Fehler können als nicht relevant betrachtet werden, da sie in der Gesamtsoftware nicht zu Fehlern führen (und insbesondere nicht ausgenutzt werden können).
-
Im Folgenden werden verschiedene Ausführungsbeispiele angegeben.
-
Ausführungsbeispiel 1 ist ein Verfahren zur Fehlerbereinigung, wie oben beschrieben.
-
Ausführungsbeispiel 2 ist das Verfahren nach Ausführungsbeispiel 1, aufweisend, für jeden gefundenen Fehler, falls der Software-Komponente bei einer Ausführung des Computerprogramms die ermittelten Eingabedaten nicht zugeführt werden, Ermitteln von ein oder mehreren Programmteilen des Computerprogramms, aufgrund derer der Software-Komponente bei einer Ausführung des Computerprogramms die ermittelten Eingabedaten nicht zugeführt werden, wobei das Computerprogramm unter Berücksichtigung der ermittelten Programmteile angepasst wird.
-
Beispielsweise kann gewährleistet werden, dass diese Programmteile in dem Computerprogramm erhalten bleiben, zumindest solange der jeweilige Fehler nicht auf andere Weise verhindert wird. Die Programmteile können auch ergänzt und robuster gemacht werden, z.B. derart, dass sie auch andere Fehler verhindern, beispielsweise andere Eingaben an die Softwarekomponente (oder auch andere Software-Komponenten), die zu Fehlern führen.
-
Ausführungsbeispiel 3 ist das Verfahren nach Ausführungsbeispiel 1 oder 2, aufweisend, für jeden gefundenen Fehler, falls der Software-Komponente bei einer Ausführung des Computerprogramms die ermittelten Eingabedaten nicht zugeführt werden, Ermitteln von ein oder mehreren Programmteilen des Computerprogramms, aufgrund derer der Software-Komponente bei einer Ausführung des Computerprogramms die ermittelten Eingabedaten nicht zugeführt werden, und Testen der ermittelten ein oder mehreren Programmteile.
-
Auf diese Weise wird sichergestellt, dass Programmteile, die gewährleisten, dass Fehler in Softwarekomponenten nicht auftreten (bzw. keine Wirkung haben) weil die Programmteile entsprechende Eingaben an die Softwarekomponenten verhindern, selbst fehlerfrei sind. Sie können beispielsweise selbst mittels Fuzzing getestet werden.
-
Ausführungsbeispiel 4 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 3, aufweisend, für jeden gefundenen Fehler, falls der Software-Komponente bei einer Ausführung des Computerprogramms die ermittelten Eingabedaten nicht zugeführt werden, Behandeln der Softwarekomponente bei der Fehlerbereinigung in Hinblick auf den Fehler als fehlerfrei.
-
In anderen Worten werden Fehler von Softwarekomponenten, die in dem Sinne nicht relevant sind, dass sie bei einer Ausführung des (Gesamt-)Computerprogramms nicht auftreten, weil den Softwarekomponenten bei der Ausführung des Computerprogramms keine Eingaben zugeführt werden, bei denen diese Fehler auftreten, gemäß verschiedenen Ausführungsformen in dem Sinne ignoriert, dass keine Anpassung der jeweiligen Softwarekomponente durch die Identifikation des Fehlers beim Testen ausgelöst wird.
-
Ausführungsbeispiel 5 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 4, wobei die Software-Komponente unabhängig von anderen Software-Komponenten des Computerprogramms getestet wird.
-
Die Software-Komponente bekommt somit eigene Eingabedaten und das Zusammenspiel mit anderen Software-Komponenten des Computerprogramms entfällt. Dies erleichtert das Testen der Software-Komponente mittels Fuzzing. Eine entsprechende „Isolation“ der Software-Komponente und deren Einbettung in eine eigene Testumgebung, z.B. eine virtuelle Steuereinrichtung (mit hohem Abstraktionsgrad, z.B. ohne Bereitstellung bzw. Simulation von in der Praxis vorhandenen Software- und auch Hardware-Komponenten), kann als Teil des Extrahierens der Software-Komponente angesehen werden.
-
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 mit dem Computerprogramm oder, falls es angepasst wurde, mit dem angepassten Computerprogramm gesteuert wird.
-
Ausführungsbeispiel 7 ist ein Software Test- und Fehlerbereinigungssystem, 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ührungsbeispiel e 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 100 für die Entwicklung und/oder das Testen von Softwareanwendungen.
- 2 veranschaulicht das Testen einer Software gemäß einer Ausführungsform.
- 3 zeigt ein Ablaufdiagramm 300, das ein Verfahren zur Software-Fehlerbereinigung 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 (d.h. ein Computerprogramm, also eine Software) 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 und Fehler bereinigen (d.h. die Anwendung 105, d.h. das Programm, ggf. anpassen), 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.
-
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.
-
Elektronische Geräte wie Steuervorrichtungen für Robotervorrichtungen wie Fahrzeuge und Roboterarme werden typischerweise als Kombination von Software mit Hardware bereitgestellt. Das Testen eines solchen (integrierten) Komplettsystems ist keine einfache Aufgabe. Gemäß verschiedenen Ausführungsformen wird eine Herangehensweise bereitgestellt, bei der beim Testen einer Software der Fokus auf die relevantesten Fehler gelegt wird.
-
Fehler, die nur bei Eingaben an Softwarekomponenten auftreten, die in der Gesamtsoftware nicht vorkommen, können als nicht relevant betrachtet werden, da sie in der Gesamtsoftware (d.h. einem Gesamt-Programm) nicht zu Fehlern führen (und insbesondere nicht ausgenutzt werden können). Nichtsdestotrotz kann es dennoch wünschenswert sein, Fehler in Software-Komponenten zu finden, da eine Softwarekomponente möglicherweise in verschiedenen größeren (Gesamt-)Programmen (d.h. nicht nur in der einen Gesamt-Software) eingesetzt wird. Darüber hinaus soll ermittelt werden, wie die Fehler in den verschiedenen (Gesamt-)Programmen kompensiert werden können (d.h. verhindert werden kann, dass sie zu Fehlern des Gesamt-Programms führen) und auch, ob diese Kompensation (z.B. durch einen Angreifer) umgangen werden kann.
-
Im Folgenden werden Herangehensweisen beschrieben, die beide obigen Punkte insofern berücksichtigen, dass auf zwei Arten mit Fehlern in Softwarekomponenten (z.B. in tiefen Schichten der Gesamtsoftware) umgegangen werden kann, die beispielsweise mittels Fuzzing gefunden werden:
- 1. Ermittlung, ob die Gesamtsoftware von einem Fehler in einer Softwarekomponente beeinflusst wird.
- 2. Ermittlung von Informationen darüber, wie vermieden werden kann, das ein Fehler in einer Softwarekomponente zu einem Fehler in der Gesamtsoftware führt (d.h. wie die Auswirkungen des Fehlers auf die Gesamtsoftware abgeschwächt bzw. verhindert werden können)
-
Die Softwarekomponenten werden dabei auf niedriger Ebene, d.h. mit hoher Abstraktion, beispielsweise ohne im praktischen Einsatz vorhandenen Komponenten wie Laufzeitumgebung, anderen Softwarekomponenten, insbesondere Basis-Softwarekomponenten (wie Betriebssystem) und MCAL (microcontroller abstraction layer) getestet. Für den Test nötige Komponenten 207 (wie Basis-Softwarekomponenten und Echtzeitumgebung) können allerdings für das Testen der Softwarekomponente 201 imitiert werden.
-
Mittels statischer Analyse wird ermittelt, ob ein Fehler, der bei einem Aufruf der Softwarekomponente mit einer bestimmten Eingabe aufgetreten ist, von der Gesamtsoftware erreicht werden kann, d.h. über eine Schnittstelle der Softwarekomponente zu externen Software-Komponenten ausgelöst werden kann. Ist dies nicht der Fall, kann auch ermittelt werden, warum dies so ist, beispielsweise welcher Programmcodeabschnitt dafür verantwortlich ist, dass der Fehler in der Gesamtsoftware nicht auftreten kann. In anderen Worten wird das Testen mittels Fuzzing auf den Schnittstellen der einzelnen Software-Komponenten durchgeführt. Außerdem können die relevantesten Programmteile (z.B. Funktionen) des Gesamtprogramms (d.h. im Software-Stack, der das Gesamtprogramm bildet) identifiziert werden, die für das „Sauberhalten“ der Daten verantwortlich sind, d.h. dafür sorgen, dass Eingabedaten für Software-Komponenten, die zu Fehlern führen, nicht auftreten. Diese Programmteile können selbst mittels Fuzzing getestet werden und sie können robuster gemacht werden oder durch zusätzliche Features ergänzt werden.
-
2 veranschaulicht das Testen einer Software gemäß einer Ausführungsform.
-
Anstatt eine Gesamtsoftware 201 zu in einem komplett integrierten Umfeld 208 zu testen, d.h. so dass sie alle Software-Komponenten, die letztlich beim Einsatz der Gesamtsoftware auf einem Zielsystem vorhanden sind (wie MCAL, Basis-Softwarekomponenten, Echtzeitumgebung) enthält und auch die im Einsatz vorhandene Hardware des Zielsystems (als virtuelle Hardware 202) simuliert wird, wird eine einzelne Softwarekomponente der Anwendungssoftware extrahiert und in einem Umfeld 209 (d.h. einer Testumgebung) mit hoher Abstraktion getestet. Dabei wird die Schnittstelle (oder auch mehrere Einzel-Schnittstellen, die hier aber als eine einzige Gesamt-Schnittstelle angesehen wird) zu den anderen Komponenten des Gesamtprogramms imitiert. Über diese Schnittstelle kann die Software-Komponente 203 dann mittels Fuzzing getestet werden.
-
Dies kann für mehrere Software-Komponenten durchgeführt werden und damit auch interne Schnittstellen (z.B. APIs), nicht nur die von extern einfach erreichbaren Schnittstellen der Gesamtsoftware 201 getestet werden. Damit wird erreicht, dass die Robustheit der individuellen Software-Komponenten sowie ihre Schnittstellen getestet werden.
-
Wurde auf diese Weise ein Fehler 204 in einer Software-Komponente 203 gefunden, so wird, als zweite Phase des Testens, die die statische Analyse 205 umfasst, das gewonnene Wissen über den Fehler der einzelnen Software-Komponente mit dem Wissen über die Gesamtsoftware kombiniert werden, um zu ermitteln, ob der Fehler im Kontext der Gesamtsoftware relevant ist, d.h. dort auftreten kann und wenn nicht, aus welchen Gründen er nicht auftreten kann.
-
Die statische Analyse, bei der auf diese Weise die Relevanz von Fehlern ermittelt wird, kann klassische Statische-Analyse-Techniken oder Daten-getriebene (engl. data driven) Verfahren, wie beispielsweise maschinelles Lernen (ML) verwenden. Wenn maschinelles Lernen eingesetzt wird kann sich die statische Analyse Daten (und Wissen) aus der Analyse anderer Programme zu Nutze machen, um verbesserte Vorhersagen bzgl. der Relevanz von Fehlern zu machen. Dazu wird zuvor ein ML-Modell mit Daten über frühere Programme trainiert.
-
Die statische Analyse 205 erhält die Gesamtsoftware 201 und auch Wissen über die Hardware 202 als Eingabe. Ergebnisse 206 der statischen Analyse sind, ob die in einzelnen Softwarekomponenten gefundenen Fehler im Kontext der Gesamtsoftware auftreten und Information darüber, welche Teile der Gesamtsoftware (die z.B. Teil anderer Softwarekomponenten sind) dies ggf. verhindern.
-
Zusammengefasst wird gemäß verschiedenen Ausführungsformen ein Verfahren bereitgestellt, wie in 3 dargestellt.
-
3 zeigt ein Ablaufdiagramm 300, das ein Verfahren zur Software-Fehlerbereinigung gemäß einer Ausführungsform darstellt.
-
In 301 wird mindestens eine Software-Komponente aus einem zu testenden Computerprogramm extrahiert. Die Software-Komponente hat eine Schnittstelle, über die sie bei einer Ausführung des Computerprogramms Eingabedaten empfängt.
-
In 302 wird die extrahierte Software-Komponente (z.B. mittels Fuzzing) auf der Schnittstelle der Software-Komponente zum Finden von Fehlern getestet und für jeden Fehler werden Eingabedaten ermittelt, die, wenn sie über die Schnittstelle der Software-Komponente zugeführt werden, zu dem Fehler führen.
-
In 303 wird für jeden gefundenen Fehler der Software-Komponente überprüft, ob der Software-Komponente bei einer Ausführung des Computerprogramms die ermittelten Eingabedaten zugeführt werden.
-
In 304 wird das Computerprogramm in Hinblick auf den Fehler abhängig davon angepasst, ob der Software-Komponente bei einer Ausführung des Computerprogramms die ermittelten Eingabedaten zugeführt werden.
-
Es sollte beachtet werden, dass obwohl die obigen Ausführungsbeispiele hauptsächlich im Zusammenhang mit Fuzzing beschrieben wurden, auch andere Testverfahren zum Testen der Software-Komponenten verwendet werden können. Für diese ergeben sich ähnliche Vorteile wie beim Einsatz von Fuzzing.
-
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 wird beispielsweise auf ein Steuerprogramm für eine Robotervorrichtung angewendet, das bei seiner Ausführung ein Steuersignal für die Robotervorrichtung erzeugt. Der Begriff „Robotervorrichtung“ kann als sich auf irgendein technisches System (mit einem mechanischen Teil, dessen Bewegung gesteuert wird) 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.
-
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.
