Testen Übersicht

1. TestenÜbersicht Inhalt: • Testkonzept/-plan • Testarten, -stufen und -phasen • Testmethoden für black box testing • Testmethoden für white box testing • Kontrollflussbasiert • Datenflussbasiert • Testszenarien und Testfälle • Unittest • Integrationstest • Testabschlusskriterien • Fehlermanagement Datei: TestenVorlesung.ppt

2. TestenTestkonzept/-plan • Im Testkonzept (häufig auch bezeichnet als Testplan) werden zuerst die geplanten Testarten (auch bezeichnet als Teststufen bzw. Testphasen) festgelegt (s. nächste Seite). • Dabei wird für jede Testart folgendes festgelegt: • Ziel • Zuständigkeit (für Koordination, Durchführung und Abnahme) • Zeitraum der Durchführung • Testmethode • Aufwandsabschätzung • Testumgebung (incl. Tool): • Treiber für benötigte Testdaten • Treiber für erforderliche Aufrufmodule • Simulation der aufgerufenen Module

3. TestenTestarten/-phasen/-stufen

4. TestenTestmethoden Black Box Testing (funktionsorientiertes Testen) • Spezifikation des Testobjekts als Ausgangspunkt der Testdatenermittlung • Testdaten werden in Klassen eingeteilt, bei jedem Repräsentant einer Klasse verhält sich das Testobjekt gleich • Qualität der Testdaten hängt ab von der Aussagekraft der Spezifikation • Es kann nicht ermittelt werden, ob das Programm mehr tut als es soll (Computerkriminalität) White Box Testing (strukturorientiertes Testen) • Programmtext als Ausgangspunkt der Testdatenermittlung • möglichst viele Programmabläufe werden ausgeführt • unterschiedliche Überdeckungen werden angestrebt (C0, C1, …) • Programme können getestet werden, für die keine Spezifikation vorliegt • vergessene Teile der Spezifikation können nicht gefunden werden • es ist nicht erkennbar, ob die getesteten Anweisungen im Betrieb überhaupt ausgeführt werden

5. TestenBlack Box Testing: Testziele Mögliche Testziele (einzeln oder in Kombination): • Funktionsüberdeckung: jede spezifizierte Funktion mindestens einmal aktiviert • Ausgabeüberdeckung: jede spezifizierte Ausgabe mindestens einmal erzeugt • Ausnahmeüberdeckung: jede spezifizierte Ausnahme- bzw. Fehlersituation mindestens einmal erzeugt • Attributüberdeckung: alle geforderten Attribute (soweit technisch möglich) getestet • insbesondere Erreichung der spezifizierten Leistungsanforderungen • unter normalen Bedingungen • unter möglichst ungünstigen Bedingungen (Belastungstest)

6. TestenBlack Box Testing: Verfahren Problem der Testfall-Auswahl: die gewählten Testziele mit möglichst wenig und möglichst guten Testfällen umsetzen Klassische Techniken: • Äquivalenzklassenbildung: Gleichartige Eingabedaten werden zu Klassen zusammengefasst und aus jeder Klasse wird ein Repräsentant getestet • Grenzwertanalyse: An den Grenzen zulässiger Datenbereiche treten erfahrungsgemäß häufig Fehler auf; Testfälle für solche Grenzfälle auswählen • Ursache-Wirkungsgraphen: systematischen Bestimmung von Eingabedaten, die ein gewünschtes Ergebnis bewirken • Statistisches Testen (random testing): Eingabedaten werden zufällig ausgewählt; die gezielte Testfall-Auswahl wird durch eine große Zahl von Testfällen ersetzt; Problem: Auswahl der Eingabedaten muss der tatsächlichen Verteilung der Eingabedaten im produktiven Betrieb der Software entsprechen • Fehler raten (error guessing): Intuitive Testfallauswahl aufgrund von Erfahrung; ergänzt andere Methoden zur Testfallbestimmung; Qualität stark von Erfahrung und Intuition der Tester abhängig

