Softwaretest
Gegen den Baum
Fortsetzung des Artikels von Teil 1
Einheitliche Sprache wichtig
In der Softwareentwicklung haben sich viele Begriffe eingebürgert. Leider unterscheiden sich die Begriffe und deren Verständnis von Unternehmen zu Unternehmen. Durch die natürliche Fluktuation kommen neue Mitarbeiter ins Unternehmen, die unter etablierten Formulierungen etwas anderes verstehen als langjährige Mitarbeiter. Ein Beispiel ist der Begriff Unit-Test. Handelt es sich dabei um den Test einer einzelnen Funktion, bei der alle Unterfunktionen durch Stub-Funktionen ersetzt sind? Möglicherweise ist aber ein Unit-Test auch der Test einer Funktion inklusive aller aufgerufenen Unterfunktionen im gleichen Modul. Mitunter ist ein Unit-Test jedoch auch der Test eines gesamten Moduls (wobei hierbei zu klären ist, was ein Modul ist). Wer mal Kontakt mit Entwicklern aus mehreren Unternehmen aufnimmt und nachfragt, was sie unter einem Softwaremodul verstehen, wird über die Antworten überrascht sein.
Bei der Einführung von systematischen Softwaretests sollte man genau prüfen, welche Ziele durch die Tests erreicht werden sollen. Danach sollte unternehmensspezifisch die beste Umsetzung festgelegt werden. Zu beachten ist, dass dem Testprozess die gleiche Aufmerksamkeit zu widmen ist wie dem eigentlichen Entwicklungsprozess. Der Einsatz von Tools beim Testen ist grundsätzlich hilfreich, jedoch muss die Zielsetzung stimmen, sonst hilft einem ein Tool nur, schneller die falschen Ergebnisse zu produzieren. So wie im Entwicklungsprozess oft Kodierrichtlinien (Coding Rules) existieren, sind auch Testrichtlinien zu definieren und umzusetzen. Die Erarbeitung einer »Best Practice « als verbindlicher Standard ist empfehlenswert. Ebenfalls ist darauf zu achten, dass sowohl Entwickler als auch Tester das Verbessern der Softwarequalität als gemeinsames Ziel ansehen und ein gemeinsames Vokabular verwenden.
Jobangebote+ passend zum Thema
Quellenhinweis:
[1] Helmut Balzert, Lehrbuch der Softwaretechnik Band 2, Spektrum Akademischer Verlag
Links:
Energie sparen bei eingebetteter Software
Unit-Tests mit Open-Source-Werkzeugen
Autor:
Joachim Klein ist Manager Training bei Hitex Development Tools. Telefon 07 21/96 28 19 0 hitex.de>www.hitex.de
Wann ist man fertig mit Testen? Es gibt unterschiedliche Ansätze. Eine Möglichkeit ist es, zum Beispiel die Testabdeckung als Kriterium heranzuziehen. Dies ist gefährlich, denn eine Testabdeckung auf Codebasis darf niemals das Testende definieren. Was ist, wenn der Code falsch ist? Dann ist zwangsweise die daraus abgeleitete Definition des Testendes falsch. Falls eine Testabdeckung als Kriterium für das Testende dienen soll, dann muss die Abdeckung der Anforderungen dazu verwendet werden. Dies erreicht man am besten, wenn ein Tool in Verbindung mit einer systematischen Vorgehensweise zur Testspezifikation verwendet wird. In Verbindung mit Tessy kommt hier zum Beispiel der Klassifikationsbaum- Editor (CTE, Classification Tree Editor) zum Einsatz. Mit CTE lässt sich die Klassifikationsbaummethode anwenden, mit der sich sehr effektiv Testfälle spezifizieren lassen, die alle Anforderungen an eine Funktion abdecken.
Was glauben wir, beim Testen zu finden? Bei Balzert [1] kann man nachlesen, dass die meisten Fehler im Software-Entwicklungsprozess bereits in der Anforderungsund Spezifikationsphase gemacht werden, während die meisten Fehler beim Entwickeln und Testen gefunden werden. Daraus folgt, dass die meisten gefundenen Fehler nicht vom Entwickler stammen, sondern auf Fehler in früheren Entwicklungsphasen zurückzuführen sind. Dies bestätigen auch die Erfahrungen aus der Praxis. Typische Fehler von Softwareentwicklern sind Codierfehler. Diese lassen sich effektiv mit Werkzeugen zur statischen Codeanalyse erkennen. Da solche Analysetools in der Regel sehr preiswert sind, sollten diese zur Grundausstattung in jedem Unternehmen gehören, das Wert auf gute Software legt. Es gibt immer wieder wundersame Software, die Testfälle automatisch erzeugen will. Der Autor hat bisher niemand kennen gelernt, der solche Tools erfolgreich einsetzt. Das Problem ist, dass es nicht reicht, einfach Testdaten (in der Werbung gerne auch als Testvektoren bezeichnet) zu erzeugen. Die Testergebnisse sind auch zu überprüfen. Bei Tools, die automatisch mehrere tausend Testfälle erzeugen, ist es alles andere als trivial, die Ergebnisse zu überprüfen. Ein Werkzeug, das aus einer formalen Spezifikation systematisch Testfälle für den Unit-Test erzeugt, ist derzeit nicht verfügbar.
- Gegen den Baum
- Einheitliche Sprache wichtig
- Wer soll testen?
