ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 1799
Скачиваний: 4
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 41/84
1.8.2011
© International Software Testing Qualifications Board
4.2 Kategorien von Testentwurfsverfahren (K2)
15 Minuten
Begriffe
Black-Box-Testentwurfsverfahren, erfahrungsbasierte Testentwurfsverfahren, Testentwurfsverfahren,
White-Box-Testentwurfsverfahren
Hintergrund
Das Ziel von Testentwurfsverfahren ist es, Testbedingungen, Testfälle und Testdaten zu ermitteln.
Ein klassischer Ansatz unterscheidet Testentwurfsverfahren in Black-Box- oder White-Box-Verfahren.
Black-Box-Verfahren (die auch spezifikationsorientierte Verfahren genannt werden) stellen einen Weg
dar, Testbedingungen, Testfälle oder Testdaten für eine Komponente oder ein System aufgrund der
Analyse der zugrunde liegenden Dokumentation der Testbasis abzuleiten und auszuwählen. Dies
umfasst funktionales und nicht-funktionales Testen. Black-Box-Testverfahren verwenden per Definiti-
on keine Informationen über die interne Struktur der Komponente oder des Systems, welches zu tes-
ten ist. White-Box-Verfahren (auch strukturelle oder strukturorientierte Verfahren) stützen sich auf eine
Analyse der Struktur einer Komponente oder eines Systems. Black-Box- und White-Box-Tests können
auch mit erfahrungsbasierten Testentwurfsverfahren kombiniert werden, um die Erfahrung der Ent-
wickler, Tester und Anwender bei der Festlegung, was getestet werden soll, wirksam einzusetzen.
Einige Verfahren lassen sich klar in eine dieser Kategorien einordnen; andere tragen Züge von mehr
als einer Kategorie.
Dieser Lehrplan bezeichnet spezifikationsorientierte Testentwurfsverfahren als Black-Box-Verfahren,
und strukturorientierte Testentwurfsverfahren als White-Box-Verfahren. Zusätzlich werden die erfah-
rungsbasierten Testentwurfsverfahren abgedeckt.
Gemeinsame Merkmale der spezifikationsorientierten Testentwurfsverfahren:
•
Modelle, ob formal oder nicht formal, werden zur Spezifikation des zu lösenden Problems, der
Software oder ihrer Komponente herangezogen.
•
Testfälle können systematisch von diesen Modellen abgeleitet werden.
Gemeinsame Merkmale der strukturorientierten Testentwurfsverfahren:
•
Informationen über den Aufbau der Software werden für die Ableitung von Testfällen verwen-
det, beispielsweise der Code und Informationen des Detailentwurfs (detailed design).
•
Der Überdeckungsgrad der Software kann für vorhandene Testfälle gemessen werden. Wei-
tere Testfälle können zur Erhöhung des Überdeckungsgrads systematisch abgeleitet werden.
Gemeinsame Merkmale der erfahrungsbasierten Testentwurfsverfahren:
•
Das Wissen und die Erfahrung von Menschen wird zur Ableitung der Testfälle genutzt.
•
Das Wissen von Testern, Entwicklern, Anwendern und Betroffenen über die Software, ihre
Verwendung und ihre Umgebung ist eine Informationsquelle.
•
Das Wissen über wahrscheinliche Fehlerzustände und ihre Verteilung ist eine weitere Infor-
mationsquelle.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 42/84
1.8.2011
© International Software Testing Qualifications Board
4.3 Spezifikationsorientierte oder Black-Box-
Verfahren (K3)
150 Minuten
Begriffe
Äquivalenzklassenbildung, anwendungsfallbasierter Test, Entscheidungstabellentest, Grenzwertana-
lyse, zustandsbasierter Test
4.3.1 Äquivalenzklassenbildung (K3)
Bei der Äquivalenzklassenbildung werden Eingabewerte für die Software oder das System in Gruppen
eingeteilt, bei denen man von einem ähnlichen Verhalten ausgeht, so dass es wahrscheinlich ist, dass
sie auf dieselbe Weise verarbeitet werden. Äquivalenzklassen können gleichermaßen für gültige Da-
ten – also Werte, die angenommen werden sollten – gebildet werden wie für ungültige Daten – also
Werte, die zurückgewiesen werden sollten. Die Äquivalenzklassen können außerdem für Ausgabe-
werte, interne Werte, zeitbezogene Werte (d.h. vor oder nach einem Ereignis) und für Schnitt-
stellenparameter (d.h. integrierte Komponenten, die beim Integrationstest getestet werden) gebildet
werden. Tests können so entworfen werden, dass alle gültigen und ungültigen Klassen abgedeckt
werden. Äquivalenzklassenbildung kann in allen Teststufen angewandt werden.
Das Ziel ist, durch Bildung von Äquivalenzklassen eine hohe Fehlerentdeckungswahrscheinlichkeit bei
minimaler Anzahl von Testfällen zu erreichen.
Äquivalenzklassenbildung kann eingesetzt werden, um Überdeckungsziele in Bezug auf Eingabe-
oder Ausgabewerte zu erreichen. Es kann auf Eingaben eines menschlichen Benutzers, auf Eingaben
an ein System über Schnittstellen oder im Integrationstest auf Schnittstellenparameter angewandt
werden.
4.3.2 Grenzwertanalyse (K3)
Da das Verhalten an der Grenze jeder Äquivalenzklasse mit einer höheren Wahrscheinlichkeit fehler-
haft ist als das Verhalten innerhalb der Klasse, sind solche Grenzen ein Bereich, in dem Testen wahr-
scheinlich Fehlerzustände aufdecken wird. Der größte und der kleinste Wert einer Klasse sind deren
Grenzwerte. Ein Grenzwert für eine gültige Klasse ist ein gültiger Grenzwert, die Grenze einer ungülti-
gen Klasse ist ein ungültiger Grenzwert. Tests können entworfen werden, um beides, sowohl gültige
als auch ungültige Grenzwerte abzudecken. Beim Entwurf von Testfällen wird ein Test für jeden
Grenzwert gewählt.
Grenzwertanalyse kann in allen Teststufen angewandt werden. Sie ist vergleichsweise einfach anzu-
wenden und das Potenzial, Fehlerzustände aufzudecken, ist hoch. Detaillierte Spezifikationen sind bei
der Bestimmung der interessanten Grenzen hilfreich.
Dieses Verfahren wird häufig als Erweiterung der Äquivalenzklassenbildung oder anderer Black-Box-
Testverfahren betrachtet. Es kann bei der Bildung von Äquivalenzklassen angewendet werden, glei-
chermaßen für Benutzereingaben am Bildschirm, beispielsweise bei Zeitspannen (z.B. Timeout,
Transaktionsgeschwindigkeitsanforderungen) oder Grenzen von Tabellenbereichen (z.B. Tabellen-
größe 256*256).
4.3.3 Entscheidungstabellentest (K3)
Entscheidungstabellen sind eine gute Möglichkeit, um Systemanforderungen zu erfassen, die logische
Bedingungen enthalten und um den internen Systementwurf zu dokumentieren. Sie können zur Erfas-
sung komplexer, von einem System umzusetzenden Regeln in Geschäftsprozessen verwendet wer-
den. Beim Erstellen einer Entscheidungstabelle wird die Spezifikation analysiert, und die Bedingungen
und Aktionen des Systems werden ermittelt.
Die Eingabebedingungen und Aktionen werden meist so festgesetzt, dass sie entweder „wahr“ oder
„falsch“ sein müssen (Boolesche Werte). Die Entscheidungstabelle enthält die auslösenden Bedin-
gungen, oft Kombinationen von „wahr“ und „falsch“ für alle Eingabebedingungen und die daraus resul-
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 43/84
1.8.2011
© International Software Testing Qualifications Board
tierenden Aktionen für jede Kombination der Bedingungen. Jede Spalte der Tabelle entspricht einer
Regel im Geschäftsprozess, die eine eindeutige Kombination der Bedingungen definiert, die wiederum
die Ausführung der mit dieser Regel verbundenen Aktionen nach sich zieht. Der üblicherweise bei
Entscheidungstabellentest verwendete Standardüberdeckungsgrad besagt, dass wenigstens ein Test-
fall pro Spalte in der Tabelle benötigt wird, was in der Regel die Abdeckung aller Kombinationen der
auslösenden Bedingungen umfasst.
Die Stärke des Entscheidungstabellentests ist, dass er Kombinationen von Bedingungen ableitet, die
andernfalls beim Test möglicherweise nicht ausgeführt worden wären. Er kann in allen Situationen
angewandt werden, in denen die Abläufe der Software von mehreren logischen Entscheidungen ab-
hängen.
4.3.4 Zustandsbasierter Test (K3)
Ein System kann in Abhängigkeit von aktuellen Gegebenheiten oder von seiner Vorgeschichte (sei-
nem Zustand) unterschiedliche Reaktionen zeigen. In diesem Fall kann dieser Aspekt des Systems
mit einem Zustandsdiagramm dargestellt werden. Es ermöglicht dem Tester, die Software darzustel-
len im Bezug auf ihre Zustände, Übergänge zwischen den Zuständen, Eingaben oder Ereignisse, die
die Zustandsübergänge (transitions) auslösen, und Aktionen, die aus den Übergängen folgen können.
Die Zustände des Systems oder Testobjekts sind einzeln unterscheidbar, eindeutig identifizierbar und
endlich in ihrer Anzahl.
Eine Zustandsübergangstabelle stellt den Zusammenhang zwischen Zuständen und Eingaben dar,
und kann mögliche ungültige Übergänge aufzeigen.
Tests können so gestaltet sein, dass sie jeden Zustand oder eine typische Sequenz von Zuständen
abdecken, jeden Übergang oder bestimmte Sequenzen von Übergängen ausführen, oder dass sie
ungültige Übergänge überprüfen.
Zustandsbasierte Tests werden häufig in Branchen der eingebetteten Software (embedded software)
und generell in der Automatisierungstechnik eingesetzt. Davon abgesehen ist dieses Verfahren ge-
nauso gut einsetzbar für die Modellierung von Geschäftsobjekten, die verschiedene Zustände besit-
zen, oder zum Test von dialogbasierten Abläufen (z.B. für Internet-Anwendungen oder Geschäftssze-
narios).
4.3.5 Anwendungsfallbasierter Test (K2)
Tests können aus Anwendungsfällen (use cases) abgeleitet werden. Ein Anwendungsfall beschreibt
die Interaktionen zwischen den Aktoren (Anwender oder Systeme), die ein aus Sicht des Anwenders
oder Kunden gewünschtes und wahrnehmbares Ergebnis zur Folge haben. Anwendungsfälle können
auf einer abstrakten Ebene (fachlicher Anwendungsvorfall, technologiefrei, Geschäftsprozessebene)
oder auf einer Systemebene (Systemanwendungsfall auf Ebene der Systemfunktionalität) beschrieben
werden. Jeder Anwendungsfall hat Vorbedingungen, die erfüllt sein müssen, damit der Anwendungs-
fall erfolgreich durchgeführt werden kann. Jeder Anwendungsfall endet mit Nachbedingungen, den
beobachtbaren Ergebnissen und dem Endzustand des Systems, wenn der Anwendungsfall vollständig
abgewickelt wurde. Ein Anwendungsfall hat üblicherweise ein Hauptszenario (das wahrscheinlichste
Szenario) und alternative Szenarien.
Anwendungsfälle beschreiben die „Prozessabläufe” durch das System auf Grundlage seiner voraus-
sichtlich tatsächlichen Verwendung. Daher sind von Anwendungsfällen abgeleitete Testfälle bestens
geeignet, während des Praxiseinsatzes des Systems Fehlerzustände in den Prozessabläufen aufzu-
decken. Anwendungsfälle sind für den Entwurf von Abnahmetests mit Kunden-/Anwenderbeteiligung
sehr hilfreich. Indem das Zusammenwirken und die gegenseitige Beeinflussung unterschiedlicher
Komponenten betrachtet werden, können sie auch Fehlerzustände im Umfeld der Integration aufde-
cken, die durch den Test der einzelnen Komponenten nicht gefunden werden könnten. Das Entwerfen
von Testfällen auf Basis von Anwendungsfällen kann mit anderen spezifikationsorientierten Testent-
wurfsverfahren kombiniert werden.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 44/84
1.8.2011
© International Software Testing Qualifications Board
4.4 Strukturorientierter Test oder White-Box-
Verfahren (K4)
60 Minuten
Begriffe
Anweisungsüberdeckung, Codeüberdeckung, Entscheidungsüberdeckung, strukturorientierter Test .
Hintergrund
Der strukturorientierte oder White-Box-Test baut auf der vorgefundenen Struktur der Software oder
des Systems auf, wie aus folgenden Beispielen ersichtlich ist:
•
Komponentenebene: Die Struktur der Softwarekomponente, d.h. Anweisungen, Entscheidun-
gen, Zweige oder sogar einzelne Pfade
•
Integrationsebene: Die Struktur kann ein Aufrufgraph sein (ein Diagramm, das zeigt, welche
Module andere Module aufrufen)
•
Systemebene: Die Struktur kann die Menüstruktur sein, Geschäftsprozesse oder die Struktur
einer Webseite
In diesem Abschnitt werden drei codebezogene, strukturorientierte Testentwurfsverfahren für Code-
überdeckung vorgestellt, bezogen auf Anweisungen, Zweige und Entscheidungen. Für Entschei-
dungstest können Kontrollflussgraphen zur Darstellung der Alternativen für jede Entscheidung heran-
gezogen werden.
4.4.1 Anweisungstest und -überdeckung (K4)
Im Komponententest steht Anweisungsüberdeckung für die Messung des prozentualen Anteils von
allen Anweisungen einer Komponente, welche durch eine Testsuite ausgeführt wurden. Das Anwei-
sungstestverfahren leitet Testfälle so ab, dass bestimmte Anweisungen ausgeführt werden, in der
Regel mit dem Ziel die Anweisungsüberdeckung zu erhöhen.
Anweisungsüberdeckung ist bestimmt durch die Anzahl ausführbarer Anweisungen, die durch entwor-
fene oder ausgeführte Testfälle überdeckt sind, dividiert durch die Anzahl aller ausführbaren Anwei-
sungen des Programmcodes im Test.
4.4.2 Entscheidungstest und -überdeckung (K4)
Die Entscheidungsüberdeckung, die mit dem Zweigtest verwandt ist, ist die Messung des prozentua-
len Anteils eines Entscheidungsergebnisses (z.B. „wahr“ und „falsch“ bei einer IF-Anweisung), welche
durch eine Testsuite ausgeführt wurden. Beim Entscheidungstestverfahren werden Testfälle abge-
leitet, um spezifische Entscheidungen zu durchlaufen. Zweige nehmen ihren Anfang in Entschei-
dungspunkten des Programmcodes und zeigen die Übertragung der Steuerung zu verschiedenen
Stellen im Code.
Die Entscheidungsüberdeckung ist bestimmt durch die Anzahl aller Entscheidungsausgänge, die
durch entworfene oder ausgeführte Testfälle überdeckt sind, dividiert durch die Anzahl aller Entschei-
dungsausgänge des Programmcodes im Test.
Der Entscheidungstest ist eine Form des kontrollflussbasierten Tests, da er einem speziellen Kontroll-
fluss durch die Entscheidungspunkte folgt. Entscheidungsüberdeckung ist stärker als Anweisungs-
überdeckung: 100% Entscheidungsüberdeckung schließt 100% Anweisungsüberdeckung ein, aber
nicht umgekehrt.
4.4.3 Andere strukturorientierte Verfahren (K1)
Über Entscheidungsüberdeckung hinaus gibt es stärkere strukturelle Überdeckungsgrade, beispiels-
weise Bedingungsüberdeckung und Mehrfachbedingungsüberdeckung.
Das Konzept der Überdeckungsgrade kann auch auf andere Teststufen übertragen werden. Bei-
spielsweise wird auf der Integrationsebene der prozentuale Anteil von Modulen, Komponenten oder
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 45/84
1.8.2011
© International Software Testing Qualifications Board
Klassen, die durch eine Testsuite ausgeführt wurden, als Modul-, Komponenten- oder Klassen-
Überdeckung bezeichnet.
Werkzeugunterstützung ist beim strukturorientierten Test von Code sehr hilfreich.