Dynamische Code-Analyse

Dynamische Software-Testverfahren sind bestimmte Prüfmethoden um beim Softwaretest Fehler in Software aufzudecken.

Während bei statischen Verfahren die zu testende Software nicht ausgeführt wird, setzen dynamische Verfahren die Ausführbarkeit der Software voraus. Grundprinzip der dynamischen Verfahren ist die Ausführung der zu testenden Software mit systematisch festgelegten Eingabedaten (Testfälle). Für jeden Testfall werden zu den Eingabedaten auch die erwarteten Ausgabedaten angegeben. Die vom Testlauf erzeugten Ausgabedaten werden mit den jeweils erwarteten Daten verglichen. Bei Abweichungen liegt ein Fehler vor.

Wesentliche Aufgabe der einzelnen Verfahren ist die Bestimmung geeigneter Testfälle für den Test der Software.

Die dynamischen Verfahren lassen sich wie folgt kategorisieren:

Funktionsorientierte Testmethoden

Funktionsorientierte Testmethoden werden zur Bestimmung von Testfällen benutzt, mit denen geprüft werden soll, inwieweit der Prüfling (auch Testling, Testobjekt oder Testgegenstand genannt) die vorgegebenen Spezifikationen erfüllt. Man spricht auch davon, dass „gegen die Spezifikationen“ getestet wird. Je nach Testling und Testart sind die Spezifikationen dabei von unterschiedlicher Art. Beim Modultest wird z. B. gegen die Modulspezifikation getestet, beim Schnittstellentest gegen die Schnittstellenspezifikation und beim Abnahmetest gegen die fachlichen Anforderungen, wie sie etwa in einem Pflichtenheft niedergelegt sind.

Äquivalenzklassenbildung

Bei der Äquivalenzklassenbildung werden die möglichen Werte der Eingaben (oder auch der Ausgaben) in Klassen eingeteilt, von denen vermutet werden kann, dass Fehler, die bei der Verarbeitung eines Wertes aus dieser Klasse auftreten, auch bei allen anderen Vertretern der Klasse auftreten. Wenn andererseits ein Vertreter der Klasse korrekt verarbeitet wird, dann wird vermutet, dass auch die Eingabe aller anderen Elemente der Klasse nicht zu Fehlern führt. Insofern können die Werte einer Klasse als (in dieser Hinsicht) äquivalent zueinander angesehen werden.

Auf Basis der Äquivalenzklassen werden die Testfälle gebildet. Zum Test der gültigen Äquivalenzklassen werden die Testdaten aus möglichst vielen gültigen Äquivalenzklassen gebildet. Zum Test der ungültigen Äquivalenzklassen wird jeweils ein Testdatum aus einer ungültigen Äquivalenzklasse mit ausschließlich gültigen Testdaten aus den übrigen Äquivalenzklassen kombiniert.

Ein Beispiel, um diese recht abstrakte Beschreibung zu verdeutlichen: In der Spezifikation eines Online-Banking-Systems wird gefordert, dass nur Beträge von 0,01 bis 500 € eingegeben werden dürfen. Man kann dann vermuten, dass eine Überweisung in Höhe von 123,45 € akzeptiert und korrekt ausgeführt wird, wenn ein Test ergeben hat, dass eine Überweisung von 123,44 € korrekt durchgeführt wird. Verallgemeinert kann angenommen werden, dass alle Beträge von 0,01€ bis 500,00 € korrekt verarbeitet werden, wenn dies für einen beliebigen Betrag aus diesem Bereich der Fall ist. Es reicht also aus, einen beliebigen Vertreter aus dem Bereich zu testen, um einem möglichen Fehler auf die Spur zu kommen.

In gleicher Weise kann man für negative Werte und für Werte größer als 500 € argumentieren. Für Tests sollte es daher ausreichen, zwei Äquivalenzklassen zu bilden (eine gültige und eine ungültige Äquivalenzklassen):

• Werte von 0,01 bis und mit 500,00 €
• Werte kleiner gleich null oder größer als 500,00 €

Jede Überweisung im Online-Banking-System muss durch die Eingabe einer TAN autorisiert werden. Analog zur ersten Äquivalenzklasse können hier für die Eingabe der TAN zwei Äquivalenzklassen gebildet werden:

• Eingabe einer korrekten TAN
• Eingabe einer falschen TAN

Auf Basis der beiden Äquivalenzklassen werden die nachfolgenden Testfälle definiert:

