Testen:

Testing-Begriff

Software testing is the process of uncovering evidence of defects in software systems
„Software testing is the process of uncovering evidence of defects in software systems.“ (McGregor, 2002)
„Unter Testen versteht man den Prozess des Planens, der Vorbereitung und der Messung, mit dem Ziel, die Eigenschaften eines IT-Systems festzustellen und den Unterschied zwischen dem tatsächlichen und dem erforderlichen Zustand aufzuzeigen (Pol, 2000)

Als Testen bezeichnen wir jede einzelne Ausführung des Testobjekts unter spezifizierten Bedingungen zum Zwecke des Überprüfens der Ergebnis im Hinblick auf gewisse gewünschte Eigenschaften

Testen ist Kontrollfunktion im Software – Entwicklungsprozess, umfasst nicht

Fehlerkorrektur

Durch Testen können Fehlerwirkungen aufgedeckt werden
Debuggen ist die Tätigkeit des Lokalisierens und Behebens eines Fehlerzustands

Gründe für Testing

Kostenreduktion: je später Fehler erkannt, desto teurer Beseitigung
Fehler führen zu Kundenunzufriedenheit
Produkte benötigen bestimmte Qualität
Entdeckte Fehler ermöglichen Analyse und Prozessverbesserung

Testziele

Ziel des Testens ist es, Fehler zu entdecken. Somit ist ein Test erfolgreich, wenn mindestens ein Fehler entdeckt wurde.

Test Orakel:

Um einen Fehler erkennen zu können, benötigt man Soll – Ergebnisse
Darf nicht das Programm sein, dass getestet wird
Idealerweise sollten Test Orakel generiert werden
Typischerweise sind Test Orakel jedoch Menschen
Probleme: Auch Sollvorgaben können Fehler haben
Regel: Weicht Ist – Wert vom Soll – Wert ab, so sollte zuerst geprüft werden, ob der Soll – Wert korrekt ist

Vorsicht: Auch Sollvorgaben können Fehler haben!

Klassifikation von Tests:

Laufversuch: Entwickler übersetzt und startet das Programm, Programm ist irgendwann ausführbar, Ergebnisse sind nicht offensichtlich falsch
Wegwerf – Test: Programm ausgeführt, Daten werden eingegeben, in einigen Fällen

werden Fehler erkannt, Problem: Programm – Änderung, Nachvollziehbarkeit

Systematischer Test: Ableitung von Testfällen aus der Spezifikation, Ausführung des

Programms, Vergleich von Ist – und Sollresultaten, Analyse der Resultate, Dokumentation der Testdaten und Ist – Situation

Fehlerbegriff

Fehler = Abweichung zwischen Ist – Zustand und erwartetem Soll – Zustand
Zwei Abweichungskategorien
- Abweichung zur Spezifikation
- Abweichung zur Erwartung des Kunden (die aus Spez. nicht hervorgeht)

Fehlerkategorien

Wrong: Falsche Umsetzung eines Aspekts der Spezifikation
Missing: Aspekt der Spezifikation nicht umgesetzt
Extra „golden plate“: Aspekt in der Spezifikation nicht beschrieben Prinzipien

Vor- und Nachteile von Tests

Vorteile
- Objektives Prüfverfahren
- Reproduzierbarkeit von Tests
- Systemverhalten wird sichtbar gemacht

Nachteile
- Ergebnisse oft überinterpretiert
- Nicht alle Softwareeigenschaften sind testbar
- Nicht alle Anwendungssituationen sind testbar
- keine Erkennung der Fehlerursachen

Test-Prinzipien

Testen erfordert Unabhängigkeit
- Entwickler sollten ihre Programme nicht selbst testen
- Qualität vs. Termindruck
- …
Vollständiges Testen ist nicht möglich
Vollständiges Testen ist nicht möglich
Tests sind immer nur Stichproben
Mit Testen kann man Fehler nur nachweisen – nicht deren Nichtexistenz
- Mit Testen kann man Fehler nur nachweisen nicht deren Nichtexistenz

beweisen

Teststrategien:

Top down (abstrakteste Komponente zuerst, dann konkretere Komponenten)
Bottom up (atomare Komponenten zuerst, anschließend zusammengesetzte

Komponenten, zum Schluss Gesamtsystem)

