Testen. SEPR Referat: Testen - Oliver Herbst

Transkript

1 Testen

2 Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2

3 1. Grundlagen des Testens 3

4 Grundlagen des Testens Motivation erfüllt die Software die geforderten Anforderungen? Risiken beim Einsatz der Software verringern oft Gegenstand des Vertrags mit Auftraggeber optische Prüfung nur eingeschränkt möglich 4

5 Grundlagen des Testens Begriffe Fehlerbegriff Testbegriff Softwarequalität Testaufwand 5

6 Grundlagen des Testens Grundlegende Testarten funktionaler Test nicht funktionaler Test strukturbezogener Test änderungsbezogener Test 6

7 2. Testen im Softwarelebenszyklus 7

8 Grundlagen des Testens Fundamentaler Testprozess Beginn Planung und Steuerung Analyse und Design Realisierung und Durchführung Auswertung und Bericht Abschluss In Anlehnung an den International Software Testing Qualifications Ende Board (ISTQB) - Lehrplan Quelle: Spillner, A.., Basiswissen Softwaretest, S. 20 8

9 Testen im Softwarelebenszyklus Das allgemeine V-Modell funktionaler Systementwurf technischer Systementwurf Systemtest Integrationstest Abnahmetest Anforderungsdefinition Komponentenspezifikation Komponenetentest Verifikation Validierung Programmierung Konstruktion & Integration Quelle: Spillner, A.., Basiswissen Softwaretest, S. 40 9

10 Testen im Softwarelebenszyklus Komponententest prüft einzelne Komponenten (Module, Units, Klassen) werden einzeln für sich getestet (isoliert) Test der internen Realisierung Whitebox - Test Integrationstest Zusammenspiel von Gruppen von Komponenten Perspektive des Entwicklers verschieden Strategien zur Integration Wiederverwendbarkeit der Testtreiber des Komponententests Ziel: Schnittstellenfehler finden 10

11 Testen im Softwarelebenszyklus Systemtest nach erfolgreichem Integrationstest Perspektive des Kunden/Anwenders System als Ganzes Testumgebung nahe an Produktivumgebung Ziel: funktionale und nicht funktionale Anforderungen validieren Abnahmetest beim Kunden/Anwender vertragliche Akzeptanz Wichtig: Kunde muss Testfälle selbst entwerfen oder einem sehr guten Review unterziehen 11

12 3. Statischer Test 12

13 Statischer Test Strukturierte Gruppenanalyse Reviews nicht werkzeuggestützt intensives Lesen der Dokumente Statische Analyse Datenflussanalyse Kontrollflussanalyse Werkzeuge 13

14 Statischer Test Reviews Kosten: frühzeitige Fehlererkennung + - beseitigung Zeit: kürzere Entwicklungzeiten, weniger dynamische Tests Qualität: Wissensaustausch, dadurch verbesserte Arbeitsmethoden einzelner Personen Team: Darstellung der Zusammenhänge + einheitliches Verständnis des Prüfobjekts 14

15 4. Dynamischer Test 15

16 Dynamischer Test Begriffe Testobjekt Testtreiber Testrahmen Ziel Blackbox Whitebox 16

17 Dynamischer Test Blackbox - Verfahren (1/9) innerer Aufbau des Testobjektes ist nicht bekannt Testfälle aus der Spezifikation vollständiger Test sinnvoller Test 17

18 Dynamischer Test Blackbox - Verfahren (2/9) sinnvolle Testfälle mittels Äquivalenzklassenbildung Menge der möglichen Eingabewerte in ÄK unterteilen Repräsentant einer ÄK ergibt einen Testfall für gültige und ungültige Werte vorzunehmen 18

19 Blackbox - Verfahren (3/9) Beispiel: Weihnachtsgratifikation Dynamischer Test Parameter Äquivalenzklasse Repräsentant Gratifikation gäk1: 0 <= x <= 3 gäk2: 3 < x <= 5 gäk3: 5 < x <= 8 gäk4: x > uäk1: x < 0 uäk2: x > Quelle: Spillner, A.., Basiswissen Softwaretest, S

20 Blackbox - Verfahren (4/9) Dynamischer Test Beispiel: calculate_price (baseprice, specialprice, extraprice, extras, discount) 1. Schritt: Definitionsbereich jedes Parameter ermitteln 2. Schritt: Weitere Zerlegung mit Spezifikation 3. Schritt: Geeignete Repräsentanten auswählen 4. Schritt: Repräsentanten zu Testfällen kombinieren alle möglichen Kombinationen der Repräsentanten der gäk für jeden Repräsentanten der uäk einen extra Testfall 20

