IST FL
Für den persönlichen Gebrauch...
Für den persönlichen Gebrauch...
-
- 1 / 70
-
Lernkarten
Dynamische Tests
- Whitebox
- Blackbox
- Erfahrungsbasiert
Zustandsbezogene Test
- Historie / Zustand beinflusst die Verarbeitung von Eingabe
- GUI-Tests sind oft ZT
Review Phasen
- Planung (Welches Dokument Wann durch Wen prüfen)
- Einführung / Kickoff (Einladung + Vorstellung des Prüfdokuments und Basisdokumente + Prüfkriterien)
- Vorbereitung (Individuell)
- Reviewsitzung (max 2h, Abbruch möglich, Moderator <> Gutachter, Konsens protokollieren, Protokoll unterschreiben)
- Überarbeitung (des Dokuments)
- Nachbereitung (überprüfen der Überarbeitung durch ausgewählte Person)
Rollen im Review
- Manager (Auswahl des Prüfobjekts / Reviewteam zusammenstellen / Ressourcen bereitstellen)
- Moderator (Einladen / Sitzung leiten / Protokoll / keine eigene Meinung äussern)
- Autor (Verantwortlich für die Eintrittskriterien = Reviewfähiges Dokument)
- Gutachter (Prüft das Dokument - evtl nur aus einer bestimmten Sicht)
- Protokllant ( Erstellung des Protokolls / z.T der Autor selbst)
Blackbox-Testfallentwurfsverfahren
- Wo wird geprüft
- Wie enstehen Testfälle
- Welche Teststufen
- Nachteile
Eigent sich für Systemtests
- Eingabe -> PoC = Point of Control liegt ausserhalb des Testobjekts
- Ausgabe -> PoO = Point of Observation liegt ausserhalb des Testobjek
- Testfälle anhand der Spezifikation
- Test driven development nutzt BBT
Ungewünschte Funktionalität kann nicht gefunden / geprüft werden -> Grund für auftretende Sicherheitsprobleme
Reviewarten
- Review eines Produkts / Teilprodukts
- Review eines Projekts / Entwicklungsprozess -> Management Review (Budget / Zeit / Effektivität)
Testfälle für Zustandsbezogene Tests
- Wie kommt man zu Testfällen?
- Spez?
- Ausgangskriterium?
- Übergangsbaum -> Keine Zyklen; Jeder Weg von der Wurzel zu einem Blatt ist ein Testfall
- Vorbedingung: Anfangszustand
- Eingabe
- Sollreaktion: Ausgabe
- Nachbedinung: Endzustand
Ausgangskriterium: Alle Zustände und alle Übergänge min 1 Mal durchlaufen
- Tipp: Zustand muss leicht abgefragt werden können
Whitebox-Testfallentwurfsverfahren
- Andere Bezeichnung
- Wo wird geprüft
- Wie enstehen Testfälle
- Welche Teststufen
Auch als strukturelles Testverfahren bezeichnet
Eignet sich für Komponenten und Integrationstests
- Eingabe -> PoC = Point of Control kann innerhalb des Testobjekts liegen
- Ausgabe -> PoO = Point of Observation liegt innerhalb des Testobjek
- Testfälle anhand der Detailspez und / oder SourceCode
- Ziel hoher Überdeckungsgrad (z.B. > 80%) -> möglichst viel SourceCode wurde mit Testfällen geprüft
Ursache-Wirkung-Graph-Analyse
- Auflisten aller Bedinungen welche für eine postive Aktion nötig sind
- Auflisten aller möglichen Aktionen die möglich sind inkl der positiven
- Entscheidungstabelle Bediungen und Aktionen -> Testfälle
Testprozedur
- Testfälle, welche nacheinander ausgeführt werden
Synoym: Testsequenz oder Testszenario
Inhalt von Testrahmen / Test bed
- Testobjekt
- Laufzeitumgebung (JUnit)
- Stub / Mocks
- Testtreiber (Testfall)
- Vergleich mit Erwartetem Verhalten
Grenzwertanalyse
- "Ränder" der ÄK deckt oft Fehlerzustände auf
- vor der Grenze / Grenze / nach der Grenze = 3 Testfäll
Testfälle aus Äquivalenzklassen
- Viele Kombinationen -> Wie reduzieren?
- Ausgangskriterium?
- GültigeAK kombinieren (häufigste)
- nur je 1 Ungültige AK mit gAK kombinieren
Ausgangskriterium: AK-Abdeckung = Anzahl AK bei Test verwendet zum Total %
Informelles Review
- Autor verteilt das Dokument
- Leser melden Anmerkungen zurück
- Geringer Aufwand
Testplan
- Zuordnung der Testfälle zu Testern
- Durchführungszeitpunkt
Äquivalenzklassenbildung
- Was versteht man darunter
- Welche Arten von ÄK
- Ausgabe?
- Wert in einem Wertebereich bei welchem das gleiche Verhalten angenommen wird = > Repräsentat
- Äquivalenzklasse für gültige Werte
- Äquivalenzklassen für ungültige Werte
- Für alle Repräsentanten muss ein Ausgabewert bestimmt werden
Inspektion
Formale Prüfung
- Gutachter bestätigen gut vorbereitet zu sein
- Geschulter Moderator
- Über Unstimmigkeiten wird am Ende entschieden und protokolliert
- Gutachter am Schluss die aufgezeichneten Fehler als vollständ
Testskript
Automatische Ausführung von mehreren Testfällen
Technisches Review
Prüfen eines Dokuments gegen die "offizielle" Spezifikation
Statische Tests
- Strukturierte Gruppenprüfung
- Statische Analyse
- Strukturierte Gruppenprüfung
- Review
- Walktrough
- Inspektion
- Technisches Review
- Informelles Review
- Statische Analyse
- Compiler
- Standards / Konventionen
- Datenflussanalyse
- Kontrollflussanalyse
- Metriken (z.B. Zyklomatische Komplexität)
Statische Analyse
- Rechtschreibekorrektur
- Compiler: Typen-Checks, Nicht erreichbarer Code, Sprünge...
- "Checkstyle": Syntax, Konventionene, Kontrollfluss, Komplexität,...
Walktrough
Informale Prüfung eines Dokuments
-> durch das Dokument gehen; Minimale Vorbereitung; Wissen verteilen auf Team
Anweisungstest
- Ziel ist alle Anweisungen (Knoten) durchlaufen zu haben
- Ausgangskriterium: C0-Mass (Anweisungsüberdeckung)
Zweigtest / Entscheidungstest
- Unterschied
Zweigtest: Zählt alle Zweige -> IF / THEN (mit Anweisungen) / ELSE (ohne Anweisungen) / ENDIF = 3 Zweige
Entscheidungstest: Zählt alle Entscheidungen -> IF / THEN (mit Anweisungen) / ELSE (ohne Anweisungen) / ENDIF = 2 Entscheidungen (THEN + ELSE)
Ausgangskriterium = 100% Zweigüberdeckung
Whitebox-Testmethoden
- Anweisungstest
- Zweig / Entscheidungstest
- Test der Bedingungen
- Bedingungstest (Jede Teilbedinung muss true / false sein...)
- Mehrfachbedinungstest (Alle kombinationen
- Definierter Bedingungstest / Minimaler Mehrfachbedinungstest
- Pfadtest (bei Schleifen)
Intuitive und Erfahrungsbasierte Testfallermittlung
- Nicht als primäres Testverfahren einsetzen
- Testfälle werden intuitiv erstellt (wo die Fehler vermutet werden - aus Erfahrung)
- Exploratives Testen: Falls kein Dokumentation vorhanden und / oder hoher Zeitdruck
Wichtig: Auch bei Explortivem Testen entstehen schriftliche Testfälle und werden protokolliert!
"Fehler"-Begriff
- Fehler
- Mangel
- Fehlerwirkung (weitere Begriffe?)
- Fehlerzustand (weitere Begriffe?)
- Fehlhandlung (weitere Begriffe?)
- Fehler: Nicht erfüllen einer festgelegten Anforderung (Istverhalten != Sollverhalten)
- Mangel: Nicht angemessen erfüllt (z.B. Beeinträchtigung der Verwendbakeit bei gleichzeitiger Erfüllung der Funktion)
- Fehlerwirkung (aka Failure / Fehlfunktion / äusserer Fehler / Ausfall): Die Fehlerwirkung wird nach aussen Sichtbar -> Ein Ausgabewert ist falsch oder ein Programm stürtzt ab
- Fehlerzustand (aka fault / bug / Defekt / innerer Fehler): Falsch programmierte Anweisung
- Fehlhandlung (aka Error): Fehlerhafte Programmierung durch den Entwickler
Debugging vs Testen
Debugging: Ziel Defekte zu lokalisieren
Testen: Fehlerwirkung (die auf Defekte hinweisen) gezielt und systematisch aufzudecken
Qualitätsmerkmale einer Software (ISO 9126)
-> Achtung in 2001 abgelöst duch ISO 25010
- Funktionalität
- Zuverlässigkeit
- Benutzbarkeit
- Effizienz
- Änderbarkeit
- Übertragbarkeit
Produktrisiken
Produktrisiken sind Risiken, die aus Problemen mit gelieferten Produkt resultieren
Beispiele
- Schlechte SW-Eigenschaften und ist unbrauchbar
- Einsatz des Produkts führt zu Schäden
- Lieferung fehleranfälliger SW
- Mangelhafte Zuverlässigkeit
Fundamentaler Testprozess
- Prozessschritte?
- Planung / Steuerung (laufend)
- Analyse und Design
- Realisierung und Durchführung
- Auswertung und Bericht
- Abschluss
Planung
- Aktivitäten
Testkonzept erstellen u.a. zu diesen Themen:
- Benötigte Ressourcen einplanen (Mitarbeiter / Hardware / SW)
- Schulung Test-MAs
- Organisationsstruktur inkl. Testmanagement
- Testziele / Teststrategie bestimmen (Verteilen der Testaktivitäten auf Systemteile)
Steuerung
- Aktivitäten
- Testaktivitäten im Vergleich zur Planung
- Berichterstattung über Abweichungen
- ... und Massnahmen zur Zielerreichung
- Verwaltung der Testinfrastruktur und Testmittel
Teststrategie
- Ziel
- Aktivitäten
Ziel: optimale Verteilung der Tests auf die "richtigen" Stellen der SW
Aktivitäten
- Priorisieren anhand Risikoeinschätzung
- Kritische Systemteile erhöhter Testaufwand
- Unkritisch Systemteile minimaler Aufwand / evtl sogar nicht testen
- Testmethoden festlegen
- Ausgangskriterien / Testendkriterien festlegen
Testanalyse und Testdesign
- Aktivitäten
- Zuerst Testbasis (Dokumentation) prüfen ob Anforderungen hinsichtlich Tests genau genug sind
- Prüfen des Testobjekts bezüglich Testbarkeit (Zerlegbarkeit, Offene Schnittstellen,..)
- Erstellen Testspezifikation
Testspezifikation (in Testanalyse und Design)
- Was ist wichtig
- Art der Testfälle
- Traceability ist wichtig (Anforderung -> Testfall)
- Logische Testfälle um daraus die
- In Schritt Realisierung: ... Konkrete Testfällen (mit konkreten Eingabewerten) erstellen oder umgekehrt im Fall von explorativem Testen(keine Spez vorhanden)
Testfall
- Merkmale
- Arten
Bestandteile
- Vorbedingung
- Durchzuführende Schritte
- Erwartetes Resultat (direkte Ausgabe inkl ggf. Änderungen an globalen Daten) -> Testorakel
Arten
- Spezifiziertes Verhalten prüfen (Normalfall)
- Negativtests: Ausnahmsituation / Fehlersituation prüfen
- Ungültige / Unerwartete Eingaben (Exception handling)
Testorakel
Das Testorakel kann "befragt" werden um für einen Testfall das erwartete Resultate "vorauszusagen" -> Um den Testfall zu spezifizieren. Das TO kann sein:
- Spezifikation
- Umkehrfunktionen..
Test Realisierung und Durchführung
- Aktivitäten
- Prioritäten
- Wichtig
- Logische Testfälle zu konkreten Testfällen spezifizieren (konkrete Eingabewerte)
- Testfälle anhand Prioriät zu Testsequenzen verbinden
- Prio
- 1. Vollständigkeit der zu testenden Teile bestimmen
- Hauptfunktion prüfen (Smoke-Test)
- Testsequenzen durchführen
- Wichtig
- Protokollierung
- Nachvollziehbarkeit / Reproduzierbarkeit
Fehlerklasse
Prio für die Fehlerbehebung
