Verifikation und Testen
This commit is contained in:
parent
4505f885a6
commit
945cf237ba
BIN
Assets/Softwaretechnik1_Codegenerierung.png
Normal file
BIN
Assets/Softwaretechnik1_Codegenerierung.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 109 KiB |
@ -1674,13 +1674,412 @@ Dokumentation des Feinentwurfs
|
||||
- Klassenschnittstellen
|
||||
|
||||
# Implementierung
|
||||
Aufgaben der Implementierung
|
||||
- Aus Spezifikationen Programm(code) erzeugen
|
||||
- Aufbauend auf Ergebnissen des Feinentwurfs
|
||||
- Algorithmen konzipieren
|
||||
- Datenstrukturen realisieren
|
||||
- Umsetzen in konkreter Programmiersprache
|
||||
- Dokumentation
|
||||
- Untersuchung des Zeit- und Speicherbedarfs
|
||||
- Test und Verifikation
|
||||
- „Programmieren im Kleinen“
|
||||
|
||||
## Konventionen und Werkzeuge
|
||||
Konventionen beim Programmieren
|
||||
- (Coding Rules, -conventions, -standards)
|
||||
- Regeln für verständliche Programme
|
||||
- „wie“ sollte Quellcode formal und strukturell gestaltet sein
|
||||
- Bezeichner, Einrückungen, Dokumentation, Dateien, ...
|
||||
- Strukturierung: Block, Methode, Klasse, Package
|
||||
- Firmenspezifische Regeln
|
||||
- Festlegung Entwurfsprinzipien (z.B. keine Mehrfachvererbung)
|
||||
|
||||
Namenskonventionen
|
||||
- Klasse
|
||||
- (mit) Substantiv, „UpperCamelCase“
|
||||
- Beispiele: Account, StandardTemplate
|
||||
- Methode
|
||||
- (mit) Verb, Imperativ (Aufforderung), „lowerCamelCase“
|
||||
- Beispiele: checkAvailability(), getDate()
|
||||
- Attribut, Variable
|
||||
- (mit) Substantiv, „lowerCamelCase“
|
||||
- Beispiele: anzahlAutos, fensterBreite
|
||||
- Konstante
|
||||
- Nur Großbuchstaben, Worte mit "_" zusammengesetzt
|
||||
- Standardpräfixe: "MIN_", "MAX_", "DEFAULT_", ...
|
||||
- Beispiele: NORTH, BLUE, MIN_WIDTH, DEFAULT_SIZE
|
||||
|
||||
Formatierungs-Richtlinien
|
||||
- Entsprechend Schachtelungstiefe einrücken, aber nicht zu weit
|
||||
- Einheitliche Verwendung von Leerzeilen und Leerzeichen
|
||||
- Einheitliche Dateistruktur verwenden
|
||||
- Eine .java-Datei pro Klasse
|
||||
- Ein Verzeichnis für jedes package
|
||||
- Werkzeuge: source beautifier, oft in IDEs enthalten
|
||||
- Editor: syntax highlighting
|
||||
- Navigationswerkzeuge
|
||||
- Auf- und Zuklappen, Inhaltsverzeichnis, tagging
|
||||
- doxygen, Eclipse etc.
|
||||
|
||||
Änderungsfreundlicher Code
|
||||
- Wahl von Variablen, Konstanten und Typen orientiert an der fachlichen Aufgabe, nicht an der Implementierung:
|
||||
- `typedef char name [NAME_LENGTH]`
|
||||
- `typedef char firstName [FIRST_NAME_LENGTH]`
|
||||
- Symbolische Konstanten statt literaler Werte verwenden, wenn spätere Änderung denkbar
|
||||
- Algorithmen, Formeln, Standardkonzepte in Methoden/Prozeduren kapseln
|
||||
- Übersichtlichkeit: Zusammenhängende Einheit nicht größer als Editorfenster (40-60 Zeilen, 70 Zeichen breit)
|
||||
- Strukturierte Programmierung (Regeln je nach Schärfe)
|
||||
- Kein goto verwenden (in anderen Sprachen als Java)
|
||||
- switch nur mit break-Anweisung nach jedem Fall
|
||||
- break nur in switch-Anweisungen verwenden
|
||||
- continue nicht verwenden (Effekt ähnlich goto)
|
||||
- return nur am Ende zur Rückgabe des Werts
|
||||
- Übersichtliche Ausdrücke
|
||||
- Seiteneffektfreie Ausdrücke, schlecht: y += 12*x++;
|
||||
- Variablen möglichst lokal und immer private deklarieren
|
||||
- Wiederverwendung "äußerer" Namen vermeiden
|
||||
|
||||
Werkzeuge
|
||||
- Integrated Development Environments (Eclipse, KDevelop)
|
||||
- Compiler, Linker; Build / Make; Versionskontrolle (git, svn)
|
||||
|
||||
## Code-Qualität
|
||||
Portierbarer Code
|
||||
- Code, den man ohne Änderungen in ein anderes System (Compiler, Betriebssystem, Rechner) übertragen kann
|
||||
- Kein implementierungsabhängiges Verhalten!
|
||||
- ANSI C++ Standard ist nicht vollständig definiert
|
||||
- Ist das Verhalten nicht festgelegt, unterscheidet der ANSI C++ Standard zwischen:
|
||||
- Implementierungsabhängigem, unspezifiziertem oder undefiniertem Verhalten
|
||||
- Code, welcher auf implementierungsabhängigem, unspezifiziertem oder undefiniertem Verhalten basiert, ist
|
||||
- Nicht portabel und somit häufig verboten
|
||||
- Wird unter Umständen ungewollt wegoptimiert
|
||||
|
||||
Implementierungsabhängiges Verhalten
|
||||
- Compiler übersetzen bestimmte Sprachkonstrukte unterschiedlich, Ergebnis unterscheidet sich
|
||||
- Voraussetzung
|
||||
- Verhalten ist konsistent festgelegt und dokumentiert
|
||||
- Kompilierung von standardkonformem Code ist erfolgreich
|
||||
- Beispiel: Speichergröße von Integer-Typen
|
||||
- char kann signed oder unsigned sein: Nicht damit rechnen!
|
||||
- 32 Bit System ist wie erwartet
|
||||
- 16 Bit System: Multiplikation wird mit int durchgeführt -> Überlauf -> undefiniertes Verhalten
|
||||
|
||||
- Unspezifiziertes Verhalten
|
||||
- Wie implementierungsabhängiges Verhalten
|
||||
- Compiler muss sich für ein bestimmtes Verhalten entscheiden
|
||||
- Muss nicht dokumentiert sein
|
||||
- Beispiel: Evaluierungsreihenfolge von Funktionsargumenten `tuWas(zuerstDas(),oderDochLieberDas());`
|
||||
- Undefiniertes Verhalten
|
||||
- Keinerlei Vorgaben
|
||||
- Compiler muss mögliches Problem nicht melden
|
||||
- Keine Voraussage welches Resultat eintritt
|
||||
- Bereits die Kompilierung kann fehlschlagen
|
||||
- Oder das laufende Programm kann falsche Resultate liefern.
|
||||
- Effekt: „Bei mir läuft es aber!?“
|
||||
- „undefiniertes Verhalten nutzen grenzt an Sabotage!“
|
||||
|
||||
Sicherer Code mit const
|
||||
- Const Variable – Konstante
|
||||
- Stellt sicher, dass sich der Wert nicht verändert
|
||||
- Const Parameter
|
||||
- Übergabeparameter ändert sich nicht innerhalb der Operation
|
||||
- Z.B. bei Übergabe komplexer Daten als Referenz bzw. Zeiger `long calcMeanValue(const image &i){...}`
|
||||
- Const Operationen
|
||||
- Sicherstellen, dass Operation das Exemplar nicht ändert
|
||||
- Aufruf der const Operation bei const Variablen möglich
|
||||
- Verwende const wenn möglich
|
||||
|
||||
|
||||
## Dokumentation
|
||||
- Selbstdokumentierende Programme?
|
||||
- 2001 Int. Obfuscated C Code Contest Winner, Short Program
|
||||
|
||||
Integrierte Dokumentation
|
||||
- Verständlichkeit, Wartbarkeit – auch für Programmierer!
|
||||
- Code selbst sollte möglichst verständlich sein
|
||||
- Dokumentation in Programm schreiben und aktualisieren
|
||||
- Beschreibung der Bedeutung des Codes!
|
||||
- Als Konventionen festschreiben
|
||||
- Programmvorspann
|
||||
- Kurzbeschreibung Datei / Klasse / Funktion ...
|
||||
- Verwaltungsinformationen
|
||||
- Autor, Datum, Version, Projekt, ToDo, FixMe, ...
|
||||
- Zustand: geplant, in Bearbeitung, vorgelegt, akzeptiert
|
||||
- Laufende Kommentare im Quellcode
|
||||
|
||||
Programmierer-Dokumentation
|
||||
- Als eigenes Dokument elektronisch oder gedruckt
|
||||
- Einstieg in Programmverständnis (z.B. Bachelor-Arbeit)
|
||||
- Konsistenz mit Quelltext? Verweise?
|
||||
- Technische Unterstützung: JavaDoc (Java), doxygen (C++)
|
||||
- Ergänztes Java-Programm Dokumentation HTML, PDF,
|
||||
```js
|
||||
/** @author name Mustermann */
|
||||
/** @param name description */
|
||||
/** @return description */
|
||||
```
|
||||
|
||||
Benutzerdokumentation
|
||||
- Benutzer-Handbuch, Online-Dokumentation
|
||||
- Unterstützung ohne Support?
|
||||
- Vollständige und fehlerfreie Beschreibung der Benutzung
|
||||
- Beispiele, screen shots
|
||||
- Arten: Tutorial, Beschreibung, Referenz
|
||||
|
||||
Benutzer-Unterstützungssysteme
|
||||
- Integrierte Hilfe (Suchfunktion, balloon help / tool tips)
|
||||
- Assistenz-System (Zustandsabhängige Anleitung)
|
||||
- Tutor-System zum Erlernen
|
||||
- Bug-Listen, Mailinglisten, Diskussionsforen
|
||||
|
||||
## Codegenerierung
|
||||
Bezug zwischen Modell und Programmcode
|
||||
- Vorwärtsmodellierung: Modell - Code
|
||||
- Rückwärtsmodellierung: Code - Modell
|
||||
- Außerdem: Modelltransformation, Refaktorisierung
|
||||
- Idealfall: Automatische Übersetzung durch SW-Werkzeug (in beiden Richtungen)
|
||||
- „Modellbasierte Entwicklung“
|
||||
- Statisch: Beispiel Klassendiagramm - Quelltext der Klassen mit allen Vererbungsbeziehungen, Attributen und Methodensignaturen (Klassen-Stümpfe mit leeren Methodenrümpfen zum Ausfüllen)
|
||||
- Dynamisch: Beispiel Zustandsdiagramm - Quelltext der Zustandssteuerung einer Klasse
|
||||
|
||||
|
||||
|
||||
Weitere statische Transformationen
|
||||
- Abbildung von Assoziationen auf Sammlungen
|
||||
- Abbildung von Verträgen auf Ausnahmen
|
||||
- Abbildung von Objektmodellen auf Datenbankschemata
|
||||
- Abbildung von Entwurfsmustern auf Codefragmente
|
||||
|
||||
Optimierung des Entwurfsmodells
|
||||
- Grund: nichtfunktionale Eigenschaften
|
||||
- Zugriffspfade
|
||||
- Klassen in Attribute umwandeln
|
||||
- Verzögerung von Berechnungen
|
||||
- Zwischenspeicherung aufwändiger Ergebnisse
|
||||
|
||||
Codegenerierung aus StateCharts
|
||||
- Einfachste Möglichkeit: Switch (Case) Statement
|
||||
- Zustände werden durch Datenwerte repräsentiert
|
||||
- Aktueller Zustand: einzelne skalare Variable
|
||||
- Jedes Ereignis wird durch Methode implementiert
|
||||
- Ausgehend von aktivem Zustand wird bei Eintreffen eines Ereignisses der entsprechende Programmcode ausgeführt
|
||||
- Abhängig von Zustandsvariable wird Aktion ausgeführt und der Folgezustand eingestellt
|
||||
- Wird in einer Klasse realisiert
|
||||
- Sinnvoll für einfache, “flache” Modelle
|
||||
- Sonst Logik für Hierarchie nötig
|
||||
|
||||
Anpassung der Generierung
|
||||
- Verschiedene Zielsprachen (Java, C++, ...)
|
||||
- Model2Text-Transformationen
|
||||
- Verschiedene Generatoren, z.B. Eclipse Modelling Project
|
||||
- Generierung aus dem Modellierungswerkzeug
|
||||
- Parametrisierung der Codegenerierung
|
||||
- Generierungsvorlagen
|
||||
|
||||
Weitere Werkzeuge
|
||||
- Compiler-Compiler: Syntaxbeschreibung wird in lexikalische Analyse (tokenizer) und Syntaxanalyse-Programm transformiert (lex & yacc / flex & bison / antlr)
|
||||
- Codegenerierung für grafische Benutzungsoberflächen aus grafischer Beschreibung: GUI toolkits
|
||||
- XML-Parser
|
||||
- XSLT, DOM, SAX, ...
|
||||
|
||||
## Implementierung aktiver Objekte
|
||||
Realisierung aktiver Entwurfsobjekte
|
||||
- Reagieren nicht nur (Methodenaufruf), sondern implementieren eigenes Verhalten
|
||||
- Aktive Klassen, z.B. Steuerobjekte
|
||||
|
||||
Arten von Programmabarbeitung
|
||||
- Sequentiell: es gibt immer genau einen nächsten Schritt, alle Schritte werden nacheinander ausgeführt
|
||||
- Parallel: Spezielle Hardware bzw. Mehrkernprozessor, mehrere Befehlsfolgen werden echt parallel bearbeitet
|
||||
- Quasi-parallel: Ein Prozessor arbeitet mehrere Befehlsfolgen in freier Einteilung ab
|
||||
- Nebenläufig: Oberbegriff für Parallel und Quasi-parallel
|
||||
- concurrent
|
||||
|
||||
Vorteile
|
||||
- Höhere Geschwindigkeit
|
||||
- Kein aktives Warten auf Ereignisse
|
||||
- Getrennte Implementierung unabhängiger Aspekte
|
||||
|
||||
Ergebnisse eines Programms
|
||||
- Ein Programm, dessen Ablauf eindeutig vorherbestimmt ist, nennt man deterministisch (deterministic)
|
||||
- Ein Programm, das bei gleichen Eingaben gleiche Ausgaben produziert, heißt determiniert (determined)
|
||||
- Programme in üblichen Programmiersprachen sind sequentiell, deterministisch und determiniert
|
||||
- Grund: Herkömmliche Programmiersprachen sind durch das von-Neumann-Modell geprägt
|
||||
- Determinismus nicht notwendig für Determiniertheit!
|
||||
- Determiniertheit nebenläufiger Programme: Synchronisation
|
||||
- Vermeidung von Schreib/Schreib und Schreib/Lese-Konflikten
|
||||
|
||||
Java Threads
|
||||
- Verwaltung durch die Java Virtuelle Maschine (JVM)
|
||||
- Realisierung der Threads ist je nach Implementierung der JVM unterschiedlich
|
||||
- Abbildung auf Betriebssystem-Threads (z.B. unter Windows weitverbreitet)
|
||||
- Realisierung durch die JVM (z.B. unter Unix und in Java-fähigen Browsern)
|
||||
- Nachteile: Keine Ausnutzung von Multiprozessorsystemen durch die VM; Zuteilungsstrategie für Threads ist in derzeitigen Implementierungen unterschiedlich
|
||||
- Threads arbeiten immer im Adressraum der JVM (eigener Prozess) und sind außerhalb dieser nicht sichtbar
|
||||
|
||||
Erzeugung eines Threads
|
||||
- Unterklasse der Basisklasse „Thread“ bilden `class MyThread extends Thread`
|
||||
- Problem: keine Mehrfachvererbung, daher Alternative nötig (Beispiel: Applet):
|
||||
- Schnittstelle „Runnable“ implementieren
|
||||
- `class MyThread implements Runnable`
|
||||
- Die vordefinierte Schnittstelle Runnable ist definiert als
|
||||
```java
|
||||
public interface Runnable
|
||||
{ public abstract void run(); }
|
||||
```
|
||||
|
||||
Starten eines Threads
|
||||
- Eine Klasse, die Runnable implementiert, muss wie Unterklassen von Thread immer eine run()-Methode definieren
|
||||
- Seiteneffekt der Runnable-Schnittstelle
|
||||
- Instanzen der Klasse werden nebenläufig zu den anderen laufenden Threads ausgeführt
|
||||
- Ausführung beginnt mit der Methode run ()
|
||||
- Ablauf
|
||||
- Thread-Objekt erzeugen
|
||||
- Thread starten mit t.start()
|
||||
- start() ruft implizit run() auf
|
||||
|
||||
Synchronisation von Threads
|
||||
- Gezielte Einschränkung der Nebenläufigkeit
|
||||
- Gründe
|
||||
- Zugriffsbeschränkung, gegenseitiger Ausschluss
|
||||
- Abhängigkeiten, einseitige Synchronisation
|
||||
- Methoden: Semaphore, Monitore, Schlossvariablen, ...
|
||||
|
||||
Java: Monitore
|
||||
- Zugriffsoperationen werden in Klassen zusammengefasst
|
||||
- Gegenseitiger Ausschluss: Spezifikation der betroffenen Zugriffsoperation als synchronized
|
||||
|
||||
## Verifikation und Testen
|
||||
Wie erreicht man qualitativ hochwertige Software?
|
||||
- Wissen, Erfahrung und Methodenkompetenz der Programmierer
|
||||
- Projektstruktur, klare Verantwortlichkeiten
|
||||
- Kosten- und Zeitdruck? Änderungen?
|
||||
- Programmier- und Testmethoden
|
||||
- pair programming, code reading etc.
|
||||
- Qualitätsverantwortlicher, automatisiertes Testen
|
||||
- Technische Unterstützung
|
||||
- Z.B. Versionierung, Dokumentation, Testen, Entwicklungsumgebung
|
||||
|
||||
Begriffe
|
||||
- Zuverlässigkeit: Maß für Übereinstimmung des Systemverhaltens mit Spezifikation
|
||||
- Grund für Unzuverlässigkeit:
|
||||
- Fehler (bug, fault): fehlerhafter Programmcode o.ä.
|
||||
- Der Begriff „Bug“:
|
||||
- Schon vor Computern als Begriff für Fehler benutzt
|
||||
- Motte im Relais des Computers Mark II Aiken (1947)
|
||||
- Fehlerhafter Zustand (error): Fehler hat zur Laufzeit zu einem internen fehlerhaften Zustand geführt, der möglicherweise zu einem Ausfall führt
|
||||
- Störfall, Ausfall (failure): Abweichung vom spezifizierten Verhalten, meist mit negativen Folgen
|
||||
|
||||
Vergleich System / Systemmodell
|
||||
- Anspruch guter Software: System entspricht Systemmodell (Korrektheit)
|
||||
- Problem: System nicht vollständig automatisch erzeugbar!
|
||||
- Auswege
|
||||
- Fehlervermeidung (Inspektion, pair programming, ...)
|
||||
- Nachweis, dass System dem Modell entspricht - Verifikation
|
||||
- Überprüfen, ob System dem Modell entspricht - Testen
|
||||
- Fehlertoleranz (durch Redundanz)
|
||||
|
||||
Verifikation
|
||||
- Mathematisch formaler Beweis, dass ein Programm einer Spezifikation genügt
|
||||
- Vorteil: wenn anwendbar, dann vollständiger Beweis
|
||||
- Problem: für viele (realistisch große) Fälle nicht anwendbar
|
||||
- Zu aufwändig
|
||||
- Umgebung muss ebenfalls verifiziert werden
|
||||
- Auch in der Theorie nicht immer entscheidbar: Halteproblem, Gödelscher Unvollständigkeitssatz
|
||||
- Theoretische Informatik: Berechenbarkeitstheorie, formale Semantik; aktives Forschungsgebiet
|
||||
- model checking
|
||||
|
||||
Testen
|
||||
- Systematischer Versuch, Defekte in der Software zu finden
|
||||
- Ingenieurtechnik zur Erhöhung des Vertrauens in Softwaresysteme, aber: unvollständig!
|
||||
- Kann nur die Anwesenheit von Fehlern nachweisen, aber nicht Korrektheit (Abwesenheit von Fehlern)!
|
||||
- Aufgabe: Unterschiede zwischen Modell und System finden
|
||||
- Destruktiv im Gegensatz zu sonstigen SWE-Aufgaben
|
||||
- Daher sollten nicht (nur) Entwickler selbst testen
|
||||
|
||||
Testplanung
|
||||
- Testen ist aufwändig, deshalb ist gute Planung nötig!
|
||||
- Testplanung sollte bereits mit der Anforderungsanalyse beginnen und im Entwurf verfeinert werden (V-Modell, Test-First-Ansatz)!
|
||||
- Typische Bestandteile einer Test-Spezifikation (Testdrehbuch)
|
||||
- Phasenmodell des Testprozesses
|
||||
- Zusammenhang zur Anforderungsspezifikation, z.B. dort festgelegte Qualitätsziele
|
||||
- Zu testende Produkte
|
||||
- Zeitplan für die Tests
|
||||
- Abhängigkeiten der Testphasen
|
||||
- Aufzeichnung der Testergebnisse
|
||||
- Hardware- und Softwareanforderungen
|
||||
|
||||
Arten von Tests
|
||||
- Komponententest: Fehler in einzelnen Objekten oder Subsystemen, losgelöst vom umgebenden System
|
||||
- Umgebung muss nachgebildet werden
|
||||
- Integrationstest: Zusammenspiel von Komponenten
|
||||
- Vollständiges System: Systemtest; Szenarios
|
||||
- Strukturtest: innere Zustände, Interaktionen
|
||||
- Funktionstest: Anforderungen aus Lastenheft
|
||||
- Leistungstest: nichtfunktionale Anforderungen
|
||||
- Benutzbarkeitstest: Fehler in der Benutzungsschnittstelle, Verständlichkeit, Akzeptanz bei Anwendern
|
||||
- Prototypen
|
||||
- Akzeptanztest, Installationstest: Kunde, Abnahme
|
||||
|
||||
Komponententests
|
||||
- Überprüft Verhalten einer Systemkomponenten im Vergleich zur Spezifikation
|
||||
- Da Tests bereits frühzeitig stattfinden sollten, ist Umgebung meist nicht vollständig implementiert
|
||||
- Teststumpf (stub, dummy) simuliert aufgerufene Komponenten
|
||||
- Testtreiber simuliert aufrufende Komponenten
|
||||
- Vorgehensweisen
|
||||
- Bottom-up
|
||||
- Top-down
|
||||
- Sandwich
|
||||
- Schichtenweises Testen
|
||||
|
||||
Systematisches Testen
|
||||
- Testfall
|
||||
- Beschreibung, Name
|
||||
- Zu testende Komponente, Testgegenstand (Pfad, Aufrufart)
|
||||
- Eingabedaten (Testdaten)
|
||||
- Erwartete Ergebnisse („Orakel“)
|
||||
- Protokoll (erzeugte Ausgaben)
|
||||
- Bewertung des Ergebnisses
|
||||
- Weitere Begriffe
|
||||
- Regressionstest: erneute Durchführung eines Tests anhand einer geänderten Version des Testgegenstands
|
||||
- Alphatest: Test eines Prototypen durch Benutzer
|
||||
- Betatest: Test der vollständigen Software durch Benutzer
|
||||
|
||||
Funktionaler Test (black box test)
|
||||
- Testfallauswahl beruht auf Spezifikation
|
||||
- Ohne Wissen über inneren Aufbau
|
||||
- E/A-Zusammenhang
|
||||
|
||||
Äquivalenzklassen im funktionalen Test
|
||||
- Problem: alle Kombinationsmöglichkeiten der Eingangsdaten sind zu umfangreich für vollständigen Test
|
||||
- Mögliche Einschränkung: Bildung von Äquivalenzklassen der Eingangsdaten, für die ähnliches Verhalten erwartet wird
|
||||
- Basierend auf Anwendungsdomäne
|
||||
- Äquivalenzklasse = Teilmenge der möglichen Datenwerte der Eingabeparameter
|
||||
- Test je eines Repräsentanten jeder Äquivalenzklasse
|
||||
- Finden von Äquivalenzklassen
|
||||
- Zulässige / unzulässige Teilbereiche der Datenwerte
|
||||
- Unterteilung der Bereiche nach erwarteten Ausgabewerten
|
||||
|
||||
Grenztests
|
||||
- Ergänzung von Äquivalenztests: Spezialfälle
|
||||
- Rand der Äquivalenzklasse
|
||||
- Außerdem: Sonderfälle, erwartete Problemfälle (technisch)
|
||||
|
||||
Strukturtest (white box test, glass box test)
|
||||
- Testfallauswahl beruht auf Programmstruktur
|
||||
- Wie erreicht man möglichst vollständige Abdeckung?
|
||||
- Kontrollflussorientiert
|
||||
- Anweisungsüberdeckung anhand Quellcode
|
||||
- Zweigüberdeckung und
|
||||
- Pfadüberdeckung anhand des Flussgraphen reduzierte Variante: bounded interior Pfadtest
|
||||
- Datenflussorientiert
|
||||
- defines / uses-Verfahren: Abarbeitungspfade von Definition zu jeder Verwendung von Variable oder Objekt durchlaufen
|
||||
- Zustandsorientiert
|
||||
|
||||
## Testaktivitäten und Werkzeuge
|
||||
|
||||
|
||||
|
||||
## Softwareverteilung
|
||||
|
||||
# Vorgehensweise
|
||||
|
||||
Loading…
Reference in New Issue
Block a user