Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

Final Round ISTQB CTL > 2 SW-ELebenszyklus: Aufzählungen > Flashcards

2 SW-ELebenszyklus: Aufzählungen Flashcards

1
Q

SW-Entwicklungslebenszyklus-Modelle &
Testen

LZ

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Unabhängig von SWELZ-Modell:
Übergreifende Merkmale für
gutes Testen

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Wasserfallmodell

A

sequenzielles Entwicklungsmodell

Testen

  • einmalige Phase, also nur System-/Abnahmetest
  • nach Abschluss von allen anderen Entwicklungsaktivitäten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Phasen Wasserfallmodell

A

Analyse

Entwurf

Implementierung

Test

Betrieb

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

V-Modell

A

Sequenzielles Entwicklungsmodell, das
Grundsatz des frühen Testens integriert.

=> Teststufen mit Bezug zu Entwicklungsphasen
= jede Entwicklungsaktivität
- korrespondierende Testaktivität, bzw. Teststufe

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

V-Modell:

Stufen & Testbasis

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Inkrementelle Entwicklungsmodelle & Testen

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

SWELZ-Modelle & Testen

A

Abhängig vom
Kontext des Projekts

  • Teststufen, deren Varianten,
  • Testaktivitäten
  • kombinieren
  • neu organisieren
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Auswahl
SWELZ-Modelle im
Kontext

A

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Kombination

SWELZ-Modelle

A

Geschäftseinheiten
- Teil eines Projekts oder Programms
<=> unterschiedl. SWELZ

weitere Bsp. siehe Ausdruck Dojo-Folie

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Kontext & Testen

A

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Teststufen V-Modell: Übersicht

A

Komponententest

Integrationstest

Systemtest

Abnahmetest

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Verantwortlichkeiten nach Teststufe

A

Komponententest:
- Entwickler

Integrationstest

  • Entwickler für Komponentenintegration
  • Tester für Systemintegration

Systemtest
- Tester

Abnahmetest

  • Kunden
  • Fachanwender,
  • Product Owner
  • Betreiber eines Systems
  • andere Stakeholder
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Teststufen: Aspekte

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

gemeinsame Ziele Teststufen außer Abnahmetest

