Verifikation und Integration Flashcards
Validierung und Verifikation (V&V)
Unterscheidung nach Boehm (1979):
* Validierung: Erstellen wir das richtige Produkt?
(Erwartungen der Benutzer getroffen?)
* Verifikation: Erstellen wir das Produkt richtig?
(funktionale und nicht-funktionale Anforderungen erfüllt?)
Qualitätssicherung der Implementierung (Verifikation)
Überprüfung geforderter Eigenschaften
- Korrektheit
- Funktionale Anforderungen
- Qualitätsanforderungen
- Überwiegend Maßnahmen der analytischen Qualitätssicherung
- Typischerweise: Testen (statisch und dynamisch)
- Dynamisches Testen erfordert ablauffähige System(teil)e, aka Testobjekt, System under Test (SuT)
Definition: Testfälle und Test
Testfall (engl. Test Case): Elementarer, funktionaler Softwaretest zur Überprüfung einer in einer Spezifikation zugesicherten Eigenschaft eines Testobjektes. Besteht aus einer Menge von Eingaben und der Festlegung der geforderten Ausgaben.
Test (auch Test suite): Menge von Testfällen
Art von Testfällen
-
Positiv-Testfälle (Validierungstests)
Arbeiten mit gültigen Vorbedingungen und Eingaben -
Negativ-Testfälle (Fehlertests, Robustheitstests)
Arbeiten mit ungültigen Vorbedingungen und/oder Eingaben - Variation von Eingabewerten und Vorbedingungen erlaubt Überprüfung verschiedener Varianten eines Testfalls
Inbesondere Grenzwerte von Interesse
Definition: Anomalie (Testen)
Abweichung von Ausgaben oder Nachbedingungen während der
Testdurchführung von der Dokumentation oder dem erwarteten Betriebsverhalten.
Stellt einen zu behebenden Mangel oder Fehler in dem zu testenden System, dem Testfall oder der Testumgebung dar.
Einteilung Anomalie
-
Fehlerhandlung (Error, Mistake): ein Problem im
Code aufgrund falscher Programmierung oder
inkorrekter Anforderungen -
Fehlerzustand (Fault, Bug, Defect):
Systemverhalten nicht erwartungsgemäß -
Fehlerwirkung (Failure): Ausfall eines Systems,
System kann geforderte Funktion gemäß Spezifikation nicht mehr erbringen
Testobjekte, Testtreiber und Dummies
- Testumgebung für die Durchführung eines Tests
- Versorgt Testobjekt mit allen erforderlichen Betriebsmitteln
- Besteht aus Testobjekt, Testtreiber (Driver) und Dummies (Stubs, Mocks)
Testtreiber:
Ruft das Testobjekt auf, stellt Testdaten bereit, führt Testfall durch.
Testobjekt:
Relevante Systemeinheit für den Test (z.B. einzelnes Modul, Komponente,
vollständiges System)
Dummy:
Simuliert Systemverhalten für betrachtete Testfälle, enthält keine oder nur unvollständige ImplemenIerung.
Statische Testverfahren
- Statische Testverfahren
Formal -> weniger Formal:
Inspektion -> Team Review -> Walkthrough -> Pair Programming -> Ad-hoc Review
Statische Code-Analyse
- Formale Prüfungen zur Compile-Zeit (vor dynamischen Tests)
- Können besammte Fehlertypen idenafzieren, z.B.
- Fehlende IniUalisierung von Variablen
- Fehlende Rückgaben in allen Pfaden einer FunkUon
- Nicht-erreichbarer Code
- Fehlende oder falsche Typumwandlungen
- Unsichere FunkUonssignaturen
- Mangelnde Einhaltung von NamenskonvenUonen und von Codierungsrichtlinien
+++
* Teilweise von IDEs während der Programmierung durchgeführt
Funktionale Korrektheit
Systematisches Testen und Verifikation setzen immer einen Begriff
von funktionaler Korrektheit (entsprechende Spezifikation) voraus!
(Aus Anforderungsanalyse)
Verifikation durch Korrektheisbeweis und Model Checking
- Auch möglich: Korrektheit einer Komponente durch mathematischen Beweis zeigen
- Automatische theorembeweiser (theorem provers) können Korrekheitsbeweise führen/unterstützen
- Modellprüfer (engl. Model Checker) können zustandsendliche Systeme auf Einhaltung gewisser Eigenschaften (z.B. Sicherheitseigenschaften) prüfen
Allgemeiner Testprozess
Testplanung -> -design -> -spezifikation -> -durchführung -> -evaluation
Grundsätzliche Testformen
Black-Box-Test
* Testfälle werden aus der Außensicht (Anforderungs- und Schnittstellen-spezifikation)
erstellt
* Zielt auf Abdeckung typischer Nutzungsfälle, Randfälle, typischer Kombinationen oder
Belastungstests
White-Box-Test (auch Glass-Box-Test)
* Testfälle werden aus der Innensicht (Implementierung und Struktur des
Programmcodes) heraus bestimmt
* Zielt auf Abdeckung von möglichst allen Anweisungen, Bedingungen und Pfaden
Gray-Box-Test
* Fokussiert auf Integration/Zusammenspiel von Modulen
Aquivalenzklassenmethode
- Häufig eingesetzte Methode beim Black-Box-Testing
- Mögliche Eingaben werden in Äquivalenzklassen eingeteilt, und man
geht von der Vorstellung aus, dass sich ein Softwaresystem bei der
Eingabe eines Vertreters einer Äquivalenzklasse genauso verhält, wie
bei allen anderen Vertretern dieser Klasse.
Bei Funktionen mit mehreren Parametern (p1, p2, p3, …):
1. Für jeden Parameter pi Äquivalenzklassen wie zuvor beschrieben bilden
2. Für alle Parameter pi Kombinationen der Äquivalenzklassen bilden:
a) Einfache Kombination aller Äquivalenzklassen (sehr viele Testfälle)
b) Äquivalenzklassen erneut gruppieren in “erfolgreiche” und “fehlschlagende”
Kombinationen
c) Erfolgreiche Kombinationen können entsprechend reduziert werden
Entwurfsregelfür Tests: F.I.R.S.T.
Entwurfsregel für Tests (aus dem Kontext des Clean-Code-Prinzips):
* Fast: Tests sollen schnell auszuführen sein
* Independent: Tests sollen unabhängig voneinander sein
* Repeatable: Tests sollen in jeder Umgebung wiederholbar sein
* Self-Validating: Tests sollen einen Booleschen Wert als Ergebnis zurückliefern (erfolgreich/fehlgeschlagen).
* Timely: Tests sollen zeitnah zu dem Programmcode erstellt werden, auf den sie sich beziehen, oder gar schon bei der Erstellung der Anforderung.
