Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Größe: px

Ab Seite anzeigen:

Download "Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1"

Stephanie Weiner
vor 8 Jahren
Abrufe

1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1

2 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2

3 Software Test / Erprobung Messen der Qualität der Software. Zuverlässigkeitsabschätzung. Vergleich des Verhaltens mit den Anforderungen. Verifizierung und Validierung. Finden von Fehlern bevor ein Kunde diese findet. Qualitätsverbesserung. 9-3

4 Testphasen Modultest / Unit Test. Test einzelner Module. Integrationstest. (IVT) Test ob alle Module zusammenpassen. Systemtest. (SVT) Testen des Systems unter realistischen Bedingungen. Abnahmetest. Vergleich mit dem Pflichtenheft/Vertrag. 9-4

5 Weitere Testphasen Funktionale Tests. (FVT) Prüfen ob einzelne Funktionen korrekt arbeiten. Performance Test. Prüfen ob das System den erwünschten Datendurchsatz erreicht. Installationstest. Läßt sich die Software auf allen Zielsystemen installieren? Stresstest. Testen des Verhaltens in Extremsituationen. Regression Test. Prüfen in einer neuen Programmversion alle wichtigen Funktionen noch funktionieren. 9-5

Läßt sich die Software auf allen Zielsystemen installieren? Stresstest.

6 Modultest / Unit Test Durchgeführt von Entwicklern. Ziel die neu entwickelten Code Pfade zu prüfen. 9-6

7 Funktionale Tests. Test einzelner Komponenten gegen das Design. Möglichst vollständige Abdeckung der Eingabeparameter. Inklusive möglicher Fehler. 9-7

8 Integrationstest Test ob getrennt entwickelte Komponenten zusammenarbeiten. Fokus auf Testen der Schnittstellen. Test auf Zusammensetzbarkeit. 9-8

9 Systemtest Test ob das entwickelte Produkt mit externen Komponenten als System zusammenarbeitet. Kenntnisse der typischen Verwendung des Produktes beim Kunden erforderlich. Kenntnisse der Arbeitsweise externer Programme nötig. System als ganzes muss auf injezierte Fehler reagieren können. Testen mit unterschiedlichen Programmversionen. 9-9

Kenntnisse der typischen Verwendung des Produktes beim Kunden erforderlich.

10 Abnahmetest Test ob die im Vertrag vereinbarten Requirements eingehalten werden. Teilweise ist die Spezifikation von Abnahmetests Vertragsbestandteil. 9-10

11 Performance Test Testen der Performance des Produktes. Test gegen Spezifikation des Designs. Finden von Performance Regressionen. 9-11

12 Installationstest Test ob das finale Produkt installierbar ist. Test ob Basisfunktionalität existiert. Vermeiden von peinlichen Fehlern im letzten Produktionsschritt. 9-12

13 Stresstest Testen des Produktes in Extremsituationen. Test mit real nicht vorkommender Last. Rückschlüsse auf Stabilität. Simulation von typischer Fehlerdichte über den Produktlebenscyclus in kurzer Zeit. 9-13

14 Regression Test Prüfen existierender Funktionalität in neuen Programmversionen. Nach kurzer Zeit wichtigster Test. Muss bei modernen Entwicklungsmethoden vollautomatisch passieren. 9-14

15 Testaufwand Testaufwand tyischerweise 2x höher als Entwicklungsaufwand. Oft gleichviele Tester aber deutlich mehr Hardware als in der Entwicklung. 9-15

16 Anzahl Fehler im Entwicklungszyklus Plots der Anzahl offener und gelöster Fehler geben Auskunft über Produktqualität und zu erwartende Dauer der Testphase. Fehler Gefunden Fehler Gefunden Gelöst Gelöst Abnehmende Fehleranzahl. Kleiner Fehlerpool. t t Weitere Fehler wahrscheinlich. Großer Fehlerpool. 9-16

17 IEEE 829 Dokumente Übersicht Testkonzept (Test Plan) Test Spezifikation Test Design Spezifikation Testfall Spezifikation Test Ablauf Spezifikation Test Beschreibung Testfall Übertragunsbeschreibung Test Protokoll Test Störfall Beschreibung Test Zusammenfassung 9-17

Test Ablauf Spezifikation Test Beschreibung Testfall

18 IEEE 829 Dokumente Spezifiziert Dokumente mit Name, Inhalt und Form. Läßt offen wann welche Dokumente eingesetzt werden sollten. 9-18

