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.
Unit Testing
- Unit Tests sind automatisierte Tests einer kleinen Menge Quellcode
- Werden so oft wie möglich ausgeführt, um Seiteneffekte der
Entwicklungstätigkeiten frühzeitig erkennen und beheben zu können - Sollen möglichst effizient und effektiv sein
- Werden idealerweise bereits während der Entwicklung entworfen
- Entsprechen im Wesentlichen der Definition eines Testfalls (sollen in sich
abgeschlossen sein, Vor- und Nachbedingungen definieren und eine
spezifische Funktion abdecken).
Integration in mehreren Stufen
- Prüfung der Einzelsysteme (Eingangsprüfung)
- Integration der Einzelsysteme
- Prüfung des integrierten Systems (Verifikation)
- Identifikation von Fehlern (Defekten)
- Diagnose und Korrektur von Fehlern
- Nachprüfung
Modulintegration
Erste Aufgabe der Integration: Module zu Komponenten zusammenfassen
* Dreistufiges Vorgehen empfohlen:
1. Frühzeitig ausführbare Rahmen für die Integration schaffen, in die die
realisierten Module Schritt für Schritt eingehängt werden können
2. Jedes Modul wird von den zuständigen Entwicklern implementiert und
ausgetestet, bevor es an das Integrationsteam übergeben wird.
3. Ein Modul wird u.U. bei der Übergabe nochmals getestet (Eingangstest), dann in den Integrationsrahmen eingehängt und schließlich dort getestet.
Modultest
Modultest: Überprüfung, ob Modul seiner Spezifikation entspricht
* Folgt im Wesentlichen dem allgemeinen Testprozess:
1. Testfallauswahl und –entwurf
2. Testvorbereitung (Testumgebung schaffen)
3. Testdurchführung
4. Testauswertung
* Black-Box- und White-Box-Tests
Integrationstest
Überprüfung des reibungslosen Zusammenspiels der (zuvor) erfolgreich getesteten Einheiten.
- Integration und Integrationstest sollten schrittweise und einem frühzeitig festgeleten Integrationsplan folgend vorgenommen werden
- Teilintegration möglich (ggf. Nutzung von Mock/Dummy-Modulen)
- Integrationsprozess heute oft automatisiert
Abnahmetest
Überprüfung eines Softwaresystems bei der Auslieferung bzw. Übergabe an den Auftraggeber und die Nutzer.
- Überprüfung des integrierten Systems, um festzustellen, ob alle
spezifierten Anforderungen erfüllt sind. - Betrachtung des Systems als Ganzes
Nachweis der Korrektheit aus Benutzersicht
Bestätigung des Erreichens des Entwicklungsziels durch den Auftraggeber
Systemtests
Schwerpunkte des Systemtests:
- Test der Funktionen nach Anforderungen
- Test des Verhaltens unter Normalbenutzerbetrieb
- Test des Verhaltens in Ausnahmesituationen und im Dauerbetrieb
- Test der Leistungskenngrößen
+++
* Basis: Anforderungen aus dem Pflichtenheft
* Black-Box-Tests
* Testumgebung, die Produktiv-/Einsatzumgebung möglichst nahekommt
* Ggf. Simulation in Staging-Umgebung
* Systemtests für Produktanforderungen und Qualitätsanforderungen
Top-Down (Integrationstrategie)
PRO:
* Es werden nur wenige Treiber benötigt, die
in vielen Fällen auch einfacher gestaltet sind
* Testfälle können anhand der funktionalen
Anforderungen erstellt werden
* Fehler sind einfach zuzuordnen
* Die Systeme können zur nächsten
Integration ausgetestet und verbessert
werden
* Komponenten können Schritt für Schritt
fertig gestellt werden
CON:
* Dummies sind erforderlich
* Einige Schnittstellen werden nicht einzeln
getestet
Bottom-Up (integrationsstrategie)
PRO:
* Es werden keine Dummies
benötigt
* Testfälle können anhand der
funktionalen Anforderungen
erstellt werden
* Fehler sind einfach
zuzuordnen
CON:
* Für jedes Teilsystem werden Treiber benötigt, die fehlende Systemteile simulieren
Big-Bang (Integrationsstrategie)
PRO:
* Es werden keine Dummies
benötigt
* Es werden keine Treiber
benötigt
* Es wird unmittelbar das
System getestet
CON:
* Hohe Anzahl von Fehlern auf einen Schlag
* Fehler nur schlecht zuzuordnen
* System oft nicht lauffähig
* Alle Komponenten müssen fertig gestellt sein
Kontinuierliche Integration und Entwicklung (CI/CD)
- Grundidee: verschränkte Durchführung von Codierung, Test und
Integration, um kurze Entwicklungszyklen zu realisieren - Dazu ggf. Auslieferung (Delivery) und Verteilung (Deployment)
- Zielt auf frühzeitiges Finden von Fehlern und schnelle Rückkopplung
zwischen Entwicklern und Anwendern - Wichtig: Es dürfen nur erfolgreich getestete Systemteile integriert werden
Vorgehen CI/CD
- Commit changes to “Version control server”
- Changes get send to CI Server
- Ci Server builds and integrates and tests
- Verteilen von neuer Version oder bei Fehler benachrichtigung von diesem
Stufen der Kontinuierlichen Softwareentwicklung
- Commit changes
- Build
- Statische Analyse
- Pre-Development Testing
- Packaging
- Deployment für Akzeptanztest
- Akzeptanztest
- Deployment in die Produktion
- Post-Deployment Testing
Die drei DevOps-Prinzipien
- Prinzip des Flusses Entwickler -> Admin
- Prinzip des Feedsbacks Admin -> Entwickler
- Prinzip des Lernens und Experimentierens Entwickler <-> Admin
