5. Dynamische QS: Testen

Prüfung aller in der Spezifikation geforderten Funktionen und Eigenschaften zu einem System oder einer Systemkomponente

möglichst große Abdeckung der spezifizierten Funktionen eines Systems

—> nur das nach außen hin sichtbare Verhalten ist relevant

1. Tester liest und interpretiert die Spezifikation.

2. Erstellung anhand Interpretation Testfälle und führt diese aus

3. Beurteilung Testergebnisse anhand Interpretation

Zusammenspiel verschiedener Systemkomponenten

—> Einsatz Integrations-, System- und Abnahmetests

anwendernah

Spezifikation

—> Auf Basis der Spezifikation wird der Grad der Testabdeckung bestimmt; sie wird als Basis für die Erstellung der Testfälle genutzt und anhand der Spezifikation werden die Testergebnisse beurteilt. Daher ist es umso wichtiger, dass bei der Erstellung der Spezifikation sorgfältig darauf geachtet wird, dass in ihr alle tatsächlich von den Stakeholdern benötigten Funktionen und Eigenschaften dokumentiert werden.

möglichst große Ab­deckung der im Programmcode implementierten Anweisungen und Kontrollstrukturen (wie if, while, for, switch),

um dabei möglichst alle implementierten Anweisungen zu testen

1. Teil des Programmcodes implementieren

2. Analyse erzeugte Struktur des Codes analysiert.

3. Auf dieser Basis werden dann Testfälle formuliert (möglichst große Abdeckung)

4. Nach der Ausführung werden die Ergebnisse ausgewertet und bei Bedarf der Programmcode angepasst, bevor erneut getestet wird.

—> selbe Person

begleitend zur Implementierung und bei Komponenten- und Integrationstests

Technik zur Auswahl konkreter Testdaten bei der Testfallerstellung auf der Ebene von Funktionen. Dabei werden alle möglichen Eingabewerte, die zu einer Funktion gemacht werden können (zu gleichem Systemvrhalten führen), in sogenannte Äquivalenzklassen eingeteilt.

Nicht alle Eingabewerte testen, sondern nur jeweils ein beliebig ausgewählter Vertreter aus jeder Äquivalenzklasse

—> weniger Testdaten pro Testfall

Grundsätzlich für alle Tests, in denen Daten übergeben oder Funktionen aufgerufen werden

Beispiele

• Eine oder mehrere Bedingungen, die erfüllt werden müssen

• Festgelegter Wertebereich

• Anzahl von Elementen einer Menge ( Anzahl der Werte)

• Auswahl Elemente einer Menge, die jeweils unterschiedlich behandelt werden

Testdaten müssen nicht disjunkt sein

Äquivalenzklassen für jeden Eingabeparameter der Funktion bzw. jedes GUI-Element der Dialogmaske bestimmt und eindeutig gekennzeichnet.

Testfälle erstellen, mit denen alle gültigen Äquivalenzklassen abgedeckt werden

—> Ziel: möglichst viele Äquvalenzklassen in möglichst vielen Testfälle

Testfälle erstellen, mit denen alle ungültigen Äquivalenzklassen abgedeckt werden

—> Unterschied: pro Testfall nur eine ungültige Äquivalenzklasse

—> einfachere Identifizierung bei Fehlschlag

Erstellen konkreter Eingabedaten auf Basis der ausgewählten Äquivalenzklassen für jeden Testfall

Vorteile

• einfache Technik zur Ermittlung von Testdaten und Testfällen

• Einsatz für jede technische oder fachliche Funktion, die Eingabedaten erwartet

• einfache Erstellung der Testfälle als auch eine intuitive Dokumentation aufgrund Tabellen

Nachteile

• Keine Berücksichtigung fachlicher Abhängigkeiten

• ungeeignet für Komponenten/ Systeme, deren Verhalten von internen Zuständen abhängig ist

Technik zur Auswahl von konkreten Eingabedaten

Beobachtung, dass Softwarefehler häufig in dem Grenzbereich liegen, der den Übergang von gültigen zu ungültigen Eingabewerten darstellt, d. h. an den Grenzen von Äquivalenzklassen

in Kombination mit der Äquivalenzklassenbildung

Bei der Erstellung von Testfällen mit der Grenzwertanalyse werden gezielt gültige und ungültige Werte berücksichtigt, die an den Grenzen von Äquivalenzklassen liegen.

—> Bei der Grenzwertanalyse wird der am dichtesten an der Grenze liegende gültige Wert sowie der am dichtesten an der Grenze liegende ungültige Wert ermittelt und als Eingabewert für die Testfälle verwendet

jeweils ein Vertreter der Äquivalenzklasse im mittleren Wertebereich als Testdaten

—> mehr Testfälle

—> Einsatz verschiedener Grenzwerte, um Menge der Testfälle niedrig zu halten

bei Systemen oder Systemkomponenten eingesetzt, deren Verhalten maßgeblich durch einen internen fachlichen oder technischen Zustand gesteuert

- fachlich: Phasen in Lebenszyklen von Geschäftsobjekten (wie: beantragt, angenommen, abgelehnt) oder Prozessen (wie: eröffnet, Gutachten beauftragt, Schaden bewertet, Schaden reguliert)

- technisch: interne Zustände von Systemkomponenten; Protokollen an technischen Schnittstellen

für White-Box-Tests als auch für Black-Box-Tests eingesetzt

- Prüfung der Erreichung von definierten Zuständen über die dafür vorgesehenen Zustandsübergänge

—>explizit auch die Nicht-Unterstützung von nicht-vorgesehenen Zustandsübergängen durch das System geprüft.

Erstellen einer Zustandsübergangstabelle

Ausfüllen der Tabelle

Fehlerzustände in Tabelle eintragen

Testfälle aus Tabelle ableiten

Vorteile

- leichte Anwendung —> weit verbreitet

- Zustandsübergangstabellen: Testfälle leicht ableiten & Testabdeckung veranschaulichen

Nachteile

• Zustandsübergangstabelle bei zuvielen zu testenden Zuständen schnell unübersichtlich

• fachliche Funktionen, die ihre Zustände nicht ändern werden vergessen

Testdaten, die als Eingabewerte für zu testende Funktionen genutzt werden

Beispiele:

• Test von Benutzeroberflächen mit vielen Eingabeelementen

• für das Testen des Datenaustausches über technische Schnittstellen

Erzeugung zufälliger Werte im Rahemn eines gegebenen Wertebereichs von EIngabeparametern

- Grenzen von Wertebereichen mit der Äquivalenz­klassenbildung ermitteln und die Festlegung der konkreten Eingabewerte über Zufallstestdaten erfolgen

- komplexe Zufallstestdaten auf Grundlage bereits bestehender Testdatensätze

Vorteile:

• generieren vieler verschiedener Testdatensätze mit geringem Aufwand

• durch automatische Erzeugung durch Testdatengenerator können menschliche Fehler ausgeschlossen werden

Nachteile

• keine Erzeugung realistischer Daten

  —> Auwand Prüfung auf Nutzen individuell zu entscheiden

  —> Häufig Ergänzung, nicht als einzige Technik ausreichend