Istqb Certified Tester Foundation Level

1.

2
1
2
3
Grundlagen
Testen im
Lebenszyklus
Statische
Methoden
4
5
63
Testentwurfsverfahren
Testmanagement
Testwerkzeuge
V 3.0 - 1 / 63
ISTQB Certified Tester
Foundation Level
T-Systems · PDC Test · 2010

2.

1
2
3
4
5
6
ISTQB Certified Tester
Foundation Level
Testen im
Lebenszyklus
Lernzielstufe
K2
Softwareentwicklungsmodelle
K2
Teststufen
K2
Testarten
K2
Wartungstest
Sehe Lehrplan, Kapitel 2 für die Lernzielbeschreibung dieses Moduls
Siehe Modul 1, Anhang A, Beschreibung der Lernzielstufen
V 2.1 - 2 / 63
T-Systems · PDC Test · 2010

3. Das V-Modell*

G
2
ISTQB Certified Tester
Foundation Level
Das V-Modell* Vorgehensmodell für die Softwareentwicklung, um die Aktivitäten des Software-
Entwicklungslebenszyklus von der Anforderungsspezifikation bis zur Wartung zu beschreiben.
Anforderungsdefinition
Abnahmetest
funktionaler
Systementwurf
Systemtest
technischer
Systementwurf
*Das „allgemeine“
V-Modell wird hier gezeigt.
Andere Varianten können
weniger, mehr oder andere
Stufen haben.
Integrationstest
Komponentenspezifikation
Komponententest
Programmierung
V 3.0 - 3 / 63
G
Das V-Modell stellt dar, wie
Prüf- und Testaktivitäten in
jede Phase des Software-Entwicklungslebenszyklus integriert und die Zwischenprodukte geprüft (validiert und
verifiziert) werden können.
T-Systems · PDC Test · 2010

4. Das V-Modell: Früher Testentwurf

2
Das V-Modell: Früher Testentwurf
Anforderungsdefinition
ISTQB Certified Tester
Foundation Level
Abnahmetest
funktionaler
Systementwurf
Systemtest
technischer
Systementwurf
Integrationstest
Testentwurf
kommt hier
zu spät!
Komponentenspezifikation
Komponententest
Programmierung
V 3.0 - 4 / 63
T-Systems · PDC Test · 2010

5. Das V-Modell: Präventiver Testansatz

Anforderungsdefinition
2
Abnahmetest
Das V-Modell unterstützt
einen präventiven
Testansatz
funktionaler
Systementwurf
Systemtest
technischer
Systementwurf
Früherer
Entwurf
der Tests
ISTQB Certified Tester
Foundation Level
Integrationstest
Komponentenspezifikation
Komponententest
Späteres
Ausführen des
Testentwurf
Programmierung
V 3.0 - 5 / 63
T-Systems · PDC Test · 2010

6. Relevante Entwicklungsdokumente

2
Relevante Entwicklungsdokumente
Geschäftsvorfälle (Geschäftsabläufe oder
Geschäftsprozesse)
Anforderungsdefinition
Funktionaler und technischer Systementwurf
Komponentenspezifikation
ISTQB Certified Tester
Foundation Level
Testbasis
Mögliche Quellen für generische Dokumente:
CMMI (Capability Maturity Model Integration)*
IEEE 12207 - Software life cycle processes*
UP (Unified Process) [www.rational.com]
* Quellen sind im Lehrplan, Kapitel 7 beschrieben
V 3.0 - 6 / 63
T-Systems · PDC Test · 2010

7. Validierung und Verifizierung

2
Validierung und Verifizierung
ISTQB Certified Tester
Foundation Level
Validierung
G Bestätigung durch Bereitstellung eines objektiven Nachweises, dass die
Anforderungen für einen spezifischen beabsichtigten Gebrauch oder
eine spezifische beabsichtigte Anwendung erfüllt worden sind
[ISO 9000].
Validierung bestätigt, dass das Produkt, so wie es vorliegt, seinen
beabsichtigten Verwendungszweck erfüllen kann. Mit anderen Worten,
Validierung stellt sicher, dass „du das richtige Ding erzeugst“ [CMMI-SW, V1.1]
Verifizierung
G Verifizierung: Bestätigung durch Bereitstellung eines objektiven
Nachweises, dass festgelegte Anforderungen erfüllt worden sind [ISO 9000]
Prüfung, ob die Ergebnisse einer Entwicklungsphase die Vorgaben der
Phaseneingangsdokumente erfüllen
[nach IEEE 610]
Verifikation bestätigt, dass das in Arbeit befindliche Produkt die dafür
festgelegten Anforderungen erfüllt. In anderen Worten, Verifikation stellt
sicher, dass „du das Ding richtig erzeugst“
[CMMI-SW, V1.1]
V 3.0 - 7 / 63
T-Systems · PDC Test · 2010

8.

2
V & V im V – Modell
Anforderungsdefinition
Validierung
ISTQB Certified Tester
Foundation Level
Abnahmetest
Verifizierung
funktionaler
Systementwurf
Validierung
Systemtest
Verifizierung
technischer
Systementwurf
Integrationstest
Validierung
Verifizierung
Komponentenspezifikation
Verifizierung
Val.
Komponententest
Programmierung
V 3.0 - 8 / 63
T-Systems · PDC Test · 2010

9.

2
ISTQB Certified Tester
Foundation Level
Gemeinsamkeiten der
Softwareentwicklungsmodelle
Das Testen „begleitet“ die
SW-Entwicklung. Jede
Entwicklungsaktivität wird von
einer entsprechenden
Testaktivität begleitet.
Testentwurf findet während der
zugehörigen SW-Entwicklungsstufe
statt.
Das frühzeitige Einbindung der Tester
wird gefordert (z.B. Reviews).
Testziele sind teststufenabhängig
(siehe nächste Folie).
V 3.0 - 9 / 63
Charakteristika
für gutes Testen
T-Systems · PDC Test · 2010

10. Teststufen während des Lebenszyklus

Abnahmetest
Vertrauen aufbauen,
z.T. automatisiert
Systemtest
Funktional &
Nicht-funktional,
WAN & LAN,
interne &
externe Systeme
Schnittstellen
Inhalt des Testkonzept:
Komponententest
Detail: Felder,
Masken, Meldungen
Eine Teststufe ist eine Gruppe von
Testaktivitäten, die gemeinsam
ausgeführt und verwaltet werden.
V 3.0 - 10 / 63
ISTQB Certified Tester
Foundation Level
Für jede
(auch neu-definierte) Stufe:
Integrationstest
2
Testziele
Testbasis
Testobjekt
Typische Fehlerwirkungen,
die gefunden werden sollten
Eingangs- / Ausgangskriterien
Liefergegenstände
Testtechniken
Metriken
Werkzeuge
Organisatorische
Verantwortlichkeit
Einzuhaltende
Standards
T-Systems · PDC Test · 2010

