Testverfahren: Black-Box, White-Box

Testverfahren im Überblick

• Testverfahren unterstützen Tester bei Testanalyse und Testentwurf.
• Ziel ist eine systematische Entwicklung von Testfällen, Definition von Testbedingungen, Identifizierung von Überdeckungselementen und Testdaten.
• Testverfahren werden in Black-Box-, White-Box- und erfahrungsbasierte Verfahren klassifiziert.

Black-Box-Testverfahren

• Basieren auf Analyse des spezifischen Verhaltens des Testobjekts.
• Testfälle werden unabhängig von der Implementierung der Software erstellt.
• Testfälle sind auch bei Änderungen an der Implementierung noch nützlich, solange das Verhalten gleich bleibt.

White-Box-Testverfahren

• Basieren auf Analyse der internen Struktur und Verarbeitung des Testobjekts.
• Testfälle können erst nach Entwurf oder Implementierung erstellt werden, da sie vom Softwareentwurf abhängig sind.

Erfahrungsbasierte Testverfahren

• Nutzen Wissen und Erfahrung von Testern für Entwurf und Implementierung von Testfällen.
• Fehlerzustände können aufgedeckt werden, die bei Black-Box- und White-Box-Tests übersehen werden könnten.
• Die Effektivität ist von den Kenntnissen des Testers abhängig.

Black-Box-Testverfahren

• Zu den üblichen Black-Box-Testverfahren gehören:
  • Äquivalenzklassenbildung
  • Grenzwertanalyse
  • Entscheidungstabellentest
  • Zustandsübergangstest

Äquivalenzklassenbildung

• Daten werden in Äquivalenzklassen unterteilt, wobei angenommen wird, dass alle Elemente einer Klasse gleich verarbeitet werden.
• Wenn ein Testfall einen Wert aus einer Äquivalenzklasse testet und einen Fehler findet, werden auch andere Werte derselben Klasse den Fehler finden.
• Datenelemente des Testobjekts werden in Äquivalenzklassen unterteilt (Eingaben, Ausgaben, Konfigurationselemente, interne Werte, zeitbezogene Werte, Schnittstellenparameter).
• Klassen können zusammenhängend oder einzeln, geordnet oder ungeordnet, endlich oder unendlich sein.
• Klassen dürfen sich nicht überschneiden und müssen nicht-leere Mengen sein.
• Schwierigkeit in der Praxis
• Gültige Klasse: enthält gültige Werte
• Ungültige Klasse: enthält ungültige Werte
• Die Definitionen können je nach Team und/ oder Unternehmen variieren

Überdeckungselemente

• Äquivalenzklassen sind die Überdeckungselemente.
• Eine 100-prozentige Überdeckung erfordert die Ausführung aller Klassen (einschließlich ungültiger) durch die Testfälle, mindestens einmal.
• Mehrere Klassengruppen kommen in vielen Testelementen vor und umfassen mehr als einen Eingabeparameter.
• Each-Choice-Überdeckung: das einfachste Überdeckungskriterium für das Abdecken durch Testfälle mindestens einer Klasse aus jeder Klassengruppe.
• Getrennte Testfälle für ungültige Äquivalenzklassen sind nötig, um Fehlermaskierung zu vermeiden.

Grenzwertanalyse

• Testverfahren zur Überprüfung von Grenzen von Äquivalenzklassen und kann nur für geordnete Klassen verwendet werden.
• Minimum- und Maximumwerte einer Klasse sind ihre Grenzwerte.
• Zwei Elemente derselben Klasse: alle Elemente zwischen ihnen müssen ebenfalls zu dieser Klasse gehören.
• Konzentriert sich auf Grenzwerte, da hier eher Fehlhandlungen passieren.
• Fehlerzustände: implementierte Grenzen an verschobenen oder ausgelassenen Positionen.
• Versionen: 2-Wert-Grenzwertanalyse und 3-Wert-Grenzwertanalyse
• Unterscheidung in Anzahl der Überdeckungselemente pro Grenzwert für 100%ige Überdeckung.

2-Wert-Grenzwertanalyse

• Für jeden Grenzwert gibt es zwei Überdeckungselemente: den Grenzwert und seinen engsten Nachbarn.
• Testfälle müssen alle identifizierten Grenzwerte abdecken, um eine 100-prozentige Überdeckung zu erreichen.
• Die Überdeckung wird durch Zählung der ausgeführten Grenzwerte gemessen.

3-Wert-Grenzwertanalyse

