Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

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
Q

Systemtest:

Spezifische Ziele

A

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
Q

Systemtest & Abnahmetest:

Unterschied

A

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
Q

Systemtest:

Testbasis

A 
- System- und SW-Anforderungsspezifikationen 
(funktional und nicht-funktional)
- Risikoanalyseberichte
- Anwendungsfälle
- Epics & User-Stories
- Modelle des Systemverhaltens
- Zustandsdiagramme
- System- & Benutzeranleitungen
28
Q

Systemtest: Testobjekte

A

Komplett zusammengebautes SW-System,
System wird als Ganzes betrachtet

  • Anwendungen
  • Hardware/ Softwaresysteme
  • Betriebssysteme
  • Systeme unter Test (SUT)
  • Systemkonfiguration & Konfigurationsdaten
29
Q

Systemtest:

Spezifische Ansätze

A

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
Q

Systemtest:

Optionale Ziele

A

Verifizierung der Datenqualität

Informationen liefern für
- Freigabeentscheidungen durch Stakeholder

Erfüllung rechtlicher oder regulatorischer

  • Anforderungen oder
  • Standards
31
Q

Abnahmetest:

Ziele

A

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
Q

Abnahmetests:

Ziele Vergleich mit Systemtest

A 
Ziele/ Fokus wie Systemtest
OHNE
- Risikoreduktion 
- Finden von FZ
- Verhindern, dass FZ in die Produktion weitergegeben werden
33
Q

Abnahmetest:

Häufige Ausprägungen

A

Benutzerabnahmetest
- User Acceptance Testing UAT

Betrieblicher Abnahmetest
- Operational Acceptance Testing OAT

Vertraglicher oder regulatorische Abnahmetest

Alpha- und Beta-Tests

34
Q

Abnahmetests:

Typische funktionale FZ und FW

A
  • Systemworkflows erfüllen nicht Fach- oder Benutzeranforderungen
  • Geschäftsregeln werden nicht korrekt umgesetzt
  • System erfüllt nicht vertragliche oder regulatorische Anforderungen
35
Q

Abnahmetests:
Typische
nicht-funktionale
FZ und FW

A

IT-Sicherheitsschwachstellen

nicht angemessene Performanz unter hoher Last

nicht ordnungsgemäßer Betrieb auf einer unterstützten Plattform

36
Q

Abnahmetest:
Spezifische Ansätze & Verantwortlichkeiten

Dojo

A

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
Q

Abnahmetest: Testumgebung

A

Gleiche Rahmenbedingungen wie im Systemtest

Testumgebung = Abnahmetestumgebung beim Kunden

u.U. erst bei Abnahmetest repräsentative Umgebung, insbesondere bei Multisystemen

38
Q

Alpha- und Beta-Test:

Unterschied

A

Ort/ Umgebung Durchführung Tests

Alpha-Tests
- Standort Hersteller (entwickelndes Unternehmen)

Beta-Tests
- eigener Standort (potenzielle) Kunden und/ oder Betreiber

39
Q

Test-Arten: Überblick

A

auf Basis Kategorie zu prüfende Merkmale:

  • Funktionale Tests
  • Nicht-funktionale Tests
  • White-Box-Tests (Struktur)
  • Änderungsbezogenes Testen (alle 3 Kategorien)
40
Q

Test-Arten: Gemeinsamkeit

A

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
Q

Nicht-funktionale Tests:

Zeitpunkt/ Teststufen

A

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
Q

Spezialfall Änderungsbezogener Test

A
  • Fehlernachtests
  • Regressionstests
können 
- funktionale
- nicht-funktionale
- strukturelle Merkmale 
prüfen
43
Q

Test-Arten: Aspekte

  • funktionale Tests
  • nicht-funktionale Tests
  • White-Box Tests
A
  • Testverfahren
  • Testbasis
  • Messung Gründlichkeit
  • Erforderliche Fähigkeiten
    (- Teststufen)
44
Q

Messung Gründlichkeit Vergleich (Test-Arten)

A

Ü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
Q

Test-Arten & Testverfahren

A

Ableitung

  • Testbedingungen
  • Testfälle
    durch. …

Black-Box-Verfahren:

  • funktionale Tests
  • nicht-funktionale Tests

White-Box-Verfahren:
- White-Box-Tests

46
Q

Funktionale Tests:
Testbasis für
Testbedingungen

A

“was” das System tun sollte

  • fachliche Anforderungen
  • Epics & User-Stories
  • Anwendungsfälle
  • funktionale Spezifikationen
  • möglicherweise undokumentiert
47
Q

Funktionale Tests &

erforderliche Fähigkeiten

A

Kenntnis des

bestimmten Fachproblems,
- das die SW löst

bestimmten Funktion,
- die die SW erfüllt

48
Q

Nicht-funktionaler Test: Testbasis

A
  1. Performanz/ Effizienz
  2. Kompatibilität
  3. Gebrauchstauglichkeit/ Benutzbarkeit
  4. Zuverlässigkeit
  5. IT-Sicherheit
  6. Wartbarkeit
  7. Übertragbarkeit
49
Q

Nicht-funktionale Tests:

Erforderliche Fähigkeiten

A

wie Kenntnis

  • der zugrunde liegenden Schwächen eines Entwurfs oder einer Technologie (IT-Sicherheitsschwachstellen u.a.)
  • bestimmte Benutzergruppe
50
Q

White-Box-Tests: Testbasis

ALLGEMEIN

A

Ableitung Tests auf Basis

  • interne Struktur oder
  • Implementierung eines TO

Struktur TO

  • vollständig
  • korrekt
  • entsprechend Spezifikationen
51
Q

White-Box-Tests: Testbasis

KONKRET

A

Interne, strukturelle Merkmale TO

  • Code- Architektur
  • Kontrollfluss
  • Datenfluss

Bewertung Richtigkeit:
zusätzlich
- funktionale
- nicht-funktionale Anforderungen

52
Q

White-Box-Tests:

Spezialwissen

A

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
Q

Änderungsbezogenes Testen:

Unterkategorien

A

Fehlernachtests

Regressionstests

54
Q

Fehlernachtests (Änderungsbezogenes Testen):

Zweck

A

Bestätigen, dass der

ursprüngliche FZ erfolgreich behoben

55
Q

Fehlernachtests (Änderungsbezogenes Testen):

Ablauf & Scope

A

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
Q

Regressionen:
Definition &
Scope

A 
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
Q

Regressionstest: Aspekte

Dojo

A

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
Q

Regressionstests &

Testautomatisierung

A 
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
Q

Wartung:

Auslöser/ Anlässe

A

Auslöser:

  • Modifikation
  • Migration
  • Außerbetriebnahme
60
Q

Wartung SW und Systeme:

Ziele/ Zwecke

A

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
Q

Wartung:

Scope Wartungstests

A
  • auch Testen von Wiederherstellungsverfahren nach Archivierung bei langen Aufbewahrungsfristen
  • Regressionstests
    => sicherstellen, dass jede Funktionalität, die in Betrieb bleibt, weiterhin funktioniert
62
Q

Auswirkungsanalyse (Wartung):

ALLGEMEIN

A

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.
© 2024 Bold Learning Solutions. Terms and Conditions