11. Iterativ-inkrementelle Entwicklungsmodelle

2
Iterativ-inkrementelle Entwicklungsmodelle
ISTQB Certified Tester
Foundation Level
Beschreibung
Das Produkt wird in Phasen (Inkrements) entwickelt.
Die Aktivitäten werden in jeder Phase wiederholt.
Inkrementell: die Anzahl der Phasen ist zu Beginn bekannt;
alle Phasen werden vorab geplant.
Evolutionär: die Anzahl der Phasen ist zu Beginn noch nicht bekannt.
Verifizierung und Validierung für jede Erweiterung nötig.
Regressionstest haben nach dem ersten Inkrement große Bedeutung.
Werkzeugeinsatz wird betont.
Definition eines Inkrements
Abgeschlossene funktionale Einheit, inklusive der Begleitdokumentation
Beispiele
Prototyping
UP (Unified Process*) – inkrementell
RAD (Rapid Application Development) – evolutionär
SCRUM – agile Modelle
Extreme Programming XP
* früher „Rational Unified Process (RUP), jetzt bei IBM“
V 3.0 - 11 / 63
T-Systems · PDC Test · 2010

12. (R)UP – (Rational) Unified Process

2
(R)UP – (Rational) Unified Process
Anforderungsphase
* Abbildung und deutsche
Begriffe in Anlehnung an:
Krutschen, P. „Der Rational Unified Process
– eine Einleitung“, 1999
ISTQB Certified Tester
Foundation Level
Entwicklungsphase
Entwurfsphase
Aufgaben*
Geschäftsprozessmodellierung
Anforderungen
Analyse & Design
Implementierung
Test
Verteilung
Konfigurations- und
Änderungsmanagement
Projektmanagement
Umgebung
Rational Unified Process
Version
2003.06.01.06
Copyright 1987 - 2003
Rational Software Corporation.
All rights reserved.
Zeit
V 3.0 - 12 / 63
Iterationen
T-Systems · PDC Test · 2010
Übergangs-phase

13. RAD – Rapid Application Development

2
ISTQB Certified Tester
Foundation Level
Beschreibung
Anwender, Designer, Tester, Entwickler bilden ein kleines Team
Das Produkt wird in „Time-Boxes“ entwickelt, d.h. feste
Liefertermine ohne Verzögerung, ggf. variabler Inhalt
Anforderungen, Entwurf, Entwicklung, Test, Review werden pro
Iteration durchgeführt
Anzahl der Iterationen zu Beginn nicht bekannt
Die Entwicklung eines Inkrements hängt von den Informationen aus
vorangegangenen Iterationen ab
Für kleine Projekte geeignet
Beispiele
Wichtige Vertreter für RAD-Systeme sind IDEs
(„Integrated Development Environments“) wie
Delphi und Kylix [www.borland.com]
DSDM (Dynamic System Development Method)
[www.dsdm.org]
V 3.0 - 13 / 63
T-Systems · PDC Test · 2010

14. SCRUM

2
SCRUM
ISTQB Certified Tester
Foundation Level
3 Rollen: Product Owner, SCRUM Master, Project Team
Product Backlog: Funktionalität, die zu implementieren ist
Sprints: Zeitblöcke von typischerweise 30 Tage
Sprint Backlog: Funktionalität, die zum Sprint gehört
Tägliche SCRUM-Gespräche (ca. 15 Minuten)
während des Sprints
Was hast Du seit dem letzten SCRUM-Meeting geschafft?
Gab es Hindernisse?
Was wirst Du bis zum nächsten SCRUM-Meeting erledigt haben?
Testen wird im gesamten Entwicklungsprozess berücksichtigt.
Die Rolle des Testers ist in SCRUM nicht explizit definiert
(in DSDM, das grosse Ähnlichkeiten zu SCRUM aufweist, schon)
V 3.0 - 14 / 63
T-Systems · PDC Test · 2010

15.

1
2
3
4
5
6
ISTQB Certified Tester
Foundation Level
Testen im
Lebenszyklus
Softwareentwicklungsmodelle
Teststufen
Testarten
Wartungstest
V 2.1 - 15 / 63
T-Systems · PDC Test · 2010

16.

Komponententest im Überblick
Komponente: „Das kleinste Softwareelement,
2
ISTQB Certified Tester
Foundation Level
nach
British
Computer
Society
wofür eine separate Spezifikation verfügbar ist“
Komponententest: „ Das Testen einer einzelnen
Softwarekomponente“
Andere Bezeichnungen:
- Modultest
- Einzeltest
- Unit-Test
- Klassentest
- Entwicklertest
- Programmtes
Höchster Detaillierungsgrad
Testbasis: Softwareentwurf, Datenmodell
Entwicklerbeteiligung bzw. -durchführung (Regelfall)
Gefundene Fehlerzustände werden oft sofort behoben (keine
formelle Erfassung)
Entwicklungsumgebung bzw. -werkzeuge verwendet
Platzhalter, Treiber und Simulatoren können schon benötigt
werden (siehe Integrationstest)
V 3.0 - 16 / 63
T-Systems · PDC Test · 2010

17.

2
ISTQB Certified Tester
Foundation Level
Komponententest:
Testziele und Testobjekte
Funktion der Module
Struktur (Module, Klassen, Komponenten)
Datenbankmodule, Migrationsprogramme
Tests auf Robustheit prüfen, ob Komponenten bei ungültigen Eingaben
und extremen Umgebungsbedingungen korrekt funktionieren.
Performance („Benchmarking“)
Typische Fehlerklassen sind...
Fehlende und falsche Struktur
Berechnungsfehler
Unzureichende Performance
Zu geringe Effizienz
Speicherfehler
V 3.0 - 17 / 63
T-Systems · PDC Test · 2010

18.

2
ISTQB Certified Tester
Foundation Level
Komponententestplanung
BS7925-2
„Software Component Test Standard“ unterstützt diese
Aktivitäten:
Spezifikation der Testtechniken mit Begründung
Spezifikation der Vollständigkeitskriterien mit Begründung
Dokumentation der Testunabhängigkeit
Erstellung eines Komponententestplans, der die Abhängigkeiten
zwischen den Komponenten darstellt
„Test-First-Ansatz“ oder Testgetriebene Entwicklung
Zuerst Testfälle vorbereiten und ggf. automatisieren
Bei kleinen, iterativen Zyklen geeignet
V 3.0 - 18 / 63
T-Systems · PDC Test · 2010

19. Integrationstest

