04 [L] Testanalyse und -entwurf

Was getestet werden soll = (Testbedingungen)

Wie soll getestet werden = Testfälle

Sie sind Methoden die bei der

1. Definition von Testbedingungen

2. der Identifizierung von Überdeckungselementen

3. der Identifizierung von Testdaten 

unterstützen, und zwar während der Testanalyse und des Testentwurfs. Eine Kategorie davon sind bspw. Black-Box-Tests.

1. Black-Box

2. White-Box

3. erfahrungsbasiert

1. Black-Box-Testverfahren basieren auf einer Analyse des spezifizierten Verhaltens des Testobjekts ohne Kenntnis der internen Struktur. 

2. Daher werden die Testfälle unabhängig von der Implementierung der Software erstellt.

3. Folglich sind die Testfälle auch dann noch nützlich, wenn sich die Implementierung ändert, das geforderte Verhalten aber gleichbleibt.

4. Sie werden auch spezifikationsbasierte Verfahren genannt.

1. White-Box-Testverfahren basieren auf einer Analyse der internen Struktur und Verarbeitung des Testobjekts.

2. Da die Testfälle vom Entwurf der Software abhängig sind, können sie erst nach dem Entwurf oder der Implementierung des Testobjekts erstellt werden.

3. Man nennt sie auch strukturbasierte Verfahren.

1. Erfahrungsbasierte Testverfahren sind intuitive Verfahren, die das Wissen und die Erfahrung von Testern effektiv für den Entwurf und die Implementierung von Testfällen nutzen.

2. Die Effektivität dieser Verfahren hängt stark von den Kenntnissen des Testers ab.

3. Mit ihnen können Fehlerzustände aufgedeckt werden, die bei Black-Box- und White-Box- Testverfahren möglicherweise übersehen werden. Daher ergänzen sie Black-Box- und White-Box-Testverfahren.

• Äquivalenzklassenbildung

• Grenzwertanalyse

• Entscheidungstabellentest

• Zustandsübergangstest

Äquivalenzklassentests sind ein Black-Box Testverfahren, bei dem der Input-Space in eine Menge von Äquivalenzklassen unterteilt wird.Eine Äquivalenzklasse ist eine Menge von Eingaben, die eine bestimmte Gruppe an Fehlern triggert. Jede Eingabe eine Klasse würde genau die selben Fehler triggern und ist daher äquivalent / gleichwertig zu anderen Mitgliedern.

Äquivalenzklassen können für jeden dem Testobjekt zugehöriges Datenelement ermittelt werden. Bspw:

1. Eingaben

2. Ausgaben

3. Konfigurationen

4. Interne Zustände

1. Sie dürfen sich nicht überschneiden

2. Sie dürfen nicht leer sein

1. Gültige Klassen

   • Bspw. Eingaben, die vom Testobjekt verarbeitet werden sollen

   • oder für die laut Spezifikation eine Verarbeitungsvorschrift vorliegt

2. Ungültige Klassen

   • Bspw. Werte, die vom Testobjekt ignoriert oder abgewiesen werden sollen

   • oder für die laut Spezifikation keine Verarbeitungsvorschrift vorliegt

Die Überdeckungselemente sind die einzelnen Äquivalenzklassen.Die Überdeckung berechnet sich als:  

• (Anzahl ausgeführter Klassen / Anzahl aller Klassen)

(in Prozent).

Die Each-Choice-Überdeckung ist ein Überdeckungskriterium für Äquivalenzklassentests.Sie ist erreicht, wenn jede Äquivalenzklasse von mindestens einem Testfall ausgeführt wurde (das heißt sowohl gültige, als auch ungültige Klassen).

Kombinationen von Äquivalenzklassen (bspw. bei Parametern) wird nicht berücksichtigt.

1. Ungeordnet (bspw. user-definierte Strings)

   • Gültig: Eingaben, die die Anforderungen erfüllen (bspw. bestimmte Zeichen oder Länge)

   • Ungültig: Eingaben, die die Anforduerungen nicht erfüllen

2. Geordnet, offen

   • Eingaben, bei denen es einen Grenzwert gibt, aber nicht 2 (bspw. > X oder < Y, aber nicht beides)

   • Gültig: Ein Klasse innerhalb des Intervals

   • Ungültig: Ein Klasse außerhalb des Intervals

3. Geordnet, geschlossen

   • Eingaben, bei denen es zwei Grenzwerte gibt (>= X und <= Y)

   • Gültig: Ein Wert im Interval

   • Ungültig: Eine Klasse oberhalb und eine Klasse außerhalb des Intervals (also 2)

4. Aufzählung

   • Eingaben, bei denen eine festgelegte Auswahl möglich ist

   • Gültige Klassen: Je eine pro Element mit einzigartigem Verhalten

   • Ungültige Klasse: Ein Element außerhalb der Auswahl

Die Grenzwertanalyse ist ein Testverfahren, welches auf Äquivalenzklassen aufsetzt. Dabei werden Testfälle systematisch aus den Grenzwerten der Äquivalenzklassen anwendbar. Daher ist es nur für geordnete (bspw. numerische) Klassen anwendbar. Man unterscheidet folgende Varianten:

• 2-Wert Grenzwertanalyse

• 3-Wert Grenzwertanalyse

• Einen Testfall für jeden Grenzwert

• Einen Testfall für den angrenzenden Wert des Grenzwerts aus der anderen Äquivalenzklasse

Bspw. x > 10 führt zu den Testfällen

• 10

• 9 

• Einen Testfall für jeden Grenzwert

• Einen Testfall für jeden angrenzenden Wert des Grenzwerts (also einen "pro Seite")

Bspw. x > 10 führt zu den Testfällen

• 10

• 9

• 11

2-Wert = Die identifizierten Grenzwerte3-Wert = Die identifizierten Grenzwerte und deren Nachbarn

Bspw. wenn die spezifizierte Bedingung x <= 10 ist, dann liefert die 2-BVA:

• 10

• 11

Nehmen wir nun an, dass die Bedingung fälschlicherweise als x = 10 implementiert wurde. Dann würde nicht auffallen, dass Werte kleiner als 10 nicht akzeptiert werden, obwohl sie das sollten.Mit einer 3-BVA und den Testfällen 9, 10, 11 wäre es aber erkannt worden.

Vorteile

1. Listet alle Bedingungen und deren Kombinationen auf

2. Deckt Lücken und Widersprüche in den Requirements (Regeln) auf

Nachteile

1. Kann zeitaufwändig sein, da die Anzahl an Regeln exponentiell mit der Anzahl an Bedingungen wächst

1. Entweder einen Wahrheitswert (W = Wahr / Ja, F = Falsch / Nein) oder einen konkreten Wert eintragen.

2. -, falls die Bedingung für die aktuelle Regel irrelevant

3. N/A, falls die Bedingung für die Regel nicht durchführbar oder anwendbar ist.

1. X oder konkrete Aktion, falls eine Aktion eintreffen soll

2. Leer oder "-", falls die Aktion nicht eintreten soll

|Anz. Bed|

Pi |mgl. Werte(Bi)|

i = 1

Er berechnet sich als der Anteil von Spalten, welche durch einen Testfall abgedeckt werden, ausgedrückt in Prozent.

1. Bedingungen aufstellen

2. Tabelle erstellen (nur Bedingungswerte)

3. Aktionen hinzufügen

4. Vereinfachen und Minimieren

1. Nur atomare Bedingungen nutzen

   • Zusammensetzungen splitten

2. Positive Bedinguen aufstellen

3. Merke: Bedingungen können unterschiedlich formal sein

   • Bspw. Summe für Rabatt ist "ausreichend"

   • Oder: Summe >= 1000

1. Alle Kombinationsmöglichkeiten von Bedingungswerten müssen eingetragen werden

2. Aktionen sollten erst mal ignoriert werden

1. Nur atomare Aktionen nutzen

2. "Keine Reaktion" kann auch ein expliziter Wert sein!

Werttypen:

1. X = Aktion erwartet

2. Leer = Aktion nicht erwartet

Vereinfachen: Unrealistische und undurchführbare Regeln entfernenMinimieren:

1. Identifizieren von Regeln, welche die selben Aktionen auslösen

2. Die veränderlichen Bedingungen dieser Tabellen auf "-" setzen.

• Man hat eine Menge von Zuständen, die durch Übergänge verbunden sind

• Ein Übergang wird bei einem Ereignis (Input) ausgelöst, vorausegsetzt eine Wächterbedingung (Guard Condition) ist erfüllt

• Bei einem erfolgreichen Übergang wird eine Aktion (Output) ausgelöst

1. Überdeckung aller Zustände

2. Überdeckung aller gültigen (= definierten) Übergänge

   • Auch bekannt als 0-Switch-Überdeckung

3. Überdeckung aller (inkl. ungültiger = undefinierter) Übergänge

Die Überdeckung wird in Prozent zur jeweiligen Zielmenge angegeben.

Man sollte maximal einen ungültigen Übergang mit einem Testfall prüfen, um Fehlermaskierung zu vermeiden.

Bei unternehmens- und sicherheitskritischer Software.

1. Identifizieren der Zustände

2. Identifizieren der Ereignisse

3. Optional: Erstellen der Zustandstabelle

• In der linkesten Spalte findet man den aktuellen Zustand

• Die Überschriftenzeile gibt ein Ereignis und die Wächterbedingung an

• In den Zellen findet man den zugehörigen Zielzustand, Aktionen und Wächterbedingungen

• Ungültige = Undefinierte Übergänge werden über ein "-" gekennzechnet

Die Tabelle eignet sich besonders zur Identifizierung ungültiger Übergänge.

1. Anweisungsüberdeckung

2. Zweigüberdeckung

Die Überdeckungselemente sind ausführbare Anweisungen.100 % Überdeckung = Alle Anweisungen wurden mit mindestens einem Testfall ausgeführt.Probleme:

1. Stellt nicht sicher, dass die gesamte Entscheidungslogik getestet wurde

2. Findet nicht zwangsläufig Fehler, welche datenabhängig sind (bspw. Division durch 0)

Die Überdeckungselemente sind Zweige im Kontrollflussgraphen.Typen:

1. Bedingungslos = goto, jump

2. Bedingt = If-else

100 % Überdeckung = Alle bedingten und bedingungslosen Zweige wurden durch mindestens einen Testfall ausgeführt.

Dabei eingeschlossen ist eine 100 % Anweisungsüberdeckung (aber nicht umgekehrt).

Das Ausführen eines bestimmten Zweigs wird nicht immer einen Fehlerzustand aufdecken, der dort verborgen ist. Denn das Auslösen der zugehörigen Fehlerwirkung kann vom Pfad abhängen (also den vorherigen Knoten, die genommen wurden).

Wert / Vorteile:

1. Zieht beim Test die gesamte Implementation in Betracht

   • Das hilft bei lückenhafter, veralteter oder vager Spezifikation

2. Kann beim statischen Test verwendet werden

   • Bspw. Dry-Runs oder Reviews von Code der nicht ausführbar ist (Pseudocode oder Kontrollflussdiagramme)

3. Bietet eine objektive Messgröße der Code-Überdeckung (bietet Black-Box nicht)

4. Hilft so neue Tests abzuleiten und Vertrauen in den Code zu erhöhen

Nachteil:

1. Kann Probleme damit haben Anforderungen zu finden, die (aufgrund schwacher Spezifikation) nicht oder nicht richtig umgesetzt wurden.

1. Intuitive Testfallermittlung

2. Exploratives Testen

3. Checklistenbasierter Test

Man designed intuitiv Testfälle, bspw. unter Berücksichtigung:

1. Früheren Verhaltens des Systems

2. Typischen Fehlhandlungen und -zuständen

3. Bekannten Kontext, bspw. der Programmiersprache (z.B. "C")

Daher ist die dieses Verfahren auch als "Error Guessing" bekannt.

1. Input: Korrekte oder Inkorrekte Eingaben wird nicht richtig behandelt

2. Output: Falsches Ergebnis oder Format

3. Randfälle durch Programmlogik nicht abgedeckt

4. Schnittstelle inkorrekt

5. Dateninitialisierung inkorrekt

Das bezeichnet intuitive Testfallermittlung unter Verwendung von Listen, die bekannte Fehlhanldungen, -zustände und -wirkungen beinhalten.Die Liste basiert auf früheren Projekterfahrungen oder Fach- / Allgemeinwissen.

Tests werden direkt entworfen, ausgeführt und bewertet, sodass der Tester auch mehr Wissen über das Testobjekt gewinnt.Im Vergleich zum inutitiven Test folgt es einem formalen Prozess mit Aufgaben, Zielen und Ergebnissen.

Es ist eine Art explorativen Testens mit

1. Definiertem Zeitrahmen

2. Unter Verwendung einer Test-Charta

3. Mit einer Nachbesprechung

4. Welche bspw. Überdeckungselemente identifiziert und ausführt

Das Vorgehen und Ergebnisse werden in Session-Sheets dokumentiert.

Test-Chartas gehören zu sitzungsbasiertem Test (explorativ).

Sie legen folgendes für die Sitzung fest:

1. Testziele

2. Testobjekt

3. Testverfahren

4. Welche Probleme gesucht werden

1. Bei wenig oder unzureichender Dokumentation

2. Bei großem Zeitdruck

3. Als Ergänzung zu formalen Methoden

Wenn der Tester

1. erfahren

2. mit Fachwissen ausgestattet

3. analytisch, neugierig und krativ ist

Beim checklistenbasierten Testen werden einzelne Testbedingungen auf Basis von Checklisteneinträgen geprüft.

Die Einträge sind oft als Frage formuliert. Bspw. "Ist der gesamte Text in Arial?"Die Checklisteneinträge nehmen bspw. Bezug auf

1. GUI

2. Qualitätsmerkmale

3. Sonstige Testbedingungen

Rein prinzipiell bieten Checklisten Richtlinien und somit Konsistenz und Wiederholbarkeit.Durch generische Einträge kann aber auch Spielraum für Variabilität gelassen werden.Sind Einträge zu generisch kann sich das vllt. zu negativ auf die Wiederholbarkeit auswirken. 

1. Neue oder entfernte SUT-Features

2. Programmierer lernen alte Fehler nicht noch mal zu machen

3. Neue Einträge für neu gefundene Fehlerwirkungen mit hohem Schweregrad

1. Checklisten dürfen nicht zu lang sein

2. dürfen keine automatisiert testbaren Elemente beinhalten

3. dürfen nicht zu allgemein sein

4. sollten nichts sein, was eher nach Eingangs- oder Endekriterien klingt

Die Vermeidung von Fehlerzuständen durch Zusammenarbeit und Kommunikation.

Eine User-Story beschreibt ein Feature, das aus User-Sicht relevant ist.Komponenten (3 C's):

1. Karte (Card) = Das Medium, wo die Story festgehalten wird

2. Konversation (Conversation) = Die Beschreibung des Features, also wie das System genutzt werden soll

3. Bestätigung (Confirmation) = Die Abnahmekriterien

Formulierung: Als [Rolle] möchte ich [Feature], sodass [Zweck]. Erfüllt sein muss dabei [Abnahmekriterien].

1. Brainstorming

2. Mind-Mapping

1. Fachlichkeit

2. Entwicklung

3. Test

Man folgt dem INVEST Akronym.

1. Independent = Unabhängig

2. Negotiable = Verhandelbar

3. Valuable = Nützlich

4. Estimable = Schätzbar

5. Small = Klein

6. Testable = Testbar

Abnahmekritierien sind Testbedingungen, damit eine User-Story als korrekt implementiert betrachtet werden kann.

1. Definition des User-Story Umfangs

2. Zur Konsenserreichung zwischen Stakeholdern

3. Um positive und negative Szenarien zu beschreiben

4. Als Basis für Abnahmetests

5. Zur Ermöglichung einer genauen Planung und Schätzung

1. Szenario-Orientiert (Wenn/Dann-Schema = Behaviorial Driven Development)

2. Regelorientiert (Verifizierungsliste, Tabellarische I/O-Zuordnung)

3. Benutzerdefinierte Formate, solange klare und eindeutige Formulierungen

Beispiel Szenario-Orientiert

• Gegeben: Situation

• Wenn: Aktion

• Dann: Ergebnis

Beispiel Regelorientiert

• Stichpunktartige Auflistung an Dingen oder Sachverhalten, die erfüllt werden sollen

Ein Test-First-Ansatz, bei dem Testfälle vor der Implementation einer User-Story erstellt werden und zwar kooperativ zwischen Stakeholdern.

1. Spezifikationsworkshop

   • Analyse und Diskussion von der User-Story und Abnahmekritierien

   • Ggf. Korrektur und Erstellung

2. Erstellung der Testfälle

   • Erst Positivtests

   • Dann Negativtests

   • Dann nicht-funktionale Tests

3. Automatisierung von Testfällen

   • Ggf. werden die Kritierien in einem Format formuliert, das sich für automatisierte Testfallerstellung eignet. Dann werden aus ihnen automatisch Testfälle erzeugt, die als Treiber und ausführbare Spezifikation für die Implementation dienen können.

1. In der Regel in natürlicher Sprache, damit alle Stakeholder sie verstehen

2. Sie sollten Vorbedingungen definieren, sowie

3. Eingaben

4. Nachbedingungen

1. Tests sollen alle Merkmale einer Story abdecken, aber nichts darüber hinaus.

2. Es sollte nicht mehr als einen Testfall für ein Merkmal geben