VU Softwarequalit - PowerPoint PPT Presentation

1 / 35
About This Presentation
Title:

VU Softwarequalit

Description:

VU Softwarequalit tssicherung WS2003 Testen von Softwaresystemen Dipl.-Ing. Denis Frast denis.frast_at_qse.ifs.tuwien.ac.at Institut f r Softwaretechnik und ... – PowerPoint PPT presentation

Number of Views:52
Avg rating:3.0/5.0
Slides: 36
Provided by: DenisF150
Category:

less

Transcript and Presenter's Notes

Title: VU Softwarequalit


1
VU Softwarequalitätssicherung WS2003Testen von
Softwaresystemen
  • Dipl.-Ing. Denis Frast
  • denis.frast_at_qse.ifs.tuwien.ac.at
  • Institut für Softwaretechnik und Interaktive
    Systeme

2
Was kostet Qualität?
Minimum der Gesamtkosten
3
Testkosten und Qualität in der Praxis
Fehlerkosten
Test- bzw. Fehlerkosten
Testkosten
Testzyklus
4
Definition des Begriffs Testen
  • Testen wird oft falsch definiert
  • Testen ist der Prozess, der zeigen soll, dass ein
    Programm keine Fehler enthält
  • Testen soll zeigen, dass ein Programm seine
    Spezifikation erfüllt
  • Testen ist der Prozess, der das Vertrauen
    erzeugt, dass ein Programm das tut, was es soll

5
Was ist Testen?
  • Testen istAufdecken von möglichst vielen
    Fehlern 
  • Testen ist nichtFehlerstellen lokalisieren und
    Fehler entfernen (Debuggen)
  • Testen ist nicht Fehlerfreiheit nachweisen
    (das geht nur mit einem Korrektheitsbeweis!)

6
Testen von Software
  • Was ist Testen?
  • Testen ist das Ausführen eines Programms, mit
    der Absicht, Fehler zu finden. Myers 1979
  • Was ist ein Fehler?
  • Ein Fehler ist eine Abweichung zwischen einem
    Programm und dessen Spezifikation. Kaner et
    al., 1999
  • Testen als Teil des Qualitätsmanagements ist ein
    wichtiger und fortlaufender Bestandteil des
    Software-Entwicklungsprozesses, nicht bloß eine
    Pflichtübung am Ende

7
Testen Ein Beispiel
  • Ein Programm liest 3 ganze Zahlen a, b und c und
    soll feststellen, ob sie die Seiten eines
  • gleichseitigen Dreiecks
  • gleichschenkligen Dreiecks
  • rechtwinkeligen Dreiecks
  • sonstigen gültigen Dreiecks
  • bilden.
  • Mit welchen Eingaben würden Sie es testen?

8
Beispiel Testfälle
  • Gültige Dreiecke
  • Gleichseitig 3, 3, 3
  • Gleichschenkelig 5, 5, 3
  • Rechtwinkelig 3, 4, 5
  • Sonstiges 3, 5, 7
  • Permutationen davon(3,5,5), (5,3,5),(3,5,4),
    (4,5,3), (4,3,5), (5,3,4), (5,4,3),(3,7,5),
    (5,7,3), (5,3,7), (7,3,5), (7,5,3)
  • Ungültige Dreiecke
  • ab lt c 3, 3, 7
  • ab c 3, 4, 7
  • Negative Seitenlänge 3, 4, -5
  • 0, 0, 0
  • Nur 2 Seitenlängen 3, 4
  • Permutationen davon (3,7,3), (7,3,3),(3,7,4),
    (7,4,3),...(3,-5,4), (-5,3,4)...
  • Haben Sie überall das erwartete Ergebnis
    dazugeschrieben?

9
Testfälle
  • Tests bestehen aus einer Menge von Testfällen
    (Testsuite)
  • Ein Testfall besteht aus einer Menge (V, E, A, R)
  • V Vorbedingungen
  • E Eingabewerte
  • A Aktionen zur Eingabe der Werte
  • R erwartete Ergebnisse
  • Testerfolg
  • Ein Testfall ist erfolgreich, wenn er einen
    Fehler gefunden hat
  • kein Fehler ? Information über Produktqualität
    (Testüberdeckung!)