2
Integrationstest
ISTQB Certified Tester
Foundation Level
G Testen mit dem Ziel, Fehlerzustände in den Schnittstellen
und im Zusammenspiel zwischen integrierten
Komponenten aufzudecken.
Verbinden von Software- und/oder Hardware-
Komponenten zu größeren Baugruppen oder zum
Gesamtsystem.
Schwerpunkt auf den Schnittstellen der Komponenten
Test kollektiver Funktionen, die nicht an einzelnen
Komponenten
geprüft werden können
Nicht-funktionale Prüfungen möglich (z.B.
Leistungsfähigkeit)
Testbasis: SW- und Systementwurf, Architektur, UseCases, Workflows
V 3.0 - 19 / 63
T-Systems · PDC Test · 2010

20.

2
ISTQB Certified Tester
Foundation Level
Andere Integrationstestobjekte
Netzwerke
Systemintegrationstest:
Test des kompletten
Systems gegen andere
Systeme (meist nach dem
Systemtest)
Interne Systeme
Batch System
Standardsoftware
(COTS: Commercial
Off The Shelf)
Externe Systeme
Lieferanten von Eingabewerten für das getestete System
Abnehmer von Ausgabewerten des getesteten Systems
Datenaustauschsysteme in Subsystemen
Kompatibilität mit „koexistierenden“ Systemen
Gemeinsam genutzte Hardware (Server, Prozessoren, Laufwerke)
Gemeinsam genutzte Datenbanken
Gemeinsam genutzte Netzwerke
V 3.0 - 20 / 63
T-Systems · PDC Test · 2010

21. Integrationsstrategien

2
Integrationsstrategien
ISTQB Certified Tester
Foundation Level
Wahl der Integrationsstrategie legt Rahmenbedingungen für
die Testablaufplanung fest
„Big Bang” Integration oder
Inkrementelle Integration
Top-Down
Bottom-Up
Ad-Hoc
Funktional
Prozessgetrieben
V 3.0 - 21 / 63
T-Systems · PDC Test · 2010

22.

2
Die „Big Bang“ Integration
ISTQB Certified Tester
Foundation Level
Hypothese: Einzeln getestete Komponenten sollten ohne weitere
Tests zusammenpassen
Häufige Motivation: „Zeitersparnis“
PROBLEME ...
Die Grundannahme: „Keine weiteren Fehlerzustände
nach Test der Einzelkomponenten“ ist unrealistisch
Die Fehlerlokalisierung wird unweigerlich
schwieriger und zeitaufwändiger
Regressionen treten häufiger auf
V 3.0 - 22 / 63
T-Systems · PDC Test · 2010

23.

2
ISTQB Certified Tester
Foundation Level
Inkrementelle Integrationsstrategie
Komponenten oder Systeme werden sukzessiv (als „Baselines“)
integriert und getestet, bis alle integriert und getestet sind.
Test definierter Baselines:
Baseline 0 : Test einer Einzelkomponente
Baseline 1 : Gemeinsamer Test zweier Komponenten
Baseline 2 : Gemeinsamer Test von drei Komponenten
Baseline X : etc.
Vorteile:
Einfachere Fehlerlokalisierung und -korrektur
Einfachere Problembehebung
„Fallback“ auf frühere Baseline möglich
Fehlerzustände werden an den Schnittstellen gefunden
Kontrollierter, steuerbarer Testfortschritt
V 3.0 - 23 / 63
T-Systems · PDC Test · 2010

24.

2
„Top-Down“ Integration
Baseline-Abfolge:
A, A + B1, A + B1 + B2,
A + B1 + B2 + C1, etc.
Komponente A
Komponente
B1
ISTQB Certified Tester
Foundation Level
Komponente
B2
Für den Aufruf untergeordneter
Komponenten werden Platzhalter
benötigt, die die noch nicht
integrierten Komponenten vertreten.
Die Baseline 2 (A + B1 + B2) braucht
Platzhalter für C1, C2 und C3
Komponente
C1(Platzh.)
C1
Komponente
C2(Platzh.)
C2
V 3.0 - 24 / 63
Komponente
Component
C3C3
(Platzh.)
Platzhalter
= Stub
T-Systems · PDC Test · 2010

25. Tipps für den Gebrauch von Platzhaltern

2
Tipps für den Gebrauch
von Platzhaltern
ISTQB Certified Tester
Foundation Level
Platzhalter ...
Ersetzen im Integrationstest aufzurufende Komponenten.
Emulieren die aufgerufene Komponente.
Wie detailliert soll die Emulation sein?
Fester Rückgabewert
Einfache Berechnung oder Zufallswert
Eingabe der Antwort durch den Tester
Simulation von Bearbeitungszeiten
Mögliche Probleme?
Zu komplizierte Platzhalter (zu viel Logik oder Code)
Wartung der Platzhalter wird zu aufwändig
Platzhalter repräsentieren mangels Pflege nicht mehr die echten
Komponenten
V 3.0 - 25 / 63
T-Systems · PDC Test · 2010

26.

2
„Top-Down“ Integration
Vorteile
Kritische Kontrollflüsse
werden zuerst und am
häufigsten getestet
ISTQB Certified Tester
Foundation Level
Nachteile
Details kommen als Letztes
Das 95% Problem: „Der
Teufel steckt im Detail“
Ein funktionierendes
Modellsystem ist früh
verfügbar
Entwicklung und Pflege der
Ideal für Prototyping
Versuchung, die Platzhalter
Platzhalter erfordern Aufwand
zu kompliziert zu machen
Keine Treiber werden
benötigt (siehe S.26)
V 3.0 - 26 / 63
T-Systems · PDC Test · 2010

27.

2
„Bottom-Up“ Integration
ISTQB Certified Tester
Foundation Level
Treiber = Driver
Komponente A
(Treiber)
Baseline-Abfolge:
C3, C3+B2, C3+B2+C2, C3+B2+C2+A etc.
Treiber sind zum Aufruf der Baseline
Konfiguration notwendig. Manche
Baselines benötigen auch Platzhalter.
Komponente
Component
B1 (Platzh.)
B1
Komponente
B2
Komponente
Component
C1 (Platzh.)
C1
Die Baseline 2 (C3+B2+C2)
erfordert den Treiber A und die
Platzhalter B1 und C1
Komponente
C2
V 3.0 - 27 / 63
Komponente
C3
T-Systems · PDC Test · 2010

28. Tipps für den Gebrauch von Treibern

