Systemen - Dynamischer Test

Transkript

1 P r a k t I s c h e Testen von Software-Systemen Systemen - Dynamischer Test 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (1)

2 Inhalt Testfallentwurfsverfahren Festlegen von Testkriterien und Entwurf von Testfällen Kategorien von Testfallentwurfsverfahren Spezifikationsorientierte oder Blackbox-Verfahren Strukturorientierte oder Whitebox-Verfahren Erfahrungsbasierte Testfallermittlung Auswahl von Testverfahren Testen von Software-Systemen SS 2007 (2)

3 P r a k t I s c h e Festlegen von Testkriterien und Entwurf von Testfällen 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (3)

4 Festlegen von Testkriterien und Entwurf von Testfällen Prozess zur Ermittlung von Testkriterien und zum Entwurf von Tests Entwerfen von Tests durch Ermittlung von Testkriterien Spezifizieren der Testfälle Spezifizieren der Testszenarien Testen von Software-Systemen SS 2007 (4)

5 Festlegen von Testkriterien und Entwurf von Testfällen Formalität des Prozesses Der Prozess kann auf verschiedene Weise durchgeführt werden, von sehr informell mit wenig oder keiner Dokumentation bis sehr formal. Der Grad der Formalisierung hängt von folgenden Faktoren ab: dem Kontext des Testens, der Organisation, der Reife des Testprozesses, der Reife des Entwicklungsprozesses, zeitlichen Beschränkungen, den einbezogenen Personen. Testen von Software-Systemen SS 2007 (5)

6 Festlegen von Testkriterien Dokumente und Spezifikationen (Testbasis) werden analysiert, um zu ermitteln, was getestet werden muss Feststellen der Testkriterien Ein Testkriterium ist definiert als eine Einheit oder ein Ereignis, die (bzw. das) durch einen oder mehrere Testfälle verifiziert werden kann. Beispiele für solche Einheiten oder Ereignisse sind: eine Funktion, eine Transaktion, ein Qualitätsmerkmal, ein strukturelles Element. Testen von Software-Systemen SS 2007 (6)

7 Festlegen von Testkriterien Traceability ist wichtig! Traceability bedeutet Rückverfolgbarkeit Eine Traceability von Testkriterien auf Spezifikationen und Anforderungen sollte sichergestellt werden, denn sie erlaubt: sowohl eine Analyse der Auswirkungen (impact analysis) aufgrund von geänderten Anforderungen, als auch die Bestimmung einer Anforderungsüberdeckung, bezogen auf eine bestimmte Menge von Tests. Testen von Software-Systemen SS 2007 (7)

8 Entwurf von Testfällen Während der Testfallspezifikation und Testrealisierung werden die Testfälle und Testdaten unter Verwendung von Testfallentwurfsverfahren entwickelt und detailliert beschrieben Ein Testfall besteht aus: einer Menge von Eingabewerten, den für die Ausführung notwendigen Vorbedingungen, der Menge der erwarteten Sollwerte, den erwarteten Nachbedingungen. Erwartete Ergebnisse sollten ermittelt werden Idealerweise vor der Ausführung des Testfalls Testen von Software-Systemen SS 2007 (8)

9 Entwurf von Testfällen Organisation von Testfällen: Es entsteht eine Testspezifikation, die aus folgenden Dokumenten besteht: Testentwurfspezifikation Testfallspezifikation Testvorgehensspezifikation [CTFL-LP05] In der Testentwurfspezifikation stehen folgende Informationen zu einem Testobjekt: Testkriterien Detaillierte Testvorgehensweise Zugeordnete logische Testfälle Die definierten konkreten Testfälle werden in einer Testfallspezifikation gesammelt Testen von Software-Systemen SS 2007 (9)

10 Entwurf von Testfällen Organisation von Testfällen: Testfälle in eine ausführbare Reihenfolge bringen Erstellung der Testvorgehensspezifikation Das Testszenario (oder manuelle Testskript) legt die Reihenfolge der Aktionen für die Ausführung eines Tests fest Wenn Tests unter Verwendung eines Testausführungswerkzeugs durchgeführt werden, ist die Reihenfolge der Aktionen in einem Testskript festgelegt (in einem automatisierten Testszenario) Testen von Software-Systemen SS 2007 (10)

11 Entwurf von Testfällen Testszenarien und automatisierten Testskripte werden anschließend in einem Testausführungsplan zusammengestellt: Ein Testausführungsplan legt die Reihenfolge der Ausführung der verschiedenen Testszenarien fest legt fest, wann und wo die Testszenarien ausgeführt werden und von wem sie ausgeführt werden Der Testausführungsplan sollte dabei u.a. folgende Faktoren berücksichtigen: Regressionstests Priorisierung logische Abhängigkeiten Testen von Software-Systemen SS 2007 (11)