10
Qualität von Testfällen
  • Fehlerfindungsrate Wahrscheinlichkeit, Fehler zu
    finden
  • Fehlerlokalisierung Einschränkung der
    Fehlerlokation
  • Testüberdeckung Wenige gute überdecken mehr als
    viele schlechte
  • Komplexität Allzu komplexe Testfälle sind selten
    zur Gänze durchführbar! ? Kompromiss zwischen
    Anzahl und Komplexität!
  • Generalität so allgemein wie möglich und so
    genau wie nötig ? generische Beschreibung der
    relevanten Eigenschaften ohne konkrete Werte
    diese werden erst beim Test inkludiert

11
Testfälle Negativ-Beispiel 1 (Badeanstalt)
  • Zwei an sich gute Testfälle testen dasselbe
  • TF 1
  • V Schlüssel ist Garderobeschlüssel, zum
    Schlüssel existiert ein noch nicht
    zurückgegebenes Codeband.
  • E/A Kunde gibt Schlüssel zurück
  • R Automat akzeptiert Schlüssel
  • TF 2
  • V Codeband noch nicht zurückgegeben
  • E/A Codeband und Schlüssel werden zurückgegeben
  • R Ausgang wird freigegeben

12
Testfälle Negativ-Beispiel 2 (Bibliothek)
  • Vermischung von Eingaben und Ergebnissen
  • TF 1
  • V -
  • E/A Leser möchte Buch x entlehnen
  • R Entlehnung wird vom System zugelassen
  • TF 2
  • V -
  • E/A Leser möchte Buch x entlehnen
  • R Entlehnung wird nicht zugelassen
  • vielleicht fehlt aber auch nur die Vorbedingung
    Buch x ist entlehnbar / nicht entlehnbar

13
Testfälle Negativ-Beispiel 3 (Bibliothek)
  • kein Ergebnis
  • TF 1
  • V -
  • E/A Leser möchte Buch x entlehnen
  • R -

14
Testfälle Negativ-Beispiel 4 (Bibliothek)
  • keine Eingabe an das System bzw. kein vom System
    beeinflusstes Ergebnis
  • TF 1
  • V -
  • E/A Person kann sich nicht ausweisen, gibt aber
    Adresse bekannt. Leser soll angelegt werden.
  • R Leser wird ohne Vorlage eines Ausweises nicht
    angelegt. Leserkarte wird nicht ausgegeben

15
Testfall-Spezifikationsmethoden
  • Strukturierte Anweisungen zur Generierung von
    Testfällen
  • Vorteile gegenüber zufälliger Testfalldefinition
  • Höhere Qualität der Testfälle
  • Machen Qualität und Intensität eines Tests
    transparent
  • Erreichen gewünschte Abdeckung für jeden Teil der
    Applikation
  • Effektiver für gegebene Fehlertypen
  • Tests werden nachvollziehbar
  • Testprozess wird unabhängig von Personen
  • Testfall-Spezifikationen werden übertragbar und
    aktualisierbar
  • Testprozess wird besser plan- und steuerbar
  • Nachteile
  • Fundiertes Wissen der Tester notwendig

16
Black Box vs. White Box
  • Black Box
  • Basiert auf Spezifikation
  • Wissen über innere Struktur wird ignoriert
  • Daten-getriebene, Input-Output-getriebene Tests
  • Anforderungsüberdeck.
  • Partitionierung der Eingabe-Daten
  • White Box (Glass Box)
  • Basiert auf Code(struktur)
  • Wissen über innere Struktur notwendig
  • Logik-getriebene Tests
  • Überdeckung von Pfaden im Kontrollflussgraphen
  • Partitionierung von Daten f. Bedingungsauswertung

17
Ableitungsprinzipien
  • Überdeckungsmaße geben Testintensität an
  • Pathn coverage Pfade der Länge n
  • Anweisungs- bzw. Knotenüberdeckung (C0)
  • Entscheidungs- bzw. Kanten-Überdeckung (C1)
  • Bedingungsüberdeckung
  • Anforderungsüberdeckung
  • Abdeckung aller Eingaben, Ausgaben, Funktionen...
  • Äquivalenzklassen
  • Grenzwertanalyse
  • Verarbeitungslogik
  • CRUD-Matrix
  • Ursache/Wirkungs-Graphen
  • Zustandsübergänge
  • Error Guessing