2
Tipps für den Gebrauch
von Treibern
ISTQB Certified Tester
Foundation Level
Treiber bilden das Gerüst des Systems
Wie komplex sollten die Treiber sein?
Grundlogik des Aufrufs
Einfacher Datenempfänger für die Baseline
Senden der für die Baseline wesentlichen Daten
Mögliche Probleme?
Fehlende Updates der Treiber im Laufe der Baselines
Die Aufrufslogik wird zu komplex gemacht
V 3.0 - 28 / 63
T-Systems · PDC Test · 2010

29.

2
„Bottom-Up“ Integration
Vorteile
Schnittstellen zu „Low-
Level“-Komponenten
werden zuerst und sehr
gründlich getestet
ISTQB Certified Tester
Foundation Level
Nachteile
Funktionierendes Modell wird erst
mit der letzten Baseline verfügbar
Kritische Kontrollprobleme fallen
oft erst zum Schluss auf
Funktionale Details können
früh untersucht werden
Häufige Anpassungen der Treiber
bei neuen Baselines können
speziell bei kritischen Systemen
erheblichen Aufwand
verursachen
Ideal für die Prüfung von
Schnittstellen zu Systemkomponenten wie Hardware, Middleware (RMI,
CORBA etc)
Platzhalter sind ebenfalls nötig
V 3.0 - 29 / 63
T-Systems · PDC Test · 2010

30. Allgemeine Tipps zum Integrationstest

2
Allgemeine Tipps
zum Integrationstest
ISTQB Certified Tester
Foundation Level
Möglichst wenig neue Komponenten pro Baseline integrieren
Risikoreiche Komponenten (z.B. geschäftskritische oder
fehleranfällige) einzeln integrieren
Einfache und verwandte Komponenten
gemeinsam integrieren
Jede Baseline sollte ein einfach verifizierbares
Ergebnis hervorbringen
Treiber und Platzhalter auf ein Minimum beschränken
Ausschließlich auf die eigentliche Integration konzentrieren
V 3.0 - 30 / 63
T-Systems · PDC Test · 2010

31. Voraussetzungen für erfolgreiche Integrationstests

2
ISTQB Certified Tester
Foundation Level
Tester haben ein Verständnis für die Architektur und sind in die
Integrationsplanung mit einbezogen
Die Integrationstests werden frühzeitig im Lebenszyklus eingeplant.
Die geplanten Baselines treiben die Reihenfolge, in der die
Komponenten entwickelt werden.
Komponenten werden aus Zeitersparnis parallel zum Integrationstest
entwickelt
Die Fertigstellung der Komponenten wird anhand der Baselines geplant
Nicht möglich bei „Ad-Hoc“-Integration
Andere
Integrationsstrategien
V 3.0 - 31 / 63
T-Systems · PDC Test · 2010

32. Systemtest im Überblick

2
Systemtest im Überblick
ISTQB Certified Tester
Foundation Level
Testgegenstand ist das gesamte System, Handbücher, Konfigurationsdaten
Testumgebung sollte möglichst nahe an der Zielumgebung sein
Es ist meist zu riskant die Produktivumgebung selbst zu verwenden (Verlust
von „echten“ Daten, potentielle Betriebsstörungen, usw.)
Die Testtypen zerfallen in zwei Klassen:
Funktionale Tests
Basierend auf funktionalen Anforderungen
Basierend auf Geschäftsprozessen
Meist Black-Box-Testverfahren, aber strukturorientierte Tests (White-BoxTestverfahren) sind möglich (z.B. zur Überdeckung der Menüstrukturen
oder Navigationsstrukturen eines Client-Systems)
Nichtfunktionale (technische) Tests
Basierend auf technischen Qualitätsmerkmalen (siehe ISO9126) wie z.B.
Performance, Stabilität, Ausfallsicherheit, Datensicherheit
Der Systemtest wird häufig von unabhängigen Teams mit speziellen
Fähigkeiten in den einzelnen Testtypen durchgeführt.
V 3.0 - 32 / 63
T-Systems · PDC Test · 2010

33.

2
ISTQB Certified Tester
Foundation Level
Definitionen:
Funktionaler Systemtest
G Funktionale Anforderung:
Anforderung, die ein funktionales Verhalten spezifiziert, das ein
System oder eine Systemkomponente erbringen muss.
[IEEE 610]
Funktionaler Systemtest:
„Ein Test bzw. eine Testphase, in dem das gesamte System gegen
seine Spezifikationen getestet wird“
V 3.0 - 33 / 63
T-Systems · PDC Test · 2010

34.

2
ISTQB Certified Tester
Foundation Level
Anforderungsbasiertes Testen
Spezifikation der
Systemanforderungen
oder
Benutzeranforderungen
(Pflichtenheft,
Lastenheft)
Bemerkung:
Der Tester muss oft mit unvollständigen oder
nicht aktuellen Anforderungsdokumenten
arbeiten.
Testspezifikation
Liste der aus den Spezifikationen
abgeleiteten Testkriterien
Was tun?
Diskutieren mit wichtigen Stakeholders
Annahmen treffen und dokumentieren
Die Annahmen überprüfen bzw.
genehmigen lassen
„Anforderungen“ regelmäßig aktualisieren
V 3.0 - 34 / 63
T-Systems · PDC Test · 2010

35.

Geschäftsprozessbasiertes Testen
2
ISTQB Certified Tester
Foundation Level
Risikobewertung
• Wahrscheinlichkeit
• Auswirkung
Test
Spezifikation
Geschäftsszenarien
„End-To-End“
Geschäftsabläufe
Liste der aus den Prozessen
abgeleiteten Testkriterien
Use Cases
Anwendungsfälle aus
realen Situationen
V 3.0 - 35 / 63
T-Systems · PDC Test · 2010

36. Nicht-funktionaler Systemtest

2
Nicht-funktionaler Systemtest
ISTQB Certified Tester
Foundation Level
Nicht-funktionale Anforderung
G Eine Anforderung welche sich nicht auf die Funktionalität des Systems
bezieht sondern auf Merkmale wie Zuverlässigkeit, Benutzbarkeit,
Effizienz, Änderbarkeit und Übertragbarkeit.
Beschreibt Attribute des Systemverhaltens, also wie gut bzw. mit welcher
Qualität das System seine Funktion erbringen soll. Um-setzung
beeinflusst stark, wie zufrieden der Kunde bzw. Anwender mit dem
Produkt ist.
[ISO 9126]
Nicht-funktionaler Test
Testen der Eigenschaften eines System, die nicht direkt mit der
G
Funktionalität in Verbindung stehen, z.B. Zuverlässigkeit, Effizienz,
Benutzbarkeit, Änderbarkeit und Übertragbarkeit.
Mindestens genauso wichtig wie rein funktionale Tests
Die Vernachlässigung dieser Tests kann ein beträchtliches Risiko für den
Erfolg der Anwendung bedeuten.
Spezifikation nicht-funktionaler Anforderungen wird oft vernachlässigt
Spezifikation wird häufig vergessen
Spezifikation ist oft nicht testbar (d.h. Anforderungen sind manchmal
schwer zu quantifizieren)
V 3.0 - 36 / 63
T-Systems · PDC Test · 2010