21 Blackbox - Verfahren (5/9) Dynamischer Test Parameter Äquivalenzklasse Repräsentant baseprice gäk11: [0,...,MAX_DOUBLE] uäk11: [MIN_DOUBLE,...,0[ uäk12: NaN abc specialprice gäk21: [0,...,MAX_DOUBLE] uäk21: [MIN_DOUBLE,...,0[ uäk22: NaN abc extraprice gäk31: [0,...,MAX_DOUBLE] uäk31: [MIN_DOUBLE,...,0[ uäk32: NaN abc 18 ÄK = 7 gäk + 11 uäk Anzahl Testfälle: gültige: 1*1*1*3*1 = 3 ungültige: = 11 insgesamt: 14 Testfälle extras gäk41: [0,...,2] gäk42: [3,4] gäk43: [5,...,MAX_INT] uäk41: [MIN_INT,...,0[ uäk42: NaN abc discount gäk51: [0,...,100] uäk51: [MIN_DOUBLE,...,0[ uäk52: ]100,...,MAX_DOUBLE] uäk53: NaN abc Quelle: Spillner, A.., Basiswissen Softwaretest, S

22 Blackbox - Verfahren (6/9) Dynamischer Test Testfall bestprice specialprice extraprice extras discount result NOT_VALID NOT_VALID NOT_VALID NOT_VALID NOT_VALID NOT_VALID NOT_VALID abc NOT_VALID NOT_VALID NOT_VALID abc NOT_VALID Quelle: Spillner, A.., Basiswissen Softwaretest, S. 119 Testendkriterium: ÄK-Überdeckung = (Anzahl getesteter ÄK / Gesamtzahl ÄK) * 100% 22

23 Blackbox - Verfahren (7/9) Weitere wichtige Methode: Dynamischer Test Grenzwertanalyse sinnvolle Ergänzung zur ÄK-Bildung zusätzliche Betrachtung der Ränder der ÄK hohe Kreativität des Testers erforderlich 23

24 Blackbox - Verfahren (8/9) Dynamischer Test Zusätzlicher Test bei objektorientierten Systemen: Zustandsbezogener Test bisheriger Ablauf hat Einfluss auf Systemverhalten Zustandsautomat geeignet für ganzes System oder auch einzelne Klasse minimal: Erreichung aller möglichen Zustände Ausführung aller für einen Zustand spezifizierten Fkt. Testfälle durch Übergangsbaum jeder Pfad von der Wurzel zu einem Blatt = ein Testfall 24

25 Dynamischer Test Blackbox - Verfahren (9/9) Bewertung der Blackbox-Verfahren: Grundlage sind die Anforderungen und Spezifikationen Fehler in Anforderungen/Spezifikationen können nicht festgestellt werden Mittelpunkt: Funktionalität des Testobjekts prüfen 25

26 Whitebox - Verfahren (1/5) Dynamischer Test codebasierter Test Idee: alle Quellcodeteile des Testobjekts kommen zur Ausführung Testfallerstellung und -bewertung anhand der Spezifikation Ziel: festgelegte Überdeckung der Anweisungen 26

27 Whitebox - Verfahren (2/5) Dynamischer Test Anweisungsüberdeckung IF a Ausführung von Anweisungen C0-Maß = (Anz. durchl. Anw. / Gesamtz. Anw.) * 100% c IF b i DO f g k Hier 100% mit einem Testfall: a, b, f, g, h, d, e ENDIF d WHILE h ENDIF e Quelle: Spillner, A.., Basiswissen Softwaretest, S

28 Whitebox - Verfahren (3/5) Dynamischer Test Zweigüberdeckung a Auswertung der Bedingungen b IF C1-Maß = (Anz. durchl. Zweige / Gesamtz. Zweige) * 100% c IF i DO f g k Hier 100% mit drei Testfällen: WHILE h a, b, c, d, e ENDIF d a, b, f, g, i, g, h, d, e a, k, e ENDIF e Quelle: Spillner, A.., Basiswissen Softwaretest, S

29 Whitebox - Verfahren (4/5) Dynamischer Test Pfadüberdeckung Auswertungen von Schleifen 100% Abdeckung nie erreichbar, wenn Programm nicht trivial c IF b i DO f g IF a k 1-mal: a, b, f, g, h, d, e (ohne Rücksp.) 2-mal: a, b, f, g, i, g, h, d, e WHILE h 3-mal: a, b, f, g, i, g, i, g, h, d, e usw. ENDIF d ENDIF e Quelle: Spillner, A.., Basiswissen Softwaretest, S

30 Whitebox - Verfahren (5/5) Dynamischer Test Bewertung der Whitebox-Verfahren: Grundlage: vorliegender Programmcode geeignet für untere Teststufen fehlende Anforderungen werden nicht erkannt 30

31 5. Besondere Tests 31

32 Besondere Tests GUI-Test: durch optische Prüfung (Testfälle mit Zustandsautomat) Testfälle mit Zustandsautomat sehr zeitaufwändig Capture & Replay beim Aufzeichnen werden nicht nur x/y-koordinaten berücksichtigt Aufzeichnung in Skriptsprache Soll-Ist-Vergleiche lassen sich mit aufnehmen Problem: bei Änderung der GUI stimmt evtl. Skript nicht mehr 32

33 Besondere Tests Testen von Client/Server-Anwendungen: Client: isoliert vom Server Funktionalität des Servers nötigt simuliert durch Dummy/Mock-Objekten 33

34 Besondere Tests Testen von Client/Server-Anwendungen: Server: gestestet wird gegen die Schnittstelle des Servers Testreiber simuliert den Client Datenbank durch Dummy/Mock 34

35 Diskussion 35