18
Äquivalenzklassenzerlegung
  • Zerlegung einer Menge von Daten (Input oder
    Output) in Untermengen (Klassen), welche das
    selbe oder ähnliche Ergebnisse oder Auswirkungen
    produzieren
  • Jede Klasse(nkombination) sollte mindestens
    einmal getestet werden
  • Bestimmung des Eingabe-Vektors (A,B,C,...) und
    der Ausprägungen (Klassen A1, A2, ... B1, B2,
    ... ...)
  • Anforderung 18 lt Alter ? 65 ? drei
    Äquivalenzklassen
  • A1 Alter ? 18 (ungültig)
  • A2 18 lt Alter ? 65 (gültig)
  • A3 Alter gt 65 (ungültig
  • Drei Testfälle x ? A1, z.B. 10, x ? A2, z.B. 35,
    x ? A3, z.B. 70
  • Kombinationen (A1, B1), (A1,B2), ...

19
Grenzwertanalyse
  • Erweiterung der Äquivalenzklassenzerlegung für
    bessere Überdeckung
  • Grenzwerte werden als Klassenrepräsentanten
    gewählt ? je Klassengrenze ein Testfall
  • Anforderung 18 lt Alter ? 65
  • 18 (ungültig), 19 (gültig), 65 (gültig) and 66
    (ungültig)
  • Ev. mehrere Testfälle je Klassengrenze Alter ?
    18
  • 17 (gültig), 18 (ungültig) and 19 (ungültig)
    Bedenke Tippfehler Alter 18!

20
Strukturtest Testmaß 1
  • Pfade der Länge 1
  • - (1)
  • A (2) (3) (4)
  • B (5) (6)
  • Testfälle
  • (1, 2, 5)
  • (1, 3, 6, 4, 5)

21
Strukturtest Testmaß 2
  • Pfade der Länge 2
  • A (1,2) (1,3) (1,4) (6,2) (6,3) (6,4)
  • B (2,5) (3,5) (4,5) (2,6) (3,6) (4,6)
  • Testfälle
  • (1, 2, 5)
  • (1, 3, 5)
  • (1, 4, 5)
  • (1, 2, 6, 2, 5)
  • (1, 3, 6, 4, 6, 3, 5)

22
Datenzyklustest
  • Bilde CRUD-Matrix
  • Testfälle für jede Entität
  • Create, Read
  • Update, Read
  • Delete, Read
  • Relationen nicht vergessen!

Entität 1 Entität 2 Entität 3
Funktion 1 R C, U, D -
Funktion 2 C R -
Funktion 3 C, R, D - -
23
Testen als Prozess
  • Also was tun Sie wenn Sie die Aufgabe bekommen,
    ein Programm zu testen?
  • Unter Testen versteht man den Prozess des
    Planens, der Vorbereitung und der Messung, mit
    dem Ziel, die Eigenschaften eines IT-Systems
    festzustellen und den Unterschied zwischen dem
    tatsächlichen und dem erforderlichen Zustand
    aufzuzeigen. Pol et al., 2000
  • Phasen im Testprozess
  • Planung und Verwaltung
  • Spezifikation
  • Durchführung
  • Abschluss

24
Testmanagement
  • Umgang mit
  • verschiedenen Abteilungen im Unternehmen
  • gegensätzlichen Interessen
  • Unvorhersehbarkeit
  • Komplexen administrativen Aufgaben
  • Mangel an Erfahrung(-szahlen)
  • Zeitdruck
  • Organisatorische Aspekte
  • Betrieblich Wie viele Personen? Wann sollen sie
    was tun? Welches Wissen benötigen sie? ...
  • Strukturell Welche Organisationsstruktur? Ein
    Test-Team für alle Projekte? ...
  • Management Verwaltung und Kontrolle
  • Personal und Ausbildung Kurse und Motivation

25
CM im Testprozess
  • Dokumente
  • Testplan
  • Testfall-Spezifikationen
  • Testprotokolle (auch ad hoc erfundene Testfälle!)
  • Spezifikation, Design, ...
  • Fehlerverfolgung
  • Fehlerverfolgungs-Tool
  • Definierter Workflow
  • Testware
  • Backups der Test-DB
  • Freigabe-Versionen f. Test

26
Position von Testen im SE-Prozess
27
Teststufen und Testtypen
  • Teststufen
  • Komponententest
  • Integrationstest
  • Systemtest
  • Regressionstest
  • Akzeptanztest
  • Testtyp
  • Funktionaler Test
  • Massentest
  • Stresstest
  • Performance-Test
  • Review
  • etc.
  • Jede Teststufe besteht aus einem oder mehreren
    Testtypen
  • Jeder Testtyp testet ein oder mehrere
    Qualitätskriterien und verlangt eigene
    Test-Methoden

28
Beispiel Test IBS
  • Insurance Business Server
  • E-Commerce Applikation zur Erfassung von
    Versicherungsanträgen über einen Internet-Browser
  • DHTML-Frontend, generiert aus XML-Schnittstelle
    mittels XSLT, basierend auf Produktmodelldaten
    aus DB
  • Kommunikationsschnittstelle von IIS-Webserver zu
    Unix Backend-Server über VB-Programm und COM
  • Antragsberechnung auf Unix-Server mit Natural und
    Oracle
  • Entwicklungsaufwand ca. 100 (125) Personenmonate
    (PM)
  • Tests
  • Modultest Statement-Abdeckung (C0)
  • Integrationstest mehrere Phasen mit
    verschiedener Modul-Zusammensetzung und
    speziellen Treiberprogrammen
  • Lasttest Simulation von steigender Anzahl
    Anträge
  • Testaufwand ca. 25 (40) PM

29
Beispiel Architektur des IBS
30
Planung und Durchführung von Tests
  • Finden einer Teststrategie
  • Die wichtigsten Fehler so früh wie möglich mit
    geringen Kosten zu finden ? effizienter
    Personaleinsatz, solider Testbericht!
  • Variation in der Testintensität je
    Produktkomponente
  • Eigene Strategie für jede Teststufe
  • Testfallspezifikation
  • Definition der Testfälle der Teststrategie
    entsprechend
  • Checklisten
  • Test von Qualitätskriterien ohne
    Programmausführung
  • Review-Techniken
  • Dokumente und Source-Code im Team prüfen

31
Qualitätskriterien nach ISO 9126 / DIN 66272
32
Test-Strategie Generisches Beispiel
Kompon. (kLOC)Kriterium Teilsyst. 1 (50) Teilsyst. 2 (20) Teilsyst. 3 (15) Migration (10) Gesamt-system (5) Relative Bedeutung
Sicherheit       5
Einsetzbarkeit           -
Kontinuität           -
Kontollierbarkeit           -
Funktionalität 60
Benutzungs-freundlichkeit       10
Leistung       5
Integrierbarkeit   20
Sparsamkeit           -
Rel. Bedeutung 30 15 20 15 20 100
33
Teststrategie Funktionaler Test
Kompon.Methode G/B TF / kLOC Teilsyst. 1 (50/30) Teilsyst. 2 (20/15) Teilsyst. 3 (15/20) Migration (10/15) Gesamt (5/20)
Strukturtest Maß 2 80  
Strukturtest Maß 1 60
Entsch.tabellentest 40  
Datenzyklus-Test 30    
Error Guessing 10
  • Schätze Anzahl Testfälle je Methode und
    Größeneinheit sowie Aufwand je Testfall (wenn
    möglich, aus empirischen Daten!)
  • Ermittle Aufwand für mehrere verschiedene
    Szenarien (hier H, M, L) für Angebote, Reaktion
    auf eingetretene Risken etc.
  • Beispiel Definiere 3 Szenarien H, M, L.

34
Zusammenfassung
  • Testen hat zum Ziel, Fehler zu finden
  • Testfälle sind Eingaben an das System mit
    definierten erwarteten Ergebnissen
  • Testfall-Spezifikationsmethoden sind
    strukturierte Anweisungen zur Generierung von
    qualitativ hochwertigen Testfällen mit vielen
    Vorteilen gegenüber zufälligen Tests
  • Eine Teststrategie hat zum Ziel, die wichtigsten
    Fehler so früh wie möglich mit geringen Kosten zu
    finden
  • Testen ist ein Prozess, der den gesamten
    Software-Lebenszyklus begleitet
  • Der Testprozess basiert auf vier Eckpfeilern
  • Phasenmodell
  • Brauchbare Methoden
  • Ressourcen und Infrastruktur
  • Organisatorische Einbettung

35
Literaturempfehlungen
  • Martin Pol, Tim Koomen, Andreas Spillner
    Management und Optimierung des Testprozesses
    ein praktischer Leitfaden für erfolgreiches
    Testen von Software, mit TPI und TMap,
    dpunkt.verlag, 2000, ISBN 3-932588-65-7
  • Cem Kaner, Jack Falk, Hung Quoc Nguyen Testing
    Computer Software", Wiley, 1999, ISBN
    0-471-35846-0
  • DeMarco, Tom Der Termin Ein Roman über
    Projektmanagement, Carl Hanser Verlag, 1998,
    ISBN 3-446-19432-0
  • Thaller, "Software-Test", dPunkt, 2002
  • Spillner et al., "Basiswissen Software-Test",
    dPunkt, 2003
Write a Comment
User Comments (0)
About PowerShow.com