37. Abnahmetest

2
Abnahmetest
ISTQB Certified Tester
Foundation Level
G Formales Testen (ggf. unter Beteiligung des
Auftraggebers) hinsichtlich der Benutzeranforderungen
und -bedürfnisse bzw. der Geschäftsprozesse. Es wird
durchgeführt, um einem Auftraggeber oder einer
bevollmächtigten Instanz die Entscheidung auf der Basis
der Abnahmekriterien zu ermöglichen, ob ein System
anzunehmen ist oder nicht
[nach IEEE 610]
V 3.0 - 37 / 63
T-Systems · PDC Test · 2010

38. Abnahmetest im Überblick

2
Abnahmetest im Überblick
ISTQB Certified Tester
Foundation Level
Test unter Beteiligung des Auftraggebers, der Anwender des Systems
und anderer Stakeholder
Testbasis
Die expliziten Anforderungen des Auftraggebers, wie sie in einem
Dokument (z.B. Pflichtenheft oder Fachkonzept) für beide Seiten
verbindlich festgelegt sind.
Die impliziten Erwartungen des Auftraggebers, die dem
allgemeinen Stand der Technik entsprechen.
Risikoanalysen
Testfälle ähnlich wie im Systemtest, in der Regel jedoch nicht so
ausführlich bzw. umfangreich.
Fokus liegt darauf
Vertrauen aufzubauen (funktionale und technische
Qualitätsaspekte).
Betriebsbereitschaft festzustellen.
Restrisiken für die Produktion einzuschätzen.
V 3.0 - 38 / 63
T-Systems · PDC Test · 2010

39. Abnahmetest: Aspekte

2
Abnahmetest: Aspekte
ISTQB Certified Tester
Foundation Level
Folgende Aspekte können relevant sein:
Benutzer-Abnahmetest
Betrieblicher Abnahmetest
Vertraglicher und regulativer Abnahmetest
Siehe folgende
Folien
Alpha- und Beta-Test (Feldtest)
Teilabnahmen können sinnvoll sein, z.B.
Bei der Integration von Standard-Software (Datenbanken, COTS)
Bei der Abnahme von spezifischen Qualitätseigenschaften (Benutzbarkeit,
Sicherheit)
Bei der Abnahme von neuen Funktionen
Zeitliche Aspekte:
Teilabnahmen können in früheren Teststufen durchgeführt werden
Nach der Abnahme können weitere Tests folgen
(z.B. Systemintegrationstests)
V 3.0 - 39 / 63
T-Systems · PDC Test · 2010

40. Benutzer-Abnahmetest

2
Benutzer-Abnahmetest
ISTQB Certified Tester
Foundation Level
Test auf Benutzerakzeptanz (Validierung)
Starke Einbeziehung der Endanwender
(auch wenn sie die Tests nicht selbst durchführen)
Hauptsächlich funktionale Tests, die auf Geschäftsprozessen
basieren
Realistische Testumgebung, meist mit „echten“ Daten
Automatisierte Tests sind möglich
Es kann eine formale (eventuell vertragsrelevante) Abnahme des
Systems erfolgen
V 3.0 - 40 / 63
T-Systems · PDC Test · 2010

41. Einbeziehung der Benutzer - Vorteile

2
Einbeziehung der Benutzer - Vorteile
ISTQB Certified Tester
Foundation Level
Feedback
Ist das geplante oder fertige System brauchbar? Validierung
Die Benutzer kennen ihr Handwerk in all seiner Komplexität und wissen
am besten, was das System leisten muss.
Benutzer können realistische Einsatzszenarien liefern, die auch für den
Entwurf von Testfälle nützlich sind.
Benutzer können Workarounds für Probleme vorschlagen und Tipps zu
Varianten der Standardanwendungsfälle geben.
Bessere Akzeptanz
Die Einbeziehung von Benutzern in verschiedenen Stadien der
Entwicklung schafft ein positives, kooperatives Klima.
Offene Kommunikation mildert typische Hemmschwellen der Veränderung
(z.B. ungewohnte Bezeichnungen, betriebliche Risiken)
Benutzer werden seltener in der Abnahme „ihre Rache nehmen“
Benutzer akzeptieren ein neues System eher,
wenn sie sich damit identifizieren können
V 3.0 - 41 / 63
T-Systems · PDC Test · 2010

42. Test auf vertragliche & regulative Akzeptanz

2
Test auf vertragliche & regulative Akzeptanz
ISTQB Certified Tester
Foundation Level
Vertraglicher Abnahmetest
Vertrag über Lieferung des Software-Systems
Definiert, ausgehandelt und unterzeichnet zum Projekt
Abnahmekriterien sind definiert und abgestimmt
Spezifizierter Liefergegenstand (Hardware, Software, Dokumente)
Definierte Mitwirkungen der Anwender (z.B. Entwurf der Testfälle,
Bereitstellung von Testdaten, Ansprechpartner zu Fachthemen etc.)
Der Abnahmetest erfolgt auf Basis des Vertrags und der
abgestimmten Systemänderungen
Klar spezifizierte Anforderungen sind unabdingbar
Unerfüllte Anwenderwünsche müssen berücksichtigt werden, laufen aber
separat z.B. als Change Request für ein neues Release
Regulativer Abnahmetest / Konformitätstest
Bezug auf die Regularien, die zu erfüllen sind (z.B. Sicherheitsregeln für
Atomkraftwerke, Bundesgesetzte für Banken und Versicherungen)
V 3.0 - 42 / 63
T-Systems · PDC Test · 2010

43. Alphatest und Betatest („Feldtest“)

2
ISTQB Certified Tester
Foundation Level
Realistischer Test des stabilen Systems durch eine Gruppe,
die die Endanwender repräsentiert.
Die Testumgebung ist womöglich produktionsidentisch aufgebaut.
Feedback zu: Nutzerfreundlichkeit des Systems,
Erfüllung der Geschäftsanforderungen, gefundene Fehlerwirkungen,
Verbesserungsvorschläge.
Alpha- und Betatest unterscheiden sich primär durch den Teststandort.
Alphatest: Test in (simulierter) Produktion am Entwicklungsort auf
einer von der Entwicklung getrennten Umgebung.
Betatest / Feldtest: Test in Produktion an einem von der Entwicklung
unabhängigen Teststandort.
Andere Bezeichnungen:
Außenabnahmetest, Fabrik-Abnahmetest, Kundenakzeptanztest
V 3.0 - 43 / 63
T-Systems · PDC Test · 2010