12 P r a k t I s c h e Kategorien von Testfallentwurfsverfahren 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (12)

13 Kategorien von Testfallentwurfsverfahren Es werden drei Kategorien von Testfallentwurfsverfahren unterschieden: Blackbox-Verfahren oder spezifikationsorientierte Verfahren Strukturorientierte oder Whitebox-Verfahren Erfahrungsbasierte Verfahren Das Ziel von Testfallentwurfsverfahren ist es, Testkriterien und Testfälle zu ermitteln. Testen von Software-Systemen SS 2007 (13)

14 Kategorien von Testfallentwurfsverfahren Spezifikationsorientierte oder Blackbox-Verfahren Mit Blackbox-Verfahren können sowohl funktionale als auch nichtfunktionale Anforderungen getestet werden. Blackbox-Verfahren werden auf allen Teststufen eingesetzt. Modelle, ob formal oder nicht formal, werden zur Spezifikation des Systems, der Software oder ihrer Komponente herangezogen. Von diesen Modellen können systematisch Testkriterien und Testfälle abgeleitet werden. Testen von Software-Systemen SS 2007 (14)

15 Kategorien von Testfallentwurfsverfahren Strukturorientierte oder Whitebox-Verfahren Informationen über den Aufbau des Systems oder der Software werden für die Ableitung von Testfällen verwendet Z.B. der Code und das Design. Der Überdeckungsgrad der Software kann für vorhandene Testfälle gemessen werden. Weitere Testfälle können zur Erhöhung des Überdeckungsgrades systematisch abgeleitet werden. Testen von Software-Systemen SS 2007 (15)

16 Kategorien von Testfallentwurfsverfahren Erfahrungsbasierte Verfahren Das Wissen und die Erfahrung von Menschen wird zur Ableitung der Testfälle genutzt. Das Wissen von Testern, Entwicklern, Anwendern und Betroffenen über die Verwendung die Software und ihre Umgebung. Das Wissen über wahrscheinliche Fehler und ihre Verteilung Testen von Software-Systemen SS 2007 (16)

17 Kategorien von Testfallentwurfsverfahren Dynamischer Test = Test mit Ausführung Die Ergebnisse des Softwareentwicklungsprozesses werden ausgeführt und ihre Funktionalitäten gegen ihre Spezifikationen geprüft. Testen von Software-Systemen SS 2007 (17)

18 Kategorien von Testfallentwurfsverfahren Statischer Test Dokumente und Code Keine Ausführung Syntax, Semantik, Logik Sollte vor dem dynamischen Test durchgeführt werden Dynamischer Test Nur Code Ausführung nötig Struktur, Funktion Benötigt ausführbaren Code Prüfung von Aspekten, die nur zur Laufzeit prüfbar sind (z.b. Performanz) Testen von Software-Systemen SS 2007 (18)

19 P r a k t I s c h e Spezifikationsorientierte oder Blackbox Verfahren 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (19)

20 Blackbox-Verfahren Was sind Blackbox-Tests? Auf Anforderungen basierende Tests Kein Wissen über Programmstruktur (Programm = black box ) Testfälle basieren auf Spezifikationen/Anforderungen Benutzersicht Vollständiger Test prüft alle Kombinationen von gültigen und ungültigen Eingabewerten unmöglich für nichttriviale Programme zielt darauf ab, Funktionalität so ausführlich wie möglich zu testen und dabei Redundanzen zu vermeiden Benötigte Dokumente: Anforderungsspezifikation, Benutzerdokumentation, Schnittstellenbeschreibung Testen von Software-Systemen SS 2007 (20)

21 Blackbox-Verfahren Was sind Blackbox-Tests? Point of Control (PoC) und Point of Observation (PoO) außerhalb des Testlings Point of Control (PoC): Schnittstelle, über die das Testobjekt mit Testdaten versorgt wird. Point of Observation (PoO): Schnittstelle, an der die Reaktionen und Ausgaben des Testobjekts beobachtet und aufgezeichnet werden. Testen von Software-Systemen SS 2007 (21)

22 Blackbox-Verfahren Äquivalenzklassenbildung Vorgehen: 1. Basierend auf ihrem funktionalen Verhalten werden die Wertebereiche für Eingabe- und Ausgabeparameter in Äquivalenzklassen aufgeteilt. Alle Eingabewerte derselben Äquivalenzklasse bewirken beim Testobjekt ein ähnliches Verhalten Bei ähnlichem Verhalten des Testobjekts liegen alle Ausgabewerte in derselben Äquivalenzklasse 2. Neben verschiedenen gültigen Äquivalenzklassen (erwartete Funktionalität) werden auch ungültige Äquivalenzklasse (fehlerhafte Eingaben, Negativtest) gebildet 3. Die Menge der Äquivalenzklassen wird auf Vollständigkeit und auf Elementfremdheit überprüft 4. Aus jeder Äquivalenzklasse wird mindestens ein Wert ausgewählt (Testfallerstellung) Testen von Software-Systemen SS 2007 (22)

