Kurs:Software-Test/Test-Techniken

Hauptseite des Kurses | Der eigentliche Kurs | Treffpunkt der Kursteilnehmer

Einleitung · Geschichte des Testens · Test-Techniken · Test-Prozess · Übungen · Interaktion · Testhilfsmittel · Glossar · Weiterführende Links · Ergebnisse

Eine mögliche Einteilung (eine andere in z.B. Black-Box, White-Box, Grey-Box: siehe hier) der Test-Techniken wäre in: statische und dynamische Techniken.
Bei den statischen Techniken wird die Software auch getestet (genau wie bei den dynamischen Techniken), aber die Software wird dabei nicht ausgeführt. Ziel bei beiden Varianten ist es u.A., Anomalien zu finden (weitere Ziele beim Testen kannst du hier lesen). Man könnte es auch anders formulieren: bei den dynamischen Test-Techniken kann die Software interagieren/reagieren, während bei den statischen Techniken die Software einfach nur wie ein Skelett tot vor uns liegt und wir sie wie ein Pathologe sezieren - äh... - untersuchen können.
Beispiele zu einigen Techniken findet ihr im: Standard for Software Component Testing von BCS SIGIST.

statische Test-Techniken

manuelle Anwendung

Bei den folgenden Test-Techniken steht primär die Analyse- und Denkfähigkeit des Menschen im Vordergrund. Dazu werden verschiedene Arten von Reviews eingesetzt:

automatisierte Anwendung

Für die Werkzeuge der statischen Analyse sollte das Testobjekt eine formale Struktur/Syntax aufweisen (Testobjekt kann also auch etwas anderes sein als der Quelltext). Dann suchen die Werkzeuge nach bestimmten Mustern. Mögliche Werkzeuge sind:
Compiler: prüfen z.B. die Syntax der jeweiligen Programmiersprache oder berechnen Metriken
Analysatoren: das kann z.B. auch ganz einfach "nur" ein Rechtschreibprüfprogramm sein
Modellierungswerkzeuge: diese erstellen z.B. erst ein Modell von der Spezifikation oder vom Quelltext, damit die anderen Werkzeuge zum Einsatz kommen können
und andere Open Source bzw. kommerzielle Werkzeuge (siehe Diskussion)

dynamische Test-Techniken

Im Gegensatz zu den statischen Techniken wird hier nun das Testobjekt zur Ausführung gebracht.

systematische Test-Techniken

Einen Überblick über Black-Box, White-Box und Grey-Box findet ihr in diesem Artikel.

Black-Box

Äquivalenzklassenbildung (engl. equivalence partitioning)
Klassifikationsbaum-Methode (engl. classification tree method)
Grenzwert-Analyse (engl. boundary value analysis)
Bereichsanalysen-Test (engl. domain analysis testing)
Entscheidungstabellen-Test (engl. decision table testing)
Zustandsbezogener Test (engl. state transition test)
Anwendungsfallbezogener Test (engl. uses case test)
Geschäftsprozess-Test (engl. process cycle test)
Paarweises Testen (orthogonale Arrays, Allpairs Algorithmus) (engl. pairwise testing)
Datenzyklus-Test (engl. data cycle test)
Elementarer Vergleichstest (engl. elementary comparison test)
Semantischer Test (engl. semantic test)
Syntaxtest
Zufallstest (engl. random test)
Smoketest

White-Box

Die White-Box-Techniken können gruppiert werden in datenflussbasiert und kontrollflussbasiert.

kontrollflussbasiert (Hier dann noch eine Erklärung zu Sinn und Nutzen von Kontrollflussgraphen und CSDs!)
1. Anweisungsüberdeckungstest (engl. statement coverage test)
2. Zweigüberdeckungstest (engl. branch coverage test)
3. Bedingungs-/Entscheidungsüberdeckungstest (engl. decision condition coverage)
4. einfacher Bedingungsüberdeckungstest (engl. simple condition coverage test)
5. minimaler Mehrfach-Bedingungsüberdeckungstest (engl. modified condition decision coverage oder minimal multicondition coverage test)
6. Mehrfach-Bedingungsüberdeckungstest (engl. multiple condition coverage test)
7. Pfadüberdeckungstest (engl. path coverage test)
datenflussbasiert

Datenflussbasierte Techniken bauen auf kontrollflussbasierten Test-Techniken und erweitern diese noch zusätzlich.

Daten werden in Variablen gespeichert. Diese Variablen haben einen definierten Lebenszyklus:

undefiniert/undeklariert (u): Variable hat weder einen Wert noch einen Speicherplatz

deklariert (d): Variable hat keinen definierten Wert, ihr wurde aber schon Speicher zugewiesen.

initialisiert (i): Zuweisung eines Wertes an eine Variable,

referenziert (r): Lesen/Verwenden des Variablen-Wertes,

Dann kann es es viele Datenfluss-Anomalien geben: z.B. dr, id, ii.

Dies soll anhand eines modifizierten Quellcode-Teilstückes vom Algorithmus BubbleSort verdeutlicht werden:

 4.         temp, swaps : INTEGER;
..
13.                 IF ~(a[i] <= a[i+1]) THEN
14a.                     temp   := a[i];
14b.                     a[i]   := a[i+1]; 
14c.                     a[i+1] := temp;
15.                      INC(swaps);
16.                 END

Nehmen wir an, der Quellcode enthält nun Fehler (Zeile 14a - 14c):

 4.         temp, swaps : INTEGER;
..
13.                 IF ~(a[i] <= a[i+1]) THEN
14a.                                     (* die Zeile 14a ist nun gelöscht                                         *)
14b.                     a[i+1] := temp; (* dr-Anomalie: Variable temp aus Zeile 4 wurde noch gar nicht definiert, *)
                                         (*              wird aber benutzt                                         *)
14c.                     a[i+1] := a[i]; (* ii-Anomalie: es gibt nun zwei a[i+1] Zuweisungen (Zeile 14b + 14c),    *)
                                         (*              was einen stutzig machen sollte.                          *)
15.                      INC(swaps);
16.                 END

Grey-Box

Hier werden die Vorteile von Black Box und White Box kombiniert, um bessere Tests zu designen.
(TODO: Beispiele)

Werkzeuge für die dynamische Analyse

Testausführungswerkzeuge

GUI-Capture und Playback: Zeichnen die Aktionen am Bildschirm in einem Testskript auf. Diese Art von Werkzeugen hat Nachteile wie erheblichen Aufwand bei der Wiederverwendung des Testskriptes.
data driven: Hier besteht der Vorteil darin, dass der gleiche aufgezeichnete Test (=Testskript) mit unterschiedlichen Eingabedaten wiederholt werden kann, die der Benutzer einfach über z.B. Excel hinzufügen kann.
keyword-driven/actionword-driven: Unterschied zu data-driven: jede Zeile der Eingabedaten enthält nun auch ein keyword, welches angibt, was mit den Daten zu tun ist. Man kann sich das so vorstellen, dass das keyword eine Funktion ist, die sagt, was mit den Testdaten zu tun ist.
interaktionsgetrieben: Wurde etwas verändert an den betroffenen Testskripts selbst, so sinkt der Wartungsaufwand, da Änderungen in allen anderen Testskripten mitgezogen werden, die dieses veränderte Testskript benutzen. Hier kann man dann einfach per drag + drop die Textbausteine/Testskripte aus der Datenbank holen.

Komparatoren/Vergleichswerkzeuge
dynamische Analysewerkzeuge
Überdeckungsanalysatoren
Testrahmen
Debugger
und andere