Thread (nur für Systeme mit mehreren parallelen Prozessen)
Stress (Das System wird unter Extrembelastung getestet, (z.B. Funktionstest unter 100 % CPU-

Auslastung)

Back – to back: Test von unterschiedlichen Systemversionen sowie Vergleich der Ergebnisse

Testarten:

Modultest (Isoliertes Testen einzelner Module, benötigt zusätzliche Software, kann

schon früh durchgeführt werden, gewährleistet, dass beim Integrationstest die Module korrekt sind

Integrationstest (Testen des Zusammenspiels von Komponenten,testet das Zusammenspiel von Komponenten; stellt sicher, dass die Komponenten zusammenpassen und die gewünschte Funktionalität und Qualität erfüllen wird i.d.R. stufenweise durchgeführt)
Systemtest (Testen der Systemfunktionalität, -benutzbarkeit und –qualität, Integration

mit externen Systemen)

Akzeptanztest (akzeptiert Kunde das System, dabei werden oft

Missverständnisse bzw. in der Spezifikation fehlende Anforderungen aufgedeckt )

Installationstest (Test des Systems in der Umgebung des Kunden, prüft korrekte

Interaktion mit anderen Systemen)

Abnahmetest (beta test):(Endabnahme des Systems vom Kunden, Projekt abgeschlossen, wenn

Test bestanden)

Testtechniken:

Die Unterscheidung in Black-Box-Test und White-Box-Test ist sehr verbreitet, allerdings wird die Metapher verschieden verstanden. Es gibt kein Kriterium, das eine eindeutige, vollständige und schlüssige Einordnung von Testtechniken erlaubt

Gibt es einen Grey-Box-Test?
Forderung nach einem No Box Test!

Spezifikationsbasierter Test (Black – Box – Test)

Ziel: umfassende Prüfung der spezifizierten Funktionalität / Qualität

Motivation: es ist nicht zulässig ein Programm lediglich gegen sich selbst zu

testen

Testfall – Auswahl aufgrund der Spezifikation
Programmstruktur wird nicht betrachtet
Sollwertbestimmung anhand von Spezifikation

Nachteile: konkrete Implementierung wird nicht geeignet berücksichtigt, es

werden häufig nicht die Minimalanforderungen von White – Box – Tests erzielt

Quellcodebasierter Test (White – Box – Test)

- Testfall – Auswahl aufgrund der Quellcodestruktur
- Sollwertbestimmung anhand von Spezifikation
- Testreferenz: Quellcode des Prüfobjekts
- Techniken: Kontrollflussbasiert, Datenflussbasiert
- Vorteil: formale Testauswahlkriterien definierbar, Techniken auch für

anforderungsbasierten Test einsetzbar

- Nachteil: Fehlende (in Spezifikation nicht beschriebene Funktionen) werden

nicht erkannt

Teststrategien:

Top down (abstrakteste Komponente zuerst, dann konkretere Komponenten)
Bottom up (atomare Komponenten zuerst, anschließend zusammengesetzte

Komponenten, zum Schluss Gesamtsystem)

Thread (nur für Systeme mit mehreren parallelen Prozessen)
Stess (Das System wird unter Extrembelastung getestet)
Back – to back: Test von unterschiedlichen Systemversionen sowie Vergleich der

Ergebnisse

Testarten:

Modultest (Isoliertes Testen einzelner Module, benötigt zusätzliche Software, kann

schon früh durchgeführt werden, gewährleistet korrekt funktionierende Module

Integrationstest (Testen des Zusammenspiels von Komponenten, wird i.d.R.

stufenweise durchgeführt)

Systemtest (Testen der Systemfunktionalität, -benutzbarkeit und –qualität, Integration

mit externen Systemen)

Akzeptanztest (akzeptiert Kunde das System, dabei werden fehlende Anforderungen

aufgedeckt)

Installationstest (Test des Systems in der Umgebung des Kunden, prüft korrekte

Interaktion mit anderen Systemen)

Abnahmetest (Endabnahme des Systems vom Kunden, Projekt abgeschlossen, wenn

Test bestanden)

Testtechniken - Einfache Klassifikation

Spezifikationsbasierter Test (Black – Box – Test)

Motivation: es ist nicht zulässig ein Programm lediglich gegen sich selbst zu

testen

Ziel: umfassende Prüfung der spezifizierten Funktionalität / Qualität

Testfall – Auswahl aufgrund der Spezifikation
Programmstruktur wird nicht betrachtet
Sollwertbestimmung anhand von Spezifikation
Motivation: es ist nicht zulässig ein Programm lediglich gegen sich selbst zu

testen

Vorteil: umfassende Prüfung der spezifizierten Funktionalität /

Qualität

Nachteile: konkrete Implementierung wird nicht geeignet berücksichtigt, es

werden häufig nicht die Minimalanforderungen von White – Box – Tests erzielt

Black – Box – Tests:

Fehlerursache wird nicht erkannt

Prinzipien

Unabhängigkeit (Entwickler sollten Programme nicht selbst testen)
Vollständiges Testen nicht möglich (Stichproben, man kann Fehler nachweisen, aber nicht deren Nichtexistenz)
Test ist nur so gut wie die Testfälle (Testfälle müssen für gültige und ungültige Eingaben definiert sein, zu jedem Testfall gehört Soll – Ergebnis, vermeide Wegwerf – Testfälle)

Quellcodebasierter Test (White – Box – Test)

- Testfall – Auswahl aufgrund der Quellcodestruktur
- Sollwertbestimmung anhand von Spezifikation
- Testreferenz: Quellcode des Prüfobjekts
- Techniken: Kontrollflussbasiert, Datenflussbasiert
- Vorteil: formale Testauswahlkriterien definierbar, Techniken auch für

anforderungsbasierten Test einsetzbar

- Nachteil: Fehlende (in Spezifikation nicht beschriebene Funktionen) werden

nicht erkannt

Black – Box – Tests:

Äquivalenzklassenbildung

Repräsentative Menge von Eingabedaten wird durch

Äquivalenzklassenbildung der möglichen Eingaben gebildet

Aus jeder Klasse wird ein Repräsentant ausgewählt
Prinzip
- Zerlegung aller möglichen Eingabedaten in gültige und ungültige

Äquivalenzklassen

- Werte aus einer Äquivalenzklasse verursachen ein identisches

funktionales Verhalten (jede Äquivalenzklasse daher durch einen Repräsentanten getestet Æ Reduktion der Anzahl an Testfällen)

Vorgehen

Definitionsbereich für jede Eingabevariable ermitteln (1)
Gültige und ungültige Klassen bilden (2)
1. Äquivalenzklassen schrittweise weiter verfeinern
Äquivalenzklassen identifizieren (3)
Testfälle für gültige Äquivalenzklassen definieren (4)
Testfälle für ungültige Äquivalenzklassen definieren (5)
Optional: Ausgabeäquivalenzklassen bilden (6)

Anmerkung: gültige Testfälle immer zuerst ableiten, bei ungültigen Testfällen

soll nur eine Variable als ungültig gewählt werden, alle anderen Eingaben gültig, da sonst der Fehler nicht auszumachen wäre

Bemerkungen zur Vorgehensweise

Schritt 3: Äquival Schritt 3: Äquivalenzklassen identifizieren

Jede gültige Äquivalenzklasse wird eindeutig identifiziert (z.B. Zahlen: 1, 2, ..)
Jede dazu gehörende ungültige Äquivalenzklasse wird davon abgeleitet identifiziert (z.B. 1a, 1b, 2a).

Schritt 4: Testfälle für gültige Äquivalenzklassen definieren

Testfälle werden so ausgewählt, dass die Eingaben möglichst viele bisher noch nicht abgedeckte gültige Äquivalenzklassen abdecken enzklassen identifizieren
Jede gültige Äquivalenzklasse wird eindeutig identifiziert (z.B. Zahlen: 1, 2, ..)
Jede dazu gehörende ungültige Äquivalenzklasse wird davon abgeleitet identifiziert (z.B. 1a, 1b, 2a).

Schritt 5: Testfälle für ungültige Äquivalenzklassen definieren

Testfälle werden so ausgewählt, dass diese nur genau eine bisher noch nicht abgedeckte ungültige Äquivalenzklasse abdecken.
Mit der Zuordnung von einem Testfall zu genau einer ungültigen Äquivalenzklasse wird vermieden, dass ein Programm bei der Entdeckung einer fehlerhaften Eingabe weitere fehlerhafte Eingaben

nicht mehr verarbeitet.

Falls mehrere ungültige Äquivalenzklassen mit einem Testfall abgedeckt werden, ist nicht mehr transparent, welches falsche Testdatum die Fehlerbehandlung auslöst.

Beispiel: Bildung einer Äquivalenzklasse am 16-bit Eingabemaske

Spezifikationn:

„Mitarbeiter erhalten ab einer Zugehörigkeit (x) zur Firma von mehr als 3 Jahren 50% des Monatsgehalts als Weihnachtsgratifikation. Mitarbeiter, die länger als fünf Jahre in der Firma tätig sind, erhalten 75%. Bei einer Firmenzugehörigkeit von mehr als 8 Jahren wird eine Gratifikation von 100% gewährt.“ „Zusätzlich wird nach Gehaltsgruppen (g) unterschieden. Für Gehaltgruppe G2 eine Gratifikation von 50% gewährt und für G3 100%. G1 erhält 0%“

Wie sehen die Äquivalenzklassen aus ?

Grenzwertanalyse

An Grenzen zulässiger Datenbereiche treten erfahrungsgemäß häufig Fehler

auf

Testfälle für solche Grenzfälle werden definiert
Problem: Annahme, dass alle Werte innerhalb einer Äquivalenzklasse zum

Auffinden von Fehlern gleich gut geeignet sind ist unrealistisch

Heuristik
- Bei Äquivalenzklassen die Intervalle umfassen wird für jede Grenze

jeweils ein Testfall abgeleitet für

- - Die exakten Grenzwerte
  - Die beiden benachbarten Werte
- Fällt Grenze einer Äquivalenzklasse mit der einer anderen zusammen, so fallen auch die Testfälle zusammen

Ursache – Wirkungs – Graph:

Testreferenz = Ursache-Wirkungs-Graph (UWG)

UWG = kombinatorisches logisches Netzwerk
formale, grafische Sprache zur Beschreibung der logischen Beziehungen zwischen Ursachen und Wirkungen einer Komponente [Spillner, S. 122; Myers, S.55ff.]
- Anwesenheit einer Ursache/Wirkung = 1 – „vorhanden“
- Abwesenheit einer Ursache/Wirkung = 0 – „nicht vorhanden“
UWG wird aus textueller Spezifikation abgeleitet
Testfälle werden aus UWG abgeleitet Testreferenz = Ursache-Wirkungs-Graph (UWG)

Ursache-Wirkungsgraph löst dieses Problem

Problem:

Problem bei Tests auf Basis von Äquivalenzklassen (Äquivalenzklassen betrachten einzelne Eingaben, Wechselwirkungen und Abhängigkeiten daher nicht betrachtet, Anzahl Kombinationsmöglichkeiten sehr hoch)

Lösungsansatz

systematische Auswahl von Eingabekombinationen, Ursache – Wirkungs- Graph
Kombinationen von Eingabedaten, die zur Erzielung einer gewünschten Wirkung erforderlich sind können bestimmt werden

Vorgehensweise bei der Ursache-Wirkungsanalyse

Komplexitätsreduktion
1. Evtl. Zerlegung der Spezifikation in kleinere Teile
Ursachen und Wirkungen der Teilspezifikationen identifizieren
1. Ursache = einzelne Eingangsbedingung
2. Wirkung = Ausgangsbedingung oder Systemtransformation
Kanten ziehen: Ursachen und Wirkungen im Graphen werden auf Grund der Bedeutung der Spezifikation entsprechend verbunden
Graph wird in eine Entscheidungstabelle überführt
Spalten der Entscheidungstabelle werden in Testfälle konvertiert

Die Anzahl der möglichen Kombinationen können reduziert werden, wenn man die boolesche Algebra von ODER und UND zwischen den eingehenden Ursachen und den resultierenden Wirkungen einkalkuliert. Wir gehen dabei rückwärts von den Wirkungen zu den Ursachen, um die Kombinationen zu identifizieren.

Probleme machen dabei maskierte Ursachen. Daher haben wir bei der Identifizierung von Testkombination Regeln einzuhalten.

Als Ergebnis erhält man eine Testreferenz als Referenz für die zu bildenden Testkombinationen.

Regeln gegen maskierte Ursachen

ODER – Verknüpfung mit Ergebnis 1 => Ursachen (1 * 1, alle anderen 0)
ODER – Verknüpfung mit Ergebnis 0 => Ursachen (alle Ursachen 0)
UND – Verknüpfung mit Ergebnis 1 => Ursachen (alle Ursachen 1)
UND – Verknüpfung mit Ergebnis 0 => Ursachen (einer Ursache 0, alle anderen 1)

Vervollständigte Zusammenstellung der UWG Elemente

Identität: Ursache und Wirkung besitzen immer denselben booleschen Wert
Negation: Wirkung tritt auf, falls Ursache nicht vorhanden ist.
ODER Beziehung: Wirkung tritt auf, falls mindestens einer von (mehreren Ursachen) vorhanden ist
UND-Beziehung: Wirkung tritt ein, falls mehrere Ursachen gleichzeitig erfüllt sind
Exklusive Abhängigkeit: höchstens eines kann den Zustand 1 haben
Inklusive Abhängigkeit: mindestens eines muss den Zustand 1 haben
One-and-Only Abhängigkeit: eines und nur eines muss den Zustand 1 haben
Requires-Abhängigkeit: für a = 1 muss b 1 sein
Maskiert-Abhängigkeit: für a = 1 führt b = 0

Aufgabe: zähleZeichen

Die Operation zähleZeichen liest Zeichen von der Tastatur, solange grosse Konsonanten oder grosse Vokale eingegeben werden sowie die Anzahl kleiner ist als der Maximalwert von Integer. Ist ein gelesenes Zeichen ein grosser Konsonant oder Vokal, so wird die Gesamtzahl um 1 inkrementiert. Falls das Zeichen ein grosserr Vokal ist, so wird auch die Vokalzahl um 1 inkrementiert

Legende

U1: Zeichen ist grosser Konsonant
U2: Zeichen ist grosser Vokal
U3: Gesamtzahl ist kleiner als max. Integer
W1: Gesamtzahl wird inkrementiert
W2: Vokalzahl wird inkrementiert
W3: Zeichen wird gelesen
W4: Oprration wird beendet

Wie sieht dazu der Ursache-Wirkungsgraph aus ?

Aufgabe Datei ergänzen: Ursache & Wirkungen finden, Ursache-Wirkungsgraph skizzieren

Das Zeichen in Spalte 1 muß A oder B sein. Das Zeichen in Spalte 2 muß eine Ziffer sein. Unter diesen Umständen wird die Ergänzung einer Datei durchgeführt. Ist das erste Zeichen nicht korrekt, so wird die Meldung X 12 ausgegeben. Ist das zweite Zeichen keine Ziffer, so wird die Meldung X 13 ausgegeben.

Was sind Ursachen und Wirkungen ? Wie sieht der UWG-Graph aus ?

Vorgehensweise zum Ableiten der Entscheidungstabelle

Auswahl einer Wirkung
Durchsuchen des Graphen nach Kombinationen von Ursachen, die den Eintritt der Wirkung hervorrufen, bzw. nicht hervorrufen (erfolgt ausgehend von Wirkung in Richtung Ursachen)
Erzeugung jeweils einer Spalte der Entscheidungstabelle für alle gefundenen Ursachenkombinationen und die verursachten Zustände der übrigen Wirkungen
Eliminieren doppelter Einträge in der Entscheidungstabelle

Aufgabe: Entscheidungstabelle für das Beispiel zähleZeichen generieren

Das Ergebnis für die Entscheidungstabelle beim Beispiel zähle Zeichen ist hier zu sehen. Skizzieren Sie den Lösungsweg und vergleichen Sie dann mit der Musterlösung

Zusatzaufgabe:

Stelle die Entscheidungstabelle für das Beispiel Datei ergänzen auf !

White – Box – Tests

Kontrollflussgraphen

Programm wird als Kontrollflussgraph betrachtet

Kontrollflussgraph: gerichteter Graph G = ( N, E, $n_{start}$ $n_{start}$ , $n_{final}$ $n_{final}$ ) , wobei N die Menge von Knoten , E die Menge der gerichteten Kanten, $n_{start}$ $n_{start}$ der Startknoten und $n_{final}$ $n_{final}$ der Endknoten ist
- Knoten: Anweisungen, wobei ein Knoten mehrere ausgehende und mehrere eingehende Kanten haben kann
- Kanten: Kontrollfluss von einer Anweisung zur nächsten
- Zweig: Kante nach Bedingung
- Pfad: Weg vom Anfangs- bis zum Endknoten

Abb. einfügen von Zusammenfassung S. 26

Bestimmung der Programmpfade: alle Kombinationen aller Programmzweige bei maximalem Durchlauf aller Schleifen (gültiger Pfad führt vom Start- bis zum Endknoten, ein Pfad kann Knoten und Kanten mehrfach durchlaufen, Pfad muss nicht alle Knoten und Kanten enthalten)
Testabdeckung: Ableitung von Testfällen, welche Überdeckungskriterien erfüllen (verschiedene Arten: Anweisungsüberdeckung, Zweigüberdeckung,…)
Anweisungsüberdeckung: Eine Testfallmenge T erfüllt das Testkriterium, wenn es für jede Anweisung A des Programms P einen Testfall gibt, der die Anweisung A ausführt,

Überdeckungsgrad

{\tfrac {ausgef{\ddot {u}}hrte~Anweisungen}{Anzahl~aller~Anweisungen}}

in der Regel werden 60 – 70 % Anweisungsüberdeckung erreicht

Fazit: Fehleridentifizierungsquote 18 % (am schlechtesten), Mindestanforderungen nicht erfüllt, hilft dead – code zu finden

Zweigüberdeckung: Eine Testfallmenge T erfüllt das Testkriterium, wenn es für jede Kante k im Kontrollflussgraphen von P einen Weg in Wege (T, P) gibt, zu dem k gehört, d.h. wenn alle Entscheidungskanten ausgeführt werden,

Überdeckungsgrad

{\tfrac {ausgef{\ddot {u}}hrte~Zweige}{Anzahl~aller~Zweige}}

in der Regel 80% Zweigüberdeckung erreicht

Fazit: gilt als minimales Testkriterium, Schleifen werden nicht zuverlässig getestet, zusammengesetzte Entscheidungen werden nicht zuverlässig getestet
Problem: bereits wenige Testfälle erzielen hohe Überdeckungsrate, mit jedem weiteren Testfall werden nur noch wenige, bisher nicht abgedeckte Zweige durchlaufen, Überdeckungsrate steigt also nur langsam weiter an, was eine falsche Sicherheit bei wenigen Testfällen

vortäuscht

- Abhilfe: Zweige nicht mitzählen, die immer dann ausgeführt werden, wenn auch ein anderer Zweig ausgeführt wird $\rightarrow$ primitive (essentielle) Zweige
Bedingungsüberdeckung: „zuverlässiges“ Testen zusammengesetzter Entscheidungen $\rightarrow$ Analyse der logischen Struktur von Entscheidungen im Programmcode, mehrere Testverfahren:
Einfache Bedingungsüberdeckung: Test aller atomaren Entscheidungen gegen true / false

Tabelle auf der Zusammenfassung ist für wikiversity zu undeutlich, S. 26

Minimale Mehrfach – Bedingungsüberdeckung: neben atomaren Entscheidungen müssen auch Teilentscheidungen und Gesamtentscheidungen gegen true / false geprüft werden

Tabelle auf der Zusammenfassung ist für wikiversity zu undeutlich, S. 27

Mehrfach Bedingungsüberdeckung: Test aller Testfälle aus Tabelle gegen true / false, aber hoher Aufwand

Tabelle auf der Zusammenfassung ist für wikiversity zu undeutlich, S. 27

Allgemeines Problem: Verfahren hängen von Evaluierung der logischen Ausdrücke durch den Compiler ab
- Minimale Termüberdeckung: Jeder atomare Term einer Bedingung bestimmt wenigstens einmal mit Werten TRUE und FALSE das Gesamtergebnis der Bedingung, Beispiel: T1 = T2 AND T3, T2 bestimmt also nur dann den Wert von T1, wenn T3 den Wert TRUE besitzt
- Pfadüberdeckung: alle unterschiedlichen Pfade sollen einmal ausgeführt werden (zwei Pfade sind nur dann identisch, wenn sie exakt die gleiche Abfolge von Knoten beinhalten), d.h. alle Schleifen müssen mit jeder möglichen Anzahl von Durchläufen getestet werden
Probleme:
- Für praktischen Einsatz nur eingeschränkt tauglich $\rightarrow$ Anzahl

der Möglichkeiten kann sehr groß sein, daher extremer Aufwand

- Kontrollflussgraphen beinhalten nicht gesamte Informationen des Programmcodes (Abstraktion!)
- Testfallableitung direkt aus Programmcode $\rightarrow$ evtl. komplex
Eingeschränkte Pfadüberdeckung:
- Nicht alle Pfade durch Schleifen werden berücksichtigt, sondern nur die Pfade die neue Aspekte ansprechen
- Beschränkung auf 5 Aspekte pro Schleife: 0 Iterationen, 1 Iteration, 2 Iterationen, typische Anzahl Iterationen und maximale Anzahl Iterationen

Datenflussbasierte Techniken

Zwei Klassen von Anweisungen: Steuerung des Ablaufs (if, while, …) und Manipulation der Daten, bei datenflussbasierten Tests steht der Zugriff auf die Variablen im Mittelpunkt
Begriffe:
- c – use (lesender Zugriff / computational use) $\rightarrow$ Eingabewert für eine Berechnung wird gelesen: y = a * b
- p – use (lesender Zugriff / predicate use) $\rightarrow$ Ermittlung des Wahrheitswertes einer Entscheidung: ( )

if ( a == b )

- def (Schreibender Zugriff) $\rightarrow$ eine Variable wird definiert: a =10

o Beispiel für Programmflussgraphen:

Beispiel für datenflussattributierten Programmflussgraphen

int doIt(int a, int b) {
  int hilf, res = 0;
  if ( a > b )
    hilf = a - b;
    res = hilf;
  else
    res = b;
  return res;
}

Defs/Uses müssen in der Reihenfolge, in der sie ausgeführt werden, annotiert werden und nicht in der Reihenfolge, in der sie im Programmcode stehen !

Datenflussorientierte Techniken definieren Überdeckungskriterien auf dem

Kontrollflussgraph, die aus Datenflusssicht interessant sind

Verfahren: Defs / Uses – Test, Required k – Tuples Test, Datenkontext –

Überdeckung

Defs / Uses – Test

- globaler c-use x
  - kein def x geht im selben Block einem c-use x voraus
- lokaler c-use x
  - Gegenteil von globalen c-use
- p = ( $n_{i}$ $n_{i}$ ,...; $n_{j}$ $n_{j}$ ) definitionsfrei bzgl. x
  - in keinem Knoten $n_{i}$ ,...; $n_{j}$ ex. def. x
- def x in $n_{i}$ $n_{i}$ erreicht c-use in x in $n_{j}$ $n_{j}$
  - es gibt definitionsfreien Pfad p bzgl. x mit ( $n_{i}$ ) p( $n_{j}$ )
- def x in $n_{i}$ $n_{i}$ erreicht p-use in $n_{j}$ $n_{j}$
  - es gibt definitionsfreien Pfad p( $n_{i}$ ) bzgl. x mit $n_{i}$ p $n_{i}$ , $n_{j}$ )
- globales def x
  - letztes def x in $n_{i}$ und (def x in $n_{i}$ erreicht ein globales c-use x oder def x in $n_{j}$ erreicht ein p-use x)
- lokales def x
  - lokaler c-use x folgt auf def x und zwischen def x und c-use x kein weiteres def x
  - weder lokales noch globales def x $\rightarrow$ Fehler, da Variablenwert nie benutzt wird

DEF $n_{i}$ - Menge der global definierten Variablen des Knoten in $n_{i}$
C-USE $n_{i}$ − Menge der global berechnenden Zugriffe im Knoten in $n_{i}$
P-USE ( $n_{i},n_{j}$ ) − - Menge von Variablen, auf die in der Kante ( $n_{i},n_{j}$ ) prädikativ zugegriffen wird

Menge DCU(x, $n_{i}$ $n_{i}$ )
- Menge aller Knoten $n_{j}$ mit def x in $n_{i}$ erreicht c-use x in $n_{j}$ und x $\in$ C-Use( $n_{j}$ )
Menge DPU(x, $n_{i}$ $n_{i}$ )
- Menge aller Kanten $n_{i}$ , $n_{k}$ mit def x in $n_{i}$ erreicht p-use x in $n_{j}$

Variable	Knoten $n_{i}$	DCU(x, $n_{i}$ )	DPU(x, $n_{i}$ )
a	$n_{i}n$ )	{ $n_{3}$ }	{ $(n_{2},n_{3}),(n_{2},n_{4})$ }
b	$n_{i}n$ )	$(n_{3},n_{4})$	{ $(n_{2},n_{3}),(n_{2},n_{4})$ }
res	$n_{1}$	{}	{}
res	$n_{3}$ $n_{4}$	$n_{out}$ $n_{out}$	{}