23 Blackbox-Verfahren Äquivalenzklassenbildung Äquivalenzklassenbildung kann in allen Teststufen angewandt werden. Kann als Verfahren eingesetzt werden, um Überdeckungsgrade im Bezug auf Eingabe- oder Ausgabewerte zu erreichen. Kann z.b. auf folgende Arten von Tests angewandt werden: Eingaben eines menschlichen Benutzers Eingaben an ein System über Schnittstellen Im Integrationstest auf Schnittstellenparameter Übergabe von Funktionsparametern an eine Komponente/Modul Eine Äquivalenzklasse entspricht einer bestimmten Wirkung ( logischer Testfall) Testen von Software-Systemen SS 2007 (23)

24 Blackbox-Verfahren Beispiel numerische Darstellung eines Monats (Wertebereich) Eingabe Monat Äquivalenzklassen Gültig 1 und 12 Ungültig <1 oder >12 G 6 Testeingabedaten (Beispiele) U 0 U -13 U 88 (G Gültig, U Ungültig) Testen von Software-Systemen SS 2007 (24)

25 Blackbox-Verfahren Äquivalenzklassenbildung Mehrdimensionaler Eingaberaum (1) Kombination von Äquivalenzklassen der einzelnen Parameter: Beziehungen, Wechselwirkungen und Abhängigkeiten zwischen Werten werden bei einfacher Kombination von Klassen der Parameter nicht bedacht Beispiel: P 1 Klasse K 11 oder K 21, P 2 Klasse K 12 oder K 22 K 12 K 22 K11 P 2 P 2 K 12 K 22 K 11 P 1 P 1 K 21 K 21 Parameter P 1, P 2 unabhängig Parameter P 1, P 2 abhängig Testen von Software-Systemen SS 2007 (25)

26 Blackbox-Verfahren Äquivalenzklassenbildung Mehrdimensionaler Eingaberaum (2) Kombination von Äquivalenzklassen der einzelnen Parameter: Bei n Parametern: Nie mehr als 1 ungültige Äquivalenzklasse pro Parametersatz (sonst keine zuverlässige Vorhersage des Systemverhaltens möglich): U 1 x G 2 x... x G n G 1 x U 2 x G 3 x... G n... G 1 x... x G n-1 x U n Testen von Software-Systemen SS 2007 (26)

27 Blackbox-Verfahren Grenzwertanalyse Ergänzt die Äquivalenzklassenbildung Baut auf der Tatsache auf, dass Fehler oft an den Grenzen von Wertebereichen auftreten (obere, untere Grenze) Testet, zusätzlich zu den normalen Werten, auch Werte auf oder nahe den Grenzen von Äquivalenzklassen Beachtet implizit gültige und ungültige Werte Unterstützt bei der Findung von Werten für konkrete Testfälle. Kann auf allen Teststufen angewandt werden. Testen von Software-Systemen SS 2007 (27)

28 Blackbox-Verfahren Grenzwertanalyse Die Grenzwerte zweier benachbarter sortierter Bereiche sind: Der größte Wert des unteren Bereichs und Der kleinste Wert des oberen Bereichs Als Testeingabedaten werden gewählt: Die Grenzwerte einer Äquivalenzklasse Jeweils die 2 benachbarten Werte jedes Grenzwerts, sofern die Werte nicht bereits von anderen Testfällen abgedeckt sind Grenzwertanalyse ist nur sinnvoll auf sortierten Mengen Testen von Software-Systemen SS 2007 (28)

29 Blackbox-Verfahren Beispiele (1) numerische Darstellung eines Monats (Wertebereich) Äquivalenzklassen Eingabe U1 G U2 Monat <1 1 oder 12 >12 Grenzwerte Min Max Grenzwert-Testeingabedaten U1 U1 G G U2 U2 Min, Min+1 (Min-1 ex. nicht) -1, 0 1, 2 11, 12 13, 14 Max-1, Max (Max+1 ex. nicht) Testen von Software-Systemen SS 2007 (29)

30 Blackbox-Verfahren Beispiele (1) numerische Darstellung eines Monats (Wertebereich) Eine nicht zusammenhängende ungültige Äquivalenzklasse wird meist in einfache zusammenhängende ungültige Äquivalenzklassen aufgeteilt Eingabe Äquivalenzklassen Gültig Ungültig in Bereiche aufteilen Eingabe Äquivalenzklassen Ungültig1 Gültig Ungültig2 Monat 1 und 12 <1 oder >12 Monate <1 1 und 12 >12 Testen von Software-Systemen SS 2007 (30)

