Dynamische Programmanalysen und Tests

ggf. direkt erkennbar durch statische Tests

• inkorrektes Teilprogramm, inkorrekte Anweisung oder Datendefinition, Ursache für Fehlerwirkung

• Zustand eines Softwareprodukts oder einer seiner Komponenten, der unter spezifischen Bedingungen eine geforderte Funktion beeinträchtigen kann

ggf. direkt erkennbar durch dynamische Tests

• Wirkung eines Fehlerzustandes, die bei der Ausführung des Testobjektes nach „aussen“ in Erscheinung tritt

• Abweichung zwischen spezifiziertem Soll-Wert (Anforderungsdefinition) und beobachtetem Ist-Wert (bzw. Soll- und Ist-Verhalten)

• menschliche Handlung (des Entwicklers), die zu Fehlerzustand in der SW führt

• NICHT einbezogen: menschliche Handlung eines Anwenders, die ein unerwünschtes Ergebnis zur Folge hat

Prüfung, ob SW das vom Anwender „wirklich“ gewünschte Verhalten zeigt

-> Haben wir das richtige SWsystem realisiert?

Prüfung, ob Implementierung der SW vorher (vertraglich) festgelegte Anforderungen erfüllt

-> Haben wir das SWsystem richtig realisiert?

• Berechnungsfehler

• Schnittstellenfehler

• Kontrollflussfehler

• Datenflussfehler

• Zeitfehler

• Redefinitionsfehler

• Funktionalitätstest

• Benutzbarkeitstest

• Performanztest

• Lasttest

• Stresstest

Schnittstelle, über die Testobjekt mit Testdaten versorgt wird

Schnittstelle, über die Reaktionen/Ausgaben des Testobjekts beobachtet werden

die interne Struktur der Komponente wird nicht betrachtet;

getestet wird Ein-/Ausgabeverhalten gegen Spezifikation (informell oder formal);

interne Struktur der Komponente wird zur Testplanung und -Überwachung herangezogen:

• Kontrollflussgraph

• Datenflussgraph

• [Automaten]

Verhalten einer Komponentenversion wird mit Verhalten anderer Versionen verglichen

• Mutationstestverfahren

• N-Versionen-Programmierung

ein Programm wird absichtlich durch Transformationen verändert und damit in aller Regel mit Fehlern versehen

• Einbau von Fehlern lässt sich (mehr oder weniger) automatisieren

• eingebaute Fehler entsprechen oft nicht tatsächlich gemachten Fehlern

• eingebaute Fehler stören Suche nach echten Fehlern

verschiedene Versionen eines Programms werden völlig unabhängig voneinander entwickelt

• sehr aufwändig, da man mehrere Entwicklerteams braucht (und gegebenfalls sogar Hardware mehrfach beschaffen muß)

• Fehler der verschiedenen Teams nicht unabhängig voneinander (z.B. haben alle Versionen dieselben Anforderungsdefinitionsfehlern)

• Identifikation fehlender Testfälle

• Eliminination nutzloser Testfälle

• Schätzung der Restfehlermenge

• Version als Orakel für Korrektheit der Ausgaben anderer Versionen nutzen (ab 2 Versionen)

• Gleichzeitige Berechnung v. Ergebnissen mit mehreren Versionen erhöht Robustheit der SW

• Verwende Mehrheitsentscheidungen, wenn verschiedene Versionen unterschiedliche Ergebnisse liefern (ab 3 Versionen)

• Isolierte prüfung einzelner Softwarebausteine

• Komponente (Unit) z.B. Klasse oder Paket (Modul)

• Subsystemtest kann als Test einer besonders großen Komponente aufgefasst werden

• getestet wird gegen Spezifikation der Schnittstelle der Komponente, dabei betrachtet werden funktionales Verhalten, Robustheit, Effizienz, ...

• Testziel: Berechnungsfehlern, Kontrollflussfehlern, ...

• getestet wird in jedem Fall die Komponente für sich mit

  • Teststummel (Platzhalter, Dummies, Stubs) für benötigte Dienste anderer Komponenten

  • Testtreibern (Driver) für den (automatisierten) Test der Schnittstelle (für Eingabe von Parametern, Ausgabe von Parametern, ... )

• Gesamtes SW-System (oder abgeschlossenes Teilsystem) wird getestet;

• Schwerpunkt liegt auf Test des Zusammenspiels der Einzelkomponenten

• normalerweise wird vorausgesetzt, dass Einzelkomponenten vorab bereits getestet wurden

• Verwendung von Testtreiber (Testwerkzeuge), die zu testende Komponente aufrufen bzw. steuern

• (Meistens) Verzichten auf Teststummel, da alle benötigten Teilsysteme zusammen getestet werde

• Ziel: Schnittstellenfehlern, insb. Fehler beim Austausch von Daten

• “Big Bang”-Strategie

• “Top-down”-Testverfahren

• “Bottom-Up”-Testverfahren

• Ad-Hoc-Integration

• Backbone-Integration (Inkrementelle Vorgehensweise)

• Regressionstest (für inkrementelle Vorgehensweise)

