2 SW-ELebenszyklus: Aufzählungen Flashcards
(97 cards)
1
Q
SW-Entwicklungslebenszyklusmodell
LZ
A
Phasen eines SW- Entwicklungsprojekts
Arten von Aktivitäten pro Phase
wie Phasen und deren Aktivitäten
- logisch &
- zeitlich zueinander in Beziehung stehen.
2
Q
SW-Entwicklungslebenszyklus-Modelle &
Testen
LZ
A
Testen findet im
Kontext der anderen Aktivitäten der SW-Entwicklung
Testen muss geeignet mit SWELZ-Modell
integriert werden
Jedes SWELZ-Modell
=> spezifische Testvorgehensweise
Tester sollte mit gängigen SWELZ-Modellen vertraut sein
=> angemessene Testaktivitäten
3
Q
SWELZ-Modelle:
Übergreifende Merkmale für
gutes Testen
LANG
A
- Jede Entwicklungsaktivität - zugehörige Testaktivität
- Jede Teststufe: stufenspezifische Testziele
- Für Teststufe beginnen Testanalyse & Entwurf bereits während Entwicklungsaktivität
- Tester nehmen an Diskussionen zur Definition & Verfeinerung von Anforderungen & Entwurf teil
- Tester sind am Review von genannten AE beteiligt, sobald erste Entwürfe davor vorliegen
- Testaktivitäten beginnen so früh wie möglich.
4
Q
SWELZ-Modelle:
Übergreifende Merkmale für
gutes Testen
KURZ
LZ
A
Entwicklungsaktivität - zugehörige Testaktivität
stufenspezifische Ziele/ Fokus
Testaktivitäten beginnen so früh wie möglich.
- Testanalyse & -entwurf beginnen bereits während Entwicklungsaktivität
- Tester teil Diskussionen Anforderungen & Entwurf
- Tester teil Review von genannten AE sobald erste Entwürfe
5
Q
Sequenzielles Entwicklungsmodell
A
SW-Entwicklung als
- linearer
- sequenzieller Ablauf von Aktivitäten
= Phase im Entwicklungsprozess erst beginnen nach Abschluss vorheriger/ keine Überlappung
Sequenzieller Entwicklungsmodelle
- liefern SW mit kompletten Feature-Set
- typischerweise Monate oder Jahre für Auslieferung
6
Q
Wasserfallmodell
LZ
A
sequenzielles Entwicklungsmodell
Testen
- einmalige Phase und damit nur System-/Abnahmetest
- nach Abschluss alle anderen Entwicklungsaktivitäten
7
Q
Phasen Wasserfallmodell
LZ
A
Analyse
Entwurf
Implementierung
Test
Betrieb
8
Q
V-Modell
LZ
A
Sequenzielles Entwicklungsmodell, das
Grundsatz des frühen Testens integriert.
=> Teststufen mit Bezug zu Entwicklungsphasen
= jede Entwicklungsaktivität
- korrespondierende Testaktivität, bzw. Teststufe
9
Q
V-Modell:
Testbasis
LZ
A
Dokumente der Entwicklungsaktivitäten oft
Grundlage für dazugehörige Teststufen
Anforderungsdefinition:
- Testbasis Abnahmetest
Funktionaler Systementwurf:
- Testbasis Systemtest
Technischer Systementwurf:
- Testbasis Integrationstest
Komponentenspezifikation:
- Testbasis Komponententest
10
Q
V-Modell:
Wichtigste Kennzeichen laut
Dojo
A
Entwicklungs- und Testaktivitäten getrennt, aber gleichwertig
“V” : Prüfaspekte Verifizierung & Validierung
Unterscheidung getrennter Teststufen
- jede Stufe testet gegen Artefakte jeweilige Entwicklungsphase
11
Q
Inkrementelles Entwicklungsmodell
LZ
A
SW-Features wachsen inkrementell an
<= Festlegung in Teilen von Anforderungen, Entwurf, Implementierung & Testen eines Systems
Jedes Iteration liefert lauffähige SW
= mit jeder Iteration wächst Teilmenge des gesamten Feature-Sets
Auslieferung lauffähige SW bereits nach Tagen oder Wochen, vollständige Menge Anforderungen/ Release-Set auch erst nach Monaten oder Jahren.
Inkremente
- Größe variiert
- Änderungen sowohl Änderungen an Leistungsmerkmalen früherer Iterationen als auch Änderungen am Projektumfang
12
Q
Inkrementelle Entwicklungsmodelle: Beispiele
A
- Rational Unified Process: Iteration relativ lang (2 - 3 Monate)
- Scrum: Iteration eher (Stunden bis Wochen)
- Kanban: Länge Iterationen nicht zwingend festgelegt
- Spiralmodell: experimentelle Inkremente
13
Q
Inkrementelle Entwicklungsmodelle & Testen
LZ
A
Teststufen überlappen sich häufig,
insbesondere Komponenten- und Systemtest
jedes Feature auf Weg zur Auslieferung auf mehreren Teststufen idealerweise getestet
schnelle Auslieferung Anreiz für Testautomatisierung
viele Inkremente => viele Regressionstests
Selbstorganisierende Team verändern
- Organisation von Tests &
- Beziehung zwischen Entwicklern & Testern
=> erfordern anderes Mindset der Tester
14
Q
Auswahl & ggf. Kombination
SWELZ-Modelle im
Kontext
LZ
A
SWELZ-Modelle müssen im Kontext von Projekt- und Produkteigenschaften - ausgewählt und - angepasst werden.
15
Q
Auswahl/ Anpassung SWELZ-Modell:
Faktoren
LZ
A
Projektziele
Art des Produkts
Geschäftsprioritäten wie Time-to-Market
Produkt- und Projektrisiken
16
Q
SWELZ-Modelle & Testen
LZ
A
Abhängig vom
Kontext des Projekts
- Teststufen und/ oder
- Testaktivitäten
- kombinieren
- neu organisieren
17
Q
Auswahl & ggf. Kombination
SWELZ-Modelle im
Kontext
A
Kontext von Projekt- und Produkteigenschaften:
- Unterschiedliche Produktrisiken von Systemen
- Viele Geschäftseinheiten können Teil eines Projekts oder Programms sein
=> Kombination aus sequenzieller & agiler Entwicklung - Zeit bis zur Markeinführung eines Produkts
=> Zusammenführen von Teststufen und/ oder Integration von Testarten in Teststufen - Voraussetzungen Kommunikation/ Zusammenarbeit innerhalb Team für iterative Entwicklung
18
Q
Kontext & Testen
A
Kontext Projekt
=> Teststufen/ Testaktivitäten auswählen & kombinieren
Bsp. Kommerzielle Standardsoftware zur Integration in größeres System Teststufe Systemintegration: - Interoperabilitätstest Teststufe Abnahmetest: - Benutzertest - betrieblicher Test
19
Q
Teststufen: Übersicht
LZ
A
Komponententest
Integrationstest
Systemtest
Abnahmetest
20
Q
Teststufen: Eigenschaften
LZ
A
- (Spezifische Ziele: Ziele für alle Teststufen gleich, Zielerreichung jeweils pro Fokus der Teststufe notwendig)
- Testbasis = AE, von denen Testfälle abgeleitet werden
- Testobjekt
- Typische Fehlerzustände & Fehlerwirkungen
- Spezifische Ansätze & Verantwortlichkeiten
- Anforderungen an Testumgebung
21
Q
Ziele Teststufen außer Abnahmetest
(Komponenten, Integrations- und Systemtest)
LANG
A
- Risikoreduktion
- Verifizierung, ob die funktionalen und nicht-funktionalen Verhaltensweisen des Fokus der Teststufe den Entwurf oder den Spezifikationen entsprechen
- Schaffen von Vertrauen in die Qualität des Testobjekts/ Fokus der Teststufe
- Finden von Fehlerzuständen
- Verhindern, dass Fehlerzustände an höhere Teststufen (System: auch Produktion)
22
Q
Ziele Teststufen außer Abnahmetest
(Komponenten, Integrations- und Systemtest)
KURZ
LZ
A
- Risikoreduktion
- Verifizieren (nicht-) funktionale Verhaltensweisen Fokus entsprechend Entwurf/ Spezifikationen
- Vertrauen Qualität des TO/ Fokus der Teststufe schaffen
- Finden von FZ
- Verhindern, dass FZ an höhere Teststufen
(System: auch Produktion)
23
Q
Komponenten- und Integrationstests:
Testziele
A
nur gemeinsame Testziele
- Komponenten-,
- Integration-,
- Systemtests
natürlich für TO
- jeweiliger Fokus Teststufe
24
Q
Verantwortlichkeiten nach Teststufe
LZ
A
Komponententest:
- Entwickler
Integrationstest
- Entwickler für Komponentenintegration
- Tester für Systemintegration
Systemtest
- Tester
Abnahmetest
- Kunden
- Fachanwender,
- Product Owner
- Betreiber eines Systems
- andere Stakeholder
25
Komponententest:
Bezeichnung Bausteine..
LZ
.. abhängig von der Programmiersprache
Module => Modultest
Units => Unittest
Klassen => Klassentest
26
Komponententest:
Testbasis
LZ
- Feinentwurf
- Code
- Datenmodelle
- Komponentenspezifikationen
27
Komponententest:
| Testobjekte
- Komponenten, Units oder Module
- Code und Datenstrukturen
- Klassen
- Datenbankmodule
28
Komponententest: Testumgebung
LZ
Ausführung Komponententests
<= speziellen Komponententestumgebung
= Unittest-Framework
= Testrahmen mit Treibern & Platzhaltern, der zusätzlichen Entwicklungsaufwand erfordert
Unterstützung Komponententests durch #
Entwicklungsumgebung
29
Komponententest:
Gängige FZ und FW
LZ
Funktionale Fehler:
- Berechnungsfehler...
nicht-funktionale Fehler:
- hoher Speicherverbrauch,
- schlechte Wartbarkeit,
- schlechte Performance
Strukturelle Probleme
- Datenflussprobleme
- Nicht korrekter Code und nicht korrekte Logik
30
Komponententest:
| Fehlerberichte
Komponententest häufig ohne formales Fehlermanagement
Fehlberichte durch Entwickler
= Information für
- Grundursachenanalyse &
- Prozessverbesserung
31
Komponententest-Werkzeuge:
- häufig direkt in Entwicklungsumgebung integriert
| - Anzeige: Überdeckung/ Code, der mit Unit test erreicht wurde, bzw. nicht
32
Komponententest in agiler Entwicklung
LZ
Schreiben von
automatisierten Komponententestfällen
VOR
Anwendungscode
Bsp. testgetriebene Entwicklung/ test driven development/ TDD
- Beispiel für Ansatz "test first"
- Ursprung eXtreme Programming
- verbreitet in andere Formen der agilen & sequenziellen SWELZ-Modelle
33
Integrationstests:
Ausprägungen
LZ
Ausprägungen in Funktion von
- Integrationsstufen
=> Testobjekte unterschiedlicher Größe
Komponentenintegrationstests
- Zusammenspiel SW-Komponenten
- Nach Komponententest
Systemintegrationstests
- Zusammenspiel verschiedener SW-System
- Zusammenspiel zwischen SW und HW
- Nach Systemtest beteiligte Systeme
34
Komponentenintegrationstests:
| Merkmale
Fokus:
Interaktionen/ Schnittstellen zwischen
integrierten KOMPONENTEN
Durchführung nach Komponententests
Generell automatisiert
Iterative/ inkrementelle Entwicklung:
- Teil von continuous integration/ kontinuierlichen Integrationprozesses
35
Systemintegrationstests:
| Merkmale
```
Fokus:
Interaktion/ Schnittstellen zwischen
- Systemen
- Paketen
- Microservices
- externe Organisationen
```
Systemintegrationstests
sowohl in in der sequenziellen als auch iterativen und inkrementellen Entwicklung:
- nach Systemtest
- parallel zu Systemtestaktivitäten
36
Integrationstests:
| Testbasis
SW- und Systementwurf
Definitionen/ Spezifikationen von
- Schnittstellen
- Kommunikationsprotokollen
Architektur auf Komponenten- oder Systemebene
Nutzungsabläufe und Workflows
Sequenzdiagramme
Anwendungsfälle
37
Integrationstests:
| Testobjekte
- Subsysteme
- Datenbanken
- Infrastruktur
- Schnittstellen
- APIs
- Microservices
38
```
Integrationstests:
Typische FZ und FW
Gemeinsam
(Komponentenintegration &
Systemintegration)
```
- Falsche Daten, fehlende Daten oder falsche Datenverschlüsselung
- Falsch angepasste Schnittstellen
- FW in Kommunikation zwischen Komponenten
- Nicht oder nicht ordnungsgemäß behandelte FW in der Kommunikation zwischen Komponenten
- Nicht korrekte Annahmen über Bedeutung, Einheiten oder Grenzen der Daten, die zwischen Komponenten hin- und hergereicht werden
39
Integrationstests:
Typische FZ und FW
nur
KOMPONENTEN-Integration
Falsche Reihenfolge oder Timing (zeitl. Abfolge) von Schnittstellenaufrufen
40
Systematische
Integrationsstrategien:
Basis
- Systemarchitektur (z.B. Top-down und Bottom-up)
- funktionelle Aufgaben
- Reihenfolge der Transaktionsverarbeitung
- andere Aspekte System/ Komponenten
41
Integrationstests:
Spezifische Ansätze
LZ
Fokus auf Integration/ Kommunikation zwischen Komponenten & Systemen
- NICHT Funktionalität einzelne Komponenten/ Systeme
42
Integrationsstrategien und -tests
Planung Integrationsstrategie & -tests VOR Entwicklung
=> Reihenfolge Entwicklung Komponenten/ Systeme erforderlich
für effizientes Testen
Integration inkrementell <=> "Big Bang"
=> Isolation von FZ vereinfachen
=> FZ früh zu erkennen
Kontinuierliche Integration/ continuous integration
- häufig automatisierte Regressionstests
- idealerweise auf mehreren Teststufen
Risikoanalyse der komplexesten Schnittstellen
=> Unterstützung Integrationstests
43
```
Integrationstests:
Geeignete Testarten (Spezifische Ansätze)
```
- Funktional
- Nicht-funktional
- Strukturelle Testarten
44
Integrationstests:
Typische FZ und FW
Exklusiv
SYSTEM-Integration
- Inkonsistente Nachrichtenstrukturen zwischen den Systemen
| - Mangelende Konformität mit Richtlinien zur IT-Sicherheit
45
Systemtest <==>
- Komponententest
- Integrationstest:
Unterschiede
LZ
Komponenten- und Integrationstests:
- prüfen eher gegen technischen Spezifikationen
Systemtest:
Perspektive späterer Anwender
46
Systemtest:
Spezifische Ansätze & Verantwortlichkeiten
LZ
Validieren, dass
- System vollständig und
- wie erwartet funktionieren wird
Finden von FZ im System als Ganzem/
End-to-end-Aufgaben überprüfen
Weitergabe verhindern in Produktion (anstatt höhere Teststufe)
47
Systemtest & Abnahmetest:
Unterschied
LZ
Verantwortlichkeiten
Systemtest:
unabhängiger Tester beim SW-Hersteller/
letzter Test in Verantwortung des Auftragnehmers vor Auslieferung an Auftraggeber
```
Abnahmetest:
Stakeholder je nach Ausprägung
- Kunden
- Fachanwender
- Product Owner
- Systemadministratoren
```
48
Systemtest:
Testbasis
LZ
```
- System- und SW-Anforderungsspezifikationen
(funktional und nicht-funktional)
- Risikoanalyseberichte
- Anwendungsfälle
- Epics & User-Stories
- Modelle des Systemverhaltens
- Zustandsdiagramme
- System- & Benutzeranleitungen
```
49
Systemtest: Testobjekte
LZ
Komplett zusammengebautes SW-System, System wird als Ganzes betrachtet
- Anwendungen
- Hardware/ Softwaresysteme
- Betriebssysteme
- Systeme unter Test (SUT)
- Systemkonfiguration & Konfigurationsdaten
50
Systemtest:
Typische FZ & FW
LZ
- falsche oder
- unerwartete
(nicht-)funktionale Systemverhaltensweisen
falsche Kontroll- und/ oder Datenflüsse innerhalb des Systems
funktionale End-to-End-Aufgaben nicht
- korrekt oder
- vollständig ausgeführt
ordnungsgemäße Arbeit in Systemumgebung nicht möglich
System funktioniert nicht wie in System- oder Benutzeranleitungen beschrieben
51
Systemtest:
| Optionale Ziele
Verifizierung der Datenqualität
Entscheidungen liefern für Freigabeentscheidungen durch Stakeholder
Erfüllung rechtlicher oder regulatorischer
- Anforderungen oder
- Standards
52
Systemtest:
| Spezifische Ansätze
Fokus auf allgemeines End-to-End-Verhalten des Systems als Ganzen
- (sowohl in funktionaler als auch nicht-funktionaler Hinsicht)
Testumgebung:
- idealerweise finale Ziel- oder Produktivumgebung
Auswahl Testverfahren, die am besten für zu testende Aspekte des Systems geeignet sind
Systemtests stützen sich stark auf Spezifikationen
- FZ in Spezifikationen
=> Verständnisprobleme oder Unstimmigkeiten über erwartetes Systemverhalten
=> falsch positive oder falsch negative Ergebnisse
<= Frühe Einbeziehen von Testern in
- User-Story-Verfeinerungen oder
- statische Testaktivitäten wie Reviews
53
Systemtest:
Spezifische Ansätze & Verantwortlichkeiten
LANG
Dojo
LZ
Fokus: allgemeines End-to-End-Verhalten System als Ganzen
(funktional & nicht-funktional)
in Verantwortung Auftragnehmer/ Hersteller
i.d.R. durch unabhängige Tester durchgeführt
Tester schon in Spezifikationsphase einbeziehen, um falsch positive/ negative Ergebnisse zu vermeiden
häufig: liefert Inf. an SH für Freigabeentscheidungen
evtl. notwendig für compliance (Erfüllung rechtlicher oder regulatorischer Anforderungen)
54
Systemtest:
Spezifische Ansätze & Verantwortlichkeiten
KURZ
Dojo
LZ
End-to-End-Verhalten System als Ganzes (nicht)-funktional
Auftragnehmer/ Hersteller
unabhängige Tester
Tester Spezifikationsphase
Informationen Freigabeentscheidungen
evtl. notwendig für compliance (Erfüllung rechtlicher oder regulatorischer Anforderungen)
55
Systemtest: Testumgebung
Dojo
LZ
sollte späterer Produktivumgebung möglichst nahe kommen
u.U. sehr viel Aufwand komplexe Testumgebungen
keine Testtreiber & Platzhalter, sondern die tatsächlich später zum Einsatz kommenden Komponenten
```
hohe Risiken beim
- Testen in Produktionsumgebung
< FW
- mit Echtdaten
<= IT-Sicherheit, Datenschutz
```
56
Abnahmetest:
Ziele
LZ
Vertrauen in Qualität des Systems als Ganzem aufbauen
Validieren, ob System aus Anwendersicht
- vollständig &
- Funktionieren wie erwartet
Verifizieren, ob (nicht-)funktionale Verhaltensweisen des Systems Spezifikationen entsprechen
57
Abnahmetests:
Ziele Vergleich mit Systemtest
LZ
```
Ziele/ Fokus wie Systemtest
OHNE
- Risikoreduktion
- Finden von FZ
- Verhindern, dass FZ in die Produktion weitergegeben werden
```
58
Abnahmetest:
Häufige Ausprägungen
LZ
Benutzerabnahmetest/
User Acceptance Testing UAT
Betrieblicher Abnahmetest
Operational Acceptance Testing OAT
Vertraglicher oder regulatorische Abnahmetest
Alpha- und Beta-Tests
59
Abnahmetests:
Testbasis alle Arten
LZ
1. Anwender- und Systemanforderungen
2. Anwendungsfälle, Geschäftsprozesse, Anwenderverfahren
3. Vorschriften, Gesetze, rechtliche Verträge & Standards
4. Prozessbeschreibungen der Systemnutzung
5. System- oder Benutzerdokumentation
6. Konfigurationsdaten/ Installationsverfahren
7. Risikoanalyseberichte
(8. Betriebs- und Wartungsprozesse)
60
Betriebliche Abnahmetest:
Testbasis im Detail
LZ
- Sicherungs- und Wiederherstellungsverfahren
- Disaster-Recovery-Verfahren
- Nicht-funktonale Anforderungen
- Betriebsdokumentation
- Bereitstellungs- und Installationsanweisungen
- Performanzziele
- Datenbankpakete
- Standards oder Vorschriften bzgl. IT-Sicherheit
61
Abnahmetests:
Typische Testobjekte
LZ
- System unter Test (SUT)
- Systemkonfigurationen & Konfigurationsdaten
- Geschäftsprozesse des vollintegrierten Systems
- Wiederherstellungssysteme und Hot Sites
- Betriebs- und Wartungsprozesse
- Formulare
- Berichte
- Bestehende und konvertierte Produktionsdaten
62
Abnahmetests:
Typische funktionale FZ und FW
LZ
- Systemworkflows erfüllen nicht Fach- oder Benutzeranforderungen
- Geschäftsregeln werden nicht korrekt umgesetzt
- System erfüllt nicht vertragliche oder regulatorische Anforderungen
63
Abnahmetests:
Typische
nicht-funktionale
FZ und FW
LZ
- IT-Sicherheitsschwachstellen
- nicht angemessene Performanz unter hoher Last
- nicht ordnungsgemäßer Betrieb auf einer unterstützten Plattform
64
Abnahmetest:
Spezifische Ansätze & Verantwortlichkeiten
LZ
Dojo
- Verantwortung Auftraggeber/ Kunde
- i.d.R letzte Teststufe (ggf. noch Systemintegrationstest)
- ggf. durch Anwender in täglicher Arbeit durchgeführt (Alpha- und Beta-Test)
- Umfang abhängig von Risiko/ Vertrauen Auftraggeber in Auftragnehmer
65
Abnahmetest: Testumgebung
LZ
Gleiche Rahmenbedingungen wie im Systemtest
Testumgebung = Abnahmetestumgebung beim Kunden
u.U. erst bei Abnahmetest repräsentative Umgebung, insbesondere bei Multisystemen
66
Alpha- und Beta-Test:
Unterschied
LZ
Ort/ Umgebung Durchführung Tests
Alpha-Tests
- Standort Hersteller (entwickelndes Unternehmen)
Beta-Tests
- eigener Standort (potenzielle) Kunden und/ oder Betreiber
67
Test-Arten: Überblick
LZ
- Funktionale Tests
- Nicht-funktionale Tests
- White-Box-Tests
- Änderungsbezogenes Testen
68
Test-Arten: Gemeinsamkeit
LZ
Alle Teststufen Durchführung möglich
<=> jedoch nicht für jede SW notwendig/ praktikabel
Grundsätzlich in jeder Teststufe angemessene Menge von Tests
- insbesondere auf unteren Teststufen
69
Nicht-funktionale Tests:
Zeitpunkt/ Teststufen
LZ
Im Gegensatz zu gängigen Fehleinschätzungen
- in allen Teststufen
- so früh wie möglich durchgeführt werden.
Spätes Entdecken nicht-funktionale FZ gefährlich für
Projekterfolg
70
Spezialfall Änderungsbezogener Test
LZ
- Fehlernachtests
- Regressionstests
```
können
- funktionale
- nicht-funktionale
- strukturelle Merkmale
prüfen
```
71
Test-Arten: Aspekte
- funktionale Tests
- nicht-funktionale Tests
- White-Box Tests
LZ
- Testverfahren
- Testbasis
(- Teststufen)
- Messung Gründlichkeit
- Erforderliche Fähigkeiten
72
Messung Gründlichkeit Vergleich (Test-Arten)
LZ
Überdeckung jeweils Anteil der durch Testen abgedeckten Elemente
funktionale Tests:
- funktionale Überdeckung
<= Rückverfolgbarkeit Tests - - - - funktionalen Anforderungen
nicht-funktionale Tests
- nicht-funktionale Überdeckung
<= Rückverfolgbarkeit Tests - - - - nicht-funktionalen Anforderungen
White-Box-Tests:
- strukturelle Überdeckung
- Codeü. , Ü Aufrufhierarchie Komponenten, Ü Menüstruktur...
73
Testverfahren Vergleich (Test-Arten)
LZ
Ableitung
- Testbedingungen
- Testfälle
durch. ...
Black-Box-Verfahren:
- funktionale Tests
- nicht-funktionale Tests
White-Box-Verfahren:
- White-Box-Tests
74
Funktionale Tests:
Testbasis für
Testbedingungen
"was" das System tun sollte
- fachliche Anforderungen
- Epics & User-Stories
- Anwendungsfälle
- funktionale Spezifikationen
- möglicherweise undokumentiert
75
Funktionale Tests &
erforderliche Fähigkeiten
LZ
Kenntnis des
bestimmten Fachproblems,
- das die SW löst
bestimmten Funktion,
- die die SW erfüllt
76
Nicht-funktionaler Test: Testbasis
1. Funktionalität
2. Performanz/ Effizienz
3. Kompatibilität
4. Gebrauchstauglichkeit/ Benutzbarkeit
5. Zuverlässigkeit
6. IT-Sicherheit
7. Wartbarkeit
8. Übertragbarkeit
77
Nicht-funktionale Tests:
Erforderliche Fähigkeiten
LZ
wie Kenntnis
- der zugrunde liegenden Schwächen eines Entwurfs oder einer Technologie (IT-Sicherheitsschwachstellen u.a.)
- bestimmte Benutzergruppe
78
White-Box-Tests: Testbasis
| ALLGEMEIN
Ableitung Tests auf Basis
- internen Struktur oder
- der Implementierung eines Tp
Struktur TO
- vollständig
- korrekt
- entsprechend Spezifikationen
79
White-Box-Tests: Testbasis
| KONKRET
Interne, strukturelle Merkmale TP
- Code
- Architektur
- Kontrollfluss
- Datenfluss
Bewertung Richtigkeit:
zusätzlich
- funktionale
- nicht-funktionale Anforderungen
80
White-Box-Tests: Teststufen
Ausprägungen
Komponententest:
Code
Komponentenintegrationstest:
Aufrufhierarchie der Komponenten
Systemtest:
Menüstruktur
81
White-Box-Tests:
Messung Gründlichkeit
Komponententests
LZ
Prozentsatz des
Komponentencodes, der
getestet wurde
% Prozentsatz
Codeüberdeckung: Zusammenfassung
- ausführbare Anweisungen
- Entscheidungsüberweisungen
82
White-Box-Tests:
Messung Gründlichkeit
Komponenten-
Integrationstests
LZ
% Prozentsatz
Schnittstellen, die durch die
Tests ausgeführt wurden
83
White-Box-Tests:
Spezialwissen
LZ
Kenntnisse über Art und Weise
wie der Code aufgebaut ist
Daten gespeichert werden
- (bspw. um mögliche Datenbankanfragen zu bewerten)
wie Überdeckungswerkzeuge korrekt genutzt und
- ihre Ergebnisse korrekt interpretiert werden
84
Änderungsbezogenes Testen:
| Unterkategorien
- Fehlernachtests
| - Regressionstests
85
Fehlernachtests (Änderungsbezogenes Testen):
| Zweck
Bestätigen, dass der
| ursprüngliche FZ erfolgreich behoben
86
Fehlernachtests (Änderungsbezogenes Testen):
| Ablauf & Scope
Wiederholen:
- mit neuer SW-Version
- alle Testfälle wiederholen, die aufgrund von FZ fehlgeschlagen
- mindestens Schritte, die durch FZ entstandene FW produziert haben
- Nachweis, dass FZ erfolgreich behoben, wenn FW nicht mehr auftritt
Ggf. auch neue Tests, für
Abdeckung Änderungen notwendig um
- FZ zu beheben
87
Regressionen:
Definition &
Scope
```
Eine Änderung
- Fehlerbehebung oder
- andere Art Änderung
in
- einem Teil des Codes oder
- in der Umgebung (bspw. neue Version BS oder DBMS)
```
beeinflusst ungewollt/ versehentlich
das Verhalten andere Teile des Codes:
- gleiche Komponente
- andere Komponenten des gleichen Systems
- andere Systeme
88
Regressionstest: was
Dojo
Erneutes Testen
- eines bereits getesteten TO
- nach Änderungen TO oder Umgebung
Prüfen, ob Änderungen
- unerwünschte Auswirkungen auf die
- nicht geänderten Teil
Nachweis, dass durch Änderungen
- keine neuen FZ eingebaut
- keine bisher maskierten FZ freigelegt wurden
89
Regressionstest: Aspekte
Dojo
Umfang
<= Risiko von neuen FZ in vorher funktionierenden SW
Iterative/ Inkrementelle SWELZ-Modelle wie agil
- häufige Änderungen
<= Änderung Features
<= Refactoring
=> sollten durch regelmäßige Regressionstests abgesichert werden
90
Regressionstests &
| Testautomatisierung
```
Regressionstests sind ein
starker Kandidat für
Testautomatisierung:
- Regressionstestsuiten laufen viele Male und
- ändern sich in der Regel nur langsam.
```
Automatisierung Regressionstests sollte
FRÜH im Projekt beginnen
91
Wartung SW und Systeme:
Ziele/ Zwecke
LZ
FZ in SW beheben, die in betrieblicher Nutzung aufgetreten sind
neue Funktionalitäten hinzufügen
bereits gelieferte Funktionalitäten
- ändern
- entfernen
nicht-funktionale Qualitätsmerkmale von K | S erhalten:
- Performanz
- Kompatibilität
- Zuverlässigkeit
- IT-Sicherheit
- Übertragbarkeit
92
Wartung:
Auslöser/ Anlässe
LZ
Auslöser:
- Modifikation
- Migration
- Außerbetriebnahme
93
Wartung:
| Scope Wartungstests
- auch Testen von Wiederherstellungsverfahren nach Archivierung bei langen Aufbewahrungsfristen
- Regressionstests
=> sicherstellen, dass jede Funktionalität, die in Betrieb bleibt, weiterhin funktioniert
94
Auswirkungsanalyse (Wartung):
| ALLGEMEIN
Entscheidung unterstützen, ob Änderung vorgenommen werden sollte
- auf Grundlage Folgen der potenziellen Folgen für andere Bereiche S.
Auswirkungen von Änderungen im Rahmen Wartungsrelease bewerten:
- gewünschte Folgen
- erwartete & mögliche Nebeneffekte
- Bereiche S, die von Änderung betroffen
- bestehende Tests, die von Änderung betroffen
- evtl. fehlende Tests identifizieren
95
Auswirkungsanalyse (Wartung):
| Einsatz im Wartungstest
Auswirkungsanalyse unterstützt
Bestimmung Umfang
REGRESSIONSTESTS
96
Wartungsrelease &
| Testumfang
Abhängig vom Umfang Wartung
=> Wartungstests
- in mehreren Teststufen
- verschiedene Testarten nutzen
Umfang Einflussfaktoren:
- Risikohöhe Änderung
- Größe des bestehenden Systems
- Größe der Änderung
Bsp. für Risikohöhe Änderung:
Grad, zu dem geänderter Bereich SW mit anderen Komponenten oder Systemen kommuniziert
97
Auswirkungsanalyse & Wartungstests:
| Erschwerende Faktoren
Häufig bei Legacy-Systemen
- Spezifikationen veraltet oder fehlen
- Testfälle nicht dokumentiert & veraltet
- Lücken Bidirektionale Verfolgbarkeit zwischen Tests & Testbasis
- Werkzeugunterstützung schwach oder nicht existent
- Beteiligte Personen keine Fach- oder Systemkenntnis
- Während Entwicklung Wartbarkeit der SW nicht ausreichend berücksichtigt