31 Blackbox-Verfahren Entscheidungstabellentest Entscheidungstabellen können zur Erfassung komplexer, von einem System umzusetzenden Regeln verwendet werden (DIN-Norm 66241). Entscheidungstabellen eignen sich zur Spezifikation von komplexen logischen Regeln. Eine vollständige Abdeckung von Bedingungen wird erreicht Entscheidungstabellen sind geeignet, um Testfälle zu entwerfen. Üblicherweise mindestens 1 Testfall pro Spalte bzw. Bedingungskombination Testen von Software-Systemen SS 2007 (31)

32 Blackbox-Verfahren Entscheidungstabellentest Die vier Quadranten einer Entscheidungstabelle Bedingungen Aktionen Regeln Aktionszeiger Bedingungen: Mögliche Zustände von Objekten Regeln: Kombinationen von Bedingungswerten Aktionen: Aktivitäten, die abhängig von den Regeln auszuführen sind Aktionszeiger: Belegungen der Bedingungen mit Aktionen Testen von Software-Systemen SS 2007 (32)

33 Blackbox-Verfahren Entscheidungstabellentest Beispiel Krankenbesuch (1) Besuchsmöglichkeiten Bedingungen Ansteckende Krankheit (j/n) j j j j n n n n Besuch innerhalb Besuchszeit (j/n) j j n n j j n n Patient hat Fieber (j/n) j n j n j n j n Aktionen Besuch max. 30 Minuten Besuch ablehnen Besuch nur mit Schwester x x x x x x x x Zu Beginn: 8 Testfälle Normalbesuch x Testen von Software-Systemen SS 2007 (33)

34 Blackbox-Verfahren Entscheidungstabellentest Beispiel Krankenbesuch (2) Besuchsmöglichkeiten Bedingungen Ansteckende Krankheit (j/n) Besuch innerhalb Besuchszeit (j/n) 1 j j 2 j j 3 j n 4 j n 5 n j 6 n j 7 n n 8 n n Regeln ohne Auswirkung kennzeichnen Patient hat Fieber (j/n) j n j n j n j n Aktionen Besuch max. 30 Minuten x x Besuch ablehnen x x x x Besuch nur mit Schwester x x Normalbesuch x Gleiche Wirkung Testen von Software-Systemen SS 2007 (34)

35 Blackbox-Verfahren Entscheidungstabellentest Beispiel Krankenbesuch (3) Besuchsmöglichkeiten Bedingungen Ansteckende Krankheit (j/n) Besuch innerhalb Besuchszeit (j/n) 1 j -- 5 n j 6 n j 7 n n 8 n n Entscheidungs -tabelle konsolidieren Patient hat Fieber (j/n) -- j n j n Aktionen Besuch max. 30 Minuten Besuch ablehnen Besuch nur mit Schwester x x x x x Nach Analyse: 5 Testfälle Normalbesuch x Testen von Software-Systemen SS 2007 (35)

36 Blackbox-Verfahren Zustandsbasierter Test Betrachtet Zustandsübergänge Analysiert die Spezifikation, um das Verhalten der Software bei Zustandsübergängen zu modellieren Basiert auf Zustandsdiagrammen bzw. Zustandsautomaten Wird benutzt, um reaktive Systeme zu testen, z.b.: Embedded Systems Sicherheitsrelevante Software Identifiziert Zustände, Übergänge, Ereignisse und Aktionen Beispiele üblicher Strategien Minimale Abdeckung: alle möglichen Zustände Alle Funktionen Abdeckung von Geschäftsprozessen/Workflows/Szenarien, u.u. mit risikobasierter Priorisierung Übergangsbaum zur Identifizierung von Testfällen Testen von Software-Systemen SS 2007 (36)

37 Blackbox-Verfahren Beispiel (1) init Ein Stapel Schokoriegel in einem Verkaufsautomaten kann sich in einem von drei Zuständen befinden: leer ( empty ), gefüllt ( filled ) (mit weniger als der vollen Kapazität), und voll ( full ) displaytop pop[ height > 1 ] push[ height < max -1 ] push * displaytop the stack cannot accept any more items when it's full - behavior has to be specified if push is tried in this state empty push filled push[ height = max -1 ] full pop[ height = 1 ] pop delete Testen von Software-Systemen SS 2007 (37)

38 Dyn. Test Black-Box -Verfahren Beispiel (2) Übergangsbaum (prinzipiell mögliche Übergänge) ERROR pop displaytop push pop ERROR push initial init empty filled push pop delete delete deleted displaytop ERROR empty filled full filled filled displaytop push* pop delete full full filled ERROR Testen von Software-Systemen SS 2007 (38)