(Komponenten-,
Integrations- und
Systemtest

A
  1. Risikoreduktion
  2. Verifizieren (nicht-) funktionale Verhaltensweisen gegen
    Entwurf/ Spezifikationen
  3. Vertrauen Qualität des TO schaffen
  4. Finden von FZ
  5. Verhindern, dass FZ an höhere Teststufen weitergegeben
    (System: auch Produktion)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Komponenten- und Integrationstests:

Testziele

A

nur gemeinsame Testziele

  • Komponenten-,
  • Integration-,
  • Systemtests

natürlich für TO
- jeweiliger Fokus Teststufe

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Komponententest in agiler Entwicklung

A

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Integrationstests:

Ausprägungen

A

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Komponentenintegrationstests:

Merkmale

A

Fokus:
Interaktionen/ Schnittstellen zwischen
integrierten KOMPONENTEN

Durchführung nach Komponententests

Generell automatisiert

Iterative/ inkrementelle Entwicklung:
- Teil von continuous integration/ kontinuierlichen Integrationprozesses

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Systemintegrationstests:

Merkmale

A 
Fokus:
Interaktion/ Schnittstellen zwischen
- Systemen
- Paketen
- Microservices 
- externe Organisationen

Systemintegrationstests
in sequenzieller UND iterativer/ inkrementeller Entwicklung:
- nach Systemtest
- parallel zu Systemtestaktivitäten

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Integrationstests:

Spezifische Ansätze

A

Fokus auf Integration/ Kommunikation zwischen Komponenten & Systemen
- NICHT Funktionalität einzelne Komponenten/ Systeme

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Integrationsstrategien und -tests

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Systemtest <==>

  • Komponententest
  • Integrationstest:

Unterschiede

A

Komponenten- und Integrationstests:
- prüfen eher gegen technischen Spezifikationen

Systemtest:
Perspektive späterer Anwender

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
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)
26
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 ```
27
Systemtest: | Testbasis
``` - System- und SW-Anforderungsspezifikationen (funktional und nicht-funktional) - Risikoanalyseberichte - Anwendungsfälle - Epics & User-Stories - Modelle des Systemverhaltens - Zustandsdiagramme - System- & Benutzeranleitungen ```
28
Systemtest: Testobjekte
Komplett zusammengebautes SW-System, System wird als Ganzes betrachtet - Anwendungen - Hardware/ Softwaresysteme - Betriebssysteme - Systeme unter Test (SUT) - Systemkonfiguration & Konfigurationsdaten
29
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
30
Systemtest: | Optionale Ziele
Verifizierung der Datenqualität Informationen liefern für - Freigabeentscheidungen durch Stakeholder Erfüllung rechtlicher oder regulatorischer - Anforderungen oder - Standards
31
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
32
Abnahmetests: | Ziele Vergleich mit Systemtest
``` Ziele/ Fokus wie Systemtest OHNE - Risikoreduktion - Finden von FZ - Verhindern, dass FZ in die Produktion weitergegeben werden ```
33
Abnahmetest: | Häufige Ausprägungen
Benutzerabnahmetest - User Acceptance Testing UAT Betrieblicher Abnahmetest - Operational Acceptance Testing OAT Vertraglicher oder regulatorische Abnahmetest Alpha- und Beta-Tests
34
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
35
Abnahmetests: Typische nicht-funktionale FZ und FW
IT-Sicherheitsschwachstellen nicht angemessene Performanz unter hoher Last nicht ordnungsgemäßer Betrieb auf einer unterstützten Plattform
36
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
37
Abnahmetest: Testumgebung
Gleiche Rahmenbedingungen wie im Systemtest Testumgebung = Abnahmetestumgebung beim Kunden u.U. erst bei Abnahmetest repräsentative Umgebung, insbesondere bei Multisystemen
38
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
39
Test-Arten: Überblick
auf Basis Kategorie zu prüfende Merkmale: - Funktionale Tests - Nicht-funktionale Tests - White-Box-Tests (Struktur) - Änderungsbezogenes Testen (alle 3 Kategorien)
40
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
41
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
42
Spezialfall Änderungsbezogener Test
- Fehlernachtests - Regressionstests ``` können - funktionale - nicht-funktionale - strukturelle Merkmale prüfen ```
43
Test-Arten: Aspekte - funktionale Tests - nicht-funktionale Tests - White-Box Tests
- Testverfahren - Testbasis - Messung Gründlichkeit - Erforderliche Fähigkeiten (- Teststufen)
44
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
45
Test-Arten & Testverfahren
Ableitung - Testbedingungen - Testfälle durch. ... Black-Box-Verfahren: - funktionale Tests - nicht-funktionale Tests White-Box-Verfahren: - White-Box-Tests
46
Funktionale Tests: Testbasis für Testbedingungen
"was" das System tun sollte - fachliche Anforderungen - Epics & User-Stories - Anwendungsfälle - funktionale Spezifikationen - möglicherweise undokumentiert
47
Funktionale Tests & | erforderliche Fähigkeiten
Kenntnis des bestimmten Fachproblems, - das die SW löst bestimmten Funktion, - die die SW erfüllt
48
Nicht-funktionaler Test: Testbasis
2. Performanz/ Effizienz 3. Kompatibilität 4. Gebrauchstauglichkeit/ Benutzbarkeit 5. Zuverlässigkeit 6. IT-Sicherheit 7. Wartbarkeit 8. Übertragbarkeit
49
Nicht-funktionale Tests: | Erforderliche Fähigkeiten
wie Kenntnis - der zugrunde liegenden Schwächen eines Entwurfs oder einer Technologie (IT-Sicherheitsschwachstellen u.a.) - bestimmte Benutzergruppe
50
White-Box-Tests: Testbasis | ALLGEMEIN
Ableitung Tests auf Basis - interne Struktur oder - Implementierung eines TO Struktur TO - vollständig - korrekt - entsprechend Spezifikationen
51
White-Box-Tests: Testbasis | KONKRET
Interne, strukturelle Merkmale TO - Code- Architektur - Kontrollfluss - Datenfluss Bewertung Richtigkeit: zusätzlich - funktionale - nicht-funktionale Anforderungen
52
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
53
Änderungsbezogenes Testen: | Unterkategorien
Fehlernachtests Regressionstests
54
Fehlernachtests (Änderungsbezogenes Testen): | Zweck
Bestätigen, dass der | ursprüngliche FZ erfolgreich behoben
55
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
56
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
57
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
58
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
59
Wartung: | Auslöser/ Anlässe
Auslöser: - Modifikation - Migration - Außerbetriebnahme
60
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
61
Wartung: | Scope Wartungstests
- auch Testen von Wiederherstellungsverfahren nach Archivierung bei langen Aufbewahrungsfristen - Regressionstests => sicherstellen, dass jede Funktionalität, die in Betrieb bleibt, weiterhin funktioniert
62
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

Final Round ISTQB CTL (12 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions