Brainscape's Knowledge GenomeTM

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


See full index

Study ISTQB CTFL > 2 SW-ELebenszyklus: Aufzählungen > Flashcards

2 SW-ELebenszyklus: Aufzählungen Flashcards

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

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

Wasserfallmodell

LZ

A

sequenzielles Entwicklungsmodell

Testen

  • einmalige Phase und damit nur System-/Abnahmetest
  • nach Abschluss alle anderen Entwicklungsaktivitäten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Phasen Wasserfallmodell

LZ

A

Analyse

Entwurf

Implementierung

Test

Betrieb

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

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

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

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

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

Auswahl/ Anpassung SWELZ-Modell:
Faktoren

LZ

A

Projektziele

Art des Produkts

Geschäftsprioritäten wie Time-to-Market

Produkt- und Projektrisiken

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

SWELZ-Modelle & Testen

LZ

A

Abhängig vom
Kontext des Projekts

  • Teststufen und/ oder
  • Testaktivitäten
  • kombinieren
  • neu organisieren
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Teststufen: Übersicht

LZ

A

Komponententest

Integrationstest

Systemtest

Abnahmetest

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

Komponententest:
Bezeichnung Bausteine..

LZ

A

.. abhängig von der Programmiersprache

Module => Modultest

Units => Unittest

Klassen => Klassentest

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

Komponententest:
Testbasis

LZ

A
  • Feinentwurf
  • Code
  • Datenmodelle
  • Komponentenspezifikationen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Komponententest:

Testobjekte

A
  • Komponenten, Units oder Module
  • Code und Datenstrukturen
  • Klassen
  • Datenbankmodule
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Komponententest: Testumgebung

LZ

A

Ausführung Komponententests
<= speziellen Komponententestumgebung
= Unittest-Framework
= Testrahmen mit Treibern & Platzhaltern, der zusätzlichen Entwicklungsaufwand erfordert

Unterstützung Komponententests durch #
Entwicklungsumgebung

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

Komponententest:
Gängige FZ und FW

LZ

A

Funktionale Fehler:
- Berechnungsfehler…

nicht-funktionale Fehler:

  • hoher Speicherverbrauch,
  • schlechte Wartbarkeit,
  • schlechte Performance

Strukturelle Probleme

  • Datenflussprobleme
  • Nicht korrekter Code und nicht korrekte Logik
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Komponententest:

Fehlerberichte

A

Komponententest häufig ohne formales Fehlermanagement

Fehlberichte durch Entwickler
= Information für
- Grundursachenanalyse &
- Prozessverbesserung

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

Komponententest-Werkzeuge:

A
  • häufig direkt in Entwicklungsumgebung integriert

- Anzeige: Überdeckung/ Code, der mit Unit test erreicht wurde, bzw. nicht

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

Komponententest in agiler Entwicklung

LZ

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

Integrationstests:
Ausprägungen

LZ

A

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

Systemintegrationstests:

Merkmale

A 
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

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

Integrationstests:

Testbasis

A

SW- und Systementwurf

Definitionen/ Spezifikationen von

  • Schnittstellen
  • Kommunikationsprotokollen

Architektur auf Komponenten- oder Systemebene

Nutzungsabläufe und Workflows

Sequenzdiagramme

Anwendungsfälle

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

Integrationstests:

Testobjekte

A
  • Subsysteme
  • Datenbanken
  • Infrastruktur
  • Schnittstellen
  • APIs
  • Microservices
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q 
Integrationstests:
Typische FZ und FW
Gemeinsam 
(Komponentenintegration &
Systemintegration)
A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Integrationstests:
Typische FZ und FW
nur
KOMPONENTEN-Integration

A

Falsche Reihenfolge oder Timing (zeitl. Abfolge) von Schnittstellenaufrufen

40
Q

Systematische
Integrationsstrategien:
Basis

A
  • Systemarchitektur (z.B. Top-down und Bottom-up)
  • funktionelle Aufgaben
  • Reihenfolge der Transaktionsverarbeitung
  • andere Aspekte System/ Komponenten
41
Q

Integrationstests:
Spezifische Ansätze

LZ

A

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

42
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

43
Q 
Integrationstests:
Geeignete Testarten (Spezifische Ansätze)
A
  • Funktional
  • Nicht-funktional
  • Strukturelle Testarten
44
Q

Integrationstests:
Typische FZ und FW
Exklusiv
SYSTEM-Integration

A
  • Inkonsistente Nachrichtenstrukturen zwischen den Systemen

- Mangelende Konformität mit Richtlinien zur IT-Sicherheit

45
Q

Systemtest <==>

  • Komponententest
  • Integrationstest:

Unterschiede

LZ

A

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

Systemtest:
Perspektive späterer Anwender

46
Q

Systemtest:
Spezifische Ansätze & Verantwortlichkeiten

LZ

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)

47
Q

Systemtest & Abnahmetest:
Unterschied

LZ

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

Systemtest:
Testbasis

LZ

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

Systemtest: Testobjekte

LZ

A

Komplett zusammengebautes SW-System, System wird als Ganzes betrachtet

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

Systemtest:
Typische FZ & FW

LZ

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

Systemtest:

Optionale Ziele

A

Verifizierung der Datenqualität

Entscheidungen liefern für Freigabeentscheidungen durch Stakeholder

Erfüllung rechtlicher oder regulatorischer

  • Anforderungen oder
  • Standards
52
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

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
Q

Systemtest:
Spezifische Ansätze & Verantwortlichkeiten
LANG

Dojo
LZ

A

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
Q

Systemtest:
Spezifische Ansätze & Verantwortlichkeiten
KURZ

Dojo
LZ

A

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
Q