39 Blackbox-Verfahren Anwendungsfallbasierter Test Tests können auf Basis von Anwendungsfällen (Use Cases) oder von Geschäftsszenarien spezifiziert werden Derartige Tests sind geeignet für System- und Abnahmetests Z.B. können ggfs. Fehler in Prozessabläufen aufgedeckt werden, die vom System unterstützt werden Da das Zusammenwirken und die gegenseitige Beeinflussung unterschiedlicher Komponenten betrachtet werden, können solche Testfälle auch Fehler im Umfeld der Integration aufdecken, die durch den Test der einzelnen Komponenten nicht gefunden werden könnten. Testen von Software-Systemen SS 2007 (39)

40 Blackbox-Verfahren Anwendungsfälle Was ist die sichtbare Funktionalität das Systems? Welche Benutzer (Akteure) greifen auf das System zu? Welche anderen Systeme und Benutzer gibt es? Wo verlaufen die Systemgrenzen? Use Cases beschreiben Abläufe bei der Benutzung des Systems Was soll das System leisten, nicht wie soll es das tun! Semiformal, für Menschen verständlich Benutzersicht Testen von Software-Systemen SS 2007 (40)

41 Blackbox-Verfahren Anwendungsfälle Bankautomat Geld überweisen Kunde Benutzer des Systems Kontostand abfragen Geld abheben Servicetechniker Protokoll abfragen Testen von Software-Systemen SS 2007 (41)

42 Blackbox-Verfahren Anwendungsfälle - Attribute + Name und Kurzbeschreibung Akteure (primär, auslösend, beteiligt) Auslösendes Ereignis Vorbedingungen Erfolgsszenario (Normalablauf) Alternativszenarien (Alternativen, Fehlerfälle) Abnahmekriterien Verknüpfungen zu anderen Anforderungen Verwendung der Anwendungsfallattribute in den Testfällen! Testen von Software-Systemen SS 2007 (42)

43 Blackbox-Verfahren Wann wendet man Blackbox-Verfahren an? Im ganzen Lebenszyklus, aber verstärkt in späten Phasen, d.h. im System- und Abnahmetest, wo der Fokus auf Spezifikationen und Anforderungen liegt. Testen von Software-Systemen SS 2007 (43)

44 Blackbox-Verfahren Grenzen der Blackbox-Verfahren Testfälle basieren auf Spezifikationen (Verifikation) Spezifikationsfehler werden durch Testen nicht gefunden (aber evtl. bei der Testfallerstellung) Blackbox-Testfälle können keine zusätzlichen Funktionalitäten testen, die in der Spezifikation nicht beschrieben sind. Wechselwirkungen zwischen Eingabe, Ausgabe und dem internen Zustand des Testobjekts werden nur implizit bedacht. Die Kenntnis der Programmstrukturen sowie die Verfügbarkeit geeigneter Testschnittstellen kann helfen, solche Wechselwirkungen und Abhängigkeiten besser zu erfassen und dadurch intensiver prüfen zu können. Testen von Software-Systemen SS 2007 (44)

45 Blackbox-Verfahren Zusammenfassung Blackbox-Verfahren definieren Testfälle, insbesondere für funktionale Tests. Da nachgewiesen werden muss, dass die Software korrekt funktioniert, müssen Blackbox-Tests immer durchgeführt werden. Wichtige Blackbox-Verfahren: Äquivalenzklassenbildung Grenzwertanalyse Entscheidungstabellentest Zustandsbasierter Test Anwendungsfallbasierter Test Benutzersicht Testen von Software-Systemen SS 2007 (45)

46 P r a k t I s c h e Strukturorientierte oder Whitebox-Verfahren 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (46)

47 Whitebox-Verfahren Was sind Whitebox-Tests? Strukturelle oder Design-orientierte Tests Nutzen der Kenntnis der Programmstruktur: Programm = white box Nutzen des Kontrollflussgraphen (CFG) Entwicklersicht Welcher bzw. wie viel Code einer SW-Komponente wurde bereits getestet? Testen von Software-Systemen SS 2007 (47)

48 Whitebox-Verfahren Was sind Whitebox-Tests? Ein kompletter Tests besteht aus allen möglichen Pfaden durch das Programm (100% Pfadabdeckung) unmöglich für nichttriviale Programme Die Aufgabe des Testers besteht nun darin, Testfälle zu ermitteln, welche die angestrebte Abdeckung erreicht PoC (Point of Control) und PoO (Point of Observation) innerhalb des Testlings Benötigte Dokumente: Quellcode, Designdokumentation, Anforderungsdefinition, Benutzerdokumentation Testen von Software-Systemen SS 2007 (48)