• Eingabe eines gültigen Werts (z. B. 123,45 €) und Bestätigung mit einer korrekten TAN
• Eingabe eines gültigen Werts (z. B. 123,45 €) und Bestätigung mit einer falschen TAN
• Eingabe eines ungültigen Werts (z. B. 600,00 €) und Bestätigung mit einer korrekten TAN

Grenzwertanalyse

Die Grenzwertanalyse ist ein Spezialfall der Äquivalenzklassenanalyse. Sie ist aus der Beobachtung entstanden, dass Fehler besonders häufig an den „Rändern“ der Äquivalenzklassen auftreten. Daher werden hier nicht beliebige Werte getestet, sondern sog. Randwerte oder Grenzwerte. Im Beispiel wären dies die Werte

• -0,01 € (ungültige Eingabe)
• 0,00 € (ungültige Eingabe)
• 0,01 € (gültige Eingabe)
• 500,00 € (gültige Eingabe)
• 500,01 € (ungültige Eingabe)

Pairwise-Methode

Die Pairwise-Methode ist ein Verfahren, die Anzahl von Tests von Kombinationen mehrerer Eingabewerte zu reduzieren, indem nicht alle möglichen Kombinationen getestet werden. Stattdessen wird lediglich jeder Eingabewert eines Feldes paarweise mit jedem Eingabewert der anderen Felder zusammen getestet. Dies reduziert die Anzahl der nötigen Tests radikal, bedeutet aber natürlich auch, dass unter Umständen Fehler nicht entdeckt werden, die nur bei ganz bestimmten Kombinationen von mehr als zwei Feldern auftreten.

Zustandsbasierte Testmethoden

Zustandsbasierte Testmethoden basieren auf Zustandsautomaten, die heute oft als UML-Diagramm dargestellt werden.

In der Beschreibung des Zustandsautomaten sind üblicherweise keine Fehlerfälle vorgesehen. Diese sind zusätzlich zu spezifizieren, indem zu jeder Kombination „{Ausgangszustand; Ereignis}“ (auch den im Automaten nicht spezifizierten Kombinationen) der Folgezustand und die ausgelösten Aktionen angegeben werden. Diese Kombinationen können dann alle getestet werden. Einsetzbar sind zustandsbasierte Methoden außer in technischen Anwendungen auch beim Test grafischer Benutzeroberflächen und von Klassen, die durch Zustandsautomaten definiert sind.

Um die Vollständigkeit der so ermittelten Testfälle zu prüfen, gibt es verschiedene Kriterien:

• Werden bei den Tests alle Zustände durchlaufen?
• Werden alle Zustandsübergänge durchlaufen?
• Werden alle Ereignisse, die Zustandsübergänge hervorrufen, getestet?

Ursache-Wirkungs-Analyse

Bei dieser Methode werden Ursachen und Wirkungen jeder Teilspezifikation identifiziert. Eine Ursache ist dabei eine einzelne Eingabebedingung oder eine Äquivalenzklasse von Eingabebedingungen; eine Wirkung ist eine Ausgabebedingung oder eine Systemtransformation.

Die Teilspezifikation wird in einen Boole’schen Graphen überführt, der Ursachen und Wirkungen durch logische Verknüpfungen verbindet. Anschließend wird der Graph um Abhängigkeiten auf Grund von syntaktischen Zwängen oder Umgebungsbedingungen ergänzt. Die folgenden Arten von Abhängigkeiten zwischen Ursachen werden dabei unterschieden:

1. Exklusive Abhängigkeit: Die Anwesenheit einer Ursache schließt andere Ursachen aus.
2. Inklusive Beziehung: Mindestens eine von mehreren Ursachen liegt vor (z. B. ist eine Ampel immer grün, gelb oder rot – oder rot und gelb zusammen. Wenn sie funktioniert und eingeschaltet ist).
3. One-and-only-one-Beziehung: Es liegt genau eine von mehreren Ursachen vor (z. B. männlich oder weiblich).
4. Requires-Abhängigkeit: Die Anwesenheit einer Ursache ist Voraussetzung für das Vorhandensein einer anderen (z. B. Alter > 21 und Alter > 18).
5. Maskierungsabhängigkeit: Eine Ursache verhindert, dass eine andere Ursache eintreten kann.

Der so entstandene Graph wird zu einer Entscheidungstabelle umgeformt. Dabei werden bestimmte Regeln angewandt, die aus einer Verknüpfung von n Ursachen n+1 Testfälle generieren (statt 2ⁿ , wie es bei einer vollständigen Entscheidungstabelle der Fall wäre). Dabei entspricht jeder Testfall einer Spalte der Entscheidungstabelle.