Systemtest: Testumgebung

Dojo

LZ

A

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
Q

Abnahmetest:
Ziele

LZ

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

57
Q

Abnahmetests:
Ziele Vergleich mit Systemtest

LZ

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

Abnahmetest:
Häufige Ausprägungen

LZ

A

Benutzerabnahmetest/
User Acceptance Testing UAT

Betrieblicher Abnahmetest
Operational Acceptance Testing OAT

Vertraglicher oder regulatorische Abnahmetest

Alpha- und Beta-Tests

59
Q

Abnahmetests:
Testbasis alle Arten

LZ

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

Betriebliche Abnahmetest:
Testbasis im Detail

LZ

A
  • Sicherungs- und Wiederherstellungsverfahren
  • Disaster-Recovery-Verfahren
  • Nicht-funktonale Anforderungen
  • Betriebsdokumentation
  • Bereitstellungs- und Installationsanweisungen
  • Performanzziele
  • Datenbankpakete
  • Standards oder Vorschriften bzgl. IT-Sicherheit
61
Q

Abnahmetests:
Typische Testobjekte

LZ

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

Abnahmetests:
Typische funktionale FZ und FW

LZ

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

Abnahmetests:
Typische
nicht-funktionale
FZ und FW

LZ

A
  • IT-Sicherheitsschwachstellen
  • nicht angemessene Performanz unter hoher Last
  • nicht ordnungsgemäßer Betrieb auf einer unterstützten Plattform
64
Q

Abnahmetest:
Spezifische Ansätze & Verantwortlichkeiten

LZ

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

Abnahmetest: Testumgebung

LZ

A

Gleiche Rahmenbedingungen wie im Systemtest

Testumgebung = Abnahmetestumgebung beim Kunden

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

66
Q

Alpha- und Beta-Test:
Unterschied

LZ

A

Ort/ Umgebung Durchführung Tests

Alpha-Tests
- Standort Hersteller (entwickelndes Unternehmen)

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

67
Q

Test-Arten: Überblick

LZ

A
  • Funktionale Tests
  • Nicht-funktionale Tests
  • White-Box-Tests
  • Änderungsbezogenes Testen
68
Q

Test-Arten: Gemeinsamkeit

LZ

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

69
Q

Nicht-funktionale Tests:
Zeitpunkt/ Teststufen

LZ

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

70
Q

Spezialfall Änderungsbezogener Test

LZ

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

Test-Arten: Aspekte

  • funktionale Tests
  • nicht-funktionale Tests
  • White-Box Tests

LZ

A
  • Testverfahren
  • Testbasis
    (- Teststufen)
  • Messung Gründlichkeit
  • Erforderliche Fähigkeiten
72
Q

Messung Gründlichkeit Vergleich (Test-Arten)

LZ

A

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

Testverfahren Vergleich (Test-Arten)

LZ

A

Ableitung

  • Testbedingungen
  • Testfälle
    durch. …

Black-Box-Verfahren:

  • funktionale Tests
  • nicht-funktionale Tests

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

74
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
75
Q

Funktionale Tests &
erforderliche Fähigkeiten

LZ

A

Kenntnis des

bestimmten Fachproblems,
- das die SW löst

bestimmten Funktion,
- die die SW erfüllt

76
Q

Nicht-funktionaler Test: Testbasis

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

Nicht-funktionale Tests:
Erforderliche Fähigkeiten

LZ

A

wie Kenntnis

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

White-Box-Tests: Testbasis

ALLGEMEIN

A

Ableitung Tests auf Basis

  • internen Struktur oder
  • der Implementierung eines Tp

Struktur TO

  • vollständig
  • korrekt
  • entsprechend Spezifikationen
79
Q

White-Box-Tests: Testbasis

KONKRET

A

Interne, strukturelle Merkmale TP

  • Code
  • Architektur
  • Kontrollfluss
  • Datenfluss

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

80
Q

White-Box-Tests: Teststufen

Ausprägungen

A

Komponententest:
Code

Komponentenintegrationstest:
Aufrufhierarchie der Komponenten

Systemtest:
Menüstruktur

81
Q

White-Box-Tests:
Messung Gründlichkeit
Komponententests

LZ

A

Prozentsatz des
Komponentencodes, der
getestet wurde

% Prozentsatz
Codeüberdeckung: Zusammenfassung
- ausführbare Anweisungen
- Entscheidungsüberweisungen

82
Q

White-Box-Tests:
Messung Gründlichkeit
Komponenten-
Integrationstests

LZ

A

% Prozentsatz
Schnittstellen, die durch die
Tests ausgeführt wurden

83
Q

White-Box-Tests:
Spezialwissen

LZ

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

84
Q

Änderungsbezogenes Testen:

Unterkategorien

A
  • Fehlernachtests

- Regressionstests

85
Q

Fehlernachtests (Änderungsbezogenes Testen):

Zweck

A

Bestätigen, dass der

ursprüngliche FZ erfolgreich behoben

86
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

87
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
88
Q

Regressionstest: was

Dojo

A

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

90
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

91
Q

Wartung SW und Systeme:
Ziele/ Zwecke

LZ

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

Wartung:
Auslöser/ Anlässe

LZ

A

Auslöser:

  • Modifikation
  • Migration
  • Außerbetriebnahme
93
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
94
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
95
Q

Auswirkungsanalyse (Wartung):

Einsatz im Wartungstest

A

Auswirkungsanalyse unterstützt

Bestimmung Umfang
REGRESSIONSTESTS

96
Q

Wartungsrelease &

Testumfang

A

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
Q

Auswirkungsanalyse & Wartungstests:

Erschwerende Faktoren

A

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

Study ISTQB CTFL (10 decks)

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