Verifikation und Validierung von Software

Question 1

Verifikation

Answer 1

“Entspricht das Produkt den Anforderungen?”

Question 2

Validierung

Answer 2

“Stellt das Produkt die Anwender in ihrer Arbeitsumgebung zufrieden?”

Question 3

Verfahren der V&V

Answer 3

• Softwareinspektion

- Softwaretest

Question 4

Softwareinspektion

Answer 4

Je nach Entwicklungsfortschritt Prüfen der Spezifikationen, Entwurfsmodelle und Quellcode auf Fehler

Question 5

Softwaretest

Answer 5

• Programm zur Ausführung bringen und prüfen, ob es leistet, was es soll
• soll kostenökonomisch sein, wird exponentiell teurer, je mehr Fehler gefunden werden sollen
• unmöglich alle zu finden

Question 6

Testcases

Answer 6

• Szenarien, die die zu tätigenden Eingaben und die vom System erwartenden Ausgaben enthalten
• Abdecken möglichst vieler Möglichkeiten
• werden aus Use-Cases abgeleitet (Anleitung für Tester)

Question 7

Ablauf Testen

Answer 7

1) Entwerfen der Testfälle
2) Erstellen der Testdaten
3) Ausführung des Programms mit Testdaten
4) Vergleich der Ergebnisse mit Testfällen

Question 8

Was beschreiben Testcases?

Answer 8

• Vorbedingungen
• Eingabedaten (müssen gültige und ungültige Eingabewerte enthalten)
• Aktionen
• Erwartete Ergebnisse

Question 9

Fehlerklassen

Answer 9

• Datenfehler
• Steuerungsfehler
• Ein-/Ausgabefehler
• Schnittstellenfehler
• Speicherverwaltungsfehler
• Exception-Verwaltungsfehler

Problem: Fehler aus Spezifikation bleiben unentdeckt

Question 10

White Box Test

Answer 10

Beim Erstellen der Testfälle wird Wissen um den Aufbau des Programms berücksichtigt (z.B. Arraylänge bekannt)

Question 11

Black Box Test

Answer 11

Testfälle werden ausschließlich aus Spezifikation abgeleitet (Aufbau des Programms nicht bekannt / berücksichtigt)

Question 12

Testprinzipien (6)

Answer 12

1) Anforderungsbasiert (Test Cases aus Use Cases abgeleitet)
2) Klassenbasiert (Ein- und Ausgabewerte werden klassifiziert nach der Art wie sie verarbeitet werden –> Alle Äquivalenzklassen werden getestet)
3) Strukturell (Abdecken von Grenzfällen bei bekanntem Algorithmus)
4) Pfadüberdeckung (Abdecken aller Ausführungspfade eines Programms)
5) Testen auf Zufallswerte (ergänzend, um Blick zu erweitern)
6) CRUD (Datenbasiertes Testen. Objekt durchläuft Create-Read-Update-Delete)

Question 13

Model based Testing

Answer 13

• Testfälle werden mit Modellen beschrieben

- aus Umgebungsmodellen abgeleitet (Use-Case- oder Aktivitätsdiagramme)

Question 14

Nicht-funktionale Tests

Answer 14

• Lasttest/Stresstest: simuliert große Benutzerzahlen
• Usability-Test: prüft Bedienbarkeit mit Testnutzern
• Recovery-Test: testet Wiederherstellung und Datenintegrität nach Systemausfällen
• Sicherheitstest gegen potentielle Angreifer

Question 15

Teststufen: Unittest (Schnittstellentest)

Answer 15

• einzelne Komponenten des Gesamtsystems werden über ihre Schnittstelle angesprochen
• Grenzen der Gültigkeitsbereiche aller Parameter testen
• Reaktion auf Kombinationen von gültigen und ungültigen Parametern
• Reaktion auf Überlastung durch Vielzahl von Aufrufen

Question 16

Teststufen: Integrationstest / Systemtest

Answer 16

• Gesamtsystem wird getestet (auch Performance)
• Tester haben Zugriff auf Quellcode (White Box Test)
• automatisierte Testtools für große Lasten und viele Wiederholungen

Question 17

Teststufen: Regressionstest

Answer 17

• bei neuer Version der Software (nicht komplett neu)

- unveränderter Code wird ebenfalls getestet um Seiteneffekte zu finden

Question 18

Teststufen: Auslieferungstest (User-Acceptance-Test)

Answer 18

• Gesamtsystem wird getestet

- Tester haben keinen Zugriff auf Quellcode (Black Box Test)

Question 19

Teststufen für COTS-Software (Commerical off-the-shelf)

Answer 19

• Alphatest (interner Test mit Fokus auf Funktionalität und Usability)
• Betatest (erste Version an eingeschränkten Benutzerkreis für Fehlermeldungen)
• Möglichkeiten nach Betatest: Release Candidate (RC), Release to Manufacturing (RTM), General Availability (GA)

Question 20

Verifikation und Validierung kritischer Systeme

Answer 20

• V & V braucht hier noch mehr Zeit und Budget
• -> Ausfälle sind gravierender und Kunden verlangen bei kritischen Systemen gesonderte Dokumentation der Verlässlichkeit

Question 21

Testwerkzeuge

Answer 21

• Bug Tracking Tools
• dynamische Analysewerkzeuge (z.B. für Speicherbedarf)
• Testautomatisierung (hoher Aufwand) lohnenswert für Regressionstests (wiederkehrende Kosten manueller Tests) und Lasttests (mangels Alternative)

Question 22

Statische Codeanalyse

Answer 22

• automatisierte Untersuchung des Quellcodes ohne das Programm auszuführen
• Schwerpunkt nicht auf Laufzeitfehlern, sondern auf Suche nach typischen, wiederkehrenden Fehlern
• einstellbar, welche Fehlerarten gesucht werden sollen
• z.B. Rundungsfehler bei Teilen zweier int-Werte –> double-Wert besser

Question 23

Äquivalenzklasse

Answer 23

• Bezüglich Ein- und Ausgabedaten ähnliche Klassen bzw. Objekte, bei denen erwarten wird, dass sie sich gleichartig verhalten (entsprechen sich)
• Alle Ein- und Ausgabedaten werden in Äquivalenzklassen unterteilt
• mit jedem beliebigen Objekt einer Klasse können die gleichen Fehler wie mit jedem anderen Objekt dieser Äquivalenzklasse