19 Probleme Testabdeckung bei komplexer Software schwierig. Realistische Testlast nicht immer verfügbar aus Kostengründen. 9-19

20 Alternativen Formale Verifikation Scheitert wie Tests an der Komplexität, nur früher. Fehleranfällige Software Designs vermeiden. 9-20

21 Testautomation Komplexe Software erfordert eine Vielzahl an Tests. Diese Tests sind z.t. ähnlich und müssen in Varianten durchgeführt werden. Nach Änderungen an der Software sind viele Tests erneut durchzuführen. Im Falle von beim Kunden aufgetretenen Fehlern bleibt für den Test nur wenig Zeit. => Testautomation 9-21

22 Test framework Starten von Einzeltests. Typische Funktionen zum Festhalten von Ergebnissen. Abbrechen von endlos laufenden Tests. Zusammenfassen der Ergebnisse. => Test Frameworks sind relativ einfach. => Es gibt eine große Menge an Test Frameworks. 9-22

23 Kommerzielle Test frameworks Es gibt kommerzielle Test Frameworks. In Firmen sind Test und Development oft getrennt. Zusatzfunktionen zum schreiben von Tests. Integrierte IDE. Spezielle Unterstützung von Programmiersprachen. Vorgefertigte Hocks für normalen Code. Einfach zu bedienen von nicht Programmierern. => Vendor Lock-In => Keine Wiederverwendbarkeit bei Wechsel des TF. 9-23

24 Tests für test frameworks Tests unabhängig vom Test Framework schreiben. Nutzen einer Schnittstelle. Tests einzeln starten können mit trivialer Schnittstelle. Logs und Traces an ein framework weiterleiten. Test cases abbrechen können. Ausganszustand wiederherstellen können. Neukonfiguration. Eventuell automatische Neuinstallation. 9-24

25 Wieso unabhängige Tests? Software Projekte verwenden oft mehrere Komponenten. Nicht alle in der selben Programmiersprache geschrieben. Teilweise von alten Projekten. Einige Komponenten sollen wiederverwertbar sein. Test Frameworks ändern sich im Laufe eines Projektes. Programmierer können eigene Tests schreiben. Gleichzeitiger Einsatz mehrerer Test Frameworks. 9-25

26 Test Test Input Software Test Output Daten identisch? Referenzdaten Nein Ja Manuelle Analyse Test Fehler Test Erfolgreich 9-26

27 Basic test automation cat test01-input.txt testprog testparam > test01-output.txt fc /b test01-output.txt test01-reference.txt if ERRORLEVEL 1 echo test01 failed >> testresult.txt 9-27

28 Beispiel Upstart Upstart ist auf modernen Linux Systemen der erste laufende Prozess. Ersetzt init. Startet weitere Programme, insbesonde Login Shells und Services. Programmcode ca Befehle in C. Testcode ca Befehle in C. 9-28

29 Beispiel Samba Samba ermöglicht Windows interoperabilität für Unix. Bietet insbesondere CIFS File System Dienste an. Print Services, Domain Controller. Vollautomatische Regression Tests bei Code Checkin. Tests unterteilt in Muß fehlschlagen Muß funktionieren Darf fehlschlagen 9-29

30 Test driven development Um Veränderungen schnell durchführen zu können darf man keine Angst vor Veränderungen haben. Umfangreiche, automatisierte Tests garantieren, daß eine Veränderung keine Nebeneffekte hat. Tests werden vor dem Programmcode entwickelt. Aber: Vollständige Tests sind bei komplexen Problemen nicht möglich. Viele Produkte setzen Hardware voraus. Eine vom Test steuerbare Simulation der Hardware ist nötig. Methoden der 9-30

31 Test driven development Nur möglich wenn die Schnittstelle für Test im Voraus vollständig spezifiziert ist. Schwierig bei komplexen Projekten. Führt oft dazu, daß die Testbarkeit beim Design bereits berücksichtigt wird. Einbau von Schnittstellen zum einfachen Testen. Reduktion der Komplexität hinsichtlich Test. Oftmals der wahre Vorteil von TDD. 9-31

Ähnliche Dokumente

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 9. Vorlesung 1 Pläne Kein Plan überlebt die erste Feindberührung - Feldmarschall Helmuth von Moltke Prognosen sind schwierig, besonders wenn sie die Zukunft