Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
DESIGN ELEKTRONIK 03 2023 22 www designelektronik de Software Testmethoden Bild 2 Screenshot eines gefundenen Fehlers im statischen Analysetool von TrustInSoft Bild TrustInSoft Verglichen mit traditionellen Testverfahren und statischen Analysemethoden haben diese Tools mehrere Vorteile zu bieten ■ ■ Bis zu 100 % Applikationsabdeckung unter Einbeziehung aller denkbaren Funktionen Anweisungen Pfade Entscheidungen und Bedingungen ■ ■ Bis zu 100 % Eingabeabdeckung unter Einschluss sämtlicher möglichen Werte innerhalb des Bereichs des jeweils geprüften Moduls ■ ■ Mathematische Garantie der Abwesenheit von undefiniertem Verhalten – Fehler und Schwachstellen – im Code mit dem Resultat von null Fehlern im Deployment ■ ■ Keine Falsch-Negativmeldungen sodass Entwickler verstärkt darauf vertrauen können dass sämtliche Probleme gefunden wurden ■ ■ Dank der geringen oder bestenfalls null betragenden Falsch-Positiv-Quote muss weniger Zeit in die Beseitigung von Problemen investiert werden die eigentlich gar keine sind ■ ■ Deutlich kürzere Testzeiten und effizientere Ressourcennutzung Bild 1 zeigt den Unterschied deutlich Traditionelle Testmethoden gehen bei der Testfallentwicklung und dem Algorithmenentwurf nach dem Best-Effort-Prinzip vor und werden dabei durch die Fähigkeiten des Menschen und die Projektzeitpläne eingeschränkt Das Resultat sind Tests die pro Durchgang nur einen einzigen Codezweig ausführen wodurch in einem bestimmten Testzeitraum nur ein begrenzter Teil des Codes getestet werden kann Eine vollständige statische Analyse gestützt durch formale Methoden kann dagegen in einem Testdurchlauf sämtliche Zweige prüfen sodass die Testabdeckung auf 100 % steigt und der Zeitaufwand dramatisch sinkt Die gründliche statische Analyse kann die Art und Weise wie Entwickler die Komplexität von Software beurteilen grundlegend verändern indem ihnen eine wirkungsvolle Methode zum Umgang mit dieser Komplexität in die Hand gegeben wird So hilft die gründliche statische Analyse Ein Mangel traditioneller Testmethoden betrifft die Abdeckung des Zustandsraums Anders ausgedrückt können diese Methoden nur eine begrenzte Zahl unterschiedlicher Kombinationen von Datenwerten und Eingaben Kontrollund Datenflussvarianten sowie Ausgangspfaden abdecken Unter anderem prüfen traditionelle Testmethoden die Funktionen nur auf erwartete Ausgaben bei erwarteten Eingaben Einige statische Analysetools gehen zwar noch einen Schritt weiter und decken einen größeren Bereich von Einund Ausgaben ab jedoch sind die Tools infolge von Restriktionen in Bezug auf den Entwurf die Implementierung und den Zeitplan der Tests nicht in der Lage alle möglichen Verhaltensvarianten zu testen Der folgende Codeausschnitt zeigt eine C-Funktion die die Werte von Zellen in einem Array inkrementiert void increment array int array[] int len { while len > 0 { *array ++ Increment the value of the array cell array++ Move to next array cell len-- Decrement counter } } int main int argc char *argv[] { int data[4] {1 3 5 7} char name[] “foobars” increment array data 4 Increment array } Ein typischer Modultest würde die Validierung hier anhand der Anforderungen an die Funktion vornehmen und überprüfen ob die Funktion die Zellenwerte im ausgegebenen Array tatsächlich inkrementiert hat um je nach Ergebnis ein »pass« oder »fail« zu melden Allerdings würde dieser Test nicht unbedingt prüfen ob der Array-Index *p aufgrund von unerwarteten oder unerwünschten Nebeneffekten im System einen über die Grenzen des Arrays hinausreichenden Speicherzugriff ausgeführt hat wie es in diesem Codebeispiel wegen einer in der while-Schleife spezifizierten unkorrekten Bedingung der Fall ist Ungeachtet des Pufferüberlaufs würde ein traditioneller an den Anforderungen orientierter Test lediglich verifizieren dass der Inhalt des Arrays nach Aufrufen der Funktion {2 4 6 8} lautet – und er somit stets ein »pass« als Resultat ausgeben wie der folgenden Konsolenausgabe zu entnehmen ist gcc -Iincrement c -o ub ub Run test increment array increment array {1 3 5 7} {2 4 6 8} --> PASSED Solange die Testingenieure die Möglichkeit eines über die Array grenzen hinausreichenden Zugriffs nicht einkalkulieren wird dieser Pufferüberlauf also niemals aufgedeckt werden Subtile Fehler dieser Art können zu Verfälschungen von Speicherinhalten führen die wiederum Bugs Abstürze oder Sicherheitslücken der Applikation verursachen können Obwohl sie traditionellen Testmethoden verborgen bleiben lassen sie sich mit gründlichen statischen Analysetools aufdecken wie in Bild 2 zu sehen ist Das Tool erkennt dass nach Beginn des Arrays 16 Byte geschrieben werden und somit ein Pufferüberlauf vorliegt Diese Verfälschung des Speicherinhalts lässt sich mit einem etwas ausführlicheren Testfall aufdecken in dem sich die über die Grenzen hinausgehenden Schreibzugriffe auf den Wert des