All – uses Kriterium: Testfälle müssen für jede Definition aller Variablen alle definitionsfreien Pfade von der Definition zu einem berechnenden oder prädikativen Zugriff auf die Variable enthalten
Formale Beschreibung: Für jeden Knoten $n_{i}$ und jede Variable x $\in$ def( $n_{i}$ muss ein definitionsfreier Pfad bezüglich x von math>n_i</math> zu allem Elemente aus DCU (x, $n_{i}$ )und DPU(x, $n_{i}$ in der Menge der getesteten Pfade enthalten sein

$n_{i}n$ , $n_{1}$ , $n_{2}$ , $n_{3}$ , $n_{out}$

DCU(a, $n_{3}$ )
DCU(b, $n_{3}$ )
DCU( $res_{n3}$ , $n_{out}$ )
DPU(a, ( $n_{2}$ , $n_{3}$ ))
DPU(b, ( $n_{2}$ , $n_{3}$ ))

$n_{i}n$ , $n_{1}$ , $n_{2}$ , $n_{4}$ , $n_{out}$

DCU(b, $n_{4}$ )
DCU( $res_{n4}$ , $n_{out}$ )
DCU( $res_{n3}$ , $n_{out}$ )
DPU(a, ( $n_{2}$ , $n_{4}$ ))
DPU(b, ( $n_{2}$ , $n_{4}$ ))

Variable	Knoten $n_{i}$	DCU (x, $n_{i}$	DPU ( x, $n_{i}$ )
a	$n_{in}$	{ $n_{3}$ }	{( $n_{2}$ , $n_{3}$ ), ( $n_{2}$ , $n_{4}$ )
b	$n_{in}$	({ $n_{3}$ }, { $n_{4}$ })	{( $n_{2}$ , $n_{3}$ ), ( $n_{2}$ , $n_{4}$ )
res	$n_{1}$	{}	{}
res	$n_{3}$ $n_{4}$	{ $n_{out}$ $n_{out}$	{}

Zusammenfassung Quellcode basierte Testverfahren:

Funktionstests beinhalten Methoden zur Testfallableitung aus der Spezifikation
Strukturtests geben Testvollständigkeitskriterien auf der Basis des Programmcodes an

(beinhalten aber i.d.R. keine Methode zur Ableitung von Testeinhaben und erwarteten Ergebnissen)

Kombination der Strukturtests mit Methoden zur Testfallableitung, mögliches Vorgehen:
- Tester definiert nach einer gewählten Methode Testfälle
- Teste führt die Testfälle aus, wobei ein Werkzeug anhand des Quellcodes die Testabdeckung ermittelt

o Tester analysiert die erreichte Testabdeckung und ergänzt bei Bedarf die Testfälle

Strukturtests nur sinnvoll für Modultests und bedingt für Integrationstests

Systematische Testfallermittlung

für Testobjekte mit mittlerem oder hohen Risiko

Äquivalenzklassenanalyse
Entscheidungstabellentest
Grenzwertanalyse

Charakteristika

formalisiert
dokumentiert
vollständig skalierbar

Testmethoden sollen zum Objekt passen

Äquivalenzklassenbildung
Grenzwertanalyse
Entscheidungstabellentest $rightarrow$ Ursache-Wirkungsanalyse
Zustandbezogener Test
Anwendungsfallbasierter Test

Äquivalenzklassenbildung

Zerlegung der Eingabedaten in eine endliche Zahl von Äquivalenzklassen
unter der Annahme: mit jedem beliebigen Repräsentanten der Klasse wird die gleiche Wirkung wie mit jedem anderen Repräsentanten der Klasse erzielt

$\leftarrow$ Reduktion der Anzahl der Testfälle

Zerlegung aller möglichen Eingabedaten in

gültige
und ungültige Äquivalenzklassen

Die Äquivalenzklassen können ausserdem für Ausgabedaten, interne Werte, zeitbezogene Werte (z.B. vor oder nach dem Ereignis) und für Schnittstellenparameter (z.B. Integrationstest gebildet werden.

Äquivalenzklassenanalyse und Grenzwertanalyse haben eine Schwäche

sie können keine Kombinationen von Eingabebedingungen untersuchen

Ursache-Wirkungsanalyse

Kombinationen von Eingaben: Ursache <=> Wirkungen
Jede Ursache wird als Bedingung geschrieben, die aus Eingabedaten besteht und die wahr oder falsch sein kann
schwierige Aufgabe wegen Anzahl der Kombinationen
die Darstellung erfolgt mittels eines Graphen (Ursache-Wirkungsgraph) oder einer Entscheidungstabelle (=> Entscheidungstabellentest)

Vorgehensweise bei der systematischen Testfallermittlung

Analyse Fachkonzept

eingaberelevante Elemente (Dialog- oder Tabellenfenster) bestimmen
Spezifizieren zu prüfender Wirkungen (fachliche Ausgaben bzw. Ergebnisse)
Identifikation der Verarbeitungsregeln (wenn dann, sonst)

Elementklassen, Äquivalenzklassen bilden

vollständige Abdeckung des Eingabebereiches (positive und zum Fehler führende Elementklassen)
keiine Überschneidung
eindeutige fachliche Wirkung

Direkte Wirkung refernzieren

Abhängigkeiten identifizieren

voneinander abhängige Elemente auswählen
Kombinationen bilden
Zusammenfassen von Kombinationen
- gleiche Wirkung UND
- Differenz in nur einer Äquivalenzklasse

Wirkung den Kombinationen zuweisen

Testfälle erstellen

Testfallrümpfe generieren
aus positiven Kombinationen
- Auffüllen mit Kombinationen anderer Abhängigkeiten
- Auffüllen mit positiven Elementklassen
- Auffüllen mit Standartkombinationen

aus fehlerhaften Kombinationen und Elementklassen
- auffüllen mit positiven Elementklassen und Kombinationen

Endekriterien für Testfallbildung prüfen

jede positive Elementklasse in einen Testfallfall
jede positive Elementklasse in eine Kombination
alle Wirkungen abgedeckt
vollständig spezifiziert (Standartkombination)
je zum Fehler führende Kombination ein separater Testfall
je zum Fehler führende Elementklasse ein separater Testfall

Review

Fachlich
Kommentare vollständig