44. Betrieblicher Abnahmetest

2
Betrieblicher Abnahmetest
ISTQB Certified Tester
Foundation Level
G Betriebstest in der Abnahmeteststufe, üblicherweise in einer
simulierten Produktionsumgebung durch den Betreiber und/oder
Administrator durchgeführt, mit Schwerpunkt bei den operationalen
Aspekten, z.B. Wiederherstellbarkeit, Ressourcenverwendung,
Installierbarkeit und technische Konformität
Synonym: operationaler Abnahmetest
Durch den oder im Auftrag des Betreibers oder Administrators
Untersucht in der Regel nicht-funktionale Anforderungen
Backup / Restore
Wiederherstellbarkeit nach Ausfällen
Benutzermanagement
Wartungsaufgaben, auch organisatorische Aspekte
Datenlade- und Migrationsaufgaben
Überprüfung von Sicherheitslücken
V 3.0 - 44 / 63
T-Systems · PDC Test · 2010

45.

1
2
3
4
5
6
ISTQB Certified Tester
Foundation Level
Testen im
Lebenszyklus
Softwareentwicklungsmodelle
Teststufen
Testarten
Wartungstest
V 2.1 - 45 / 63
T-Systems · PDC Test · 2010

46. Testart / Testtyp

2
Testart / Testtyp
ISTQB Certified Tester
Foundation Level
Eine Testart ist eine Gruppe von Testaktivitäten, die gemeinsam ausgeführt
G
und verwaltet werden, mit dem Ziel der Überprüfung einer Komponente und
eines Systems auf einige zusammenhängende Qualitätsmerkmale.
Eine Testart kann sich auf bestimmte Testziele beziehen, wie z.B.
Zuverlässigkeitstest, Regressionstest, Benutzbarkeitstest.
Die Testart kann sich auch auf eine oder mehrere Testebenen oder -phasen
beziehen.
Wir betrachten im folgenden diese 4 Testarten:
Testen einer zu erfüllenden Funktion
Testen einer nicht-funktionalen Anforderung
Testen der Struktur oder Architektur der Software beziehungsweise des Systems
Prüfen auf erfolgreiche Beseitigung eines Fehlers (Nachtest) oder Prüfen auf
unbeabsichtigte beziehungsweise ungewollte Änderungen oder Seiteneffekte
(Regressionstest)
V 3.0 - 46 / 63
T-Systems · PDC Test · 2010

47. Testart / Testtyp im Überblick

Dynamische Methoden
ISTQB Certified Tester
Foundation Level
2
* siehe BS 7925-2
** www.testingstandards.co.uk
White Box
(Struktureller Test*)
Abdeckung von…
Codeanweisungen,
Black-Box (Spezifikationsbasierter Test)
Abdeckung von…
3
Zweigen, Pfaden, …
Funktional *
Anforderungen
X
Geschäftsprozessen
X
1
Nicht-funktional **
X
2
4
Nachtest und Regressionstest
Testentwurfsmethoden für 1 und 3 in Modul 4
V 3.0 - 47 / 63
T-Systems · PDC Test · 2010

48.

Qualitätsmerkmale nach DIN-ISO 9126
Qualitätsmerkmal
Aspekt
Funktionalität
Richtigkeit
Angemessenheit
Ordnungsmäßigkeit
Interoperabilität
Sicherheit
Zuverlässigkeit
Reife
Fehlertoleranz
Wiederherstellbarkeit
Benutzbarkeit
Verständlichkeit
Erlernbarkeit
Bedienbarkeit
Effizienz
Verbrauchsverhalten
Zeitverhalten
Änderbarkeit
Prüfbarkeit
Stabilität
Analysierbarkeit
Modifizierbarkeit
Übertragbarkeit
Austauschbarkeit
Koexistenz
Installierbarkeit
Anpassbarkeit
2
ISTQB Certified Tester
Foundation Level
1
Es gibt viele Arten
funktionaler und nichtfunktionaler Tests.
Nicht alle davon müssen
für eine gegebene
Anwendung sinnvoll sein.
Zusätzlicher Aspekt:
Verträglichkeit mit
jeweiligen Standards
V 3.0 - 48 / 63
T-Systems · PDC Test · 2010

49. Qualitätsmerkmal „Funktionalität“

2
ISTQB Certified Tester
Foundation Level
1
Die Funktionalität besagt, „was“ das System leisten soll
Richtigkeit
Sind alle Berechnungen richtig?
Werden die richtigen Daten angezeigt oder abgespeichert?
Werden die richtigen Funktionen oder Routinen aufgerufen?
Angemessenheit
So komplex wie nötig, so einfach wie möglich
Ordnungsmäßigkeit
für alle Teststufen
relevant
Erfüllung von Normen und
gesetzlichen Bestimmungen
Interoperabilität
Passen die beiden Seiten einer
Schnittstelle zusammen?
Werden passende Daten übertragen?
Werden passende Datenformate verwendet?
Sind die Felder gleich lang?
Sicherheit (siehe nächste Folie)
V 3.0 - 49 / 63
T-Systems · PDC Test · 2010

50. Qualitätsmerkmal „Sicherheit“

2
ISTQB Certified Tester
Foundation Level
1
Verschlüsselung
Eingabe und vorausgesagtes Ergebnis spezifizierbar?
Ist die Verschlüsselung leicht überwindbar?
Berechtigungen und Passwörter
Sind Passwörter hinreichend geschützt?
Sind die Passwörter leicht zu knacken?
Welche Berechtigungsstufen gibt es? (Daten, Funktionen, ..)
Ist die Hardwareseite genügend gesichert?
Weitere Sicherheitsmaßnahmen
Organisatorische Abläufe
Physikalische Absicherung
Sicherheitskonzepte
Systemarchitektur
V 3.0 - 50 / 63
T-Systems · PDC Test · 2010

51.

Qualitätsmerkmale nach DIN-ISO 9126
Qualitätsmerkmal
Aspekt
Funktionalität
Richtigkeit
Angemessenheit
Ordnungsmäßigkeit
Interoperabilität
Sicherheit
Zuverlässigkeit
Reife
Fehlertoleranz
Wiederherstellbarkeit
Benutzbarkeit
Verständlichkeit
Erlernbarkeit
Bedienbarkeit
Effizienz
Verbrauchsverhalten
Zeitverhalten
Änderbarkeit
Prüfbarkeit
Stabilität
Analysierbarkeit
Modifizierbarkeit
Übertragbarkeit
Austauschbarkeit
Koexistenz
Installierbarkeit
Anpassbarkeit
2
ISTQB Certified Tester
Foundation Level
2
Es gibt viele Arten
funktionaler und nichtfunktionaler Tests.
Nicht-funktionale
Merkmale besagen, „wie“
das System arbeitet.
Nicht alle davon müssen
für eine gegebene
Anwendung sinnvoll sein.
Zusätzlicher Aspekt:
Verträglichkeit mit
jeweiligen Standards
V 3.0 - 51 / 63
T-Systems · PDC Test · 2010