49 Whitebox-Verfahren Whitebox-Verfahren auf verschiedenen Teststufen Komponentenebene: Die Struktur ist die des Codes selbst, also Anweisungen, Entscheidungen oder Zweige. Integrationsebene: Die Struktur kann z.b. ein Aufruf-Baum sein (ein Diagramm, das zeigt, welche Module ein anderes Modul aufrufen), dokumentiert in der Designspezifikation Systemebene: Die Struktur kann z.b. die Menüstruktur sein, Geschäftsprozesse oder die Struktur einer Webseite, dokumentiert in der Anforderungsspezifikation Testen von Software-Systemen SS 2007 (49)

50 Whitebox-Verfahren Testen von Software-Systemen SS 2007 (50)

51 Whitebox-Verfahren Anweisungsüberdeckung Ziel: Alle Anweisungen im Testobjekt werden mindestens einmal ausgeführt. Nachteil: Kontrollfluss wird nicht berücksichtigt Abhängigkeiten zwischen Daten werden nicht berücksichtigt C 0 = # ausgeführte Anweisungen # alle Anweisungen Kante wird nicht erreicht Testen von Software-Systemen SS 2007 (51)

52 Whitebox-Verfahren Entscheidungsüberdeckung Alle Zweige in der Komponente werden mindestens einmal ausgeführt, d.h. alle Entscheidungen müssen mindestens einmal mit Wahr und einmal mit Falsch ausgewertet werden. Ist die Messung des prozentualen Anteils eines Entscheidungsausgangs (z.b. wahr und falsch bei einer If-Anweisung), welche durch die Testfälle ausgeführt wurden. Um eine hohe Entscheidungsüberdeckung zu erreichen, leitet man Testfälle so ab, dass bestimmte Zweige (Entscheidungsausgang) durchlaufen werden. Der Entscheidungsüberdeckungstest ist eine Form des kontrollflussbasierten Tests, da er einen speziellen Kontrollfluss durch die Entscheidungspunkte erzeugt. Testen von Software-Systemen SS 2007 (52)

53 Whitebox-Verfahren Entscheidungsüberdeckung Nachteile: Schleifen müssen nur einmal durchlaufen werden Komplexe Bedingungen werden nicht berücksichtigt Subsumiert Anweisungsüberdeckung C 1 = # zu Wahr und zu Falsch ausgewertete Entscheidungen # alle Entscheidungen Kante wird erreicht Testen von Software-Systemen SS 2007 (53)

54 Whitebox-Verfahren Beispiel (Ausschnitt des o.a. Beispiels zur Berechnung der Zahl Schaltjahre) Entscheidungsüberdeckung Anweisungsüberdeckung 2 Pfade: a) b) T T T a) b) siehe Anweisungsüberdeckung 4 Pfade: c) d) Testdaten: 2000, Testdaten: 2000, 2004, 1900, 1902 Testen von Software-Systemen SS 2007 (54)

55 Whitebox-Verfahren Einfache Bedingungsüberdeckung Alle atomaren (Teil-)Bedingungen müssen jeweils mindestens einmal true und einmal false sein. Beispiel: if (kundennr 5000 prodnr 1000) 2 Testfälle reichen Nachteil: Kombinationen von Wahrheitswerten atomarer Teilbedingungen werden nicht berücksichtigt schwaches Kriterium C 2 = # ausgewertete atomare Bedingungen # alle atomaren Bedingungen Testen von Software-Systemen SS 2007 (55)

56 Whitebox-Verfahren Mehrfachbedingungsüberdeckung Alle Kombinationen von Wahrheitswerten atomarer (Teil-) Bedingungen müssen berücksichtigt werden. Alle möglichen Kombinationen müssen durchlaufen werden. Beispiel: if (kundennr 5000 prodnr 1000) 2x2 = 4 Testfälle sind notwendig Nachteile: Anzahl der möglichen Kombinationen steigt exponentiell mit der Anzahl der atomaren Bedingungen Oft können nicht alle möglichen Kombinationen mit Testdaten erreicht werden Subsumiert Anweisungs- und Zweigüberdeckung C 3 = # ausgewertete Wahrheitswert Kombinationen # alle Wahrheitswert Kombinationen Testen von Software-Systemen SS 2007 (56)

57 Whitebox-Verfahren Minimale Mehrfachbedingungsabdeckung Jede mögliche Kombination von Wahrheitswerten atomarer (Teil-) Bedingungen, die den Wahrheitswert der gesamten logischen Verknüpfung verändert, muss berücksichtigt werden. Nachteile: Oft ist es schwierig Eingabedaten zu finden, die für eine gegebene atomare Bedingung einen bestimmten Wahrheitswert ergeben. Vorteile: Umgeht die Nachteile der einfachen und mehrfachen Bedingungsüberdeckung Niedrigere Zahl von Testfällen MCDC = # ausgewertete relevante Wahrheitswert Kombinationen # alle relevanten Wahrheitswert Kombinationen Testen von Software-Systemen SS 2007 (57)

