Testen von Software

Guido Wirtz

Das Stichwort beschreibt die wesentlichen Aspekte von Softwaretests und bietet einen Überblick über die eingesetzten Testmethoden wie auch eine Einordnung der verschiedenen Testarten in den Softwareentwicklungsprozess.

Einordnung in den Entwicklungsprozess

Tests zum Aufdecken von unerwünschtem Verhalten von Software sind ein wichtiger Aspekt der Qualitätssicherung in allen heute anerkannten Vorgehensmodellen zur Softwareentwicklung. Grundsätzlich kann Testen sowohl zur Validierung gegenüber Nutzern und Auftraggebern im Rahmen der Begutachtung von Prototypen als auch zur Verifikation auf Erfüllung einer vorliegenden Spezifikation eingesetzt werden. Testen steht deshalb in engem Zusammenhang mit der Beschreibung von Anforderungen und Randbedingungen der intendierten Programmnutzung in den frühen Phasen der Softwareentwicklung. Auf dieser Grundlage erlauben Tests die Beobachtung und Analyse des Verhaltens von Software auf vorgesehene und unerwartete Eingaben. Dabei dienen Tests dem Aufdecken von Fehlverhalten durch Abgleich mit dem vorher beschriebenen intendierten Verhalten von Software. Tests liefern dementsprechend Information über die Existenz und Art von Fehlverhalten (engl. ‚fault‘), bestenfalls aber lediglich Anhaltspunkte über die das Fehlverhalten verursachenden Programmfehler (engl. ‚bug‘). Hier setzt die Suche nach Fehlern im Programm, das sogenannte ‚Debuggen‘, ebenso an wie daraus abzuleitende Maßnahmen zur Behebung von Fehlern.

Grundsätzliche Probleme

Testen von Software verfolgt das Ziel, mit vertretbarem Aufwand an Zeit und Personal möglichst verlässliche Aussagen über das Verhalten von Software zu machen, wobei zwei grundlegende Probleme zu bewältigen sind:

1. Fehlverhalten kann unterschiedliche Formen annehmen, die unterschiedliche Tests erfordern. 
   Ein System kann nicht das tun, was von ihm erwartet wird, also z.B. die erwarteten Rechenergebnisse liefern oder eine Grafik korrekt darstellen. Es kann aber auch Dinge tun, die nicht von ihm erwartet werden, z.B. unerlaubt Werte ändern oder das umgebende System zum Absturz bringen. Je nach den beteiligten Komponenten eines Systems sind so unterschiedliche Aspekte wie die Datenhaltung in einer Datenbank, die Datenübertragung, die Ausführung der Programmlogik oder aber die Reaktion einer Benutzeroberfläche bei einer Mausbewegung auf Fehlverhalten hin zu überprüfen, wobei dies sowohl die Ergebnisse als auch die Dauer des Vorgangs betreffen kann. Diese Vielfalt an möglichem Fehlverhalten führt dazu, dass es sehr schwer ist, mit einer vom Aufwand her akzeptablen Menge von Tests das vollständige Verhalten eines Softwaresystems zu erfassen.

2. Softwaresysteme sind in der Regel so komplex, dass nicht jeder mögliche Ablauf explizit auf das Auftreten von Fehlverhalten überprüft werden kann.    
   Im Hinblick auf eine möglichst gute Verhaltensüberdeckung werden alle Methoden der statischen Programmanalyse im Rahmen sogenannter

   Whitebox-Tests eingesetzt. Im Rahmen sogenannter

   Blackbox-Tests sind eine Reihe von Methoden zur Erzeugung typischer erlaubter Eingaben und besonders fehleranfälliger Grenzfälle als Repräsentanten für alle möglichen Eingaben im Einsatz. Hier ist Werkzeugunterstützung durch Softwareentwicklungsumgebungen ebenso unverzichtbar wie die Aufzeichnung und Generierung typischer Benutzerinteraktionen beim Test von Benutzeroberflächen.

Grenzen

Trotz aller Maßnahmen sind Tests nur Stichproben, die bestenfalls statistische Aussagen über die Korrektheit erlauben, nicht aber deren vollständigen Nachweis. Dem begegnet zeitgemäße Softwareentwicklung mit einer Reihe von Maßnahmen. Testen wird nicht mehr als isolierte Phase im Softwareentwicklungsprozess angesehen, die erst nach der Implementierung einsetzt und den top-down vorgehenden Entwicklungsprozess bottom-up vom Modultest über Integrationstest und Systemtest bis hin zum Akzeptanztest beim Kunden widerspiegelt, sondern als wichtige Maßnahme einer umfassenden Qualitätssicherung, die durch alle früheren Phasen der Softwareentwicklung vorbereitet wird. Hier spielt das Pflichtenheft eine zentrale Rolle, wenn es das erwartete Verhalten so beschreibt, dass daraus Testszenarien und Testfälle abgeleitet werden können. In sicherheitskritischen Fällen werden Teile eines Systems zusätzlich einer formalen Verifikation unterworfen [Hierons, Bogdanov et al., 2009]. Ergänzend werden Reviews eingesetzt, die Software von unabhängigen Sachverständigen auf die Erfüllung vorgegebener Prüfkriterien in Struktur und Inhalt hin untersuchen. Diese Ergänzung ist wichtig, weil Tests im klassischen Sinn erst bei Vorliegen ablauffähiger Software recht spät im Softwareentwicklungsprozess möglich sind. Abhilfe kann hier ein an Prototypen orientiertes Verfahren liefern, das schneller zu lauffähigen und damit testfähigen Teilsystemen gelangt.

Interessenkonflikte werden vermieden, indem die Vorbereitung, Durchführung und Auswertung von Tests mit Ausnahme der Modultests weder von den Entwicklern noch von den unmittelbaren Projektverantwortlichen durchgeführt wird. Aus diesem Grund ist Testen in größeren Projekten ein formalisierter, iterativer Prozess zwischen Testphasen in unabhängigen Abteilungen mit dokumentiertem Ergebnis und Korrekturphasen bis zur Abnahme eines Softwaresystems.

Literatur

Liggesmeyer, Peter: Software-Qualität – Testen, Analysieren und Verifizieren von Software. 2. Auflage. Spektrum Akademischer Verlag : Heidelberg, 2009.

Myers, G.J.; Sandler, C.; Badgett, T. : The Art of Software Testing. 3. Auflage. John Wiley & Sons : New York, 2011.

Spillner, A.; Linz, T.: Basiswissen Softwaretest. 4. Auflage. dpunkt Verlag : Heidelberg, 2010.

Hierons, M.; Bogdanov, K. et al.: Using formal specifications to support testing. in: ACM Computing Surveys 41(2), Februar 2009.