Strukturorientierte Testmethoden

Strukturorientierte Testmethoden bestimmen Testfälle auf Basis des Softwarequellcodes (Whiteboxtest).

Software-Module enthalten Daten, die verarbeitet werden, und Kontrollstrukturen, die die Verarbeitung der Daten steuern. Entsprechend unterscheidet man Tests, die auf dem Kontrollfluss basieren, und Tests, die Datenzugriffe als Grundlage haben.

Kontrollflussorientierte Tests beziehen sich auf logische Ausdrücke der Implementierung. Datenflussorientierte Kriterien konzentrieren sich auf den Datenfluss der Implementierung. Genau genommen konzentrieren sie sich auf die Art und Weise in welcher Hinsicht die Werte mit ihren Variablen verbunden sind und wie diese Anweisungen die Durchführung der Implementierung beeinflussen.

Kontrollflussorientierte Tests

Die kontrollflussorientierten Testverfahren orientieren sich am Kontrollflussgraphen des Programms.

Es werden folgende Arten unterschieden:

• Anweisungsüberdeckung (C0)
• Kantenüberdeckung (C1)
• Bedingungsüberdeckung (C2, C3)
• Pfadüberdeckung (C4)

Anweisungsüberdeckungstest (C₀ -Test)

Beim Anweisungsüberdeckungstest werden alle Knoten des Kontrollflussgraphen von mindestens einem Testfall abgedeckt, d.h., jede Anweisung im Quelltext wird mindestens einmal ausgeführt.

Zweigüberdeckungstest (C₁ -Test)

Hier werden die Testfälle so spezifiziert, dass alle Zweige (Kanten) des Kontrollflussgraphen mindestens einmal durchlaufen werden.

Diese Methode hat Nachteile da es oft schwierig ist, alle Programmzweige zu durchlaufen, da bestimmte Betriebssystemzustände oder schwierig zu erzeugende Datenkonstellationen erforderlich sind. Zudem werden Kombinationen von Zweigen und komplexe Bedingungen nicht angemessen berücksichtigt. Schließlich werden Programmschleifen nicht ausreichend getestet, da ein einzelner Durchlauf durch den Schleifenkörper von abweisenden Schleifen und eine einzelne Wiederholung von nicht abweisenden Schleifen für die Zweigüberdeckung ausreichend ist.

Einfacher Bedingungsüberdeckungstest (C₂ -Test)

Hier wird die Struktur der Entscheidungen innerhalb des Testlings für die Testfallermittlung herangezogen. Dabei wird gefordert, die Testfälle so zu bestimmen, dass die Auswertung jeder atomaren Teilentscheidung einmal den Wert wahr und einmal den Wert falsch ergibt.

Dies berücksichtigt jedoch nicht, dass Bedingungen oft aus geschachtelten logischen Verknüpfungen von Teilentscheidungen bestehen. Dadurch werden Fehlersituationen maskiert: Bei „oder“ - Verknüpfungen reicht es, wenn die erste Teilbedingung wahr ist, bei „und“ – Verknüpfungen, wenn die erste Bedingung falsch ist, um den weiteren Kontrollfluss festzulegen. Fehler in den anderen Bedingungsteilen werden nicht erkannt. Daher garantiert der einfache Bedingungsüberdeckungstest nicht einmal eine Zweigüberdeckung.

Mehrfach-Bedingungsüberdeckungstest (C₃-Test)

Der maximale Mehrfach-Überdeckungstest verlangt, dass neben den atomaren Teilentscheidungen und der Gesamtentscheidung auch alle zusammengesetzten Teilentscheidungen gegen wahr und falsch geprüft werden.

Der wesentliche Nachteil ist der extrem hohe Testaufwand: Bei n Teilentscheidungen ergeben sich 2ⁿ Testfälle.

Der modifizierte Bedingungsüberdeckungstest verlangt Testfälle, die demonstrieren, dass jede atomare Teilentscheidung den Wahrheitswert der Gesamtentscheidung unabhängig von den anderen Teilentscheidungen beeinflussen kann (Das wird etwa vom Standard RTCA DO-178B für flugkritische Software gefordert).

Bei n Teilentscheidungen ergeben sich minimal (n+1), maximal 2n Testfälle.

Pfad-Überdeckungstests (C₄ -Test)

