ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 1803
Скачиваний: 4
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 26/84
1.8.2011
© International Software Testing Qualifications Board
2.2.3 Systemtest (K2)
Testbasis
•
System- und Anforderungsspezifikation
•
Anwendungsfälle (use cases)
•
funktionale Spezifikation
•
Risikoanalyseberichte
Typische Testobjekte
•
System-, Anwender- und Betriebshandbücher
•
Systemkonfiguration und Konfigurationsdaten
Der Systemtest beschäftigt sich mit dem Verhalten eines Gesamtsystems/-produkts. Das Testziel soll
klar im Master- und/oder Stufentestkonzept dieser Teststufe festgelegt sein.
Beim Systemtest sollte die Testumgebung mit der finalen Ziel- oder Produktivumgebung so weit wie
möglich übereinstimmen, um das Risiko umgebungsspezifischer Fehler, die nicht während des Tes-
tens gefunden werden, zu minimieren.
Systemtests können Tests einschließen, die auf einer Risikoanalyse basieren und/oder auf Anforde-
rungsspezifikationen, Geschäftsprozessen, Anwendungsfällen oder anderen abstrakten textuellen
Beschreibungen oder Modellen des Systemverhaltens, auf Interaktionen mit dem Betriebssystem und
den Systemressourcen.
Systemtests sollen funktionale und nicht-funktionale Anforderungen an das System sowie Datenquali-
tätscharakteristiken untersuchen. Dabei müssen sich Tester auch oft mit unvollständigen oder
undokumentierten Anforderungen befassen. Funktionale Anforderungen werden im Systemtest zu-
nächst mit spezifikationsorientierten Testentwurfsverfahren (Black-Box-Testentwurfsverfahren) getes-
tet. Beispielsweise kann eine Entscheidungstabelle für die Kombination der Wirkungen in Geschäfts-
regeln erstellt werden. Strukturbasierte Techniken (White-Box-Testentwurfsverfahren) können einge-
setzt werden, um die Überdeckung der Tests zu bewerten, bezogen auf ein strukturelles Element wie
die Menüstruktur oder die Navigationsstruktur einer Website (siehe Kapitel 4).
Systemtests werden oft durch unabhängige Testteams durchgeführt.
2.2.4 Abnahmetest (K2)
Testbasis:
•
Benutzeranforderungen
•
Systemanforderungen
•
Anwendungsfälle (use cases)
•
Geschäftsprozesse
•
Risikoanalyseberichte
Typische Testobjekte:
•
Geschäftsprozesse des voll integrierten Systems
•
Betriebs- und Wartungsprozesse
•
Anwenderverfahren
•
Formulare
•
Berichte
•
Konfigurationsdaten
Der Abnahmetest liegt meist im Verantwortungsbereich der Kunden oder Benutzer des Systems. An-
dere Stakeholder können jedoch auch daran beteiligt sein.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 27/84
1.8.2011
© International Software Testing Qualifications Board
Das Ziel des Abnahmetests besteht darin, Vertrauen in das System, Teilsystem oder in spezifische
nicht-funktionale Eigenschaften eines Systems zu gewinnen. Das Finden von Fehlerzuständen ist
nicht das Hauptziel beim Abnahmetest. Abnahmetests können die Bereitschaft eines Systems für den
Einsatz und die Nutzung bewerten, obwohl sie nicht notwendigerweise die letzte Teststufe darstellen.
So könnte beispielsweise ein umfangreicher Systemintegrationstest dem Abnahmetest eines der Sys-
teme folgen.
Die Durchführung von Abnahmetests kann zu verschiedenen Zeiten im Lebenszyklus erfolgen:
•
Eine Standardsoftware kann einem Abnahmetest unterzogen werden, wenn sie installiert oder
integriert ist.
•
Der Abnahmetest bezüglich der Benutzbarkeit einer Komponente kann während des Kompo-
nententests durchgeführt werden.
•
Der Abnahmetest einer neuen funktionalen Erweiterung kann vor dem Systemtest erfolgen.
Unter anderem gibt es folgende typische Ausprägungen des Abnahmetests:
Anwender-Abnahmetest
Er prüft die Tauglichkeit eines Systems zum Gebrauch durch Anwender bzw. Kunden.
Betrieblicher Abnahmetest
Die Abnahme des Systems durch den Systemadministrator enthält:
•
Test des Erstellens und Wiedereinspielens von Sicherungskopien (backup/restore)
•
Wiederherstellbarkeit nach Ausfällen
•
Benutzermanagement
•
Wartungsaufgaben
•
Datenlade- u. Migrationsaufgaben und
•
periodische Überprüfungen von Sicherheitslücken
Regulatorischer und vertraglicher Abnahmetest
Beim vertraglichen Abnahmetest wird kundenindividuelle Software explizit gegen die vertraglichen
Abnahmekriterien geprüft. Abnahmekriterien sollten beim Vertragsabschluss zwischen den beteiligten
Parteien definiert werden.
Regulatorische Abnahmetests werden gegen alle Gesetze und Standards durchgeführt, denen das
System entsprechen muss – beispielsweise staatliche, gesetzliche oder Sicherheitsbestimmungen.
Alpha- und Beta-Test (oder Feldtest)
Hersteller kommerzieller oder Standardsoftware wollen oft Feedback von potenziellen oder existieren-
den Kunden erhalten, bevor sie ein Produkt kommerziell zum Kauf anbieten. Der Alpha-Test wird am
Herstellerstandort durchgeführt, nicht jedoch vom Entwicklungsteam. Der Beta- (oder Feldtest) wird
von Kunden oder potenziellen Kunden an den Kundenstandorten durchgeführt.
Organisationen können ebenso andere Begriffe nutzen z.B. Fabrikabnahmetests oder Kundenakzep-
tanztests für Systeme, die getestet werden, bevor oder nachdem sie zum Einsatzort eines Kunden
gebracht wurden.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 28/84
1.8.2011
© International Software Testing Qualifications Board
2.3 Testarten (K2)
40 Minuten
Begriffe
Benutzbarkeitstest, Black-Box-Test, Codeüberdeckung, funktionaler Test, Interoperabilitätstest,
Lasttest,
Performanztest,
Portabilitätstest,
Sicherheitstest,
Stresstest,
struktureller
Test,
Wartbarkeitstest, White-Box-Test, Zuverlässigkeitstest
Hintergrund
Eine Menge von Testaktivitäten kann darauf ausgerichtet sein, das Softwaresystem (oder ein Teilsys-
tem) entweder aus einem bestimmten Grund bzw. Anlass oder aber mit einem bestimmten Testziel zu
prüfen.
Eine Testart ist auf ein spezielles Testziel ausgerichtet:
•
Testen einer zu erfüllenden Funktion
•
Testen einer nicht-funktionalen Anforderung, wie Zuverlässigkeit oder Benutzbarkeit
•
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)
Ein Modell der zu testenden Software kann sowohl für strukturelle Tests, für nicht-funktionale Tests
als auch für funktionale Tests entwickelt und/oder eingesetzt werden, zum Beispiel ein Kontroll-
flussgraph oder Menüstrukturmodell für strukturelle Tests, ein Prozessablaufmodell, ein Zustands-
übergangsmodell, oder eine Klartextspezifikation für das funktionale Testen oder ein
Performanzmodell, ein Benutzbarkeitsmodell oder ein Modell zum Thema Sicherheitsbedrohung (se-
curity threat modeling) für nicht-funktionale Tests.
2.3.1 Testen der Funktionalität (funktionaler Test) (K2)
Die Funktionalität, die ein System, Teilsystem oder eine Komponente zu erbringen hat, kann entweder
in Arbeitsprodukten wie Anforderungsspezifikationen, Anwendungsfällen oder in einer funktionalen
Spezifikation beschrieben sein, oder sie kann undokumentiert sein. Die Funktionalität besagt, „was“
das System leistet.
Funktionale Tests basieren auf Funktionen, Eigenschaften (beschrieben in Entwicklungsdokumenten
oder gemäß dem Verständnis der Tester) und ihrer Interoperabilität zu bestimmten Systemen. Sie
kommen in allen Teststufen zur Anwendung (z.B. Komponententest basierend auf der Komponenten-
spezifikation).
Spezifikationsorientierte Testentwurfsverfahren werden verwendet, um Testbedingungen und Testfälle
aus der Funktionalität der Software oder des Systems herzuleiten (siehe Kapitel 4). Ein funktionaler
Test betrachtet das von außen sichtbare Verhalten der Software (Black-Box-Test).
Ein Typ des funktionalen Tests, der Sicherheitstest, prüft, ob Funktionen, die Software und Daten
schützen sollen (z.B. Firewalls), wirksam gegenüber externen Bedrohungen, wie Viren etc., sind. Ein
anderer Typ des funktionalen Tests ist der Interoperabilitätstest. Er bewertet die Fähigkeit des Soft-
wareprodukts mit ein oder mehr spezifizierten Komponenten oder Systemen zu interagieren.
2.3.2 Testen der nicht-funktionalen Softwaremerkmale (nicht-funktionaler Test) (K2)
Nicht-funktionales Testen umfasst unter anderem: Performanztest, Lasttest, Stresstest, Benutzbar-
keitstest, Wartbarkeitstest, Zuverlässigkeitstest und Portabilitätstest. Es geht darum, „wie“ das System
arbeitet.
Nicht-funktionales Testen kann in allen Teststufen zur Anwendung kommen. Der Begriff nicht-
funktionaler Test bezeichnet Testarten, die zur Prüfung von Software- und Systemmerkmalen ver-
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 29/84
1.8.2011
© International Software Testing Qualifications Board
wendet werden. Zur Quantifizierung dieser Merkmale werden unterschiedliche Maßstäbe eingesetzt,
so zum Beispiel Antwortzeiten beim Performanztest. Diese Testarten können sich auf ein Quali-
tätsmodell stützen, wie zum Beispiel auf die Softwarequalitätsmerkmale, die in der Norm ‘Software
engineering – Product quality’ (ISO 9126-1, 2001) definiert sind. Nicht-funktionale Tests betrachten
das nach außen sichtbare Verhalten. Sie verwenden meistens Black-Box-Testentwurfsverfahren, um
diese Prüfung durchzuführen.
2.3.3 Testen der Softwarestruktur/Softwarearchitektur (strukturorientierter Test) (K2)
Strukturelles Testen (White-Box-Test) kann in allen Teststufen angewandt werden. Strukturelle Test-
entwurfsverfahren werden am besten nach den spezifikationsorientierten Testentwurfsverfahren ein-
gesetzt, um die Testintensität anhand der gemessenen Abdeckungen zu beurteilen.
Testüberdeckung ist ein Maß dafür, inwiefern eine Struktur durch eine Testsuite geprüft bzw. ausge-
führt (überdeckt) wurde. Dabei wird jeweils der prozentuale Anteil der überdeckten Strukturelemente
angegeben. Ist die erreichte Testüberdeckung kleiner als 100%, kann diese verbessert werden, indem
für die noch nicht überdeckten Elemente zusätzliche Testfälle spezifiziert werden. Entsprechende
Testentwurfsverfahren sind im Kapitel 4 beschrieben.
Werkzeuge zur Messung der Codeüberdeckung, wie Anweisungs- oder Entscheidungsüberdeckung,
können in allen Teststufen eingesetzt werden, im Speziellen aber im Komponenten- und Komponen-
tenintegrationstest. Strukturelles Testen kann auch auf der Systemarchitektur aufbauen, so zum Bei-
spiel auf der Aufrufhierarchie.
Der Ansatz des strukturorientierten Testens kann sinngemäß ebenso in den Teststufen System-, Sys-
temintegration- oder Abnahmetest eingesetzt werden (beispielsweise für Geschäftsmodelle oder Me-
nüstrukturen).
2.3.4 Testen im Zusammenhang mit Änderungen (Fehlernachtest und Regressions-
test) (K2)
Nachdem ein Fehlerzustand entdeckt und korrigiert wurde, sollte die Software anschließend erneut
getestet werden, um zu bestätigen, dass der Fehlerzustand erfolgreich entfernt wurde. In diesem Fall
spricht man von einem Fehlernachtest. Debugging (Lokalisieren, und Entfernen eines Fehlerzustands)
ist eine Entwicklungs- und keine Testaufgabe.
Unter Regressionstest verstehen wir das wiederholte Testen eines bereits getesteten Programms
nach dessen Modifikation. Er hat das Ziel nachzuweisen, dass durch die vorgenommenen Modifikati-
onen keine Fehlerzustände eingebaut wurden oder bisher unentdeckte Fehlerzustände wirksam wer-
den. Diese Fehlerzustände können entweder in der zu testenden Software selbst oder aber in einer
anderen Softwarekomponente liegen. Ein Regressionstest wird ausgeführt, wenn sich die Software
selbst oder ihre Umgebung ändert. Der Umfang des Regressionstests ist durch das Risiko von neuen
Fehlerzuständen in der vorher funktionierenden Software bestimmt.
Tests, die für Fehlernachtests oder Regressionstests vorgesehen sind, müssen wiederholbar sein.
Regressionstests können in allen Teststufen durchgeführt werden und enthalten funktionale, nicht-
funktionale wie auch strukturelle Tests. Regressionstests werden oft wiederholt und ändern sich im
Normalfall eher selten, was sie zu bevorzugten Kandidaten für eine Automatisierung macht.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 30/84
1.8.2011
© International Software Testing Qualifications Board
2.4 Wartungstest (K2)
15 Minuten
Begriffe
Auswirkungsanalyse, Wartungstest
Hintergrund
Einmal in Betrieb, bleibt ein Softwaresystem oft über Jahre oder Jahrzehnte im Einsatz. Während
dieser Zeit werden das System, seine Konfigurationsdaten und seine Umgebung mehrmals korrigiert,
gewechselt oder erweitert. Eine vorausschauende Release-Planung ist entscheidend für einen erfolg-
reichen Wartungstest, hierbei muss eine Unterscheidung zwischen geplanten Releases und „Hot Fi-
xes“ gemacht werden. Der Wartungstest wird an einem betreibbaren System ausgeführt, wobei die
Tests jeweils durch Modifikationen, Migrationen oder Einzug der Software (Außerbetriebnahme, Ablö-
sung) oder des Systems bedingt werden.
Modifikationen enthalten geplante Erweiterungen (z.B. basierend auf dem geplanten Release), Kor-
rekturen und Notfallkorrekturen, Umgebungsänderungen wie eine geplante Aktualisierung des Be-
triebs- oder Datenbanksystems, geplante Upgrades von kommerzieller Standardsoftware oder Pat-
ches zur Korrektur erst kürzlich entdeckter Schwachstellen des Betriebssystems.
Ein Wartungstest bei einer Migration (z.B. von einer Plattform zu einer anderen) soll sowohl Tests im
Betrieb der neuen Umgebung als auch der geänderten Software umfassen. Migrationstests (Konver-
tierungstests) werden ebenso benötigt, wenn Daten aus einer anderen Anwendung in das zu warten-
de System migriert werden.
Ein Wartungstest bei Außerbetriebnahme/ Einzug oder der Ablösung eines Systems kann das Testen
der Datenmigration oder der Archivierung umfassen (falls eine lange Aufbewahrungszeit notwendig
ist).
Zusätzlich zum Testen der eingebrachten Modifikationen gehört zum Wartungstesten das Regressi-
onstesten der Systemteile, die nicht geändert wurden. Der Umfang der Wartungstests ist abhängig
vom dem mit der Änderung verbundenen Risiko, der Größe des existierenden Systems und dem Um-
fang der Änderung. Wartungstests können in Abhängigkeit von Modifikationen in allen Teststufen und
für alle Testarten durchgeführt werden.
Die Ermittlung, inwiefern ein bestehendes System durch Modifikationen beeinflusst wird, nennt man
Auswirkungsanalyse. Sie wird verwendet, um zu entscheiden, wie viele Regressionstests durchzufüh-
ren sind. Die Auswirkungsanalyse kann benutzt werden, um eine Regressionstestsuite festzulegen.
Bei veralteten oder gar fehlenden Spezifikationen oder wenn keine Tester mit entsprechendem Fach-
wissen verfügbar sind, kann sich der Wartungstest sehr schwierig gestalten.
Referenzen
2 Linz, 2010
2.1.3 CMMI, 2004, Craig, 2002, Hetzel, 1988, IEEE 12207, 2008
2.2 Hetzel, 1988
2.2.4 Copeland, 2004, Myers 2001
2.3.1 Beizer, 1990, Black, 2001, Copeland, 2004
2.3.2 Black, 2001, ISO 9126-1, 2001
2.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 1988
2.3.4 Hetzel, 1988, IEEE STD 829 – 1998
2.4 Black, 2001, Craig, 2002, Hetzel, 1988, IEEE STD 829 – 1998