Zum Inhalt springen

Kurs:Software-Test/Test-Techniken

Aus Wikiversity


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

[Bearbeiten]

manuelle Anwendung

[Bearbeiten]

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

[Bearbeiten]

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

[Bearbeiten]

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

systematische Test-Techniken

[Bearbeiten]

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

Black-Box

[Bearbeiten]

White-Box

[Bearbeiten]

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

  1. 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)
  2. 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

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

Werkzeuge für die dynamische Analyse

[Bearbeiten]
  • 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

nicht-systematische Test-Techniken

[Bearbeiten]