• Drei Überdeckungselemente gibt es für jeden Grenzwert: Den Grenzwert und seine beiden Nachbarn.
• Einige der Überdeckungselemente können keine Grenzwerte sein.
• Testfälle müssen alle identifizierten Grenzwerte und deren Nachbarn abdecken, um für die 3-Wert-Grenzwertanalyse eine 100-prozentige Überdeckung zu erreichen.
• Die Überdeckung wird gemessen, indem die Anzahl der ausgeführten Grenzwerte und ihrer Nachbarn gezählt wird.
• Dies kann Fehlerzustände aufdecken, die bei der 2-Wert-Grenzwertanalyse übersehen wurden.

Entscheidungstabellentest

• Zum Testen der Umsetzung von Anforderungen, die Kombinationen von Bedingungen zu Ergebnissen führen.
• Ein effektives Mittel zur Erfassung komplexer Logik, wie Geschäftsregeln.
• Bedingungen und resultierende Aktionen des Systems werden definiert.
• Zeilen der Tabelle: Diese bilden die Bedingungen und Aktionen.
• Spalte: entspricht einer Entscheidungsregel (eindeutige Kombination von Bedingungen mit zugehörigen Aktionen).
• Eingeschränkte Eingabe: boolesche Werte für alle Bedingungen und Aktionen (außer irrelevante), wahr oder falsch werden in Entscheidungstabellen dargestellt.
• Erweiterter Eingabe: einige/alle Bedingungen und Aktionen können mehrere Werte annehmen (Zahlenbereiche, Äquivalenzklassen, Einzelwerte).

Notation für Bedingungen

• "J" (wahr): Bedingung ist erfüllt
• "N" (falsch): Bedingung ist nicht erfüllt
• "-": Wert der Bedingung ist irrelevant
• "N/A": Bedingung ist nicht durchführbar für die Regel
• "X" (Aktionen): Aktion soll stattfinden
• Leer: Aktion soll nicht eintreten
• Weitere Notationen sind möglich.

Entscheidungstabelle

• Eine vollständige Entscheidungstabelle deckt jede Kombination von Bedingungen ab.
• Tabellenvereinfachung: Löschen von Spalten mit undurchführbaren Kombinationen und Zusammenfassen von Spalten, in denen Bedingungen irrelevant sind.
• Überdeckungselemente: Spalten, die ausführbare Kombinationen von Bedingungen enthalten.
• 100-prozentige Überdeckung: Testfälle müssen alle diese Spalten ausführen.
• Vereinfachte/risikobasierte Entscheidungstabelle, um Anzahl der auszuführenden Regeln zu reduzieren.

Zustandsübergangstest

• Modelliert das Verhalten eines Systems durch seine Zustände und Übergänge.
• Ein Übergang wird durch ein Ereignis mit einer Wächterbedingung ausgelöst.
• Syntax: "Ereignis [Wächterbedingung] / Aktion"; Wächterbedingungen und Aktionen sind optional.
• Zustandstabelle: Modell, entsprechende Zustandsdiagramme.
• Zeilen Zustandstabellen stellen Zustände dar, Spalten (Ereignisse mit optionalen Wächterbedingungen).
• Einträge (Zellen) stellen Übergänge dar und enthalten Zielzustand sowie Aktionen, ungültige Übergänge werden durch leere Zellen dargestellt.
• Testfall: Folge von Ereignissen, die zu Zustandsänderungen und Aktionen führt.

Überdeckungskriterien für Zustandsübergangstests

• Viele Überdeckungskriterien existieren.
• Überdeckung aller Zustände: Überdeckungselemente sind die Zustände; Testfälle müssen alle Zustände ausführen (100%ige Überdeckung).
• Überdeckung der gültigen Übergänge (0-Switch-Überdeckung): Überdeckungselemente sind einzelne gültige Übergänge, die von Testfällen ausgeführt werden müssen, um eine 100%ige Überdeckung zu erreichen.
• Überdeckung aller Übergänge: Testfälle müssen alle gültigen und ungültigen Übergänge ausführen oder auszuführen versuchen (100%ige Überdeckung).
• Das Testen von nur einem ungültigen Übergang kann Fehlermaskierung verhindern.
• 100% vollständige Abdeckung ist der Idealfall

Testmethoden

• Die Überdeckung aller Zustände ist schwächer als die Überdeckung aller gültigen Übergänge.
• Die Überdeckung der gültigen Übergänge ist das am häufigsten verwendete Überdeckungskriterium.
• Eine vollständige Überdeckung aller gültigen Übergänge garantiert eine vollständige Überdeckung aller Zustände.
• Das Erreichen der vollständigen Überdeckung aller Übergänge sollte Mindestanforderung für essenzielle Software sein.