58 Whitebox-Verfahren Pfadabdeckung Alle möglichen disjunkten Pfade durch ein Programm müssen mindestens einmal durchlaufen werden. Nachteil: Für nichttriviale Programme ist es unmöglich, 100% Pfadüberdeckung zu erreichen: Bei Code mit Schleifen ist die Pfadlänge generell nicht beschränkt Vorteil: Abhängigkeiten zwischen Zweigen und Schleifen werden berücksichtigt Subsumiert Anweisungs- und Zweigüberdeckung C 4 = # durchlaufene Pfade # alle Pfade Testen von Software-Systemen SS 2007 (58)

59 Whitebox-Verfahren Instrumentieren Whitebox-Tests erfordern eine Auswertung: Welche Teile des Programms wurden ausgeführt? Welche wurden (noch) nicht ausgeführt? Instrumentieren: Der Quellcode wird um Zähler erweitert, die mit 0 initialisiert und jedes Mal inkrementiert werden, wenn die entsprechende Zählanweisung ausgeführt wird. Testen von Software-Systemen SS 2007 (59)

60 Whitebox-Verfahren Weitere Whitebox-Verfahren Das Konzept der Überdeckungsgrade kann auch auf andere Teststufen übertragen werden (z.b. Integrationsebene), wobei der prozentuale Anteil von Modulen, Komponenten oder Klassen, die durch eine Testsuite ausgeführt wurden, als Modul-, Komponenten- oder Klassen-Überdeckung bezeichnet werden kann. Testen von Software-Systemen SS 2007 (60)

61 Whitebox-Verfahren Werkzeugunterstützung Die manuelle Instrumentierung bzw. die manuelle Berechnung der Abdeckung sind zeitaufwändig und fehleranfällig Werkzeugunterstützung obligatorisch: Werkzeuge sparen langfristig Geld, steigern die Effizienz und Produktivität, und damit die Qualität des Testlings. Testen von Software-Systemen SS 2007 (61)

62 Whitebox-Verfahren Problem: Testen von Exception Handling Testobjekt Fange die Exceptions des externen Systems ab Externes System z.b. Sensor, Maschine, Softwarekomponente? Wie bringt man das externe System dazu, abzustürzen Oft ist es schwierig, Exceptions zu testen (und damit 100% Abdeckung zu erreichen), da sie nur schwer provoziert werden können. Lösung: Simulation der Umgebung Einbau von testunterstützendem Code in das Testobjekt Testen von Software-Systemen SS 2007 (62)

63 Whitebox-Verfahren Wann wendet man Whitebox-Verfahren an? Hauptsächlich in den frühen Entwicklungsphasen, wenn das Hauptaugenmerk auf der internen Struktur eines Programms bzw. einer Komponente liegt Hauptsächlich Komponenten-/Modultest Integrationstest Hier betrachtet man i.a. die Abdeckung des Aufrufgraphen statt der Abdeckung bzgl. einer der oben aufgeführten Abdeckungskriterien Prinzipiell für alle Teststufen (Definition geeignetes Abdeckungskriterium) Testen von Software-Systemen SS 2007 (63)

64 Whitebox-Verfahren Wie wendet man Whitebox-Verfahren an? Durchführung des Whitebox-Tests Instrumentiere zu untersuchenden Code Führe die ermittelten (funktionalen) Blackbox-Testfälle aus Ermittle die erreichte Überdeckung Ggfs. neue Testfälle entwerfen, wenn erwartete Abdeckung nicht erreicht wird Prinzipiell ist auch möglich, für den Whitebox-Test rein strukturelle Testfälle zu erzeugen (d.h. ohne Berücksichtigung der Funktionalität, von Anwendungsfällen, etc.). Dies wird jedoch in der Fachwelt als weniger wirkungsvoll angesehen Es ist sinnvoller, erst bei der Ergänzung der bereits existierenden Blackbox-Testfälle strukturelle Aspekte zu berücksichtigen Testen von Software-Systemen SS 2007 (64)

65 Whitebox-Verfahren Grenzen der Whitebox-Verfahren Anforderungen, die übersehen und damit nicht implementiert wurden, können mit Whitebox-Tests nicht gefunden werden (ggfs. indirekt ) Falsche und fehlende Anforderungen können mit Whitebox-Tests nicht gefunden werden Whitebox-Tests decken nur implementierte Anforderungen ab Testen von Software-Systemen SS 2007 (65)

66 Whitebox-Verfahren Zusammenfassung Whitebox-Verfahren überprüfen die Programmstruktur Basierend auf Quellcode Werkzeugunterstützung obligatorisch Anwendung hauptsächlich in niedrigeren Teststufen Entwicklersicht Testen von Software-Systemen SS 2007 (66)