7. TestenBlack Box Testing: Übung Gegeben sei ein Programm, das folgende Spezifikation erfüllen soll: Das Programm fordert zur Eingabe von drei nicht negativen reellen Zahlen auf und liest die eingegebenen Werte; es interpretiert die eingegebenen Zahlen als Strecken a, b und c und untersucht, ob die drei Strecken ein Dreieck bilden, und klassifiziert gültige Dreiecke. Das Programm liefert folgende Ausgaben: • kein Dreieck wenn a+b <= c oder a+c <= b oder b+c <= a • gleichseitiges Dreieck, wenn a=b=c • gleichschenkliges Dreieck, wenn a=b oder b=c oder a=c • unregelmäßiges Dreieck sonst Das Programm zeichnet ferner alle gültigen Dreiecke winkeltreu und skaliert in einem Fenster der Größe 10x14 cm auf maximal darstellbare Größe. Die Seite c liegt unten parallel zur Horizontalen. Alle Eckpunkte haben einen Minimalabstand von 0,5 cm vom Fensterrand. Das Programm liefert eine Fehlermeldung, wenn andere Daten als drei nicht negative reelle Zahlen eingegeben werden. Anschließend wird mit einer neuen Eingabeaufforderung versucht, gültige Werte einzulesen.

8. TestenBlack Box Testing: Übung Welche 4 Funktionen sind bei einer vollständigen Funktionsüberdeckung zu prüfen? Für eine vollständige Ausgaben- und Ausnahmeüberdeckung sind die notw. Äquivalenzklassen definiert worden; legen Sie für jede (Sub-)klasse einen Repräsentanten fest: • Ausgabenüberdeckung: • kein Dreieck mit 3 Subklassen • gleichseitiges Dreieck • gleichschenkliges Dreieck mit 3 Subklassen • unregelmäßiges Dreieck mit 9 Subklassen • Ausnahmeüberdeckung • ungültige Eingabe mit 3 Subklassen Legen Sie für jeden Grenzfall einer Grenzwertanalyse einen Testwert fest (insg. 7 Grenzfälle): • kein Dreieck mit 4 Werten • Sehr flaches Dreieck mit 2 Werten • Sehr steiles Dreieck

9. TestenWhite Box Testing: Verfahren Kontrollflussbasierter Test • C0-Überdeckung, Anweisungsüberdeckung, statement coverage (alle Knoten) • C1-Überdeckung, Zweigüberdeckung, branch coverage (alle Zweige) • CGI, Grenze-Inneres Test • C∞-Überdeckung, Pfadüberdeckung, path coverage (alle Pfade) Test der Bedingungen • C2-Überdeckung, Bedingungsüberdeckung (alle Bedingungen, auch Teile davon) • Mehrfachbedingungsüberdeckung (alle Kombinationen der Teilbedingungen) Datenflussbasierter Test • Überdeckungsgrad bzgl. der Datenverwendung (Def/Uses-Verfahren): • (zustandsverändernde) Wertzuweisung: z.B. r=0 • (zustandserhaltende) Benutzung in Ausdrücken: z.B. f(r) • (zustandserhaltende) Benutzung in Entscheidungen: z.B. r>0

10. TestenWhite Box Testing: C0-Überdeckung Kontrollfußgraph vom ggT (Bsp.:ggT(4,8)=4, ggT(5,8)=1, ggT(15,35)=5) 1 1. public int ggt(int m, int n) { • int r; • if (n > m) { 4. r = m; 5. m = n; 6. n = r } 7. r = m % n; 8. while (r != 0) { 9. m = n; 10. n = r; 11. r = m % n; } 12. return n; 13. } Ein Testfall für die 100%ige C0-Überdeckung: 2-3 1,2-3,4-6,7, 8,9-11,8,12,13 4-6 7 Der Pfad wird nicht getestet, weil in diesem Pfad keine Anweisung enthalten ist 2-3,7 8 9-11 12 13

11. Testen White Box Testing: C0-Überdeckung Beispiel für nicht gefundenen Fehler bei der C0-Überdeckung: Mit den Testdaten x=5 und y=0 wird zwar die C0-Überdeckung erfüllt, jedoch wird der Fehler im falschen Programm nicht gefunden, denn die Sollwerte x=25 und y=30 werden in beiden Fällen erreicht.