White-Box-Testverfahren

• Beschränkt sich auf zwei codebezogene Testverfahren: Anweisungstest und Zweigtest
• Gründlichere Verfahren für sicherheitskritische Umgebungen; White-Box-Testverfahren in höheren Teststufen (z.B. API-Test) oder Overlays, die sich nicht auf den Code beziehen

Anweisungstest und Anweisungsüberdeckung

• Überdeckungselemente: ausführbare Anweisungen.
• Ziel: Testfälle, um Anweisungen im Code auszuführen, bis akzeptable Anweisungsüberdeckung.
• Die Anweisungsabdeckung von 100 % stellt sicher, dass alle ausführbaren Anweisungen im Code mindestens einmal ausgeführt wurden.
• Fehlerzustände können durch das Ausführen einer Anweisung mit einem Testfall entdeckt werden
• Fehlerzustände werden nicht in allen Fällen aufgedeckt.
• Datenabhängige Fehlerzustände werden beispielsweise nicht erkannt.
• Es ist nicht garantiert, dass die gesamte Entscheidungslogik getestet wurde.

Zweigtest und Zweigüberdeckung

• Zweig: Kontrollübergang zwischen zwei Knoten im Kontrollflussgraph (Sequenzen von Quellcodeanweisungen im Testobjekt).
• Kontrollübergang entweder bedingungslos (geradliniger Code) oder bedingt (Entscheidungsergebnis).
• Beim Zweigtest sind die Überdeckungselemente Zweige.
• Ziel: Entwurf von Testfällen, die die Zweige im Code abdecken, bis Akzeptanzgrad erreicht ist.
• Die Zweigüberdeckung von 100 % bedeutet ein Ausführen aller Zweige des Codes.

Zweigtest

• Das Ausführen eines Zweigs mit einem Testfall bedeutet nicht zwangsläufig, dass Fehler gefunden werden.
• Bedingte Verzweigungen entsprechen typischerweise dem Ergebnis einer If-Then-Entscheidung.
• Die Zweigüberdeckung beinhaltet die Anweisungsüberdeckung.
• Die Zweigüberdeckung von 100 % beinhaltet nämlich auch eine Anweisungsüberdeckung von 100 %.

White-Box-Tests

• Eine Stärke des White-Box-Tests ist die Berücksichtigung der gesamten Softwareimplementierung beim Testen.
• Hilfreich für das Auffinden von Fehlern, auch wenn die Softwarespezifikation unvollständig oder veraltet ist.
• Ein Nachteil: Mögliche Nicht-Erkennung bestimmter Fehlerzustände falls Software Anforderungen nicht erfüllt
• White-Box-Testverfahren können beim statischen Testen und beim Review von Code eingesetzt werden.
• Sie bieten eine objektive Messgröße der Überdeckung.
• Zusätzliche Tests sind nötig um die Überdeckung zu erhöhen und das Vertrauen zu stärken.

Erfahrungsbasierte Testverfahren

• Übliche erfahrungsbasierte Testverfahren sind:
  • Intuitive Testfallermittlung
  • Explorativer Test
  • Checklistenbasierter Test

Intuitive Testfallermittlung

• Vorhersage des Auftretens von Fehlhandlungen, Fehlerzuständen und resultierenden Fehlerwirkungen basierend auf Wissen des Testers.
• Testen auf Basis von Erfahrung

Fehlerangriffe

• Ein Möglichkeit der intuitiven Testfallermittlung.
• Erstellung/Übernahme einer Liste von Fehlern, Zuständen und Fehlerwirkungen und Entwurf von Testfällen zur Identifizierung von Zuständen.

Explorativer Test

• Gleichzeitiges Entwerfen, Ausführen und Bewerten von Tests während des Lernens des Testobjekts.
• Zusätzlich sind auch weitere, speziellere Tests für ungetestete Bereiche erforderlich.
• Sitzungsbasiertes Vorgehen für mehr Strukturierung, die eine Nachbesprechung beinhaltet.
• Ein Test-Charta um das Testen zu steuern die eine abstrakte Testbedingung als Testziel hat.
• Der Tester kann Testsitzungsblätter (engl. session sheets) verwenden, um die durchgeführten Schritte und die gemachten Erkenntnisse zu dokumentieren.

Explorative Tests

• Dies ist sinnvoll, wenn die Spezifikationen rar oder die Zeit zu kurz ist.
• Ergänzung zu anderen, eher formalen Verfahren.
• Die besten Resultate erzielen Tester mit Kompetenzen und Erfahrung.
• Explorative Tests können auch andere Testverfahren nutzen (z. B. Äquivalenzklassenbildung).