52. Qualitätsmerkmal „Zuverlässigkeit“

2
ISTQB Certified Tester
Foundation Level
2
Zuverlässigkeit
Merkmal aus Nutzersicht
Wird häufig als nicht testbare Anforderung bezeichnet
Sinnvolle Messgröße: Mittlere Zeit zwischen Ausfällen (MTBF)
Die 24*7 Anforderung für E-Commerce Anwendungen
Backup & Recovery („Wiederherstellbarkeit“)
Backup als automatisiertes und manuelles Verfahren
Wiederherstellung gesicherter Daten (Software, Dokumente, etc.)
Test des gesamten Ablaufs (Vorgänge, Rollen, etc.)
Test der Dokumentation
Regelmäßiger Test im Rahmen des Betriebs
V 3.0 - 52 / 63
T-Systems · PDC Test · 2010

53. Qualitätsmerkmal „Benutzbarkeit“

2
ISTQB Certified Tester
Foundation Level
2
Merkmal aus Nutzersicht
Aussagefähigkeit von Meldungen
Kann der Benutzer darauf reagieren?
Werden für den Benutzer verständliche Begriffe verwendet?
Konsistentes Erscheinungsbild der Nutzeroberfläche
Sind die relevanten Standards berücksichtigt?
Verständlichkeit und Erlernbarkeit für den Benutzer
Überflutung mit Auswahlmöglichkeiten oder kritischer
Information?
Ist dem Benutzer klar, was das System tut? (Feedback)
Vorgehensweise beim Test der Nutzerfreundlichkeit
Wer testet?
Endanwender oder unabhängige Tester?
Wann?
Nach Fertigstellung oder prozessbegleitend?
V 3.0 - 53 / 63
T-Systems · PDC Test · 2010

54. Qualitätsmerkmal „Effizienz“

2
Qualitätsmerkmal „Effizienz“
ISTQB Certified Tester
Foundation Level
2
Merkmal aus Nutzersicht
Performance
Lasttest, Massentest (Kapazität, Datenvolumen)
Antwortzeit auf eine Benutzereingabe in Sekunden
Dauer einer komplexen Datenbanksuche, in Millisekunden
Bearbeitungsdauer einer Unterroutine, in CPU Zyklen
Test unter hoher Nutzungsintensität
Maximale geforderte Bearbeitungsrate (z.B. Transaktionen pro Sekunde)
Maximaler geforderte Datendurchsatz (z.B. Kilobyte pro Sekunde)
Maximalzahl paralleler Zugriffe oder Prozesse
Stress- und Skalierungstest
Wo liegen die Belastungsgrenzen des Systems?
Werden kurze Lastspitzen oder das geplante Wachstum verkraftet?
Wie reagiert das System bei Erreichen bzw. Überschreiten der
Belastungsgrenzen?
V 3.0 - 54 / 63
T-Systems · PDC Test · 2010

55. Qualitätsmerkmal „Änderbarkeit / Wartbarkeit“

2
ISTQB Certified Tester
Foundation Level
2
Merkmal aus der Sicht der Entwicklung und Wartung
Analysierbarkeit
Aufwand, um Mängel oder Ursachen von Versagen zu
diagnostizieren oder um änderungsbedürftige Teile zu bestimmen
Modifizierbarkeit
Aufwand zur Ausführung von Verbesserungen,
zur Fehlerbeseitigung oder
zur Anpassung an Umgebungsänderungen
Stabilität
Wahrscheinlichkeit des Auftretens unerwarteter (Neben-)
Wirkungen von Änderungen
Prüfbarkeit
Aufwand, der zur Prüfung der geänderten Software notwendig ist
V 3.0 - 55 / 63
T-Systems · PDC Test · 2010

56. Qualitätsmerkmal „Übertragbarkeit / Portabilität“

2
ISTQB Certified Tester
Foundation Level
2
Merkmal aus der Sicht der Entwicklung und Wartung
Anpassbarkeit (Konfiguration)
Kombination verschiedener Hardware- und Softwareplattformen
Mögliche Systemkonfigurationen
Konfiguration der eigenen Software und fremder Software
Installierbarkeit
Wie wird die Software für den Wirkbetrieb installiert?
- Verteilungskanal (CD, “Push”-Technologie, Netzinstallation)
Installationsverfahren
- für die einmalige Installation und für geplante Updates
Verfahren und Nebeneffekte der De-Installation
Physikalische Rahmenbedingungen: Elektromagnetische
Abschirmung, Hitze, Feuchtigkeit, Vibration, Stromversorgung, ...
Austauschbarkeit
Wie leicht lässt sich Software austauschen?
V 3.0 - 56 / 63
T-Systems · PDC Test · 2010

57. Struktureller Test

2
Struktureller Test
ISTQB Certified Tester
Foundation Level
Dynamische Methoden
3
White Box
(Struktureller Test)
Black-Box
(Spezifikationsbasierter Test)
Strukturelles Testen (strukturorientierter Test) kann in allen Teststufen
angewendet werden
Verschiedene Testüberdeckungen werden als Maß für eine Vollständigkeit
einzelner Testsuiten verwendet, z.B.
Anweisungsüberdeckung
Entscheidungs- oder Zweigüberdeckung
Unterstützung durch entsprechende Testwerkzeuge ist notwendig
Strukturelle Tests in höheren Teststufen beziehen sich auf
die Systemarchitektur (z.B. Menüstrukturen,
Aufrufhierarchien, Geschäftsmodelle)
V 3.0 - 57 / 63
T-Systems · PDC Test · 2010

58.

2
4
Nachtest und Regressionstest
G
Wiederholung aller Testfälle, die vor der Fehlerkorrektur
eine Fehlerwirkung erzeugt haben; dient der
Überprüfung, ob die Korrektur des ursächlichen
Fehlerzustands erfolgreich war.
Prüfe den behobenen
Fehlerzustand
durch Testwiederholung
ISTQB Certified Tester
Foundation Level
G
Erneuter Test eines bereits getesteten Programms
bzw. einer Teilfunktionalität nach deren Modifikation,
mit dem Ziel nachzuweisen, dass durch die
vorgenommenen Änderungen keine Fehlerzustände
eingebaut oder (bisher maskierte Fehler) freigelegt
wurden.
Neue Fehlerzustände
werden durch
Regressionstests entdeckt
Nebeneffekt des
Fixes: neue
Fehlerzustände
werden durch
Fehlernachtest nicht
untersucht.
Nachtest beruht auf der exakten Wiederholbarkeit
bzgl. Testumgebung, SW-Konfiguration, Eingaben und
Voraussetzungen.
V 3.0 - 58 / 63
Einige Fehlerzustände
können dennoch
unentdeckt bleiben.
Regressionstests:
• Benötigen mehr Aufwand.
• Umfang ist abhängig vom Risiko hinsichtlich neu
eingebrachter Fehlerzustände.
• Sind für die Erhaltung der SW-Qualität wichtig.
T-Systems · PDC Test · 2010

