KIF410:Softwaretests für Anfänger und Fortgeschrittene

AK Softwaretest

Testzyklus

1. Roten Test schreiben, der eine noch fehlende Funktionalität abzudecken (d.h. Test schlägt noch fehl)
2. Implementieren, bis der Test grün ist
3. Refaktorisieren, Test bleibt grün
4. Nächsten Test schreiben, der wiederum rot ist

Arten von Tests

• Unit Test: Test einer möglichst kleinen Softwareeinheit, typischerweise unabhängig von den anderen, z.B. einer einzelnen Klasse oder Methode. Davon gibt es viele. Test soll möglichst wenige Abhängigkeiten haben, z.B. möglichst nicht auf Datenbank zugreifen
• Integrationstest: Zusammenspiel zwischen den Einheiten bzw. Testen der Schnittstellen. Es gibt weniger Integrationstests als von den Unit Tests.
• Akzeptanztest: Test, der prüft, ob Kundenanforderungen erfüllt sind. Muss nicht funktional sein, sondern kann auch z.B. ein Performancetest sein. Kann auch manuell erfolgen, was aber teuer ist und dann nur stichprobenartig testen sollte.
• Smoketest/Anlauftest: Anfrage gegen die Software bzw. das System werfen und schauen, ob sie abstürzt bzw. nen Fehler wirft.
• UI Test: Test der Anwendbarkeit der Oberfläche: Kommen alle Knopfdrücke richtig in der Business Logic an? - Nicht versuchen, damit alle Funktionalität abzuprüfen.
• Regressionstest: Test, der sicherstellt, dass eine Neuerung keine Funktionalität verliert im Vergleich zur alten Version - sowohl funktional als auch nichtfunktional.
• Mutation Test: Werkzeug, das automatisch Code kaputtmacht, und prüft ob dann auch ein Test fehlschlägt.
• Whitebox-/Blackboxtest: Test, der "weiß", wie einzelne Komponenten implementiert sind, bzw. der das nicht weiß.
• Fuzzy Test/Monkey Test: Zufällige Erzeugung von Input und Test, wie Software reagiert bzw. welche Pfade sie durchläuft.

Was macht einen guten Test aus?

• Fast: Er läuft in kurzer Zeit durch (z.B. Unit Tests: max. 30 Sekunden, Integrationstest: max. 10 Minuten)
• Independent: Er ist unabhängig von anderen Methoden. Schlägt er fehlt, sollte das nicht dazu führen, dass andere auch fehlschlagen.
• Repeatable: Beinhaltet genug Eingangsdaten, um jederzeit alleinstehend wiederholbar zu sein.
• Small: Er ist spezifisch, d.h. nur auf einen Aspekt des Programms bezogen
• Transparent: Es ist aus dem Code/der Doku hinreichend klar, was der Test macht und warum er fehlschlägt, wenn er fehlschlägt.

Vorgehen

• Positiv- und Negativtests
• Vom Einfachen zum Schwierigen gehen
• Äquivalenzklassen bilden und diese gemeinsam testen
• Grenzfälle abdecken

• Arrange: Datenstrukturen initialisieren
• Act: Aktion ausführen
• Assert: Prüfen, ob Ergebnis korrekt ist/den Anforderungen entspricht

Akzeptanztests

"Wann bin ich mit dem Implementieren fertig?"

• Ich bin fertig, wenn der Kunde zufrieden ist und alle seine Anforderungen erfüllt wurden (und er keine weiteren hat).
• Akzeptanztests müssen zeigen, dass bei richtiger Eingabe auf der Schnittstelle zum Benutzer/Kunden das Richtige herauskommt und bei falscher Eingabe eine entsprechende Behandlung erfolgt. Sie sollten unabhängig von der Implementierung sein.
• Formulierungsformen:
  • "Wenn (Ereignis), dann (Effekt), sonst (Effekt)."
  • "Wenn (Voraussetzung) und dann (Ereignis), dann soll (Effekt), sondern (Effekt)."
• Wichtig: Akzeptanztests müssen vollständig sein, sonst kann man sie gleich weglassen.
• Aus Akzeptanztests kann man auch Regressionstests machen, z.B. für den Fall, dass man nach längerer Zeit, in der man sich nicht mit dem Code beschäftigt hat, noch ein Feature hinzufügen will.

Fixture

Bestandteile

• Set Up: Voraussetzungen schaffen, z.B. Datenstrukturen initialisieren
• Exercise: Tests ausführen
• Verify: Ergebnis prüfen
• Tear Down: Ursprungszustand des Systems wiederherstellen, z.B. Seiteneffekte des Tests rückgängig machen

Arten

• Fresh Fixture: Vor jedem Test baut die Fixture die benutzten Daten neu auf
• Shared Fixture: Die Fixture baut die Daten einmal auf und benutzt sie dann für alle Tests.
  • Problem: Tests könnten Daten verändern
  • Ausweg: Shared Mutable Fixture

Stubs

• Beispiel Master Mind: Um eine Spieler-KI dafür zu testen, möchte man nicht gegen das "echte" Master Mind testen, sondern z.B. gegen Stubs
• Stubs: Erbt von der ursprünglichen Klasse, überlagert nur die für den Test interessanten Methoden
  • z.B. reagieren immer gleich, egal was für ein Input kommt
• Dummy: Gibt bei allen Methoden nur einen statischen wert zurück
• Fake: Klasse, die nur so tut, als ob sie z.B. eine Datenbankverbindung aufbaut, aber in Wahrheit Werte stattdessen aus einer Hashtable zieht
• Mock: Implementiert bzw. erweitert ursprüngliche Klasse nicht, sondern benutzt ein Mocking Framework