QS in Softwareentwicklungsprojekten II Testpolitik / Testhandbuch Teststrategie / Testvorgehen

Lernziele Sie können ... den Zweck und Inhalt eines Testhandbuchs darlegen. eine geschickte Teststrategie wählen. die Testmethoden erläutern und anwenden.

Literatur IT-Systeme prüfen Kapitel 3 – Teststrategie

Testpolitik – Testhandbuch – Testvorgehen

Vision  Strategie Vision Unternehmensstrategie Qualitäts- Management (QM) IT-Strategie ... ... QS-Plan ... Teststrategie (Testpolitik, Testhandbuch) Testplan Projekt ... Testplan Projekt B Testplan Projekt A

Prüf-/Testpolitik Teil der Qualitätspolitik Spiegelt Unternehmensphilosophie wieder Anzustrebendes Qualitätsniveau Festlegung des QS-Prozesses Einbettung/Bedeutung Evaluierung des Testens Z.B. Kostenmessung von Fehlern Verfahrensansatz für die Testprozessverbesserung Z.B. Maturiätsmodelle (CMM, TMM)

Testhandbuch als Rahmendokument Generische projektübergreifende Richtlinien und Methodiken Darstellung der Risiken und effiziente Massnahmen Aufzuziehende Testorganisation Richtlinien für Testumgebung Infrastruktur Testwerkzeuge Workflow des Testprozesses Einsatz von Testmethoden und Testarten (Teststufen) regeln Firmeninternes Glossar Vorlagen für Test- und Berichtsdokumente bzw. Softwareeinsatz

Risikoanalyse Risiko = Wahrscheinlichkeit eines Ereignisses * Schadensausmass Mit Risikoanalyse Risiken identifizieren: Produktrisiken Technische Faktoren (z.B. Softwarefehler) Betriebssicherheit Datensicherheit Projektrisiken Termin-/Kostenüberschreitung Politische Faktoren

Kritikalitätsstufen

Risikoorientierte Teststrategie Planung aufgrund der Kritikalität*: Auswahl der Testverfahren/Testmethoden/Testarten Festlegung der Testtiefe je Testobjekt Testfallpriorisierung (Hardest-First Test) Prüfen/Testen ist eine präventive Massnahme, um Risiken zu Reduzieren! * kategorisierte Risiken: gering, mittel, hoch mit quanitativen und qualitativen Bewertungen

Teststrategie (i.e.S.) Vorgehen im konkreten Projekt Festlegen: Ziel: der Prüfobjekte (was wird getestet) der Testarten (wie wird getestet) der Testmethoden (mit welcher Methode wird getestet) Ziel: mit möglichst wenigen Fällen die risikoreichsten Teile abdecken i.e.S.  im engeren Sinne

Zu berücksichtigende Testgrundsätze Fehlerabwesenheit kann nicht nachgewiesen werden Die Fehlerbehebungskosten steigen exponential: Je früher ein Fehler unterläuft Je später ein Fehler entdeckt wird Testpsychologie Prüfen/Testen soll andere als die Autoren sein Pareto-Prinzip anwenden: mit 20 % des theoretisch möglichen Testaufwandes 80 % der enthaltenen Fehler finden

Testvorgehen I: Big-Bang Gesamtes System erst testen, wenn Entwicklung abgeschlossen Vorteil: keine Drivers oder Stubs (Testsoftware) notwendig Nachteil: Zeitverlust – später Testbeginn Komplexität – Finden der Fehlerursache

Testvorgehen II: Vertikales Testen Funktional orientiertes Testen Vorteil: Zeitvorteil: sobald eine Funktionalität über alle Schichten fertig erstellt ist, kann getestet werden begrenzte Komplexität, keine spezielle Testsoftware notwendig

Testvorgehen III: Horizontales Testen Schichtenweises Testen Top-Down (Outsight In) – vom GUI her testen Bottom-Up (Insight Out) – vom Backend her testen Vorteil: Eingrenzung der Komplexität Nachteil: Spezielle Testsoftware notwendig

Testfallermittlung

Testfallermittlung Problem: immense Anzahl der Testfälle Geschickte Ermittlung und Auswahl: Ziel ist, mit möglichst wenig Fällen möglichst viele Fehler entdecken! Zwei sich ergänzende Arten: exploratives Testen methodisches Testen

Exploratives Testen Intuitives Vorgehen Unsystematische Testtechnik Ad-hoc Testen Zufallstest Abhängig von der Erfahrung des Testers Error guessing  herausspüren von Fehlern Sollte in jedem Falle dokumentiert sein Keine systematische Testabdeckung möglich!

