Moin!
Weiss jemand, was für Methoden grundsätzlich verbreitet sind, um Treiber-Level Software gründlich auf Fehler und Schwachstellen zu untersuchen?
Wird da auch viel mit Unit-Tests gearbeitet? Oft ist es ja gar nicht mal so einfach, an die Funktionen ranzukommen, bzw eine geeignete Test-Umgebung zu erstellen, in der die jeweilige Funktion die benötigten Rahmenbedingungen (vorhandene device files etc) vorfindet.
Könnte mir die bedingte Kompilierung vorstellen, obwohl ich dies eher vermeiden möchte, weil der Code dadurch stark in mitleidenschaft gezogen wird.
Gibt es da irgendwelche "best practices"?
Gruß
Hank
Test-Methodik in Treiber-SW?
-
Marco Gerber
- Posts: 38
- Joined: 26. Aug 2006 13:07
- Location: Zürich
Hallo
Für Unit Testing eignen sich dafür sogenannte 'Mock'-Objekte. Es handelt sich dabei um Objekte, welche eine Umgebung simulieren und bereitstellen, in welcher die zu testende Unit läuft. Das benötigt meist etwas Aufwand, lohnt sich aber.
Im weiteren lohnt sich für LowLevel Treibertesting auch eine virualisierte Umgebung. Damit hat man die Vorteile, schnell in einen Zustand zu wechseln, der unberührt von Veränderungen ist. Eine Open-Source Lösung, die dir ermöglicht, vollständig die Kontrolle über einen Treiber im Gast OS zu erhalten kann hier ergänzend eingesetzt werden (bsp VirtualBox - aber ärgere dich nicht über den Code
).
Dann auch Kernel Debugging, wobei ich hier mal noch ausprobieren muss wie sich dies in einer virtualisierten Umgebung verhält (würde sich anbieten).
hth
Marco Gerber
Für Unit Testing eignen sich dafür sogenannte 'Mock'-Objekte. Es handelt sich dabei um Objekte, welche eine Umgebung simulieren und bereitstellen, in welcher die zu testende Unit läuft. Das benötigt meist etwas Aufwand, lohnt sich aber.
Im weiteren lohnt sich für LowLevel Treibertesting auch eine virualisierte Umgebung. Damit hat man die Vorteile, schnell in einen Zustand zu wechseln, der unberührt von Veränderungen ist. Eine Open-Source Lösung, die dir ermöglicht, vollständig die Kontrolle über einen Treiber im Gast OS zu erhalten kann hier ergänzend eingesetzt werden (bsp VirtualBox - aber ärgere dich nicht über den Code
).Dann auch Kernel Debugging, wobei ich hier mal noch ausprobieren muss wie sich dies in einer virtualisierten Umgebung verhält (würde sich anbieten).
hth
Marco Gerber
Hallo
Danke für die Vorschläge!
Virtuelle Umgebungen sind sicherlich nicht schlecht. Allerdings handelt es sich nicht um die x86-Architektur und Linux als Ziel-Plattform, sondern um ein eingebettetes System mit einem Sparc-Prozessor und einem Echtzeitbetriebssystem, dafür sind die meisten virtuellen Maschinen wohl nicht ausgelegt.
Ich vermute mal, dass ich invididuell mir den Code anschauen werde, teile davon vielleicht mit Ausgaben debuggen werde, oder halt Funktionstests und Integrations-tests einbaue, wo es sinnvoll ist.
Ich bin nur noch nicht lange in dem Bereich in der Praxis, sodass ich mir die Vorgehensweise dabei noch teilweise aneignen muss. Fuzz-Testing klingt auch sehr interessant, aber ich hab auch nur einen theoretischen Artikel darüber in einer Zeitschrift gelesen und es nicht ausprobiert.
Gruß
Hank
Danke für die Vorschläge!
Virtuelle Umgebungen sind sicherlich nicht schlecht. Allerdings handelt es sich nicht um die x86-Architektur und Linux als Ziel-Plattform, sondern um ein eingebettetes System mit einem Sparc-Prozessor und einem Echtzeitbetriebssystem, dafür sind die meisten virtuellen Maschinen wohl nicht ausgelegt.
Ich vermute mal, dass ich invididuell mir den Code anschauen werde, teile davon vielleicht mit Ausgaben debuggen werde, oder halt Funktionstests und Integrations-tests einbaue, wo es sinnvoll ist.
Ich bin nur noch nicht lange in dem Bereich in der Praxis, sodass ich mir die Vorgehensweise dabei noch teilweise aneignen muss.
Fuzz-Testing klingt auch sehr interessant, aber ich hab auch nur einen theoretischen Artikel darüber in einer Zeitschrift gelesen und es nicht ausprobiert.Gruß
Hank