59. Regressionstests

2
Regressionstests
ISTQB Certified Tester
Foundation Level
4
Können in jeder Teststufe angewendet werden.
Können funktionale, nicht-funktionale und strukturelle Testinhalte
abdecken.
Bestehen aus einer vordefinierten Standardgruppe von Tests
(„Regression Test Suite“), die regelmässig laufen.
Organisiere die „Suite“ durch Untergruppen von Tests, die immer
zusammen laufen können (z.B. Tests, die bestimmte Funktionen
abdecken)
Redundante, ineffektive oder nicht mehr zutreffende Tests müssen
entfernt und neue hinzugefügt werden.
Die Erstellung und insbesondere die Wartung einer
„Regression Test Suite“ erfordern Aufwand.
Plane den Aufwand!
Sind erste Kandidaten für eine Automatisierung.
V 3.0 - 59 / 63
mehr im Modul 6:
Testwerkzeuge
T-Systems · PDC Test · 2010

60.

1
2
3
4
5
6
ISTQB Certified Tester
Foundation Level
Testen im
Lebenszyklus
Softwareentwicklungsmodelle
Teststufen
Testarten
Wartungstest
V 2.1 - 60 / 63
T-Systems · PDC Test · 2010

61. Wartungstest

2
Wartungstest
ISTQB Certified Tester
Foundation Level
Anlass: ein SW-System, das sich (seit einiger Zeit) im Betrieb befindet,
muss geändert (modifiziert) werden.
Modifikationen am System erfordern Wartungstests
Geplante Spezifikationsänderung (z.B. Funktionserweiterung
auf Wunsch des Kunden )
Notfallkorrekturen (z.B. Hotfix)
Änderung der HW- oder SW-Plattform (Datenbank, Betriebssystem)
Datenmigrationen in ein neues System erfordern Wartungstests
Z.B. nach Außerbetriebnahme/Einzug („Abschalten“) eines
veralteten Systems, hier auch ggf. Test der Archivierung
Fehlende oder veraltete Spezifikationen können sich als ein großes
Problem herausstellen
Änderungen, Upgrades oder Hotfixes können ungewollte
Nebenwirkungen haben
V 3.0 - 61 / 63
T-Systems · PDC Test · 2010

62. Wartungstest: die Strategie

2
Wartungstest: die Strategie
ISTQB Certified Tester
Foundation Level
Entscheide aufgrund des Umfangs und des Inhalts der Änderungen,
welche Auswirkungen die Änderungen auf das System haben
(engl. impact analysis)
Starte mit breit angelegten Tests („Smoke Tests“), um ein
Grundvertrauen zu gewinnen, dass das System noch intakt ist
Im Anschluss Durchführung tieferer Tests für besonders kritische
Bereiche basierend auf der Risikoanalyse
Darüber hinaus Durchführung von Regressionstests aus der zur
Verfügung stehenden „Regression Test Suite“ sofern nötig
Die Auswirkungsanalyse gibt auch Aufschluss darüber, welche Teile
der „Regression Test Suite“ durchgeführt werden sollen.
Umfang und Tiefe der Tests sind vom Risiko bestimmt!
V 3.0 - 62 / 63
T-Systems · PDC Test · 2010

63. Zusammenfassung: Testen im SW-Lebenszyklus

2
Zusammenfassung: Testen im
SW-Lebenszyklus
ISTQB Certified Tester
Foundation Level
V-Modell unterscheidet Teststufen und motiviert frühen Testentwurf
Verschiedene Softwareentwicklungmodellen erfordern verschiedene
Testansätze
Der Komponententest liegt in der Verantwortung der Entwicklung
Der Integrationstest erfolgt zunächst auf Komponentenebene
Der Systemtest prüft funktionale und nicht-funktionale Kriterien
Anschließend Test der Integration auf Systemebene
Der Abnahmetest bezieht die Benutzer mit ein
Unterschiedliche Testziele und Testarten sind Basis für eine erfolgreiche
Teststrategie
Der Wartungstest dient dem Erhalt der Systemqualität
V 3.0 - 63 / 63
T-Systems · PDC Test · 2010

64. Änderungsverzeichnis

2
RUP – Rational Unified Process
Anforderung
sphase
Entwurfsphase
Entwicklung
s-phase
ISTQB Certified Tester
Foundation Level
Lebenszyklus Modelle
Übergangs-phase
Testaufgabe definieren
Aufgaben
Anforderungsmodellierung
Anforderungen
Analyse & Entwurf
Testansatz verifizieren Softwarestabilität verifizieren
Implementierung
Test
Ausrollen
Konfigurations- und
Änderungsmanagement
weitere
Methode
Projektmanagement
Test und
Evaluierung
Umgebung
Rational Unified Process
Version
2003.06.01.06
Copyright 1987 - 2003
Rational Software Corporation.
All rights reserved.
akzeptablen
Zustand
erreichen
Testmittel verbessern
Iterationen
weiterer
Testzyklus
V 3.0 - 65 / 63
T-Systems · PDC Test · 2010

65. RUP – Rational Unified Process

2
Andere Integrationsstrategien
ISTQB Certified Tester
Foundation Level
Funktionale Integration
Bausteine, die eine spezifische Funktion des Systems darstellen,
werden integriert.
Die Bausteine können eine Mischung sein aus elementaren
Komponenten und Komponenten, die weitere Komponenten
aufrufen.
Individuelle Funktionen können frühzeitig bereitgestellt werden.
Gute Strategie für inkrementelle Entwicklungsprozesse (z.B. RAD).
Ad-Hoc-Integration
Bausteine werden in der Reihenfolge der Implementierung integriert
Software kann frühzeitig integriert werden
Viele Platzhalter und Treiber werden benötigt
Prozessintegration
Ähnlich zu funktionaler Integration.
Bausteine werden integriert in der zeitlichen Reihenfolge eines
Prozessablaufs (engl. „Thread Integration“)
V 3.0 - 66 / 63
T-Systems · PDC Test · 2010