2 SW-ELebenszyklus: Aufzählungen Flashcards
SW-Entwicklungslebenszyklus-Modelle &
Testen
LZ
Testen findet statt im Kontext
andere Aktivitäten SW-Entwicklung
Unterschiedl. SWELZ-Modelle
=> unterschiedl. Testvorgehensweisen
Für erfolgreiche Integration Test in SW-Entwicklungsprozess
=> Auswahl angemessene Testaktivitäten & Timing
<= Tester sollte mit gängigen SWELZ-Modellen vertraut sein
=> angemessene Testaktivitäten
Unabhängig von SWELZ-Modell:
Übergreifende Merkmale für
gutes Testen
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
Wasserfallmodell
sequenzielles Entwicklungsmodell
Testen
- einmalige Phase, also nur System-/Abnahmetest
- nach Abschluss von allen anderen Entwicklungsaktivitäten
Phasen Wasserfallmodell
Analyse
Entwurf
Implementierung
Test
Betrieb
V-Modell
Sequenzielles Entwicklungsmodell, das
Grundsatz des frühen Testens integriert.
=> Teststufen mit Bezug zu Entwicklungsphasen
= jede Entwicklungsaktivität
- korrespondierende Testaktivität, bzw. Teststufe
V-Modell:
Stufen & Testbasis
Dokumente einer Entwicklungsaktivität oft
TESTBASIS für dazugehörige Teststufen
Anforderungsdefinition:
- Testbasis Abnahmetest
Funktionaler Systementwurf:
- Testbasis Systemtest
Technischer Systementwurf:
- Testbasis Integrationstest
Komponentenspezifikation:
- Testbasis Komponententest
V-Modell:
Wichtigste Kennzeichen laut
Dojo
Entwicklungs- und Testaktivitäten getrennt, aber gleichwertig
“V” : Prüfaspekte Verifizierung & Validierung
Unterscheidung getrennter Teststufen
- jede Stufe testet gegen Artefakte jeweilige Entwicklungsphase
Inkrementelle Entwicklungsmodelle & Testen
Teststufen überlappen sich häufig,
- insb. Komponenten- und Systemtest
jedes Feature auf Weg zur Auslieferung
- idealerweise auf mehreren Teststufen 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
SWELZ-Modelle & Testen
Abhängig vom
Kontext des Projekts
- Teststufen, deren Varianten,
- Testaktivitäten
- kombinieren
- neu organisieren
Auswahl
SWELZ-Modelle im
Kontext
Kontext = Projekt- und Produkteigenschaften:
- Projektziele
- Art des Produkts
- Geschäftsprioritäten wie Time-to-Market
- Produkt- & Projektrisiken
- Voraussetzungen Kommunikation/ Zusammenarbeit innerhalb Team für iterative Entwicklung
Kombination
SWELZ-Modelle
Geschäftseinheiten
- Teil eines Projekts oder Programms
<=> unterschiedl. SWELZ
weitere Bsp. siehe Ausdruck Dojo-Folie
Kontext & Testen
kurze Zeit bis zur Markeinführung eines Produkts
=> Zusammenführen von Teststufen
Integration von Testarten in Teststufen
Kontext Projekt/ Produkteigenschaften
=> Teststufen und deren Varianten auswählen & kombinieren
Bsp. Kommerzielle Standardsoftware zur Integration in größeres System Teststufe Systemintegration: - Interoperabilitätstest Teststufe Abnahmetest: - Benutzertest - betrieblicher Test
Teststufen V-Modell: Übersicht
Komponententest
Integrationstest
Systemtest
Abnahmetest
Verantwortlichkeiten nach Teststufe
Komponententest:
- Entwickler
Integrationstest
- Entwickler für Komponentenintegration
- Tester für Systemintegration
Systemtest
- Tester
Abnahmetest
- Kunden
- Fachanwender,
- Product Owner
- Betreiber eines Systems
- andere Stakeholder
Teststufen: Aspekte
- Ziele: Überschneidungen, wichtig Zielerreichung jeweils pro Fokus der Teststufe
- Testbasis = AE, von denen Testfälle abgeleitet werden
- Testobjekt
- Typische Fehlerzustände & Fehlerwirkungen
- Spezifische Ansätze/ Testvorgehensweise & Verantwortlichkeiten
gemeinsame Ziele Teststufen außer Abnahmetest
(Komponenten-,
Integrations- und
Systemtest
- Risikoreduktion
- Verifizieren (nicht-) funktionale Verhaltensweisen gegen
Entwurf/ Spezifikationen - Vertrauen Qualität des TO schaffen
- Finden von FZ
- Verhindern, dass FZ an höhere Teststufen weitergegeben
(System: auch Produktion)
Komponenten- und Integrationstests:
Testziele
nur gemeinsame Testziele
- Komponenten-,
- Integration-,
- Systemtests
natürlich für TO
- jeweiliger Fokus Teststufe
Komponententest in agiler Entwicklung
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
Integrationstests:
Ausprägungen
in Funktion von
- Integrationsstufen
=> Testobjekte unterschiedlicher Größe
Komponentenintegrationstests
- Zusammenspiel SW-Komponenten
- Nach Test einzelne beteiligte Komponenten
Systemintegrationstests
- Zusammenspiel verschiedener SW-Systeme
- Zusammenspiel zwischen SW und HW
- Nach Systemtest einzelne beteiligte Systeme
Komponentenintegrationstests:
Merkmale
Fokus:
Interaktionen/ Schnittstellen zwischen
integrierten KOMPONENTEN
Durchführung nach Komponententests
Generell automatisiert
Iterative/ inkrementelle Entwicklung:
- Teil von continuous integration/ kontinuierlichen Integrationprozesses
Systemintegrationstests:
Merkmale
Fokus: Interaktion/ Schnittstellen zwischen - Systemen - Paketen - Microservices - externe Organisationen
Systemintegrationstests
in sequenzieller UND iterativer/ inkrementeller Entwicklung:
- nach Systemtest
- parallel zu Systemtestaktivitäten
Integrationstests:
Spezifische Ansätze
Fokus auf Integration/ Kommunikation zwischen Komponenten & Systemen
- NICHT Funktionalität einzelne Komponenten/ Systeme
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
Systemtest <==>
- Komponententest
- Integrationstest:
Unterschiede
Komponenten- und Integrationstests:
- prüfen eher gegen technischen Spezifikationen
Systemtest:
Perspektive späterer Anwender
Systemtest:
Spezifische Ziele
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)
Systemtest & Abnahmetest:
Unterschied
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
Systemtest:
Testbasis
- System- und SW-Anforderungsspezifikationen (funktional und nicht-funktional) - Risikoanalyseberichte - Anwendungsfälle - Epics & User-Stories - Modelle des Systemverhaltens - Zustandsdiagramme - System- & Benutzeranleitungen
Systemtest: Testobjekte
Komplett zusammengebautes SW-System,
System wird als Ganzes betrachtet
- Anwendungen
- Hardware/ Softwaresysteme
- Betriebssysteme
- Systeme unter Test (SUT)
- Systemkonfiguration & Konfigurationsdaten
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
Systemtests stützen sich stark auf Spezifikationen
- FZ in Spezifikationen
=> erwartetes Systemverhalten nicht eindeutig
=> falsch positive oder falsch negative Ergebnisse
<= Frühe Einbeziehen von Testern in
- User-Story-Verfeinerungen oder
- statische Testaktivitäten wie Reviews
Systemtest:
Optionale Ziele
Verifizierung der Datenqualität
Informationen liefern für
- Freigabeentscheidungen durch Stakeholder
Erfüllung rechtlicher oder regulatorischer
- Anforderungen oder
- Standards
Abnahmetest:
Ziele
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
Abnahmetests:
Ziele Vergleich mit Systemtest
Ziele/ Fokus wie Systemtest OHNE - Risikoreduktion - Finden von FZ - Verhindern, dass FZ in die Produktion weitergegeben werden
Abnahmetest:
Häufige Ausprägungen
Benutzerabnahmetest
- User Acceptance Testing UAT
Betrieblicher Abnahmetest
- Operational Acceptance Testing OAT
Vertraglicher oder regulatorische Abnahmetest
Alpha- und Beta-Tests
Abnahmetests:
Typische funktionale FZ und FW
- Systemworkflows erfüllen nicht Fach- oder Benutzeranforderungen
- Geschäftsregeln werden nicht korrekt umgesetzt
- System erfüllt nicht vertragliche oder regulatorische Anforderungen
Abnahmetests:
Typische
nicht-funktionale
FZ und FW
IT-Sicherheitsschwachstellen
nicht angemessene Performanz unter hoher Last
nicht ordnungsgemäßer Betrieb auf einer unterstützten Plattform
Abnahmetest:
Spezifische Ansätze & Verantwortlichkeiten
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
Abnahmetest: Testumgebung
Gleiche Rahmenbedingungen wie im Systemtest
Testumgebung = Abnahmetestumgebung beim Kunden
u.U. erst bei Abnahmetest repräsentative Umgebung, insbesondere bei Multisystemen
Alpha- und Beta-Test:
Unterschied
Ort/ Umgebung Durchführung Tests
Alpha-Tests
- Standort Hersteller (entwickelndes Unternehmen)
Beta-Tests
- eigener Standort (potenzielle) Kunden und/ oder Betreiber
Test-Arten: Überblick
auf Basis Kategorie zu prüfende Merkmale:
- Funktionale Tests
- Nicht-funktionale Tests
- White-Box-Tests (Struktur)
- Änderungsbezogenes Testen (alle 3 Kategorien)
Test-Arten: Gemeinsamkeit
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
Nicht-funktionale Tests:
Zeitpunkt/ Teststufen
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
Spezialfall Änderungsbezogener Test
- Fehlernachtests
- Regressionstests
können - funktionale - nicht-funktionale - strukturelle Merkmale prüfen
Test-Arten: Aspekte
- funktionale Tests
- nicht-funktionale Tests
- White-Box Tests
- Testverfahren
- Testbasis
- Messung Gründlichkeit
- Erforderliche Fähigkeiten
(- Teststufen)
Messung Gründlichkeit Vergleich (Test-Arten)
Überdeckung jeweils Anteil der durch Testen abgedeckten Elemente
- funktionale Überdeckung
<= Rückverfolgbarkeit Tests - - - - funktionalen Anforderungen - nicht-funktionale Überdeckung
<= Rückverfolgbarkeit Tests - - - - nicht-funktionale Anforderungen
White-Box-Tests:
- strukturelle Überdeckung auf jeweilige Entwicklungs-/Test-stufe
Test-Arten & Testverfahren
Ableitung
- Testbedingungen
- Testfälle
durch. …
Black-Box-Verfahren:
- funktionale Tests
- nicht-funktionale Tests
White-Box-Verfahren:
- White-Box-Tests
Funktionale Tests:
Testbasis für
Testbedingungen
“was” das System tun sollte
- fachliche Anforderungen
- Epics & User-Stories
- Anwendungsfälle
- funktionale Spezifikationen
- möglicherweise undokumentiert
Funktionale Tests &
erforderliche Fähigkeiten
Kenntnis des
bestimmten Fachproblems,
- das die SW löst
bestimmten Funktion,
- die die SW erfüllt
Nicht-funktionaler Test: Testbasis
- Performanz/ Effizienz
- Kompatibilität
- Gebrauchstauglichkeit/ Benutzbarkeit
- Zuverlässigkeit
- IT-Sicherheit
- Wartbarkeit
- Übertragbarkeit
Nicht-funktionale Tests:
Erforderliche Fähigkeiten
wie Kenntnis
- der zugrunde liegenden Schwächen eines Entwurfs oder einer Technologie (IT-Sicherheitsschwachstellen u.a.)
- bestimmte Benutzergruppe
White-Box-Tests: Testbasis
ALLGEMEIN
Ableitung Tests auf Basis
- interne Struktur oder
- Implementierung eines TO
Struktur TO
- vollständig
- korrekt
- entsprechend Spezifikationen
White-Box-Tests: Testbasis
KONKRET
Interne, strukturelle Merkmale TO
- Code- Architektur
- Kontrollfluss
- Datenfluss
Bewertung Richtigkeit:
zusätzlich
- funktionale
- nicht-funktionale Anforderungen
White-Box-Tests:
Spezialwissen
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
Änderungsbezogenes Testen:
Unterkategorien
Fehlernachtests
Regressionstests
Fehlernachtests (Änderungsbezogenes Testen):
Zweck
Bestätigen, dass der
ursprüngliche FZ erfolgreich behoben
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
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
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
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
Wartung:
Auslöser/ Anlässe
Auslöser:
- Modifikation
- Migration
- Außerbetriebnahme
Wartung SW und Systeme:
Ziele/ Zwecke
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
Wartung:
Scope Wartungstests
- auch Testen von Wiederherstellungsverfahren nach Archivierung bei langen Aufbewahrungsfristen
- Regressionstests
=> sicherstellen, dass jede Funktionalität, die in Betrieb bleibt, weiterhin funktioniert
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