• Nach abgeschlossenem Integrationstest und vor dem Abnahmetest erfolgt der Systemtest beim Softwareentwickler durch Kunden (alpha-Test)

• Variante: Systemtests bei ausgewählten Pilotkunden vor Ort (beta-Test)

• Systemtest überprüft aus der Sicht des Kunden, ob das Gesamtprodukt die an es gestellten Anforderungen erfüllt (nicht mehr aus Sicht des Entwicklers)

• anstelle von Testtreibern und Teststummeln kommen nun soweit möglich immer die realen (Hardware-)Komponenten zum Einsatz

• Systemtest sollte nicht beim Kunden in der Produktionsumgebung stattfinden, sondern in möglichst realitätsnaher Testumgebung durchgeführt werden

• beim Test sollten die tatsächlichen Geschäftsprozesse beim Kunden berücksichtigt werden, in die das getestete System eingebettet wird

• dabei durchgeführt werden: Volumen- bzw. Lasttests (große Datenmengen), Stresstests (Überlastung), Test auf Sicherheit, Stabilität, Robustheit, ..

• Lasttest

• Performanztest

• Kompatibilität

• Benutzungsfreundlichkeit

• Benutzerdokumentation

• Änderbarkeit, Wartbarkeit

• Spezielle Form des Systemtests

• Einbeziehen des Kunde bzw. führt Test durch

• Test findet beim Kunden, aber in Testumgebung statt (Test in Produktionsumgebung zu gefährlich)

• Abnahmetests als Entschiedungsbasis für Kunde, ob bestellte SW-system mangelfrei und vertraglich festgelegte Anforderungen erfüllt sind

• durchgeführte Testfälle sollten bereits im Vertrag mit Kunden spezifiziert sein

• im Rahmen des Abnahmetests wird geprüft, ob System von allen relevanten Anwendergruppen akzeptiert wird

• im Rahmen von sogenannten Feldtests wird darüber hinaus ggf. das System in verschiedenen Produktionsumgebungen getestet

1. Testen zeigt die Anwesenheit von Fehlern (und nie die Abwesenheit)

2. Vollständiges Testen ist nicht möglich

3. Mit dem Testen frühzeitig beginnen

4. Häufung von Fehlern (in bestimmten Programmteilen)

5. Zunehmende Testresistenz (gegen existierende Tests)

6. Testen ist abhängig vom Umfeld

7. Trugschluss: Keine Fehler bedeutet ein brauchbares System

Testen Implementierung gegen ihre Spezifikation und lassen interne Programmstruktur unberücksichtigt:

• Geeignet für Abnahmetest ohne Kenntnis des Quellcodes

• Voraussetzung: vollständige und widerspruchsfreie Spezifikation (zur Auswahl von Testdaten und Interpretation von Testergebnissen)

• Auswahl repräsentative Eingabewerte (man kann nicht alle Eingabekombinationen testen)

• Braucht „Orakel“ für Überprüfung der Korrektheit der Ausgaben

Die Praxis zeigt, dass ca. 80% aller von bestimmten Parameterwertkombinationen ausgelösten Softwarefehler bereits durch Wahl bestimmter Paarkombinationen beobachtet werden können. Also werden beim „paarweisen“ Testen einer Funktion mit n Parametern nicht alle möglichen Kombinationen überprüft, sondern nur alle paarweisen Kombinationen

• Erfahrungsbasierte Testverfahren:

  • Intuitives Testen (Error Guessing)

  • Exploratives Testen

  • Checklistenbasiertes Testen

• Zufallstest

• Smoke-Test:

• Syntax-Test

• Zustandsbezogener Test

• Ursache-Wirkungs-Graph-Analyse / Entscheidungstabellenbasiertes Testen

• Anwendungsfallbasiertes Testen

• all-defs-Kriterium

• all-p-uses-Kriterium

• all-c-uses-Kriterium

• all-p-uses-some-c-uses-Kriterium

• all-c-uses-some-p-uses-Kriterium

• all-uses-Kriterium

Es werden Modelle der zu testenden SW für die Testplanung und ggf. auch -durchführung herangezogen. Dabei kommen vor allem Zustandsautomaten (Statecharts) zum Einsatz.

Es gibt zwei Hauptspielarten des modellbasierten Testens:

1. Testen von ausführbaren Modellen

2. Testen mit (ausführbaren) Modellen

• Tests müssen garantieren, dass alle Zustände mindestens einmal erreicht werden

• Tests müssen garantieren, dass jede Transition mindestens einmal ausgeführt wird

• Tests müssen garantieren, dass jede Transition mit allen sich wesentlich unterscheidenden Belegungen ihrer Bedingung ausgeführt wird

• Tests müssen alle möglichen Pfade durch Statechart (bis zu einer vorgegebenen Länge oder vorgegebenen Anzahl von Zyklen) ausführen

• zusätzlich zum Test aller explizit aufgeführten Transitionen werden für jeden Zustand alle sonst möglichen Ereignisse (Methodenaufrufe) ausgeführt

1. Testvorbereitung

2. Testausführung

   1. white-box-Sicht

   2. black-box-Sicht

3. Testbeendigung

4. Kombination