Beim Pfadüberdeckungstest werden sämtliche unterschiedlichen Pfade des Testlings in mindestens einem Testfall durchlaufen. In der Regel ist dies allerdings nicht durchführbar, da es sehr häufig unendlich viele Pfade gibt – bedingt durch Schleifen ohne feste Wiederholungszahl. Der Pfadüberdeckungstest hat alleinstehend daher wenig praktische Bedeutung.

Datenflussorientierte Tests

Datenflussorientierte Testmethoden basieren auf dem Datenfluss, also dem Zugriff auf Variablen. Sie sind besonders geeignet für objektorientiert entwickelte Systeme.

Für die datenflussorientierten Tests gibt es unterschiedliche Kriterien, welche im Folgenden beschrieben werden.

All defs-Kriterium

Für jede Definition (all defs) einer Variablen wird eine Berechnung oder Bedingung getestet. Für jeden Knoten und jede Variable muss ein definitionsfreier Pfad zu einem Element getestet werden. Die Fehlererkennungsrate liegt bei diesem Kriterium bei ca. 24%.

All p-uses-Kriterium

Die „p-uses“ dienen zur Bildung von Wahrheitswerten innerhalb eines Prädikates (predicate-uses). Die Fehlererkennungsrate liegt bei diesem Kriterium bei ca. 34%. Es werden insbesondere Kontrollflussfehler erkannt.

All c-uses Kriterium

Unter dem „c-uses-Kriterium“ wird die Berechnung von Werten innerhalb eines Ausdrucks verstanden. Dieses Kriterium deckt ca. 48% aller c-uses-Fehler auf. Es identifiziert insbesondere Berechnungsfehler.

Wegen ihrer Kompliziertheit sind die Techniken zur datenflussorientierten Testfallermittlung nur werkzeuggestützt einsetzbar. Da es aber kaum Werkzeuge gibt, haben sie zur Zeit noch keine praktische Relevanz.

Diversifizierende Testmethoden

Die Gruppe der Diversifizierenden Tests umfasst eine Menge von Testtechniken, die verschiedene Versionen einer Software gegeneinander testen. Es findet kein Vergleich zwischen den Testergebnissen und der Spezifikation, sondern ein Vergleich der Testergebnisse der verschiedenen Versionen statt. Ein Testfall gilt als erfolgreich absolviert, wenn die Ausgaben der unterschiedlichen Versionen identisch sind. Auch wird im Gegensatz zu den Funktionsorientierten und Strukturorientierten Testmethoden kein Vollständigkeitskriterium spezifiziert. Die notwendigen Testdaten werden mittels einer der anderen Techniken, per Zufall oder Aufzeichnung einer Benutzer-Session erstellt.

Die diversifizierenden Tests umgehen die oft aufwändige Beurteilung der Testergebnisse anhand der Spezifikation. Dies birgt natürlich die Gefahr, dass ein Fehler, der in den zu vergleichenden Versionen das gleiche Ergebnis produziert, nicht erkannt wird. Aufgrund des einfachen Vergleichens lassen sich solche Tests sehr gut automatisieren.

Back to Back-Test

Beim Back to Back-Test entstehen verschiedene gegeneinander zu testende Versionen aus der n-Versionen-Programmierung, d. h. die Programmierung verschiedener Versionen einer Software nach der gleichen Spezifikation. Die Unabhängigkeit der Programmierteams ist dabei eine Grundvoraussetzung.

Dieses Verfahren ist sehr teuer und nur bei entsprechend hohen Sicherheits-Anforderungen gerechtfertigt.

Mutationen-Test

Der Mutationen-Test ist keine Testtechnik im engeren Sinne, sondern ein Test der Leistungsfähigkeit anderer Testmethoden, sowie der verwendeten Testfälle. Die verschiedenen Versionen entstehen durch künstliches Einfügen von typischen Fehlern. Es wird dann geprüft, ob die benutzte Testmethode mit den vorhandenen Testdaten diese künstlichen Fehler findet. Wird ein Fehler nicht gefunden, so werden die Testdaten um entsprechende Testfälle erweitert. Diese Technik beruht auf der Annahme, dass ein erfahrener Programmierer meist nur noch "typische" Fehler macht.

Regressionstest

Aufgrund der mehrdeutigen Verwendung des Begriffes ist dem Regressionstest ein eigener Artikel gewidmet.

Weblinks

http://www.pst.informatik.uni-muenchen.de/lehre/WS0405/mse/folien/D2-BlackWhite6p.pdf

Siehe auch

• Softwaretest
• Keyword driven testing
• Testautomatisierung
• Fuzzing