Benutzer-Werkzeuge
se:softwaretest
Inhaltsverzeichnis
Sofware-Test
Klausurvorbereitung
Begriffe Test
- Definition Test, Testbasis, System, Tester, Kunde, Benutzer
- Warum kann die Fehlerfreiheit eines Programms nicht nachgewiesen werden?
- Test als Optimierungsproblem
Test im Verlauf des Entwicklungsprozesses
- Phasen des V-Modells
- Modultest
- Integrationstest
- Strategien (5)
- Systemtest
- Abnahmetest
- Regressionstest
- Änderungsszenarien (5)
- Strategien (5)
- Arten von Tests (5)
- Qualitätsmerkmale ISO 9126 (6)
- Funktionalität (5)
- Zuverlässigkeit (3)
- Benutzbarkeit (3)
- Effizienz (2)
- Wartungsfreundlichkeit (3)
- Übertragbarkeit (4)
Verfahren zur Ermittlung von Testfällen
- Ziele (3)
- Definition White-/Black-Box-Test, formal/nichtformal, Beispiele für Kategorien
- Definition Testabdeckung, Berechnungsbeispiele, Messung
- Grundlegende Vorgehensweise (6 Schritte)
- Verfahren
- funktionale Analyse (4 Eigenschaften)
- funktionale Wechselwirkungsanalyse
* Anwendungsanalyse/Geschäftsprozessanalyse * Äquivalenzklassen (4 Schritte, 3 Methoden zum Reduzieren der Testfälle) * Grenzwertanalyse * Real-Life-Test * intuitiver Test * Smoke-Test * Anweisungsüberdeckung * Zweigüberdeckung * Bedingungsüberdeckung * Definition atomare Teilbedingung * einfache Bedingungsüberdeckung * Mehrfachbedingungsüberdeckung * minimale Mehrfachbedinungsüberdeckung * Pfadanalyse, Definition Pfad * Basispfadanalyse, Definition Basispfad * Zustandsanalyse, Vorgehen (3 Schritte) * Ursache-Wirkungs-Analyse und Entscheidungstabellen * Vorgehensweise (6 Schritte) * Umwandlung in Entscheidungstabelle (4 Schritte) * Zufallswerte * Roman-Arches
Testautomatisierung
- Motivation (8 Gründe)
- Nachteile (5)
* Voraussetzungen (4) - Automatisierung von Kommandozeile/GUI/Messgeräten
Testprozess
- Generischer Testprozess (7 Schritte)
- Testdokumente (8), Zuordnung zu Testphasen
* Testplanung- Startbedingungen (4)
- Master-Testplan (5 Inhalte, Ziel)
- Beispiele für Testziele/-schwerpunkte
- Prioritäten (3 Eigenschaften, 5 Ziele, 7 Kriterien)
- Sonstige Planungsthemen (7)
- Frühe Testaktivitäten (3)
* Testspezifikation (3 Schritte)
- Vorbereitung (2 Punkte)
- Durchführung
- Start (8 Kriterien)
- Ergebnisse der Akzeptanzprüfung (8)
- Interner Abnahmetest (6 Schritte)
* Praktische Vorgehensweise * Grundsätze intuitiver Tests (3) * Protokollierung * Möglichkeiten (5) * Fehlerprotokoll (4 Prüfungen) * Ziele (5) * Änderungsprozess * Gründe für Änderungen (4) * Fehlerbericht (3 Regeln) * Informationen (13) * Testende (4 Kriterien)* Übergabe (3 Inhalte)
- Abschlussarbeiten (4)
Beispiele für Softwarefehler
Beispiele für Softwarefehler
- F-16 Kampfjet fliegt ab Äquator kopfüber weiter
- Patriot-Abwehrsystem verfehl feindliche Rakete
- Airbus A320 rast in Warschau über die Landebahn hinaus
- Eröffnung des Denver International Airport muss verschoben werden
- Mars Orbiter geht verloren
- Jahr 2000-Problem
- Sprengung der Ariane 5
Begriffe
- Test ist ein organisierter Prozess
- der mindestens aus Planung, Vorbereitung und Durchführung besteht,
- zum systematischen Nachweis, dass ein System sich exakt so verhält, wie erwartet und
- der sicherstellt, dass Abweichungen zwischen tatsächlichem und erforderlichem Systemverhalten so früh wie möglich identifiziert werden.
- Ein Tester ist eine am Testprozess beteiligte Person. Er kann verschiedene Rollen annehmen: Testmanager, Testarchitekt, Testdesigner, Testsoftware-Entwickler, Testausführender
- Testbasis: Ja nach Art des Tests etwa Kundenanforderungen, System- und Architekturspezifikationen, Quelltexte, UML-Diagramme etc. Aus der Testbasis werden Testfälle mit einzelnen Testschritten und erwarteten Ergebnissen abgeleitet.
- Ein System realisiert im Zusammenspiel von Hardware und Software das Systemverhalten, wie es den Kundenanforderungen entspricht.
* Kunden sind Käufer eines Systems. - Anwender/Benutzer benutzen das System.
Grenzen von Tests
- Komplette Tests sämtlicher Verzweigungen eines Programms sind nicht möglich (→ Kombinatorik)
- Fehlerfreiheit kann nicht nachgewiesen werden.
- Test ist ein Optimierungsproblem zwischen Zeit, Geld und Qualität → Maßstab: Kundenzufriedenheit
Test im Verlauf des Entwicklungsprozesses
- Produktentwicklung nach V-Modell
- konstruktive Phasen
- Kundenanforderungen: aus verschiedenen Quellen (Kunden, Verträge, Wissenschaft)
- Systementwurf: detaillierte Anforderungsbeschreibung, Schnittstellen, Parameter
- Systemarchitektur: Zerlegung in Systemkomponenten
- Modulspezifikation: Zerlegung in Module (kleinste Einheiten)
- Implementierung: auf Basis der Modulspezifikation
- analytische Phasen / Testphasen / -stufen
- Modultest: Test der einzelnen Module gegen deren Spezifikation
- Integrationstest: Test der Architektur und der Schnittstellen
- Systemtest: Test gegen Systemspezifikation/Anforderungen, externe Schnittstellen, evtl. Verschmelzung mit Integrationstest
- Abnahmetest: Nachweis, dass das System die Kundenanforderungen erfüllt
- Modul-/Komponententest
- Testbasis: Modulspezifikation
- strenge Trennung der Module beim Test → alle Module werden für sich allein getestet
- Schnittstellen müssen simuliert werden → Testtreiber
- üblicherweise vom Entwickler selbst durchgeführt: Compiler, Debugger, Emulator/Simulator, statische Analyse, Automatisierungswerkzeuge
- Integrationstest
- Testbasis: Systemarchitektur
- Durchführung durch spezialisierte Testgruppe <> Entwickler
- Strategien
- inkrementelle Integration
- Top-Down (anwender-/betriebssystemnahe Komponenten zuerst)
- Bottom-Up (zuletzt aufgerufene Komponenten zuerst)
- Ad-hoc (Integration sofort nach Fertigstellung von Komponenten)
- Backbone (Erstellen eines Programmskeletts, in das die Komponenten nach Fertigstellung integriert werden)
- Big Bang (alle Komponenten werden gleichzeitig integriert)
- Systemtest
- Testbasis: Systementwurf / Anforderungen / Normen etc.
- Ziel: Prüfen, ob das System den Anforderungen entspricht
- Testumgebung sollte Produktivumgebung entsprechen (sonst Simulation)
- Durchführung wieder durch spezialisiertes Testteam
- Evtl. Test bei Pilotkunden: Betatest, Feldtest, Pilotbetrieb, controlled introduction
- Qualitätsmerkmale nach ISO 9126/DIN 66272
- Funktionalität (Functionality)
- Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit
- Zuverlässigkeit (Reliability)
- Reife, Fehlertoleranz, Wiederherstellbarkeit
- Benutzbarkeit (Usability)
- Verständlichkeit, Erlernbarkeit, Bedienbarkeit
- Effizienz (Efficiency)
- Zeitverhalten, Verbrauchsverhalten
- Lasttest, Stresstest, Volumen-/Massentest, Performanztest
- Wartungsfreundlichkeit (Maintainability)
- Analysierbarkeit und Modifizierbarkeit, Stabilität, Prüfbarkeit
- Übertragbarkeit (Portability)
- Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit
- Abnahmetest
- Ziel: Zusicherung an Kunden, dass Anforderungen erfüllt werden
- Testbasis: zugesicherte Anforderungen des Kunden, Verträge, Produktdokumentation
- Wird für jeden Kunden individuell vor Ort durchgeführt
- Regressionstest
- Regression: Funktionierende Funktionalität wird durch Änderung/Erweiterung beeinträchtigt
- Änderungen/Erweiterungen: Fehlerbehebung in Entwicklung/Wartung, Hinzufügen von Feature(s) (in einem, mehreren Modulen)
- Strategien
- Auswahl repräsentativer Testfälle
- Automatisierung
- Regelmäßige Ausführung von Teiltests
- Kompletter Test vor Auslieferung neuer Versionen
- Austausch der Testfälle für die nächste Produktversion
Testprozess
- Testdokumentation
- notwendig zur internen/externen Kommunikation, teils gesetzliche Aufbewahrungsfristen
* Testplanung- Start zu Beginn des Projekts (Projekt ist genehmigt, Projektleiter benannt, Test-Projektleiter benannt, Mitarbeiter benannt)
- Nach Umfang des Projekts Testmanager für jede Phase oder Gesamtprojekt
- Master-Testplan
- Testaktivitäten über alle Phasen hinweg
- zeitliche und logistische Abhängigkeiten
- Ziele und Schwerpunkte der einzelnen Phasen (Abgrenzung)
- Pläne der Testphasen werden aus Master-Testplan abgeleitet
- Rahmenbedingungen klären: Termine, Personal etc. → Zeitplan
- Ziel: Optimierung des zeitlichen Ablaufs und des personellen/materiellen Aufwands
- Beispiel: teures Messgerät
- Testziele/-schwerpunkte
- Ableitung aus ISO 9126: z.B. Vollständigkeit, Verfügbarkeit, Fehlertoleranz, Ergonomie, Wartbarkeit
- Prioritäten
- Notwendig aufgrund von Zeitdruck
- Werden bei Projektstart definiert und müssen bei Teststart feststehen
- Dynamik durch externe/interne Faktoren
- Basis für Ressourcenzuteilung
- Ziele
- Bestmögliches Ergebnis auch bei Zeitmangel
- Hauptfunktionen sind früh stabil
- Schwewigende Fehler werden früh erkannt
- Intensiver Test kritischer Bereiche
- Wichtige Funktionen müssen nicht abgekündigt werden
- Ermittlung von Prioritäten
- Festgelegte Testschwerpunkte
- Risikoanalyse
- Kundenanforderungen
- Komplexität der Funktionen
- Zentrale Funktionen zuerst
- Erfahrungswerte aus vorherigen Projekten
- Subjektive Einschätzung
- Sonstige Planung
- Start/Ende der Testphasen
- Testumgebung, ggf. Bestellung benötigten Materials (Hard-/Software, Messgeräte etc.)
- Umgebung der Testautomatisierung, ggf. Bestellung der nötigen Werkzeuge
- Planung der Testautomatisierung
- Identifikation und Analyse von Projektrisiken
- Frühe Testaktivitäten
- Teilnahme an Insepktionen/Reviews
- Embedded Systems: Testwerkzeuge erstellen
- Teilnahme an Architektur-/Designsitzungen
- Analyse und Testspezifikation
- Festlegen der Testbasis → Testfälle ermitteln → Testspezifikation nach IEEE 829 (inkl. Angaben zur Automatisierung)
- Sollwerte für Testfälle ermitteln
- Vermeidung von Lücken/Redundanzen → Test Outline mit Review
- Vorbereitung, Realisierung
- Aufbau und Test (!) der Testumgebung
- Vorbereitung der Testautomatisierung
- Testausführung, Testauswertung, Ergebnisdokumentation
- Teststart
- Hilfsmittel und Material sind vorhanden
- Infrastruktur läuft
- Testspezifikation ist fertig
- Software zur Automatisierung ist fertig
- Akzeptanzkriterien erfüllt (Inspektion/bestimmte Testfälle/Abnahmetest durchgeführt)
- Übergabe: Meeting oder Protokoll
- Test kann beginnen
- Testobjekt wird zurückgewiesen
- Testobjekt wird akzeptiert, Test kann dennoch nicht beginnen
- Testobjekt wird akzeptiert, Test kann evtl. nach Risikoanalyse beginnen
- Test ist auf einzelne Funktionen des Testobjekts beschränkt
- Evtl. Überstimmung durch Managemententscheidung
- Interner Abnahmetest (Sanity Test)
- Vollständigkeit
- Installation in Testumgebung
- Start-/ablauffähig?
- Hauptfunktionen, wichtige Nebenfunktionen, Testfunktionen
- Praktische Vorgehensweise
- Vorgehen zunächst wie beim internen Abnahmetest
- dann systematischer Test der einzelnen Module auf Basis der Testspezifikation
- weitere Tests je nach den ersten Ergebnissen, niedrige Priorität
- Intuition
- Fehler sind Herdentiere
- Vertrauen Sie Ihrer Intuition
- Alle zusätzlich durchgeführten Tests sind zu protokollieren
- Protokollierung, Auswertung und Ergebnisdokumentation
- automatische Protokolle (Logs)
- Messergebnisse aufzeichnen
- Protokollierung der Testsoftware
- Ergebnisse der Testfälle (bestanden/nicht bestanden)
- Testfortschritt aus Testfallergebnissen ermitteln
- Fehlerbericht
- Ist die Testspezifikation korrekt?
- Läuft die Testinfrastruktur korrekt?
- Arbeitet die Testsoftware korrekt?
- Wurden die Testschritte korrekt durchgeführt?
- Ziele der Protokollierung
- Erfassung von Daten zur Fehleranalyse
- Nachvollziehbarkeit aller Rahmenbedingungen
- Wiederholbarkeit der Tests
- Nachweis der durchgeführten Tests für Kunden etc.
- Einhaltung von gesetzlichen Vorgaben
- Änderungsprozess, Änderungsanforderung, Fehlerbericht
- Nach Inspektion/Test: Änderungsprozess
- Gründe für Änderungen
- Fehlerbeseitigung
- Verbesserungswünsche
- Funktionserweiterung
- Funktionsergänzung
- Fehlerbericht
- Nur Fehlverhalten, keine Problemlösung
- Sachlichkeit (kein Angriff gegen den Entwickler)
- Informationen
- Kurzbeschreibung
- Priotität
- Verfasser des Fehlerberichts
- Status des Fehlerberichts
- Aktueller Bearbeiter
- Terminvorgabe zur Behebung
- Betroffenes Modul/System/Funktion
- Konfiguration/Version des Systems
- Testaufbau/-umgebung
- Durchgeführte Testschritte
- Erwartetes Ergebnis <> beobachtetes Ergebnis
- Testprotokolle
* Testende * realistische Kriterien bzgl. Erreichbarkeit und zeitlicher Durchführbarkeit * Festlegung von Metriken (100% geplante Tests durchgeführt etc.) * Auch Abbruchkriterien festlegen
* Übergabeprotokoll, Abschlussbericht, Freigabe
- Mit Testende zu erstellen
- Informationen für nachfolgende Testphase
- Kriterien für Testende
- Liste bekannter/behobener Fehler
* Abschlussarbeiten, Retrospektive
- Aktualisierung und Vervollständigung der Testdokumentation
- Korrektur der Testdokumentation
- Korrektur der Testsoftware
- Retrospektive Analyse des Verlaufs des Testprojekts
Verfahren zur Ermittlung von Testfällen
- Ziele
- wiederholbare, leicht wartbare Testfälle finden
- Begrenzung der Menge der Testfälle
- hohe Testabdeckung erreichen
- White-Box-Tests
- strukturorientiert
- basieren auf Quelltext/Systembeschreibung
- Kenntnis der inneren Strukturen ist erforderlich
- Verwendung interner Schnittstellen
- wichtig zu Beginn der Tests (Module)
* Black-Box-Tests - Interne Kenntnisse nicht erforderlich/gewünscht
- nur Benutzer-/Systemschnittstellen werden verwendet
- basieren auf Anforderungen/Beschreibungen/Spezifikationen
- wichtiger gegen Ende der Tests
- Gray-Box-Tests
- Mischform
- Beispiel: Kenntnis über Interna fließt in den Simulation externer Tests ein, Ausfall einer Komponente wird simuliert
- formal
- strikte Regeln zur Ermittlung von Testfällen
- kann automatisiert werden
- hohe Qualität der Testbasis erforderlich
* nichtformal
* gestalterischer Spielraum * keine Aussage über Testabdeckung möglich * Tester braucht Erfahrung
* Testabdeckung
- gibt an, welcher Teil der Testbasis durch Testfälle abgedeckt wird
- Angabe der Testbasis
- Kriterien zur Abdeckung
- spezifizierte/tatsächlich durchgeführte Testfälle
Grundlegende Vorgehensweise
- Grobanalyse der Testbasis, Aufteilung in Teilbereiche
- nichtformale Verfahren (funktionale Analyse, Intuition, Erfahrung)
- Schwerpunkte und Prioritäten setzen (Riskoanalyse)
- Detailanalyse der Testbasis pro Testbereich
- Methoden wie oben, zusätzlich Äquivalenzklassen
- Ergebnis in Testspezifikation
- Ausarbeitung von logischen Testfällen
- formale Verfahren, falls Testbasis dies erlaubt
- Verfeinerung in konkrete Testfälle
- Ergebis: Testskript für jeden Testfall
- Vorbedingungen, durchzuführende Aktivitäten, erwartete Ergebnisse
- Bereitstellung initialer Datensätze
- Intuitive, erfahrungsgetriebene Erweiterungen
Black-Box-Verfahren
- Funktionale Analyse
- Zerlegung des Systems in (atomare) Funktionen
- Jede Funktion wird individuell getestet
- Wechselwirkungen werden nich betrachtet
- Mehrere Funktionen werden nicht simultan ausgeführt
- Voraussetzung: Testbasis mit testbaren Anforderungen
- Funktionale Wechselwirkungsanalyse
- erweitert die funktionale Analyse um die dort vernachlässigten Wechselwirkungen
- oftmals notwendig
- durch erfahrene Tester mit Überblick über die Zusammenhänge
- betrifft oft mehrere Testbereiche → gute Abstimmung erforderlich
- Anwendungsanalyse (Geschäftsprozessanalyse)
- Testbasis: Anwendungsfälle, Szenarien, Geschäftsprozesse, -vorfälle
- geeignet für Akzeptanz- und Systemtest
- bei vorhandenem System: statistische Benutzungsprofile
- Äquivalenzklassen
- Vermeidung unnützer Testfälle bei gleichbleibender Testabdeckung
- jeder Testfall einer Klasse hat die gleiche Wahrscheinlichkeit einen Fehler aufzudecken
- Bildung für gültige/ungültige Werte
- Vorgehensweise
- Grobaufteilung entsprechend der Definitionsbereiche der Parameter
- Verfeinerung der Äquivalenzklassen
- Auswahl der Repräsentanten für die Testfälle
- Erstellung der Testfälle
- Kombination gültiger Klassen und ungültiger/gültiger Klassen
- Mögliche Reduktion der Testfälle
- Sortierung nach Häufigkeit im Betrieb
- Grenzwerte vorziehen
- Paarweise Kombination statt vollständiger Kombination
- Grenzwertanalyse
- sinnvolle Erweiterung der Äquivalenzklassen
- Prüfung von drei Werten: Grenzwert, Nachbarn innerhalb/außerhalb der Klasse
- Real-Life-Test
- Test in der Produktivumgebung
- frühestens nach Systemtest
- Ziel ist nicht das Entdecken von Fehlern
- identifiziert evtl. Testlücken
- Intuitive Testfallermittlung
- während der Testdurchführung
- sinnvolle Ergänzung zu strukturiertem Test
- Testabdeckung meist gering
- Exploratory Testing: keine Testspezifikation, Stichproben mit Verfeinerung beim Finden von Fehlern, iterative Fehlersuche, vorgegebene Zeit begrenzt Testdauer, jeder Schritt ist genauestens zu protokollieren
* Smoke-Test - Ziel: Absturz des Systems
- automatische Durchführung
- viele/simultane Zugriffe
- einzelne Ergebnisse werden nicht ausgewertet
White-Box-Verfahren
- Anweisungsüberdeckung
- C0-Abdeckung, Statement Coverage
- lediglich alle Anweisungen müssen einmal durchlaufen werden
- Messung meist durch Werkzeuge, Testfälle können automatisch erzeugt werden
- schwächste Methode, reicht als alleiniger Test nicht aus
- Zweigüberdeckung
- C1-Abdeckung, Branch Coverage
- jeder Zweig muss durchlaufen werden (auch solche ohne Anweisungen)
- Messung ebenfalls durch Werkzeuge, Testfälle können auch automatisch generiert werden
- Minimaler Test für ein Modul, enthält automatisch Anweisungsüberdeckung, testet jedoch nicht unterschiedliche Bedingungen oder mehrfache Schleifendurchläufe
- Bedingungsüberdeckung
- atomare Teilbedingung: Bedingung ohne logische Operatoren (nur vergleichende Symbole)
* einfache Bedingungsüberdeckung * Branch Condition Coverage * jede atomare Teilbedingung muss einmal wahr/falsch sein * schwächer als Zweigüberdeckung (Gesamtbedingung muss nicht wahr/falsch sein) * Mehrfachbedingungsüberdeckung * Branch Condition Combination Coverage * alle möglichen Kombinationen der Teilbedingungen werden berücksichtigt * schließt Anweisungs- und Zweigüberdeckung ein * führt schnell zu vielen Testfällen * minimale Mehrfachbedingungsüberdeckung * Modified Branch Condition Decision Coverage * jede Kombination von Wahrheitswerten, bei denen die Änderung einer Teilbedingung zur Änderung der Gesamtbedingung führt * bevorzugte Methode
Universelle Verfahren
- Pfadanalyse
- Anwendung nicht nur auf Quelltext möglich, sondern auf beliebige Kontrollflussgraphen
- Pfad: Sequenz durch alle Knoten des Graphen
- Vollständige Abdeckung meist unmöglich (wegen Schleifen)
- Basispfadanalyse
- Basispfad: eindeutiger Pfad durch den Graphen (Start bis Ende), der mindestens eine Kante durchläuft, die in keinem anderen Basispfad enthalten ist
- verringert die Anzahl der zu testenden Pfade drastisch
- Anzahl der Basispfade wird durch Zyklomatische Zahl vorgegeben
- Rücksprung in Schleifen wird einfach gewertet
- Mehrere Sätze an Basispfaden sind möglich, die Basispfade eines Satzes enthalten immer alle Knoten und Kanten des Graphen
- schließt Anweisungs- und Zweigüberdeckung ein
- Pro Basispfad ein Testfall
- bei mehrfachen Schleifendurchläufen ist Kombination mit Grenzwertanalyse sinnvoll
- Zustandsanalyse
- berücksichtigt den bisherigen Verlauf des Systems/Moduls
- Basis: Zustandsdiagramm
- jeder Zustand/Zustandsübergang muss einmal durchlaufen werden
* entspricht Zweigüberdeckung * Notwendig ist die Umwandlung des Zustandsdiagramms in einen zyklenfreien gerichteten Graphen * Anfangszustand -> Wurzel * Kanten zu allen möglichen Folgezuständen * Wiederholung von Schritt 2 für alle Blätter bis * aktuelles Blatt ist bereits im Weg enthalten (Zyklus) * aktuelles Blatt ist ein Endzustand * jeder Pfad von Wurzel zu Blatt ohne Nachfolger ist ein Testfall* Ursache-Wirkungs-Analyse, Entscheidungtabelle
- Vorgehen: Ursache-Wirkungs-Analyse → Entscheidungstabelle → Testfälle
- berücksichtigt Zusammenspiel von Ein- und Ausgabeparametern
- Ablauf
- funktionale Analyse
- Identifikation von Ursachen und Wirkungen (Ursache: Eingabedatum/Äquivalenzklasse, Wirkung: Ausgabedatum/Äquivalenzklasse)
- Erstellen des Ursache-Wirkungs-Graphen
- Eintragung von Abhängigkeiten zwischen Ursachen bzw. Wirkungen
- Umwandlung in eine Entscheidungstabelle
- Auswahl einer Wirkung
- Kombinationen suchen, die Wirkung hervorrufen/nicht hervorrufen
- Ursachenkombination → Spalte in Tabelle
- Entfernen von Redundanzen
- Vermeidung von Fehlermaskierung
- ODER wahr: jeweils nur eine Bedingung wahr, alle übrigen falsch
- UND falsch: jeweils nur eine Bedingung falsch, alle übrigen wahr
- Minimaltabelle: jede Ursache/Wirkung muss einmal wahr/falsch sein
- Erzeugen von Testfällen aus der Entscheidungstabelle
- Zufallswerte
- sinnvoll bei Smoke Test
- schwierig auszuwerten → Ergebnisse müssen ad hoc berechnet werden
- Roman-Arches-Verfahren
- Entwickler müssen ihre eigenen Produkte verwenden
Testautomatisierung
- Motivation
- regelmäßige Wiederholung der Regressionstests nur so wirtschaftlich möglich
- Entlastung der Tester von eintönigen Tätigkeiten
- schnellere Durchführung zu jeder denkbaren Zeit
- hohe Auslastung der Testinfrastruktur
- automatisierte Testfälle sind jederzeit wiederholbar
* große Datenmengen sind nur automatisch verarbeitbar und können ggf. grafisch aufbereitet werden * Last-, Stress- und Robustheitstests sind nur automatisch durchführbar * langfristiger Echtzeitbetrieb kann simuliert werden
* Nachteile
- hohe Einmalkosten
- Aufwand zur Pflege der Testsoftware
- Verzögerung des Projektstarts durch Entwicklung der Testsoftware
- Fähigkeiten der Testsoftware werden überschätzt
- automatische Tests können bei sehr fehlerhafter Software schwer durchzuführen sein
- Voraussetzungen
- gewisser Reifegrad des Unternehmens, gelebter Testprozess
- Zeit zum Erlernen der Testsoftware
- Änderung der Arbeitsweise der Mitarbeiter → Entwicklung von Testsoftware
- Entwicklung von Testsoftware sollte als eigenständiges Projekt evtl. mit externer Hilfe umgesetzt werden
- Werkzeuge und Verfahren
- Automatisierung von kommandozeilenbasierten Schnittstellen
- Einsatz von Skriptsprachen
- Struktur der Testsoftware sorgfältig planen und Coding Standards festlegen
- Automatisierung von GUI
- Capture-and-replay
- Problem: Änderungen an der GUI
- Testprogrammierung
- Problem: evtl. sind spezielle Bibliotheken nötig
- Automatisierung von Messgeräten und Testhilfsmitteln
ToDo
- Quellen für Softwarefehler-Beispiele suchen
Ariane 5-Beispiel genauer anschauenGenerischer Testprozess S. 33Änderungsprozess S. 49Tabelle Testfallermittlungsverfahren S. 56- Beispiel für Zustandsanalyse
- Beispielaufgaben zur Testfallermittlung
ToRead
- Hopf
- Kosten von Softwarefehlern: Kapitel 6, 6.3
- Qualitätsmerkmale: Kapitel 4.3.1
Einführung der Testdokumentation: IEEE829 Anhang B
Lernziele
- Sie können prominente Beispiele benennen, die die Folgen von unzureichenden Tests belegen.
- Anhand der Beispiele erkennen Sie, dass neben reinen Programmierfehlern vor allem Entwurfsfehler für eine Vielzahl von tragischen Softwareausfällen eine wesentliche Rolle spielen.
- Sie erkennen, welchen Einfluss der Zeitpunkt der Entdeckung eines Fehlers auf seine Folgekosten hat.
- Sie kennen die wichtigsten Begriffe zum Thema Test.
- Sie können die Definition des Begriffs "Test" angeben und erläutern.
- Sie verstehen anhand eines einfachen Beispiels, weshalb selbst bei kleinen Systemen ein vollständiger Test nicht möglich ist.
- Sie können die grundlegenden Zielstellungen eines erfolgreichen Tests beschreiben.
- Sie können beschreiben, wie eine Produktentwicklung abläuft, die einem Prozess nach dem V-Modell folgt.
- Sie kennen die Aufgaben der unterschiedlichen Testphasen und können erklären, wodurch sich die einzelnen Phasen unterscheiden.
- Sie können die unterschiedlichen Vorgehensweisen beim Integrationstest und ihre jeweiligen Vor- und Nachteile beschreiben.
- Sie kennen die Qualitätsmerkmale nach der ISO-Norm 9126 und können ihre Bedeutung für den Systemtest darlegen.
- Sie können die Notwendigkeit und Wichtigkeit eines Regressionstests begründen.
- Sie können den typischen Ablauf eines Testprojekts beschreiben, das dem generischen Testprozess folgt.
- Sie können ausführlich beschreiben, welche Aufgaben in den einzelnen Phasen des Testprozesses durchzuführen sind.
- Sie kennen die unterschiedlichen Testdokumente, die im Standard IEEE Std 829-1998 beschrieben sind.
- Sie können einen typischen Änderungsprozess beschreiben.
- Sie können erklären, welche Vorteile die Anwendung von Verfahren zur Ermittlung von Testfällen bietet im Vergleich zu einer zufälligen bzw. rein intuitiven Vorgehensweise.
- Sie können die Grundmerkmale beschreiben, durch die Testverfahren charakterisiert werden.
- Sie können verschiedene Testverfahren benennen und diese anhand dieser Grundmerkmale einordnen.
- Sie sind in der Lage, für die verschiedenen Testverfahren anzugeben, wie die Testabdeckung berechnet wird.
- Sie können die prinzipielle Vorgehensweise beschreiben, wie Sie schrittweise auf Grundlage einer vorhandenen Testbasis zu detailliert spezifizierten Testfällen kommen.
- Sie können die einzelnen Black-Box Verfahren zur Ermittlung von Testfällen beschreiben.
- Sie können für unterschiedliche Testsituationen die jeweils am besten geeigneten Verfahren angeben.
- Sie sind in der Lage, die Verfahren für verschiedene Beispiele anzuwenden.
- Sie können die einzelnen White-Box Verfahren zur Ermittlung von Testfällen beschreiben.
- Sie können für unterschiedliche Testsituationen die jeweils am besten geeigneten Verfahren angeben.
- Sie sind in der Lage, die Verfahren für verschiedene Beispiele anzuwenden.
- Sie können die einzelnen universellen Verfahren zur Ermittlung von Testfällen beschreiben.
- Sie können für unterschiedliche Testsituationen die jeweils am besten geeigneten Verfahren angeben.
- Sie sind in der Lage, die Verfahren für verschiedene Beispiele anzuwenden.
Übungen
- Übung 1.1: Überlegen Sie für das Beispiel der Ariane 5, welche der oben beschriebenen Fehler Sie als Testmanager hätten verhindern können und durch welche Maßnahmen. Geben Sie dabei auch an, welche dieser Maßnahmen ein besonders gutes Kosten-Nutzen-Verhältnis aufweisen. Beantworten Sie die Frage spontan mit Hilfe Ihres bisherigen Vorwissens. Kehren Sie im Laufe der nächsten Kapitel immer wieder zu dieser Übung zurück und überdenken Sie Ihre Antwort anhand dessen, was Sie gelernt haben.
- Übung 1.2: Überlegen Sie, an welchen Stellen sich in der oben angegebenen Definition von Test die hervorgehobenen Elemente der älteren Definitionen wieder finden.
- Übung 1.3: Suchen Sie nach öffentlich bekannten Beispielen, bei denen das Optimierungsproblem zwischen Zeit, Kosten und Qualität offensichtlich nicht erfolgreich gelöst wurde.
- Übung 2.1: Erstellen Sie für das System aus dem Beispiel in Kapitel 2.1 (PC mit Betriebsystem und zwei Anwendungen) eine grobe Planung des Testablaufs: Welches sind die einzelnen Module (gegenseitige Abgrenzung), in welcher Reihenfolge werden die Module beim Integrationstest zusammengefügt, wie muss ein Systemtest und ein Abnahmetest aussehen?
- Übung 3.1: Verfeinern Sie nun Ihre in der Übung 2.1 erstellte Grobplanung für das System aus dem Beispiel in Kapitel 2.1. Erstellen Sie zunächst einen Master-Testplan und dann die Testpläne der einzelnen Testphasen. Spielen Sie dieses Testprojekt von Anfang bis Ende durch und folgen Sie dabei dem generischen Testprozess. Bleiben Sie realistisch, d.h. lassen Sie Ihre Tester auch ein paar Fehler in jeder Testphase finden.
- Übung 4.1: Nehmen Sie die Bedienungsanleitung eines elektronischen Geräts aus Ihrem Haushalt (z.B. CD- oder DVD-Player) als Testbasis und erstellen Sie nach der obigen Anleitung Testfälle für Ihren persönlichen Akzeptanztest dieses Gerätes. Lesen Sie erst nach dieser Übung das folgende Kapitel 4.4 über Black-Box Verfahren.
- Übung 4.2: Verbessern Sie nun Ihren persönlichen Akzeptanztest, den Sie mit Hilfe des vorigen Kapitels 4.3 für Ihr elektronisches Gerät erstellt haben. Erweitern bzw. überarbeiten Sie die vorhandenen Testfälle mit den in diesem Kapitel erlernten Black-Box Verfahren.
- Übung 4.3: Überlegen Sie sich weitere Beispiele, mit denen Sie die verschiedenen White-Box-Verfahren üben. Sie sollten umfangreicher sein als die in Kapitel 4.5 verwendeten Beispiele. Ideal sind Programme oder Programmausschnitte, die Sie vor dem Studium dieser Unterlagen selbst geschrieben und/oder ohne Verwendung von systematischen Verfahren getestet haben.
- Übung 4.4: Entwerfen Sie ein kleines System, z.B. einen automatischen Garagentüröffner mit einigen Komfortfunktionen (Einklemmschutz usw.) und wenden Sie die verschiedenen universellen Verfahren zur Ermittlung von Testfällen darauf an.
se/softwaretest.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
