home  |  suche  |  kontakt/johner  |  institut 
studierende  |  tech-docs  |  mindmailer 

Klassifizierung von Tests

Es gibt viele weitere Namen von Tests, die sich jedoch meist klassifizieren lassen:

     

  • Testziel: Lasttest, Stresstest, ...
  • Testwerkzeug oder -methode: JUnit-Tests, statische Tests, dynamische Tests, Blackbox-Test, Whitebox-Test ...
  • Testobjekt: GUI-Test, Datenbanktest
  • Testperson: Anwendertest, Entwicklertest
  • Teststufe: Modultest, Systemtest, ...

Statische und dynamische Tests

Die meisten bisher genannten Tests führen den Code aus. Sie zählen damit zur Klasse der dynamischen Tests. Hingegen basieren statische Tests auf der Analyse des Quellcodes. Beispiele dafür sind

     

  • Überprüfungen durch den Compiler
  • Code-Reviews (s.u.)
  • Automatische Codeanalyse (Metriken, Namenskonventionen, ...)

Code-Review

Die Code-Reviews sollten - gemeinsam mit einem zweiten Entwickler durchgeführt - die Implementierungsphase abschließen. Zu diesem Zeitpunkt sollten auch die Modultests erstellt und ausgeführt worden sein. Während des Code-Reviews sollte Folgendes geprüft werden:

     

  • Code ist verständlich
  • Code ist gut und vollständig dokumentiert (JavaDoc, Inline-Kommentare)
  • Sicherstellen, dass der Code die definierte Architektur/Design und die Anforderungen reflektiert
  • Code enthält keine Abhängigkeiten von Sprache/Region und System (z.B. keine hart kodierten Pfade, Datenbanknamen)
  • Geeignete Fehlerbehandlung (so nah und spezifisch am Ort des potentiellen Auftretens des Fehlers)
  • Rundungsfehler, besonders bei Konvertierung von Typen
  • Potentielles Auftreten von Laufzeitfehler (NullPointer, Division by Zero)
  • Code entspricht den definierten Kodierrichtlinien (Namenskonventionen, Formatierungen, Metriken usw.)
  • Modultests prüfen erfolgreich und vollständig die Korrektheit, die Fehlerbehandlung und verschiedene Übergabeparameter (s. Äquivalenzklassen)
  • Die Modultests erreichen eine Anweisungsabdeckung von 100% (oder was die Testplanung vorschreibt)

 

 

White- und Blackbox-Tests

Die Whitebox-Tests sind Tests, die Kenntnisse der inneren Struktur einer Komponente voraussetzen. Sie werden auch als Glasboxtests bezeichnet (weil man in eine weiße Kiste nicht hineinsehen kann). Diese Tests finden vor allem auf Modultestebene Anwendung, bei denen die Tests aufgrund der inneren Struktur entworfen werden. Auf dieser Ebene ist das Messen von Abdeckungsgraden (Code-Coverage) sinnvoll.

Bei Blackbox-Tests ist die innere Struktur hingegen unbekannt oder zumindest nicht relevant. Die höheren Teststufen wie System-, Last- Stress- oder Akzeptanztests sind typische Vertreter dieser Testklasse.

Äquivalenzklassen finden sowohl bei White- als auch bei Blackbox-Tests Anwendung.

Regressionstests

Regressionstests sind Tests, die nachweisen, dass ein bereits getestetes Programm oder ein Programmteil nach einer Änderung keine neuen Fehler enthält. Alle bisher beschriebenen automatisierbaren Tests wie Modultests, Integrationstests und Systemtests sollten unbedingt als Regressionstests wiederholt werden. Dazu bieten sich die sogenannten "Nightly builds" an, bei denen neuer Code nicht nur kompiliert sondern all diesen Regressionstests ausgesetzt wird.

Es sollte jedem Entwicklungsteam klar sein, dass die Tests mindestens die gleiche Bedeutung für den Erfolg und die Qualität eines Produkts haben wie der Quellcode der Anwendung selbst. Entsprechend steckt viel Arbeit und Potential in diesen Tests, weshalb sie so oft wie möglich wiederholt werden sollten - als Regressionstests.