12. Testen White Box Testing: C1-Überdeckung 1 1 Zwei Testfälle für die 100%ige C1-Überdeckung: 2-3 2-3 1,2-3,4-6,7, 8,9-11,8,12,13 4-6 4-6 1,2-3,7,8,12,13 neu 7 7 Jedoch: • Schleifen werden nicht ausreichend getestet. • Komplexe Bedingungen werden nicht getestet. • Kombinationen von Zweigen werden nicht getestet. 8 8 9-11 9-11 12 12 13 13

13. Testen White Box Testing: C1-Überdeckung Beispiel für gefundenen Fehler bei der C1-Überdeckung: Mit den Testdaten x=5 und y=0 (Ergebnis: x=25, y=30) wird der eine Test durchgeführt, mit x=-1 und y=0 (Ergebnis: x=-1, y4) der zweite Test. Der Fehler wird im Gegensatz zur C0-Überdeckung gefunden.

14. Testen White Box Testing: CGI-Überdeckung Die CGI-Überdeckung (Grenze-Inneres) bezieht sich nur auf Schleifenanweisungen und fordert, dass jede Schleife in mindestens einem Testfall • gar nicht (gilt nur bei abweisenden Schleifen, while, for nur wenn Abbruchbedingung bei erstmaliger Auswertung wahr) • genau einmal und • mehr als einmal ausgeführt wird. 1 2-3 4-6 7 8 3 Testfälle für die CGI-Überdeckung: 1,2-3,7,8,12,13 9-11 1,2-3,4-6,7, 8,9-11,8,12,13 12 1,2-3,4-6,7, 8,9-11,8,9-11,8,12,13 13

15. Testen White Box Testing: Bedingungsüberdeckung Die C2-Überdeckung (Bedingungsüberdeckung) berücksichtigt komplexe/zusammengesetzte Bedingungen, indem sie fordert, alle Teilbedingungen zu variieren. Jedoch ist nicht gefordert, dass unterschiedliche Wahrheitswerte bei der Auswertung der gesamten Bedingung berücksichtigt werden. Somit ist die Anweisungs- bzw. Zweigüberdeckung stärker, da manche Zweige bei der C2-Überdeckung nicht getestet werden. Testfall1: A=2, B=1, C=4 Testfall2: A=1, B=0, C=1 Die Testfälle überdecken zwar alle Variationen der Teilbedingungen, jedoch wird der Pfad c nicht getestet.

16. Testen White Box Testing: Bedingungsüberdeckung Bei der Testfallermittlung sollte man sowohl die C2-Überdeckung (Bedingungsüberdeckung) als auch die Zweigüberdeckung berücksichtigen (s. auch Beispiel vorige Folie): Testfall1: A=2, B=0, C=4  Pfad a-c-e Testfall2: A=1, B=1, C=1  Pfad a-b-d Mit diesen Testfällen werden zwar alle Zweige überdeckt, jedoch nicht alle Zweigkombinationen. Um das zu zeigen, benötigt man eine äquivalente Umformung des Kontrollflussgraphen:

17. Testen White Box Testing: Bedingungsüberdeckung Testfall1: A=2, B=0, C=4 true true A>1 B=0 Testfall2: A=1, B=1, C=1 false false C:=C/A Zwei Zweige fehlen: false true A=2 Lösung: Mehrfachbedingungsüberdeckung (C3-Ü.) Die C3-Überdeckung ist dann erfüllt, wenn jede Kombination der Wahrheitswerte aller Teilbedingungen in Testfällen ausgeführt wird. true C>1 C:=C+1 false