67 P r a k t I s c h e Erfahrungsbasierte Verfahren 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (67)

68 Erfahrungsbasierte Verfahren Testfälle basieren auf Erfahrung und Intuition: Wegen ihrer größeren Erfahrung und einem sechsten Sinn für Fehlerzustände und Fehlerwirkungen sind manche Tester beim Finden von Fehlerwirkungen erfolgreicher als andere. So kann man Fehler finden, die man mit systematischen Tests wohl nicht finden würde. Testen von Software-Systemen SS 2007 (68)

69 Erfahrungsbasierte Verfahren Error Guessing Einsatz in höheren Testebenen, um systematische Tests zu ergänzen Kann von systematisch erstellten Testfällen inspiriert werden Kann genutzt werden, um Listen möglicher Fehlerzustände und Checklisten für weniger erfahrene Tester zu schreiben Testen von Software-Systemen SS 2007 (69)

70 Erfahrungsbasierte Verfahren Error Guessing Error Guessing kann äußerst unterschiedliche Grade von Effizienz erreichen, abhängig von der Erfahrung des Testers. Eine strukturierte Herangehensweise an Intuitive Testfallermittlungsverfahren ist es, eine Liste möglicher Fehler zu erstellen, und dann Testfälle zu entwerfen, die auf diese Fehler abzielen. Testen von Software-Systemen SS 2007 (70)

71 Erfahrungsbasierte Verfahren Exploratives Testen Exploratives Testen ist gleichzeitiger Testfallentwurf, Testdurchführung, Testprotokollierung und Lernen, auf Grundlage einer Test-Charta, der die Testziele zu entnehmen sind, und wird innerhalb festgelegter Zeitfenster durchgeführt. Häufig wird die Bedienung des Systems mit Hilfe von Testausführungswerkzeugen mitgeschnitten. Dieser Mitschnitt wird dann in der Folge als Basis neuer Testfälle wieder verwendet (z.b. als Teil eines Testskripts). Es ist ein Ansatz, der sich besonders gut eignet, wenn es nur wenig oder ungeeignete Spezifikationen gibt, sowie unter hohem Zeitdruck. Testen von Software-Systemen SS 2007 (71)

72 Erfahrungsbasierte Verfahren Zusammenfassung Die erfahrungsbasierte Testfallermittlung ergänzt die systematisch ermittelten Testfälle, aber sollte sie niemals ersetzen Basierend auf der Erfahrung und dem Bauchgefühl des Nutzers oder Testers Einsatz in höheren Testebenen, um die Teile des Testlings zusätzlich abzudecken, in denen viele Fehlerzustände erwartet werden Testen von Software-Systemen SS 2007 (72)

73 P r a k t I s c h e Auswahl von Testfallentwurfsverfahren 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (73)

74 Auswahl von Testfallentwurfsverfahren Die Wahl, welche Testverfahren verwendet werden sollen, hängt von folgenden Faktoren ab: Art des Systems, behördliche Anforderungen, Kunden- oder Vertragsanforderungen, Risikograd, Art des Risikos, Testziel, verfügbare Dokumentation, Wissen der Tester, Zeit und Geld, Softwareentwicklungsmodell, Anwendungsfallmodelle, vorangegangene Erfahrungen im Bezug auf Typen gefundener Fehler. Einige Techniken sind für bestimmte Situationen und Teststufen besser geeignet; andere sind in allen Teststufen gleichermaßen einsetzbar. Testen von Software-Systemen SS 2007 (74)

75 P r a k t I s c h e Zusammenfassung 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (75)

76 Zusammenfassung Für die Entwicklung qualitativ hochwertiger Software sind sowohl statische als auch dynamische Tests nötig: Weniger Fehler Bessere SW-Qualität Gute statische Prüfungen finden Fehlerzustände, bevor der Testling an den (dynamischen) Test übergeben wird. Spart Zeit und Geld Tests können früher beginnen Tests sind eher fertig Testen von Software-Systemen SS 2007 (76)

77 Zusammenfassung Blackbox Äquivalenzklassenbildung Grenzwertanalyse Zustandsbasierte Tests Entscheidungstabellentests Anwendungsfallbasierte Tests Whitebox Anweisungsüberdeckung Zweigüberdeckung Bedingungsüberdeckung Pfadüberdeckung Werkzeugunterstützung obligatorisch Weder-noch Erfahrungsbasierte Testfallermittlung Erfahrung und Intuition Modul-, Integrations-, System- und Abnahmetest hauptsächlich Modultest auch Integrations-, System- und Abnahmetest Modul-, Integrations-, System- und Abnahmetest Testen von Software-Systemen SS 2007 (77)