Verifikation und Validierung von Software Flashcards Preview

Software Engineering > Verifikation und Validierung von Software > Flashcards

Flashcards in Verifikation und Validierung von Software Deck (23)
Loading flashcards...
1
Q

Verifikation

A

“Entspricht das Produkt den Anforderungen?”

2
Q

Validierung

A

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

3
Q

Verfahren der V&V

A
  • Softwareinspektion

- Softwaretest

4
Q

Softwareinspektion

A

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

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
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)
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

8
Q

Was beschreiben Testcases?

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

Fehlerklassen

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

Problem: Fehler aus Spezifikation bleiben unentdeckt

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)

11
Q

Black Box Test

A

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

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)

13
Q

Model based Testing

A
  • Testfälle werden mit Modellen beschrieben

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

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