18. TestenWhite Box Testing Datenflussbasiertes Testen (Def/Uses-Verfahren) • Getestet werden Interaktion zwischen Anweisungen, die einer Variablen einen Wert zuwei- sen (definieren), und Anweisungen, die diesen Variablenwert benutzen (referenzieren): • Wertzuweisung (Definition, definitional use, def) • Berechnungsreferenz (Benutzung in Ausdrücken, computational use, c-use) • Entscheidungsreferenz (Benutzung in Bedingungen, predicative use, p-use) • verschiedene Test-/Überdeckungskriterien (Metriken): • Alle Definitionen: Das Resultat einer Zuweisung (Definition) wird wenigstens einmal benutzt (c-use oder p-use) • Alle DR-Interaktionen: jedes Paar (def/ref) auf irgendeinem Weg ausführen • Alle Referenzen: p-uses und c-uses • …. c-use(m,n) r = m % n r = op1(m,n) while (r != 0) if (r == 0) def(r) p-use(r)

19. TestenVerfahren zumWhite Box Testing Kontrollflussgraph mit Datenflussannotation: 1 def(m,n) 2 def(r) • public int ggt (int m, int n) { • int r; • if (n > m) { 4. r = m; 5. m = n; 6. n = r } 7. r = m % n; 8. while (r != 0) { 9. m = n; 10. n = r; 11. r = m % n; } 12. return n; 13. } Bsp. für DR-Interaktionen: (1, m, 4, r, 6): m wird in 1 definiert, in 4 referenziert, r wird in 4 definiert und in 6 referenziert; damit hängt 6 von 1 ab. (1, m, 7, r, 10): …..  Teste die Wegstücke: (1, 2, 3, 4, 5, 6) und (1, 2, 3, 7, 8, 9, 10) 3 p-use(m,n) 4 def(r), c-use(m) 5 def(m), c-use(n) 6 def(n), c-use(r) 7 def(r), c-use(m,n) 8 p-use(r) 9 def(m), c-use(n) 10 def(n), c-use(r) 11 def(r), c-use(m,n) c-use(n) 12

20. TestenVerfahren zumWhite Box Testing

21. TestenTestszenarien und Testfälle Für jede der geplanten Testarten werden die Testszenarien (o. a. Testumfänge) in Form einer Liste von Testfällen festgelegt. Für jeden Testfall gibt es dann eine Testanweisung und ein Testprotokoll, die häufig in einem(!) Formular zusammengefasst sind. Die Beschreibung eines Testfalls beinhaltet somit folgendes: • Beschreibung des Testfalls und der dazugehörigen Testschritte incl. Testbedingungen und Testdaten • Name des Erstellers der Testanweisung • Name des Freigebenden der Testanweisung • Name des Testers • Name des Abnehmenden • Die zu testende Eigenschaft (Korrektheit, Bedienoberfläche, Performance, …) • Erwartetes Ergebnis • Tatsächliches Ergebnis (diese Information liegt natürlich erst nach der Testdurchführung vor)

22. TestenUnittest • typgerechte Verwendung aller Datenobjekte (ungewollte Konvertierungen) • Objektverwendungsnachweise (Cross reference list, Aufrufhierarchie/-graph) • Datenflussanalyse von Programmobjekten (Variablen, Konstanten): • Objekte werden vor ihrer Definition verwendet • Objekte werden mehrfach überschrieben, ohne vorher verwendet worden zu sein • Objekte werden definiert, ohne danach verwendet zu werden • “nur-lesbare” Objekte werden überschrieben: z.B. Prüfung durch den ANSI-C-Compiler bei Verwendung des Schlüsselworts CONST: char *strcpy (char *ziel, const char *quelle); (der Speicherbereich quelle darf von der Funktion nicht verändert werden). • Statisch unerreichbare Programmsequenzen (z.B. fehlendes GOTO bei vorh. Sprungmarken) • Hinweise auf krasse Programmierfehler (z.B. nicht terminierende Schleife) • Prüfung von Programmierkonventionen und Qualitätsstandards (z.B. Namensgebung, Schachtelungstiefe, Komplexität)

