Testen, Debugging

Testfälle (test cases)

Um eine Software systematisch zu testen, werden ausgehend von der technischen Dokumentation und von den use cases zahlreiche Testfälle (test cases) notiert, die im Laufe der Entwicklung immer wieder durchgeführt werden um sicherzustellen, dass die erwartete Funktionalität gewährleistet ist. Ein Testfall besteht meist aus drei Teilen:

Beschreibung der Voraussetzungen des Tests
(z.B. "Der User befindet sich im Modul "Berichte". In der Datenbank befinden sich mindestens zwei Berichte. Die Tabelle mit den Berichten ist sichtbar und nach Erstellzeitpunkt sortiert.)
Beschreibung der Schritte zur Durchführung
(z.B. "Der User klickt auf den Spaltenkopf 'Name' der Tabelle.")
Beschreibung des erwarteten Ergebnisses
(z.B. "Die Tabelle ist jetzt aufsteigend nach dem Namen der Berichte sortiert.")

Arten von Softwaretests

Manuelles Testen
Beim Manuellen Testen führen Angestellte (oft auf Auftragnehmer und Auftraggeberseite) die Tests "von Hand" durch und protokollieren die Testergebnisse.
Automatisiertes Testen
Hier wird für jeden Testfall ein kleines Programm erstellt, das den Testfall automatisch durchführt, das Ergebnis überprüft und protokolliert. Man unterscheidet in technischer Hinsicht grob zwei Vorgehensweisen:
- Unit tests (sie überprüfen das Programm in technischer Hinsicht, indem sie Methoden aufrufen und die Rückgabewerte überprüfen)
  Wie das praktisch geht, erfahren Sie im Kapitel "Unit tests".
- Testsysteme, die die Interaktion des Users mit der Software (d.h. jeden Mausklick, jedes Herunterdrücken einer Taste, …) simulieren und anschließend die Ausgabe des Programms überprüfen.

Manuelles Testen vs. automatisiertes Testen

Beim manuellen Testen fallen den Tester/-innen oft Fehler des Programms auf, an die die Ersteller/-innen der Testfallbeschreibungen gar nicht gedacht hatten. Zudem bewerten die Tester/-innen oft auch die Benutzerfreundlichkeit des Programms und tragen mit Verbesserungsvorschlägen zur Verbesserung der usability bei.
Manuelles Testen ist bei der ersten Durchführung eines Tests meist günstiger als automatisiertes Testen, da der Testfall nicht in ein Testprogramm überführt werden muss. Mit zunehmender Zahl von Testdurchläufen werden automatisierte Tests aber immer wirtschaftlicher, da die Durchführung dieser Tests praktisch nichts kostet.
Automatisierte Tests können schon während des Programmierens immer wieder aufgerufen werden und helfen so, Fehler sehr frühzeitig zu erkennen und zu beheben.

Arten von Fehlern

compile time errors (Kompilierzeitfehler) sind Fehler, die der Compiler schon während der Übersetzung eines Programms erkennt und meldet.
runtime errors (Laufzeitfehler) sind Fehler, die erst zur Laufzeit auftreten und durch das Programm gemeldet werden.
logical errors (Logische Fehler) sind Fehler, die nicht vom Compiler oder vom laufenden Programm gemeldet werden, aber zu einem Verhalten des Programms führen, das den Vorgaben des Pflichtenhefts widerspricht.

Gute IDEs starten den Compiler schon während der Eingabe eines Programms fortwährend im Hintergrund und zeigen die gefundenen Fehler an, indem sie die entsprechenden Stellen beispielsweise farbig unterringeln. Die während der Compilierung erstellten Datenstrukturen des compilers (abstract syntax tree, symbol tables, types, …) werden von der IDE genutzt, um den Programmierer/-innen code assistance features zur Verfügung zu stellen, z.B.

code completion (Code-Vervollständigung)
code navigation (Strg + click auf Symbol um zur Deklaration zu gelangen)
parameter hints (Anzeige der benötigten Parameter einer Methode)
find references
refactor → rename

Auch die Werkzeuge zur Unterstützung des refactoring greifen auf diese Informationen des Compilers zurück.