Skip to main content

Test, Debugging & Safety

Wenn von ,Testen‘ gesprochen wird ist in der Regel das dynamische Ausführen von Software gemeint. Das ist jedoch nur ein Teilbereich. Weitere Disziplinen sind die statische Analyse von Software und das Test-Management. Unter dem Gesichtspunkt, dass die dynamische Ausführung in der Regel die aufwändigste Disziplin ist, lohnt sich auch ein Blick auf die anderen Disziplinen.

Am Ende bleibt noch das Debuggen, das Finden der Ursache für den Fehler. Auch hier lohnt ein Blick auf verfügbare Methoden und Werkzeuge, die anstelle von 'printf debugging' eingesetzt werden können.

∨ mehr Text anzeigen

Testen ist im Allgemeinen eine unbeliebte Aufgabe. Psychologisch ist das leicht zu erklären. Wir hätten alle lieber, dass wir für den vermeintlich abgeschlossenen Akt unserer kreativen Tätigkeit ein Lob bekommen. Ein positiv verlaufener Test hingegen zeigt uns auf, dass wir einen Fehler gemacht haben, und schlimmer noch, dass wir mit unserer Arbeit doch noch nicht fertig sind.

Nach dem Testen kommt das Debuggen. Der positive Test beweist lediglich, dass die Software in einer bestimmten Situation nicht das tut, was erwartet wird. Nun gilt es herauszufinden, was der Grund dafür ist. Dieser Vorgang wird als Debugging bezeichnet. Debugging ist ein immer wieder notwendiger Arbeitsschritt, dessen Aufwandsabschätzung schwierig ist. Bisweilen kann die Suche nach der Ursache eines Fehlers Wochen bis Monate dauern. Zum Beispiel, wenn Fehler nur sehr sporadisch auftreten und nur schwierig zu reproduzieren sind. Unter diesem Gesichtspunkt macht es häufig auch Sinn den Vorgang des Debuggens und mögliche Hilfsmittel genauer zu betrachten.

Grundsätzlich wird zwischen folgenden Formen des Tests und des Debuggings unterschieden:

  • Test-Management
  • Dynamische Ausführung
  • Statische Analyse
  • Debugging

Obwohl wahrscheinlich zu 90% die dynamische Ausführung als Testform genutzt wird, hat die statische Analyse eine mindestens gleichberechtigte Bedeutung. Der Vollständigkeit halber sei auch noch das Test-Management aufgeführt.

Test-Management

Test-Management bezieht sich überwiegend auf den oberen Teil des V-Modells. Hier wird z.B. der Grundstein für die Traceability zu den Anforderungen gelegt. Im Test-Management wird entschieden, was wann getestet werden muss/sollte und bei welcher Änderung welche Tests erneut durchgeführt werden müssen/sollten. Unterschätzt wird häufig das Potential des Testmanagements zur Effizienzsteigerung der Testaktivitäten an sich. In der Regel wird aus Unwissenheit der Abhängigkeiten auch nach vermeintlich kleinen Änderungen viel Testaufwand getrieben, da die Zusammenhänge und potentiellen Auswirkungen der Änderung unklar sind. Test Management hilft den tatsächlichen Aufwand für die Durchführung der Tests zu minimieren, bei gleichzeitiger Erhöhung der Qualität.

Dynamisches Testen

Hier wird der Code auf der realen Zielplattform oder auf Basis einer Simulation ausgeführt. Hier geht es um die Definition von Testsequenzen und den erwarteten Ergebnissen. Ziel ist immer auch, Tests mit geringem Aufwand wiederholen zu können und deren Ergebnisse zu dokumentieren. Häufiges weiteres Ziel ist die Automatisierung von Testabläufen in Form von Regression-Tests. Regression-Tests sind die Basis von Nightly Tests. Hierin wird der Hebel gleich an zwei Seiten angesetzt. Der Aufwand für die Durchführung der Tests minimiert sich. Mindestens genau so vorteilhaft ist die schnelle Rückmeldung von Fehlern. Bekommt der Entwickler die Rückmeldung eines Fehlers innerhalb von 24 Stunden zur Änderung befindet er sich gedanklich noch im Kontext der Änderung. Die Ursache des Fehlers ist naheliegend und langes Debugging nicht erforderlich. Kommt die Rückmeldung erst Wochen oder sogar Monate später fehlt der Bezug zur Änderung. In der Regel ist nun der Debugging-Aufwand (finden der Ursache) erheblich aufwändiger.

Statisches Testen

Beim statischen Testen handelt es sich um die statische Analyse des Codes. Der Code wird dabei nicht ausgeführt. Das hat den Vorteil, dass in sehr kurzer Zeit der gesamte Code analysiert werden kann. Auf Basis der statischen Analyse werden jedoch nur bestimmte Fehlerklassen abgedeckt. Aus diesem Grund wird es häufig nicht eingesetzt. Trotzdem ist es eines der effizientesten Vorgehen, um Fehler zu finden.  

Für folgende Fehlerklassen ist die statische Analyse prädestiniert. 

  • Speicherlecks
  • Zerstörung von Speicherinhalten
  • Zugriffe über NULL-Zeiger
  • Unsichere Zeigerarithmetik
  • Benutzung von Speicher nach Freigabe
  • Inkonsistente Freigabe
  • Konstruktor-/Dekonstruktor-Lecks
  • Fehlerhafte Verwendung von virtuellen Member-Funktionen
  • Arithmetische Fehler
  • Nicht initialisierte / unbenutzte Variable
  • Redundanter / überflüssiger Code
  • Division durch null
  • 32/64-bit Kompatibilitätsprobleme
  • Pufferüberläufe  

Debugging

Als Debugging wird die Suche nach der Ursache eines Fehlers bezeichnet. Debugging kann unter Umständen sehr zeitaufwändig sein. Vor Allem schlecht reproduzierbare Fehler lassen sich naturgemäß schlecht debuggen.

Treten schlecht reproduzierbare Fehler häufiger auf ist das immer ein ernstzunehmendes Warnsignal für eine unzureichende Software-Architektur.

Debugging-Hilfsmittel und Werkzeuge gibt es in Preislagen zwischen wenigen Hundert Euro bis hin zu mehreren Zehntausend Euro. Wir bezeichnen Debugging auch als Firefighting und raten die Investition in Fire Protection nicht zu vernachlässigen. Dann reichen in der Regel Werkzeuge im unteren Preissegment für effizientes Debugging. Für effizientes Fire Protection steht Architektur-Design an oberster Stelle.

IBM Rational Rhapsody Test Conductor

Die UML bietet damit eine hervorragende Basis zur effizienten Spezifikation von Testszenarien. Der TestConductor wiederum kann Sequenz-Diagramme analysieren und daraus automatische Testläufe generieren.

> mehr lesen

Willert Embedded UML Target Debugger

Passend zu IBM® Rational® Rhapsody® gibt es nun eine Debugging-Lösung, die wie herkömmliche Embedded Hochsprachen-Debugger auf Basis eines Monitors arbeitet. Der Vorteil liegt auf der Hand, echtzeitfähiges Debugging mit minimalem Overhead auf UML-Modellebene.

> mehr lesen
Hinweis: Unsere Webseite nutzt Cookies. Wenn Sie fortfahren, nehmen wir an, dass wir Ihre Erlaubnis haben Cookies zu setzen. Informationen zum Einsatz von Cookies sowie unsere Datenschutzbestimmungen finden Sie in unserer Datenschutzerklärung und über unser Impressum.