ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 1797
Скачиваний: 4
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 36/84
1.8.2011
© International Software Testing Qualifications Board
•
Das Review wird in einer Atmosphäre des Vertrauens durchgeführt, das Ergebnis dient nicht
zur Beurteilung der Teilnehmer.
•
Es werden die Reviewtechniken angewendet, die zur Erreichung der Reviewziele, für Art und
Stufe von Arbeitsergebnissen der Softwareentwicklung und für die Gutachter geeignet sind.
•
Wenn sie geeignet sind, die Effektivität der Fehleridentifikation zu steigern, werden Checklis-
ten oder Rollen verwendet.
•
Es finden Schulungen in Reviewtechniken statt, besonders für die formaleren Methoden wie
Inspektionen.
•
Das Management unterstützt einen guten Reviewprozess, indem es beispielsweise angemes-
sene Zeit für Reviewaktivitäten im Projektplan einräumt.
•
Es liegt eine Betonung auf Lernen und Prozessverbesserung.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 37/84
1.8.2011
© International Software Testing Qualifications Board
3.3 Werkzeuggestützte statische Analyse (K2)
20 Minuten
Begriffe
Compiler, Datenfluss, Komplexität, Kontrollfluss, statische Analyse
Hintergrund
Das Ziel der statischen Analyse ist es, Fehlerzustände in Softwarequellcode und in den Softwaremo-
dellen zu finden. Statische Analyse wird durchgeführt, ohne dass die untersuchte Software tatsächlich
durch das Werkzeug ausgeführt wird; dynamischer Test führt Softwarecode aus. Statische Analyse
kann Fehlerzustände lokalisieren, die durch dynamisches Testen schwer zu finden sind. Ebenso wie
Reviews findet die statische Analyse Fehlerzustände eher als Fehlerwirkungen. Statische Analyse-
werkzeuge analysieren Programmcode (z.B. Kontrollfluss und Datenfluss), ebenso wie generierte
HTML- und XML-Ausgaben.
Vorteile der statischen Analyse:
•
frühes Erkennen von Fehlerzuständen vor der Testdurchführung
•
frühe Warnung vor verdächtigen Aspekten in Code oder Design wie hohes Komplexitätsmaß
durch Berechnen von Metriken
•
Identifizieren von Fehlerzuständen, die durch dynamischen Test nicht effektiv und effizient
aufzudecken sind
•
Aufdecken von Abhängigkeiten und Inkonsistenzen in Softwaremodellen, beispielsweise tote
Links
•
verbesserte Wartbarkeit von Code und Design
•
Vorbeugen von Fehlerzuständen, wenn sich das aus Erfahrung Gelernte in der Entwicklung
niederschlägt
Typische Fehlerzustände, die durch eine werkzeuggestützte statische Analyse gefunden werden kön-
nen:
•
Referenzierung einer Variablen mit nicht definiertem Wert
•
inkonsistente Schnittstellen zwischen Modulen und Komponenten
•
Variablen, die nicht verwendet oder nicht korrekt deklariert werden
•
unerreichbarer (toter) Code
•
fehlende oder falsche Logik (mögliche Endlosschleifen)
•
übermäßig komplizierte Konstrukte
•
Verletzung von Programmierkonventionen
•
Sicherheitsschwachstellen
•
Syntax-Verletzungen von Code und Softwaremodellen
Werkzeuge für statische Analysen werden typischerweise entwicklungsbegleitend und vor Komponen-
ten- und Integrationstests oder beim Einchecken von Code in Konfigurationsmanagementwerkzeuge
genutzt (Prüfen gegen vordefinierte Regeln oder Programmierstandards), und durch Designer wäh-
rend der Softwaremodellierung. Werkzeuge für statische Analysen können große Mengen von War-
nungen und Hinweisen erzeugen, die gut verwaltet werden müssen, um eine effektive Nutzung des
Werkzeugs zu erlauben.
Compiler können auch eine gute Unterstützung für eine statische Analyse bieten, u.a. durch Berech-
nen von Metriken.
Referenzen
3 Linz, 2010
3.2 IEEE 1028-2008
3.2.2 Gilb, 1993, van Veenendaal, 2004
3.2.4 Gilb, 1993, IEEE 1028
3.3 van Veenendaal, 2004
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 38/84
1.8.2011
© International Software Testing Qualifications Board
4 Testentwurfsverfahren (K4)
285 Minuten
Lernziele für den Abschnitt Testentwurfsverfahren
Die Lernziele legen fest, was Sie nach Beenden des jeweiligen Moduls gelernt haben sollten.
4.1 Der Testentwicklungsprozess (K3)
LO-4.1.1 Unterscheiden können, zwischen Testentwurfsspezifikation, Testfallspezifikation und Test-
ablaufspezifikation. (K2)
LO-4.1.2 Begriffe Testbedingung, Testfall und Testablauf gegenüberstellen können. (K2)
LO-4.1.3 Qualität von Testfällen bewerten können, bezüglich:
o
eindeutige Rückverfolgbarkeit zu den Anforderungen
o
Sollverhalten (K2)
LO-4.1.4 Testfälle in eine wohlstrukturierte Testablaufspezifikation übersetzen können – mit einem
Detaillierungsgrad, der den Vorkenntnissen der Tester angepasst ist. (K3)
4.2 Kategorien von Testentwurfsverfahren (K2)
LO-4.2.1 Gründe wiedergeben können, dass sowohl spezifikationsorientierte (Black-Box) als auc h
strukturorientierte (White-Box) Testentwurfstechniken von Nutzen sind, und für beides
gängige Verfahren aufzählen können. (K1)
LO-4.2.2 Eigenschaften, Gemeinsamkeiten und Unterschiede zwischen spezifikationsorientiertem
Testen, strukturorientiertem Testen und erfahrungsbasiertem Testen erklären können. (K2)
4.3 Spezifikationsorientierte oder Black-Box-Verfahren (K3)
LO-4.3.1 Testfälle anhand unterschiedlicher Softwaremodelle schreiben können, unter Verwendung
von Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellen und Zustands-
übergangsdiagrammen und –tabellen. (K3)
LO-4.3.2 Hauptziele der fünf Testverfahren erklären können, auf welchen Ebenen und in welchem
Testumfeld das Verfahren eingesetzt und wie jeweils der Überdeckungsgrad gemesse n
werden kann. (K2)
LO-4.3.3 Das Konzept der anwendungsfallbasierten (use case) Tests und der damit verbundene n
Vorteile erklären können. (K2)
4.4 Strukturorientierte oder White-Box-Verfahren (K4)
LO-4.4.1 Das Konzept und den Wert von Codeüberdeckung beschreiben können. (K2)
LO-4.4.2 Die Konzepte von Anweisungs- und Entscheidungsüberdeckung erklären können und
Gründe nennen können, warum diese Überdeckungsmaße auch auf anderen Teststufen
als im Komponententest eingesetzt werden können (z.B. bei Geschäftsprozessen auf Sys-
temebene). (K2)
LO-4.4.3 Testfälle zu vorgegebenen Kontrollflüssen schreiben können unter Verwendung von An-
weisungs- und Entscheidungsüberdeckungsverfahren. (K3)
LO-4.4.4 Vollständigkeit von Anweisungs- und Entscheidungsüberdeckung in Bezug auf definierte
Ausgangskriterien überprüfen können. (K4)
4.5 Erfahrungsbasierte Verfahren (K2)
LO-4.5.1 Gründe wiedergeben können, warum Testfälle auf der Grundlage von Intuition, Erfahrung
und Wissen über typische Fehlerzustände geschrieben werden sollten. (K1)
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 39/84
1.8.2011
© International Software Testing Qualifications Board
LO-4.5.2 Erfahrungsbasierte Verfahren mit spezifikationsorientierten Testverfahren vergleichen kön-
nen. (K2)
4.6 Auswahl von Testverfahren (K2)
LO-4.6.1 Testentwurfsverfahren in einem vorgegebenen Zusammenhang gemäß ihrer Tauglichkeit,
für die Testbasis und bezüglich Modellen und Softwaremerkmalen klassifizieren können.
(K2)
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 40/84
1.8.2011
© International Software Testing Qualifications Board
4.1 Der Testentwicklungsprozess (K3)
15 Minuten
Begriffe
Rückverfolgbarkeit, Testablaufspezifikation, Testausführungsplan, Testentwurf, Testfallspezifikation,
Testskript
Hintergrund
Der Testentwicklungsprozess, der in diesem Kapitel beschrieben wird, kann auf verschiedene Weise
durchgeführt werden, von sehr informell – mit wenig oder keiner Dokumentation – bis sehr formal (wie
in diesem Abschnitt weiter unten beschrieben). Der Grad der Formalisierung hängt vom Kontext des
Testens ab, einschließlich der Reife des Testprozesses und des Entwicklungsprozesses, zeitlicher
Beschränkungen, Sicherheits- oder regulatorischer Anforderungen und der einbezogenen Personen.
Während der Testanalyse werden die dem Test zugrunde liegenden Dokumente analysiert, um fest-
zustellen, was getestet werden muss, d.h. die Testbedingungen festzulegen. Eine Testbedingung ist
definiert als eine Einheit oder ein Ereignis, z.B. eine Funktion, eine Transaktion, ein Qualitätsmerkmal
oder ein strukturelles Element, das durch einen oder mehrere Testfälle verifiziert werden kann.
Indem Testbedingungen auf Spezifikationen und Anforderungen zurückgeführt werden, erlauben sie
sowohl eine effektive Auswirkungsanalyse (impact analysis) bei geänderten Anforderungen als auch
die Bestimmung einer Anforderungsüberdeckung, bezogen auf eine bestimmte Menge von Tests.
Während der Testanalyse wird eine detaillierte Testvorgehensweise – neben anderen Gesichtspunk-
ten – auf Grundlage von den festgestellten Risiken angewendet, um benötigte Testentwurfsverfahren
auszuwählen (siehe Kapitel 5 zum Thema Risikoanalyse).
Während des Testentwurfs werden die Testfälle und Testdaten definiert und dokumentiert. Ein Testfall
besteht aus einer Menge von Eingabewerten, den für die Ausführung notwendigen Vorbedingungen,
der Menge der vorausgesagten Ergebnisse und den erwarteten Nachbedingungen, definiert mit dem
Ziel, ein oder mehrere Testziele oder Testbedingungen abzudecken. Der IEEE Standard 829-1998
(‘Standard for Software Test Documentation’) beschreibt die Inhalte von Testentwurfsspezifikationen
(inkl. Testbedingungen) und Testfallspezifikationen.
Erwartete Ergebnisse sollten im Rahmen der Spezifikation eines Testfalls ermittelt werden, und Aus-
gaben, Änderungen von Daten und Zuständen sowie alle anderen Folgen des Tests enthalten. Falls
die erwarteten Ergebnisse nicht definiert wurden, könnte ein plausibles, aber fehlerhaftes Ergebnis
fälschlicherweise als richtig angesehen werden. Erwartete Ergebnisse sollten idealerweise vor der
Testdurchführung festgelegt werden.
Während der Testimplementierung werden die Testfälle entwickelt, implementiert, priorisiert und in
einer Testablaufspezifikation (Drehbuch oder Testskript) zusammengefasst (IEEE STD 829-1998).
Das Testdrehbuch legt die Reihenfolge der Aktionen für die Ausführung eines Tests fest. Wenn Tests
unter Verwendung eines Testausführungswerkzeugs durchgeführt werden, ist die Reihenfolge der
Aktionen in einem Testskript festgelegt (in einem automatisierten Testszenario).
Die verschiedenen manuellen und automatisierten Testskripte werden anschließend in einem Test-
ausführungsplan zusammengestellt, der die Reihenfolge festlegt, in der die verschiedenen Testszena-
rios (und gegebenenfalls die automatisierten Testskripte) ausgeführt werden. Der Testausführungs-
plan berücksichtigt Faktoren wie Regressionstests, Priorisierung und logische Abhängigkeiten.