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 17:05] 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 228: | Zeile 322: | ||
| ===== Verfahren zur Ermittlung von Testfällen ===== | ===== Verfahren zur Ermittlung von Testfällen ===== | ||
| - | * Ziele | + | * **Ziele** |
| * wiederholbare, leicht wartbare Testfälle finden | * wiederholbare, leicht wartbare Testfälle finden | ||
| * Begrenzung der Menge der Testfälle | * Begrenzung der Menge der Testfälle | ||
| * hohe Testabdeckung erreichen | * hohe Testabdeckung erreichen | ||
| - | * White-Box-Tests | + | * {{:se:testverfahren.jpg|}} |
| + | * **White-Box-Tests** | ||
| * strukturorientiert | * strukturorientiert | ||
| * basieren auf Quelltext/Systembeschreibung | * basieren auf Quelltext/Systembeschreibung | ||
| Zeile 238: | Zeile 333: | ||
| * Verwendung interner Schnittstellen | * Verwendung interner Schnittstellen | ||
| * wichtig zu Beginn der Tests (Module) | * wichtig zu Beginn der Tests (Module) | ||
| - | * Black-Box-Tests | + | * **Black-Box-Tests** |
| * Interne Kenntnisse nicht erforderlich/gewünscht | * Interne Kenntnisse nicht erforderlich/gewünscht | ||
| * nur Benutzer-/Systemschnittstellen werden verwendet | * nur Benutzer-/Systemschnittstellen werden verwendet | ||
| * basieren auf Anforderungen/Beschreibungen/Spezifikationen | * basieren auf Anforderungen/Beschreibungen/Spezifikationen | ||
| * wichtiger gegen Ende der Tests | * wichtiger gegen Ende der Tests | ||
| - | * Gray-Box-Tests | + | * **Gray-Box-Tests** |
| * Mischform | * Mischform | ||
| * Beispiel: Kenntnis über Interna fließt in den Simulation externer Tests ein, Ausfall einer Komponente wird simuliert | * Beispiel: Kenntnis über Interna fließt in den Simulation externer Tests ein, Ausfall einer Komponente wird simuliert | ||
| - | * formal | + | * **formal** |
| * strikte Regeln zur Ermittlung von Testfällen | * strikte Regeln zur Ermittlung von Testfällen | ||
| * kann automatisiert werden | * kann automatisiert werden | ||
| * hohe Qualität der Testbasis erforderlich | * hohe Qualität der Testbasis erforderlich | ||
| - | * nichtformal | + | * **nichtformal** |
| * gestalterischer Spielraum | * gestalterischer Spielraum | ||
| * keine Aussage über Testabdeckung möglich | * keine Aussage über Testabdeckung möglich | ||
| * Tester braucht Erfahrung | * Tester braucht Erfahrung | ||
| - | * Testabdeckung | + | * **Testabdeckung** |
| * gibt an, welcher Teil der Testbasis durch Testfälle abgedeckt wird | * gibt an, welcher Teil der Testbasis durch Testfälle abgedeckt wird | ||
| * Angabe der Testbasis | * Angabe der Testbasis | ||
| Zeile 317: | Zeile 412: | ||
| * sinnvolle Ergänzung zu strukturiertem Test | * sinnvolle Ergänzung zu strukturiertem Test | ||
| * Testabdeckung meist gering | * 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 | + | * **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 | * Smoke-Test | ||
| * Ziel: Absturz des Systems | * Ziel: Absturz des Systems | ||
| Zeile 323: | Zeile 418: | ||
| * viele/simultane Zugriffe | * viele/simultane Zugriffe | ||
| * einzelne Ergebnisse werden nicht ausgewertet | * 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> |
| - | * Tabelle Testfallermittlungsverfahren S. 56 | + | * <del>Tabelle Testfallermittlungsverfahren S. 56</del> |
| + | * Beispiel für Zustandsanalyse | ||
| + | * Beispielaufgaben zur Testfallermittlung | ||
| | | ||
| ===== ToRead ===== | ===== ToRead ===== | ||
| Zeile 335: | 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 363: | Zeile 569: | ||
| * Sie können für unterschiedliche Testsituationen die jeweils am besten geeigneten Verfahren angeben. | * 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 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 ===== | ||
| Zeile 373: | Zeile 584: | ||
| * Ü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.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.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.1207494304.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
