Verifikation und Validierung von Software Flashcards

1
Q

Verifikation

A

“Entspricht das Produkt den Anforderungen?”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Validierung

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Verfahren der V&V

A
  • Softwareinspektion

- Softwaretest

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Softwareinspektion

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Softwaretest

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Testcases

A
  • 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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Ablauf Testen

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Was beschreiben Testcases?

A
  • Vorbedingungen
  • Eingabedaten (müssen gültige und ungültige Eingabewerte enthalten)
  • Aktionen
  • Erwartete Ergebnisse
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Fehlerklassen

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

Problem: Fehler aus Spezifikation bleiben unentdeckt

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

White Box Test

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Black Box Test

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Testprinzipien (6)

A

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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Model based Testing

A
  • Testfälle werden mit Modellen beschrieben

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Nicht-funktionale Tests

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Teststufen: Unittest (Schnittstellentest)

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Teststufen: Integrationstest / Systemtest

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

Teststufen: Regressionstest

A
  • bei neuer Version der Software (nicht komplett neu)

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

18
Q

Teststufen: Auslieferungstest (User-Acceptance-Test)

A
  • Gesamtsystem wird getestet

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

19
Q

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

A
  • 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)
20
Q

Verifikation und Validierung kritischer Systeme

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

Testwerkzeuge

A
  • 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)
22
Q

Statische Codeanalyse

A
  • 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
23
Q

Äquivalenzklasse

A
  • 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