Test

• Testen zeigt die Anwesenheit von Fehlern. Das bedeutet ausreichendes Testen verringert die Wahrscheinlichkeit von Fehlern kann sie aber nie zu 100% ausschließen auch wenn im Test keine Fehlerwirkung nachgewiesen werden kann
• Vollständiges Testen ist nicht möglich → Tests sind immer nur Stichproben. Es ist deshalb wichtig Testaufwand nach Risiko und Prioritäten zu steuern
• Mit dem Testen frühzeitig beginnen durch frühzeitiges Prüfen werden Fehler frühzeitig erkannt
• Häufung von Fehlern meist keine Gleichverteilung von Fehlerzuständen, dort wo Fehlerzustände nachgewiesen werden konnten, sind meist noch mehrere
• Zunehmende Testresistenz - Effektivität nimmt mit zunehmender Wiederholung der selben Tests ab → Testfälle regelmäßig prüfen Testfälle modifizieren
• Testen ist abhängig vom Umfeld
• Trugschluss: Keine Fehler bedeuten ein brauchbares System
• Fehlerwirkungen zu finden und zu beseitigen garantieren noch lange nicht, dass das System den Erwartungen des Nutzers entspricht → Vorstellung von Prototypen

Das Testen erfolgt parallel zum Softwareentwicklungszyklus. In der Abbildung sind die einzelnen Entwicklungsstufen sowie die dazugehörigen Teststufen anhand des V-Modells dargestellt inklusive Rückkopplungspfeilen wie im Wasserfallmodell. Die einzelnen abgebildeten Softwareentwicklungsstufen sollten bekannt sein, auf die Teststufen wird näher eingegangen.

Beim Validieren bewertet der Tester, ob ein (Teil-)Produkt seine festgelegte Aufgabe tatsächlich löst. Beim Verifizieren wird die Korrektheit und Vollständigkeit der einzelnen Entwicklungsphasenergebnisse relativ zu seiner Spezifikation überprüft, d.h unabhängig von Zweck und Nutzen des Produktes.

Prüft, ob jeder einzelne Softwarebaustein für sich die Vorgaben einer Spezifikation erfüllt.

• erstmaliger Test kleinster Softwarebausteine (z.B. Klassen, Units, Module)
• es wird jeweils der einzelne Softwarebaustein isoliert betrachtet
• → Externe Einflüssen sollen vermieden werden dadurch lässt sich Fehlerursache klar der getesteten Komponente zuweisen
• eine Komponente kann aus mehreren Bausteinen bestehen
• Testtreiber ist notwendig: ein Testtreiber ist ein kleines Programm mit dem das Testobjekt aufgerufen wird und anschließend die Reaktion des Testobjektes entgegen nimmt
• es gibt vorgefertigte generische und individuell erstellte Testtreiber die für mehrere Komponententests eingesetzt werden können

Aufgaben für den Tester (hiere wäre am geeignesten der Programmierer selbst)

• Tester muss Komponenten erkennen bzw. bilden
• Testtreiber entwickeln
• Auswahl einer geeigneten Teststrategie

Ziel:

• jeweiliges Testobjekt soll die laut seiner Spezifikation geforderte Funktionalität korrekt und vollständig realisieren
• Robustheit sicherstellen also Reaktion auf mögliche Fehler überprüfen
• Wartbarkeit und Effizienz
• häufigste Fehler: Berechnungsfehler oder fehlende und falsch gewählte Programmpfade

Teststrategien:

• Whitebox-Tests
• nutzen von Debugger
• Testfirst Ansatz

prüft, ob Gruppen von Komponenten wie im technischen Systementwurf vorgesehen zusammenspielen

• Voraussetzung ist Komponententest und Fehlerbehebung der übergebenen Komponenten
• Gruppen dieser Komponenten werden zu größeren Baugruppen bzw. Teilsystemen verbunden
• Zusammenspiel der Einzelteile miteinander wird überprüft
• Testtreiber notwendig → es ist sinnvoll vorhandene Testtreiber der Komponententests wieder zu verwenden

Aufgaben für Tester:

• Entwerfen einer Teststrategie → in welcher Reihenfolge werden die Komponenten zusammengesetzt, damit sie einfach, schnell und effizient durchführbar sind
• Schrittweise zusammenfügen der Komponenten und durchführen des Integrationstests nach jeder Änderung

Ziel:

• Schnittstellenfehler und Datenaustausch- bzw. Kommunikationsfehler erkennen
• mögliche Fehlerauswirkung:
  • eine Komponente übermittelt keine oder falsche Daten
  • Kommunikation funktioniert aber unterschiedliche Interpretation
  • Daten werden richtig aber zum Falschen Zeitpunkt übergebenen
• auch nicht-funktionale Anforderung können falls notwendig getestet werden

Teststrategien:

• abhängig von Systemarchitektur, Projektplan, Testkonzept
• Basisstrategien: Top-down, Bottom-Up, Ad-hoc, Backbone

• prüft, ob System als ganzes die spezifizierten Anforderungen erfüllt
• komplettes Softwaresystem wird aus Perspektive des Kunden und späteren Anwenders betrachtet und gegen dessen Anforderungen validiert

Aufgaben und Ziele:

• ergeben sich aus der Definition

mögliche Problem bei Systemtests:

• unklare Kundenanforderungen
  • unklare / nicht definierte Anforderungen, die beim Kunden jedoch existieren aber nicht nachlesbar sind → Tester muss nachträglich all diese Infos zusammentragen
• versäumte Entscheidungen
  • zu einer Anforderungen existieren verschiedene Ansichten wenn im Projekt versäumte wurde diese schriftlich zu dokumentieren können die Ansichten erst zu diesem späten Zeitpunkt geklärt werden. Dies ist sehr Zeit und Kostenintensiv
• Projekte scheitern
  • Wenn Anforderungen nicht dokumentiert sind fehlen den Entwicklern klare Ziele → führt meist zum scheitern des Projektes

• prüft ob das System aus Kundensicht die vertraglich vereinbarten Leistungsmerkmale aufweist
• Sicht und Urteil des Kunden stehen im Vordergrund
• meist der einzige Test den der Kunde nachvollziehen kann, an dem er direkt beteiligt oder direkt verantwortlich ist
• Kann auch in niedrigeren Teststufen in Form von Prototypen vollzogen werden

Typische Formen:

1. Test auf vertragliche Akzeptanz: Einhaltung vertraglicher Abnahmekriterien wird überprüft
2. Test der Benutzerakzeptanz: wenn Kunde und Nutzer unterschiedlich
3. Akzeptanz durch Systembetreiber: Systemadministrator überprüft wie sich das neue System in die vorhandene IT-Landschaft einfügt
4. Feldtest (Alpha- und Beta-Tests): nur wenn in vielen verschiedenen Produktivumgebungen

• Softwaretest in der Wikipedia
• Qualitätsmerkmale nach ISO/IEC 9126 (DIN 66272)
• Testende Verfahren