Methodisches Testen Whitebox Test Greybox Test Blackbox Test Verzweigungen Anweisungen Greybox Test Komponente Blackbox Test Verhalten Anwendungsfälle Schnittstellen

Whitebox (Glassbox) Testverfahren Innere Struktur bekannt  Strukturtest Einsatz vor allem beim Unit-Test Nachweisbare Testabdeckung (Testüberdeckung): Anweisungsabdeckung Zweigabdeckung Bedingungsabdeckung Pfadabdeckung

Ablaufgraph I Anweisung, Anweisungsblock Bedingungen if ... then ... else case

Ablaufgraph II Schleifen do while repeat until

Testabdeckungsanalyse

Testabdeckung/Testüberdeckung 100%-ige Anweisungsabdeckung: Alle Anweisungsblöcke werden mit mindestens einem Testfall durchlaufen 100%-ige Zweigabdeckung: Alle Zweige werden mit mindestens einem Testfall durchlaufen 100%-ige Bedingungsabdeckung (Termabdeckung): Für jede Termkombinationen gemäss der Wahrheitstabelle gibt es einen Testfall: 100%-ige Pfadabdeckung: Alle mögliche Programmpfade werden mit je einem Testfall abgedeckt (meist nicht möglich) Problematik bei Schleifen (Keinmal, Einmal, Mehrmals, Max. Anzahl) Term 1 Verknüpfung mit (A=5) (B=7) AND OR Testfall 1 wahr Testfall 2 falsch Testfall 3 Testfall 4

Nachweis der Testabdeckung Nachweis mittels Coverage Monitor Instrumentalisieren des Programms Ausführen aller Testfälle Auswerten des Testabdeckungsgrads

Blackbox Testverfahren Interne Funktionsweise unbekannt oder für Test irrelevant Wichtig für die Bestimmung der Testfälle: Schnittstellen: Input Output erwartetes Verhalten Einsatz: Unit-Test (Blackbox ist die einzelne Komponente) Systemtest (Blackbox ist das ganze System) Techniken: Äquivalenzklassenbildung Grenzwertanalyse Zustandsbezogene Tests

Äquivalenzklassenbildung Wertebereich mit gleichartigen Aktionen Vorgehen zur Bildung: Auf Zahlengerade pro Parameter beschriebene Werte abtragen Äquivalenzklassen herauslesen (von einem Wert zum nächst folgenden Wert) Äquivalenzklassen überschneiden sich nie Vollständig: keine Lücken auf Zahlengerade Zuordnen der Aktionen je Äquivalenzklasse Beispiel: Modul mit Nettowarenwertberechnung gültiger Bruttowarenwertbereich: 5 – 10000 Beträge zwischen 1000 und 10000 erhalten 5 % Rabatt Beträge über 5000 erhalten zusäztlich 200 Bonus

Grenzwertanalyse Ergänzend zur Äquivalenzklassenbildung Ermitteln von Testfällen rund um die Grenzen der Äquivalenzklassen Je Äquivalenzklasse je den minimalen und maximalen Wert als konkreten Testfall nehmen Zusätzlich sind mögliche Fehler bzw. Extremwerte zu ermitteln

Zustandsbezogener Test I Einsatz in der objektorientierten Programmierung (OOP) neuer MA [Anzahl < Max - 1] neuer MA * MA geht [Anzahl > 1] Start neuer MA [Anzahl = Max - 1] neuer MA niemand im Büro Einige sind anwesend Volle Besetzung MA geht [Anzahl = 1] MA geht Ende Zustandsbeschreibung Zustandsübergang [Anzahl = 1] Bedingung unter welcher Zustandsübergang vorgenommen wird

Zustandsbezogener Test I Ableiten der Testfälle anhand des Übergangsbaumes: I Zustände: I = Initial (Ausgangsbasis) N = Niemand im Büro E = Einige sind anwesend V = Volle Besetzung F = Fehler, nicht erlaubt D = Deleted (Beendigt) Zustandsübergänge: i = init (Starten) + = MA kommt - = MA geht d = delete (Beenden) i N d - D + F E - [Anzahl = 1] + [Anzahl = Max – 1] + [Anzahl < Max – 1] - [Anzahl > 1] V N E - + F E

Übungen Fallstudien 3 - Teststrategie 4 und 5 – Whitebox-Test 6 und 7 – Black-Box-Test