Checklistenbasierter Test

• Entwicklung für die aus einer Checkliste abgeleiteten Teste.
• Checklisten stammen aus Wissen über Softwarefehler, Erfahrungen, Anforderungen für den Benutzer.
• Checklisten sollten keine automatischen Elemente, Eingangskriterien, Endekriterien oder zu allgemeine Elemente haben.
• Die Elemente der Checkliste sind häufig in Form von Fragen formuliert.
• Direkte und einzelne Prüfbarkeit.

Checklisten

• Beziehen sich auf Anforderungen, Eigenschaften grafischer Oberflächen, Qualitätsmerkmale oder andere Testbedingungen.
• Sie können zur Untersützung verschiedener Testarten erstellt werden.
• Regelmässige Aktualisierung ratsam.
• Sie sollten nicht zu lang werden.
• Richtlinien und Konsistenz durch Testen, jedoch uneinheitlich da ein gewisse Variabilität existiert.

Auf Zusammenarbeit basierende Testansätze

• Die Konzentrierung liegt auf der Vermeidung, der Zusammenarbeit und der Kommunikation mit den Anwendern.

Gemeinsames Schreiben von User-Storys

• Beschreibt die wesentliche Funktion des Systems und der Software für den Nutzer.
• User-Storys haben drei kritische Aspekte (Jeffries 2000), die zusammen die "3 Cs" genannt werden:
  • Karte (Card) – das Medium, das eine User-Story beschreibt (z. B. eine Karteikarte, ein Eintrag auf einem elektronischen Board)
  • Konversation (Conversation) – erklärt, wie die Software genutzt werden soll (kann dokumentiert oder mündlich erfolgen)
  • Bestätigung (Confirmation) – die Akzeptanzkriterien

User Story Format

• Gängigstes Format ist:"Als [Rolle] möchte ich, dass [das zu erreichende Ziel], so dass ich [resultierender Nutzen für die Rolle]", gefolgt von den Akzeptanzkriterien.
• Techniken für die Erstellung der User-Story:Brainstorming und Mind-Mapping
• Drei Perspektiven werden berücksicht, um eine gemeinsame Verständigung zu erreichen: Entwicklung,Fachlichkeit und Testen
• Gute User-Storys sollten unabhängig (independent), verhandelbar (negotiable), nützlich (valuable), schätzbar (estimable), klein (small) und testbar (testable) sein
• Wenn ein Stakeholder nicht weiß, wie er eine User-Story testen soll, dann ist sie nicht ganz verständlich.

Akzeptanzkriterien

• Erfüllte Bedingungen, die eine Implementierung braucht, um von Stakeholdern akzeptiert zu werden.
• Testbedingungen, die durch die Tests erfüllt sein müssen.
• Ergebnis der Diskussion und verwendet, um definiert zu definieren, einen Konsens zu schaffen sowie positive/negative Szenarios bzw. Abnahmetests zu erstellen.
• Klare Planung und Schätzung mit Akzeptanzkriterien

Formulierung der Akzeptanzkriterien (2 gängige Formate)

• Szenarioorientiert (z. B. das Gegeben/Wenn/Dann)
• Regelorientiert
• Benutzerdefinieres Format ist auch möglich solange es eindeutig ist.

Abnahmetestgetriebene Entwicklung (ATDD)

• Test-First-Ansatz: Testfälle werden vor der Implementierung der User-Story erstellt.
• Die Testfälle können manuell oder automatisiert ausgeführt werden.
• In einem Workshop werden User-Story und Akzeptanzkriterien von Teammitgliedern diskutiert und analysiert.
• Der nächste Schritt ist die Erstellung von Testfällen, die auf den Akzeptanzkriterien beruhen und als Beispiele für die Funktionsweise der Software dienen können.
• Beim Testentwurf können auch andere Testverfahren angewandt werden.
• In der Regel sind die ersten Testfälle positiv, um das korrekte Verhalten ohne Ausnahmen oder Fehlerbedingungen zu bestätigen.
• Schliesslich werden auch qualitative/ negative Testfälle durchgeführt.
• In natürlicher Sprache mit den notwendigen Vor-/Nachbedingungen formuliert.

Testfälle

• Die Testfälle müssen alle Merkmale der User-Story abdecken, sollten jedoch nicht darüber hinausgehen und keinesfalls gleiche beschreiben.
• Falls das Testautomatisierungs-Framework ein bestimmtes Format unterstützt, können die Entwickler die Testfälle automatisieren und umsetzen.
• Die Abnahmetests werden dann zu ausführbaren Anforderungen aus den resultierenden Abnahmetests.