23. 4 ... ... 3 2 5 TestenUnittest (Komplexität, Überdeckung) Komplexität: metric of McCabe: Cyclomatic Number is the maximum number of independent paths in a flowgraph v(G) = e - n + 2p v(G) - Cyclomatic Number of the flowgraph Ge - number of edges in Gn - number of nodes in Gp - number of connected components (if you have subprograms, p=1 in a single program) IF a>b THEN IF b>c THEN p(a,b) ELSE p(b,c); Print(a,b,c); 1 v(G) = 8 - 7 + 2*1 = 3 Überdeckung: Statement coverage: 1-2-3-5 und 1-2-4-5 Branch coverage: 1-5 (additional)

24. TestenIntegrationstest • Syntaxprüfung der Schnittstellen (z.B. falsche Anzahl von Parametern oder nicht übereinstimmender Parametertyp), z.B. Prüfung der Argumente/aktuellen Parameter bei einem Funktionsaufruf unter Verwendung des Funktions-Prototypen zur Deklaration der Funktionen durch den ANSI-C-Compiler: float hoch (float zahl, int potenz) • Kopplungskategorisierung nach Myers, sechs Abstufungen für die interne Festigkeit eines Moduls (Cohesion), fünf Abstufungen für die Bindung zu anderen Moduln (Coupling) • Anzeige verdeckter Abhängigkeiten, Beispiel: Zwei Module verwenden (importieren) eine externe Variable, die von einem dritten Modul bereitgestellt wird, d.h. die Kopplung zwischen den beiden benutzenden Moduln ist nicht unmittelbar ersichtlich • Intermodulare Datenflussanalyse, Beispiel: Ein Parameter erhält vor dem Aufruf der Schnittstelle einen Wert und wird in der aufgerufenen Funktion sofort überschrieben, ohne vorher gelesen zu werden • Ausschöpfen der Parameterbereiche: Prüfung der Ausnahmebehandlungen und Grenzfälle (sind häufig in den Simulationen vernachlässigt worden), des Modulverhaltens bei Systemfehlern, der über Modulgrenzen hinweg realisierten Fehlerbehandlungen und der globalen Variablen • Überprüfen der Aufrufreihenfolge: systemweite Überprüfung auf Einhaltung vorgeschriebener Abläufe und Protokollierung der Abläufe einzelner Operationen • Funktionalitätsprüfung (Zusammenwirken von Teilfunktionen) stat. dyn.

25. TestenTestabschlusskriterien Wenn mit den in der Testvorschrift festgelegten Testdatensätzen keine Fehler mehr gefunden werden • Sinnvolles Kriterium, wenn der Umfang des Prüflings eine systematische Auswahl von Testfällen mit ausreichender Überdeckung ermöglicht • Übliches Kriterium bei der Abnahme Wenn die Prüfkosten pro entdecktem Fehler eine im voraus festgelegte Grenze überschreiten • Sinnvolles Kriterium für das Beenden des Systemtests • Setzt die Erfassung der Prüfkosten und der Anzahl gefundener Fehler voraus Wenn während der Ausführung einer im voraus festgelegten Menge von Testfällen keine Fehler auftreten • Beispielsweise im Systemtest mit zufällig bestimmten Testdaten. Die Anzahl der hintereinander fehlerfrei auszuführenden Testfälle bestimmt sich aus der geforderten Zuverlässigkeit Wenn die vorher festgelegte Obergrenze für die Fehlerdichte unterschritten wird • Muss mit statistischen Methoden bestimmt werden

26. TestenFehlermanagement beim Testen

27. TestenFehlermeldung: Identifikation und Klassifizierung

28. TestenAnhang: Lösung der Übungsaufgabe von Seite 8 Vollständige Funktionsüberdeckung beinhaltet: Aktivierung der Funktionen Prüfen, Klassifizieren, Skalieren und Zeichnen Vollständige Ausgaben- und Ausnahmenüberdeckung benötigen Äquivalenzklassen für Erzeugen der Ausgaben • kein Dreieck • gleichseitiges Dreieck • gleichschenkliges Dreieck • unregelmäßiges Dreieck Erzeugung der Ausnahmesituationen • ungültige Eingabe

29. TestenAnhang: Lösung der Übungsaufgabe von Seite 8

30. TestenAnhang: Lösung der Übungsaufgabe von Seite 8 Grenzwertanalyse