Black-Box Testing Flashcards
Welche Möglichkeiten gibt es, um zufällige Eingaben für Tests zu generieren?
Es gibt zwei Hauptoptionen zum Generieren von zufälligen Eingaben:
- Auswahl aus einem festen Pool: Hierbei wird für jeden Basistyp ein fester Satz von Werten betrachtet (z.B. JCrasher, Randoop).
- Auswahl aus dem gültigen Eingabebereich: Hierbei wird (gleichmäßig) ein zufälliger Wert ausgewählt. Optional kann der Eingabebereich eines Typs auf einen kleineren Bereich eingeschränkt werden (z.B. QuickCheck).
Wie generiert Randoop Methodenketten und wie kann dieser Ansatz auf ein Beispiel angewendet werden?
Randoop generiert Methodenketten, indem es zunächst mit einer leeren Sequenz beginnt und dann inkrementell Methodensequenzen erstellt, indem es entweder eine zufällig ausgewählte öffentliche Methode oder ausgewählte Eingabeparameter (und Aufrufer) verwendet. Anschließend wird die Methodenkette mit dem Methodenaufruf oder mehrfachen Methodenaufrufen (unter Verwendung der ausgewählten Werte) erweitert. Für ein Beispiel, siehe die Erklärung in der Vorlesung.
Erklären Sie die Idee hinter Basic Fuzzing und Mutational Fuzzing.
Beim Basic Fuzzing wird eine Zeichenkette aus zufälligen Zeichen (Eingabewerten) in ein Programm eingegeben, um die Robustheit und Sicherheit des Systems zu testen. Mutational Fuzzing hingegen versucht, die vielen syntaktisch ungültigen Eingaben, die durch reines Zufalls-Fuzzing entstehen, zu überwinden. Dabei wird mit einem Satz von initialen Eingaben begonnen, die anschließend mutiert werden, d.h. kleine Änderungen an den bestehenden Eingaben vorgenommen werden.
Nennen und erklären Sie Mutationsoperatoren.
Mutationsoperatoren sind Methoden, um kleine Änderungen an bestehenden Eingaben vorzunehmen. Beispiele für Mutationsoperatoren sind:
- Zufälliges Einfügen eines (zufälligen) Zeichens
- Einfügen interessanter Integer-Werte (z.B. 0, 1, INT_MAX, …)
- Einfügen von Zeichenketten aus einem Wörterbuch
- Löschen eines zufälligen Zeichens
- Umdrehen eines Bits in einer Zeichendarstellung
Wie berechnet man Mutationen von Eingaben?
Um Mutationen von Eingaben zu berechnen, wählt man zunächst zufällig (oder in fester Reihenfolge) aus einer Reihe von möglichen Mutationen aus und wendet diese auf die ursprüngliche Eingabe an. Dabei können mehrere Mutationen gleichzeitig oder in einer Sequenz angewendet werden, um eine höhere Eingangsvarietät zu erreichen.
Welche Strategien gibt es für die Auswahl von Anfangs-Seed-Daten und für die Mutation von Seed Daten?
Bei der Auswahl von Anfangs-Seed-Daten gibt es verschiedene Möglichkeiten:
- Benutzergenerierte Daten: Der Benutzer stellt einige gültige Eingabedaten zur Verfügung.
- Dateien, die vom Projekt für Tests und Demonstrationen bereitgestellt werden.
- Suche im Internet oder in anderen Quellen nach Dateien des gewünschten Typs.
- Verwendung einer Standarddatei, die vom Fuzzing-Tool bereitgestellt wird.
Für die Auswahl der Seeds für Mutation gibt es ebenfalls verschiedene Strategien: - Alle generierten Eingaben: Hierbei werden alle generierten Eingaben für Mutationen in Betracht gezogen.
- Relevante Eingaben: Hier werden nur Eingaben berücksichtigt, die neues Verhalten aufdecken (z.B. Ausführung neuer Anweisungen).
- Zufällige Auswahl: Hierbei wird eine zufällige Auswahl der zu mutierenden Eingaben getroffen.
- Priorisierung: Hier werden Eingaben nach bestimmten Kriterien priorisiert, wie z.B. wie oft sie mutiert wurden, ihre Länge, die Ausführungszeit für den Seed, wie viel neues Verhalten sie entdeckt haben, etc.
- Löschen von Eingaben, die irrelevant geworden sind, z.B. wenn sie von anderen Eingaben abgedeckt werden.
Was ist der Zweck von Specification-based Black-Box Testing und wie können Entscheidungstabellen dabei helfen, Testinputs zu generieren?
Der Zweck von Specification-based Black-Box Testing ist es, Testinputs und erwartete Ergebnisse auf der Grundlage der Anforderungsspezifikationen zu generieren. Entscheidungstabellen helfen dabei, Testinputs zu erstellen, indem sie verschiedene Kombinationen von Eingabewerten und erwarteten Ergebnissen auf der Grundlage der Anforderungen darstellen.
Was sind Äquivalenzklassen und Grenzwerte bei der Erstellung von Testinputs, und wie können sie bei der Testabdeckung helfen?
Äquivalenzklassen sind Gruppen von Eingabewerten, die aus Sicht der Testabdeckung ähnliche Eigenschaften aufweisen. Grenzwerte sind Eingabewerte, die nahe an den Grenzen der Äquivalenzklassen liegen. Diese Techniken helfen, die Anzahl der Testfälle zu reduzieren und gleichzeitig eine hohe Testabdeckung sicherzustellen.
Was sind die Hauptunterschiede zwischen Random Testing und Fuzzing, und wie beeinflusst dies ihre Anwendungsgebiete?
Hauptunterschiede zwischen Random Testing und Fuzzing sind die Auswahl der Eingaben und die Testziele. Während Random Testing zufällige Eingaben verwendet, um die Robustheit und die Fehlerfreiheit von Software zu testen, basiert Fuzzing auf der Mutation vorhandener Eingaben oder der Erzeugung von Methodenketten, um potenzielle Fehler oder Schwachstellen aufzudecken. Fuzzing konzentriert sich auf die Untersuchung von sicherheitskritischen Aspekten, wie z.B. dem Auffinden von Pufferüberläufen, während Random Testing eine breitere Anwendung hat und auf die Entdeckung von Fehlern in verschiedenen Bereichen der Software abzielt.
Was ist der Unterschied zwischen Basic Fuzzing und Mutational Fuzzing? Nennen Sie die Vorteile von Mutational Fuzzing gegenüber Basic Fuzzing.
Um Entscheidungstabellen zu erstellen, beginnt man damit, die Bedingungen und Reaktionen für die gegebene Funktion oder Methode zu identifizieren. In einer Entscheidungstabelle werden alle möglichen Kombinationen von Bedingungen aufgeführt, und für jede Kombination wird die erwartete Reaktion angegeben. Mit der Entscheidungstabelle können dann Testfälle abgeleitet werden, die die verschiedenen Kombinationen von Bedingungen abdecken und die erwarteten Reaktionen überprüfen.
Was sind die Hauptziele des Fuzzing und welche Arten von Fehlern oder Sicherheitsproblemen kann es aufdecken?
Randoop verwendet eine Technik namens Method Chaining, um Testeingaben zu generieren. Dabei wird eine zufällige Sequenz von Methoden- und Konstruktoraufrufen erstellt, um Testeingaben zu erzeugen. Die zuvor berechneten Objekte, Werte, Nullwerte und Zufallswerte für Grundtypen werden als Eingaben verwendet. Die Sequenzen werden nur erweitert, wenn sie keine Probleme verursachen. Um die Sequenzen effektiv zu generieren, kann die Sequenzlänge begrenzt werden.
Wie verwendet Randoop Feedback, um die Testgenerierung zu optimieren?
Um die Auswahl der anfänglichen Seeds für Fuzzing-Tests zu optimieren, gibt es verschiedene Strategien:
- Benutzerdefinierte Seeds: Die Tester können spezifische Seeds bereitstellen, die sie für relevant oder interessant halten.
- Projektbezogene Dateien: Dateien, die vom Projekt für Tests, Demonstrationen oder andere Zwecke bereitgestellt werden, können als Seeds verwendet werden.
- Internetrecherche: Man kann das Internet nach Dateien des gewünschten Typs durchsuchen und diese als Seeds verwenden.
- Standarddateien des Fuzzing-Tools: Manche Fuzzing-Tools stellen Standard-Seed-Dateien zur Verfügung, die als Ausgangspunkt dienen können.
Es ist wichtig, die richtige Mischung aus Seeds auszuwählen, um eine gute Abdeckung der Testfälle und eine ausreichende Vielfalt der Testeingaben zu gewährleisten.
What is the difference between black-box and white-box testing?
Bei White-Box-Tests können Sie den Quellcode verwenden, um Tests abzuleiten oder die Angemessenheit der Tests zu beurteilen. Bei Black-Box-Tests können Sie das nicht.
Consider the signature of a sum function long sum(int summand1, int summand2) with the specification “The function returns the sum of two integer arguments.”
Write a JML postcondition to reflect the given specification.
//@ ensures result == summand1 + summand2;
Consider the signature of a sum function long sum(int summand1, int summand2) with the specification “The function returns the sum of two integer arguments.”
Derive equivalence classes for each input parameter and specify one test case for each equivalence class combination.
The equivalence classes for summand1 and summand2 would be negative integers, zero, and positive integers. Test cases for each equivalence class combination would be:
Test case 1: sum(-1, -2) (negative, negative)
Test case 2: sum(-1, 0) (negative, zero)
Test case 3: sum(-1, 2) (negative, positive)
Test case 4: sum(0, -2) (zero, negative)
Test case 5: sum(0, 0) (zero, zero)
Test case 6: sum(0, 2) (zero, positive)
Test case 7: sum(2, -1) (positive, negative)
Test case 8: sum(2, 0) (positive, zero)
Test case 9: sum(2, 2) (positive, positive)
**OR **
summand1: [MIN_INT,MAX_INT]; summand2: [MIN_INT,MAX_INT]; test case: sum(1,2) = 1 + 2
Consider the signature of a sum function long sum(int summand1, int summand2) with the specification “The function returns the sum of two integer arguments.”
Repeat the previous steps for the following altered specification. “The function returns the sum of two non-negative integers.”
a) Write a JML postcondition to reflect the given specification.
b) Derive equivalence classes for each input parameter and specify one test case for each equivalence class combination.
- JML: //@ ensures summand1 >= 0 && summand2 >= 0 => \result == summand1 + summand2
- summand1: [MIN_INT,0[; summand2: [0,MAX_INT]; test cases:
sum(0,1) = 0 + 1
sum(1,-2) = Undefined
sum(-5,4) = Undefined
sum(-6,-7) = Undefined
Depending on the exact policy, a single invalid case may be considered sufficient. That is, only one of the three UNDEFINED cases above would be chosen.
Consider the signature of a sum function long sum(int summand1, int summand2) with the specification “The function returns the sum of two integer arguments.”
What changes if the signature is changed to int sum(int summand1, int summand2)?
Neither the input parameters nor the specification change. Hence, the equivalence partitioning does not change. Hence, no different/additional test cases would need to be defined. Similarly, no JML pre- or post-conditions would change.
Consider the POSIX ceil function from the 2nd exercise session. Identify all equivalence classes and derive one test case for each. Derive additional test cases from a boundary value analysis.
Finding the equivalence classes for numerical parameters can be considered easy. What could typically be relevant equivalence partitionings for the following types:
a) A character string
b) A triangle represented by the length of the sides a, b, and c
c) A pointer to a floating point variable
d) A linked list
- a) Ein Character String kann leer sein oder nicht. Je nach Anwendung können auch andere Äquivalenzklassen sinnvoll sein, z. B. “enthält Nicht-ASCII-Zeichen” oder “nicht druckbare Zeichen”, “ist ein gültiger/ungültiger regulärer Ausdruck”, “ist eine gültige/ungültige URL”, usw. Beachten Sie, dass die Klassen in diesen Beispielen kategorisch sind. Daher kann eine Grenzwert Analyse nicht sinnvoll durchgeführt werden, da die “Grenze” alle Mitglieder der der Äquivalenzklassen umfasst.
- b) Ungültige Dreiecke: eine oder mehrere Seiten haben Null oder negative Werte, eine der Seiten ist länger (oder gleich lang) als die Gesamtlänge der beiden anderen Seiten. Gültige Dreiecke: gleichseitig, gleichschenklig, ungleichschenklig.
- c) Der Pointer könnte auf eine initialisierte Memory Location, auf eine (nicht initialisierte) Malformed Memory Location, auf eine initialisierte Memory Location mit einem Non-Float Datatype oder auf eine eingeschränkte Memory Location zeigen.
- d) Leere Liste, nicht leere Liste, kreisförmige Liste.
These are examples and there may be other relevant/interesting classes.
