Benutzer-Werkzeuge
se:softwaretest
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
se:softwaretest [2008-04-06 15:33] stefan |
se:softwaretest [2014-04-05 11:42] (aktuell) |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== Sofware-Test ====== | ====== 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 ===== | ===== Beispiele für Softwarefehler ===== | ||
| Zeile 24: | Zeile 120: | ||
| * Komplette Tests sämtlicher Verzweigungen eines Programms sind nicht möglich (-> Kombinatorik) | * Komplette Tests sämtlicher Verzweigungen eines Programms sind nicht möglich (-> Kombinatorik) | ||
| * Fehlerfreiheit kann nicht nachgewiesen werden. | * Fehlerfreiheit kann nicht nachgewiesen werden. | ||
| - | * Test ist ein Optimierungsproblem zwischen Zeit, Geld und Qualität -> Maßstab: Kundenzufriedenheit | + | * Test ist ein Optimierungsproblem zwischen Zeit, Geld und Qualität -> **Maßstab: Kundenzufriedenheit** |
| ===== Test im Verlauf des Entwicklungsprozesses ===== | ===== Test im Verlauf des Entwicklungsprozesses ===== | ||
| * Produktentwicklung nach V-Modell | * Produktentwicklung nach V-Modell | ||
| * konstruktive Phasen | * konstruktive Phasen | ||
| - | * Kundenanforderungen | + | * Kundenanforderungen: aus verschiedenen Quellen (Kunden, Verträge, Wissenschaft) |
| - | * Systementwurf | + | * Systementwurf: detaillierte Anforderungsbeschreibung, Schnittstellen, Parameter |
| - | * Systemarchitektur | + | * Systemarchitektur: Zerlegung in Systemkomponenten |
| - | * Modulspezifikation | + | * Modulspezifikation: Zerlegung in Module (kleinste Einheiten) |
| - | * Implementierung | + | * Implementierung: auf Basis der Modulspezifikation |
| * analytische Phasen / Testphasen / -stufen | * analytische Phasen / Testphasen / -stufen | ||
| - | * Modultest | + | * Modultest: Test der einzelnen Module gegen deren Spezifikation |
| - | * Integrationstest | + | * Integrationstest: Test der Architektur und der Schnittstellen |
| - | * Systemtest | + | * Systemtest: Test gegen Systemspezifikation/Anforderungen, externe Schnittstellen, evtl. Verschmelzung mit Integrationstest |
| - | * Abnahmetest | + | * Abnahmetest: Nachweis, dass das System die Kundenanforderungen erfüllt |
| - | * Modul- / Komponententest | + | * **Modul-/Komponententest** |
| * Testbasis: Modulspezifikation | * Testbasis: Modulspezifikation | ||
| * strenge Trennung der Module beim Test -> alle Module werden für sich allein getestet | * strenge Trennung der Module beim Test -> alle Module werden für sich allein getestet | ||
| * Schnittstellen müssen simuliert werden -> Testtreiber | * Schnittstellen müssen simuliert werden -> Testtreiber | ||
| * üblicherweise vom Entwickler selbst durchgeführt: Compiler, Debugger, Emulator/Simulator, statische Analyse, Automatisierungswerkzeuge | * üblicherweise vom Entwickler selbst durchgeführt: Compiler, Debugger, Emulator/Simulator, statische Analyse, Automatisierungswerkzeuge | ||
| - | * Integrationstest | + | * **Integrationstest** |
| * Testbasis: Systemarchitektur | * Testbasis: Systemarchitektur | ||
| * Durchführung durch spezialisierte Testgruppe <> Entwickler | * Durchführung durch spezialisierte Testgruppe <> Entwickler | ||
| Zeile 54: | Zeile 150: | ||
| * Backbone (Erstellen eines Programmskeletts, in das die Komponenten nach Fertigstellung integriert werden) | * Backbone (Erstellen eines Programmskeletts, in das die Komponenten nach Fertigstellung integriert werden) | ||
| * Big Bang (alle Komponenten werden gleichzeitig integriert) | * Big Bang (alle Komponenten werden gleichzeitig integriert) | ||
| - | * Systemtest | + | * **Systemtest** |
| * Testbasis: Systementwurf / Anforderungen / Normen etc. | * Testbasis: Systementwurf / Anforderungen / Normen etc. | ||
| * Ziel: Prüfen, ob das System den Anforderungen entspricht | * Ziel: Prüfen, ob das System den Anforderungen entspricht | ||
| Zeile 60: | Zeile 156: | ||
| * Durchführung wieder durch spezialisiertes Testteam | * Durchführung wieder durch spezialisiertes Testteam | ||
| * Evtl. Test bei Pilotkunden: Betatest, Feldtest, Pilotbetrieb, controlled introduction | * Evtl. Test bei Pilotkunden: Betatest, Feldtest, Pilotbetrieb, controlled introduction | ||
| - | * Qualitätsmerkmale nach ISO 9126 | + | * **Qualitätsmerkmale** nach ISO 9126/DIN 66272 |
| * Funktionalität (Functionality) | * Funktionalität (Functionality) | ||
| * Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit | * Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit | ||
| Zeile 79: | Zeile 175: | ||
| * Wird für jeden Kunden individuell vor Ort durchgeführt | * Wird für jeden Kunden individuell vor Ort durchgeführt | ||
| * Regressionstest | * Regressionstest | ||
| - | * Regression: Funktionierende Funktionalität wird durch Änderung/Erweiterung beeinträchtigt | + | * **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) | * Änderungen/Erweiterungen: Fehlerbehebung in Entwicklung/Wartung, Hinzufügen von Feature(s) (in einem, mehreren Modulen) | ||
| * Strategien | * Strategien | ||
| Zeile 87: | Zeile 183: | ||
| * Kompletter Test vor Auslieferung neuer Versionen | * Kompletter Test vor Auslieferung neuer Versionen | ||
| * Austausch der Testfälle für die nächste Produktversion | * Austausch der Testfälle für die nächste Produktversion | ||
| + | |||
| ===== Testprozess ===== | ===== Testprozess ===== | ||
| + | * {{:se:generischertestprozess.jpg|}} | ||
| * Testdokumentation | * Testdokumentation | ||
| * notwendig zur internen/externen Kommunikation, teils gesetzliche Aufbewahrungsfristen | * notwendig zur internen/externen Kommunikation, teils gesetzliche Aufbewahrungsfristen | ||
| - | * Test Plan (Testplanung) | + | * {{:se:testdokumente.jpg|}} |
| - | * Test Design/Case/Procedure Specification (Testspezifikation) | + | |
| - | * Test Incident Report (Fehlerbericht) | + | |
| - | * Test Log, Test Summary Report (Ergebnisdokumentation) | + | |
| - | * Test Item Transmittal Report (Übergabeprotokoll) | + | |
| * Testplanung | * Testplanung | ||
| * Start zu Beginn des Projekts (Projekt ist genehmigt, Projektleiter benannt, Test-Projektleiter benannt, Mitarbeiter benannt) | * 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 | * Nach Umfang des Projekts Testmanager für jede Phase oder Gesamtprojekt | ||
| - | * Master-Testplan | + | * **Master-Testplan** |
| * Testaktivitäten über alle Phasen hinweg | * Testaktivitäten über alle Phasen hinweg | ||
| * zeitliche und logistische Abhängigkeiten | * zeitliche und logistische Abhängigkeiten | ||
| * Ziele und Schwerpunkte der einzelnen Phasen (Abgrenzung) | * Ziele und Schwerpunkte der einzelnen Phasen (Abgrenzung) | ||
| - | * Ziel: Optimierung des zeitlichen Ablaufs und des personellen/materiellen Aufwands | ||
| - | * Beispiel: teures Messgerät | ||
| * Pläne der Testphasen werden aus Master-Testplan abgeleitet | * Pläne der Testphasen werden aus Master-Testplan abgeleitet | ||
| * Rahmenbedingungen klären: Termine, Personal etc. -> Zeitplan | * Rahmenbedingungen klären: Termine, Personal etc. -> Zeitplan | ||
| - | * Testziele / -schwerpunkte | + | * 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 | * Ableitung aus ISO 9126: z.B. Vollständigkeit, Verfügbarkeit, Fehlertoleranz, Ergonomie, Wartbarkeit | ||
| * Prioritäten | * Prioritäten | ||
| Zeile 168: | Zeile 262: | ||
| * dann systematischer Test der einzelnen Module auf Basis der Testspezifikation | * dann systematischer Test der einzelnen Module auf Basis der Testspezifikation | ||
| * weitere Tests je nach den ersten Ergebnissen, niedrige Priorität | * weitere Tests je nach den ersten Ergebnissen, niedrige Priorität | ||
| - | * Intution | + | * Intuition |
| * Fehler sind Herdentiere | * Fehler sind Herdentiere | ||
| * Vertrauen Sie Ihrer Intuition | * Vertrauen Sie Ihrer Intuition | ||
| Zeile 190: | Zeile 284: | ||
| * Einhaltung von gesetzlichen Vorgaben | * Einhaltung von gesetzlichen Vorgaben | ||
| * Änderungsprozess, Änderungsanforderung, Fehlerbericht | * Änderungsprozess, Änderungsanforderung, Fehlerbericht | ||
| + | * Nach Inspektion/Test: Änderungsprozess | ||
| * Gründe für Änderungen | * Gründe für Änderungen | ||
| * Fehlerbeseitigung | * Fehlerbeseitigung | ||
| * Verbesserungswünsche | * Verbesserungswünsche | ||
| * Funktionserweiterung | * Funktionserweiterung | ||
| - | * Funktionsergänzung | + | * 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 | ||
| + | * {{:se:testverfahren.jpg|}} | ||
| + | * **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 ===== | ===== ToDo ===== | ||
| * Quellen für Softwarefehler-Beispiele suchen | * Quellen für Softwarefehler-Beispiele suchen | ||
| - | * Ariane 5-Beispiel genauer anschauen | + | * <del>Ariane 5-Beispiel genauer anschauen</del> |
| - | * Generischer Testprozess S. 33 | + | * <del>Generischer Testprozess S. 33</del> |
| - | * Änderungsprozess S. 49 | + | * <del>Änderungsprozess S. 49</del> |
| + | * <del>Tabelle Testfallermittlungsverfahren S. 56</del> | ||
| + | * Beispiel für Zustandsanalyse | ||
| + | * Beispielaufgaben zur Testfallermittlung | ||
| | | ||
| ===== ToRead ===== | ===== ToRead ===== | ||
| Zeile 208: | Zeile 541: | ||
| * Kosten von Softwarefehlern: Kapitel 6, 6.3 | * Kosten von Softwarefehlern: Kapitel 6, 6.3 | ||
| * Qualitätsmerkmale: Kapitel 4.3.1 | * Qualitätsmerkmale: Kapitel 4.3.1 | ||
| - | * Einführung der Testdokumentation: IEEE829 Anhang B | + | * <del>Einführung der Testdokumentation: IEEE829 Anhang B</del> |
| Zeile 228: | Zeile 561: | ||
| * Sie kennen die unterschiedlichen Testdokumente, die im Standard IEEE Std 829-1998 beschrieben 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 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 ===== | ===== Ü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.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. | ||
| Zeile 234: | Zeile 581: | ||
| * Ü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 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 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.1207488836.txt.gz · 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
