Übungsaufgaben zu Kapitel 2

2.1 Definieren Sie die Begriffe Fehlerwirkung, Fehlerzustand, Fehlhandlung. Antwort

2.2 Was ist Fehlermaskierung? Antwort

2.3 Erläutern Sie den Unterschied zwischen Testen und Debugging. Antwort

2.4 Erläutern Sie, warum jeder Test eine stichprobenartige Prüfung ist. Antwort

2.5 Nennen Sie die Hauptmerkmale der Softwarequalität nach ISO 9126. Antwort

2.6 Definieren Sie den Begriff Zuverlässigkeit eines Systems. Antwort

2.7 Erläutern Sie die Phasen des fundamentalen Testprozesses. Antwort

2.8 Was ist ein Testorakel? Antwort

2.9 Warum sollte ein Entwickler nicht seine eigenen Programme testen? Antwort

zu allen Lösungen von Kapitel 2

Übungsaufgaben zu Kapitel 3

3.1 Erläutern Sie die einzelnen Phasen des allgemeinen V-Modells. Antwort

3.2 Definieren Sie die Begriffe Verifikation und Validierung. Antwort

3.3 Begründen Sie, warum Verifikation sinnvoll ist, auch wenn eine sorgfältige Validierung stattfindet (und umgekehrt). Antwort

3.4 Charakterisieren Sie die typischen Testobjekte im Komponententest. Antwort

3.5 Nennen Sie die Testziele des Integrationstests. Antwort

3.6 Welche Integrationsstrategien lassen sich unterscheiden? Antwort

3.7 Welche Gründe sprechen dafür, Tests in einer separaten Testumgebung durchzuführen? Antwort

3.8 Erläutern Sie anforderungsbasiertes Testen. Antwort

3.9 Definieren Sie Lasttest, Performanztest, Stresstest. Was sind die Unterscheidungsmerkmale? Antwort

3.10 Worin unterscheiden sich Fehlernachtest und Regressionstest? Antwort

3.11 In welcher Projektphase nach allgemeinem V-Modell sollte das Testkonzept erstellt werden? Antwort

zu allen Lösungen von Kapitel 3

Übungsaufgaben zu Kapitel 4

4.1 Beschreiben Sie die grundlegenden Schritte die bei einem Review durchzuführen sind. Antwort

4.2 Welche Reviewarten werden unterschieden? Antwort

4.3 Welche Rollen wirken an einem technischen Review mit? Antwort

4.4 Warum sind Reviews ein effizientes Mittel zur Qualitätssicherung? Antwort

4.5 Erklären Sie den Begriff statische Analyse. Antwort

4.6 Wie stehen statische Analyse und Reviews in Zusammenhang? Antwort

4.7 Warum kann statische Analyse nicht alle in einem Programm enthaltenen Fehlerzustände aufdecken? Antwort

4.8 Welche Arten von Datenflussanomalien werden unterschieden? Antwort

zu allen Lösungen von Kapitel 4

Übungsaufgaben zu Kapitel 5

5.1 Was ist ein dynamischer Test? Antwort

5.2 Wozu dient ein Testrahmen? Antwort

5.3 Wodurch unterscheiden sich Black-Box- und White-Box-Testverfahren? Antwort

5.4 Erklären Sie das Verfahren der Äquivalenzklassenbildung. Antwort

5.5 Was ist ein Repräsentant? Antwort

5.6 Wie ist das Testendekriterium Äquivalenzklassenüberdeckung definiert? Antwort

5.7 Warum ist die Grenzwertanalyse eine gute Ergänzung zur Äquivalenzklassenbildung? Antwort

5.8 Nennen Sie weitere Black-Box-Verfahren. Antwort

5.9 Erläutern Sie den Begriff Anweisungsüberdeckung. Antwort

5.10 Worin unterscheiden sich Anweisungs- und Zweigüberdeckung? Antwort

5.11 Wozu dient eine Instrumentierung? Antwort

zu allen Lösungen von Kapitel 5

Übungsaufgaben zu Kapitel 6

6.1 Welche grundsätzlichen Modelle einer Aufgabenteilung zwischen Entwicklung und Test lassen sich unterscheiden? Antwort

6.2 Welche Rollen sind beim Testen auszufüllen und mit speziell qualifizierten Mitarbeitern zu besetzen? Antwort

6.3 Welche Aufgaben hat der Testmanager? Antwort

6.4 Welche Arten von Metriken zur Überwachung des Testfortschritts lassen sich unterscheiden? Antwort

6.5 Welche Informationen sollte ein Teststatusbericht enthalten? Antwort

6.6 Welche Daten sollte eine Fehlermeldung enthalten? Antwort

6.7 Was ist der Unterschied zwischen Fehlerpriorität und Fehlerklasse? Antwort

6.8 Wozu wird ein Fehlerstatusmodell benötigt? Antwort

6.9 Welche Aufgabe hat ein Änderungskontrollausschuss? Antwort

6.10 Welche Anforderungen aus Sicht des Tests stellen sich an das Konfigurationsmanagement? Antwort

6.11 Welche grundsätzlichen Arten von Normen und Standards lassen sich unterscheiden? Antwort

zu allen Lösungen von Kapitel 6

Übungsaufgaben zu Kapitel 7

7.1 Welche grundlegenden Funktionen bieten Testplanungswerkzeuge? Antwort

7.2 Welche Typen von Testdatengeneratoren werden unterschieden? Antwort

7.3 Welcher Typ von Testdatengenerator kann auch Sollwerte generieren? Warum können die anderen Typen das nicht? Antwort

7.4 Erläutern Sie die prinzipielle Funktionsweise eines Capture&Replay-Tools. Antwort

7.5 Aus welchen Schritten besteht der Prozess zur Auswahl eines Testwerkzeugs? Antwort

7.6 Welche Schritte sind bei der Werkzeugeinführung zu beachten? Antwort

zu allen Lösungen von Kapitel 7

Antworten zu den Übungsaufgaben

Antworten zu den Übungsaufgaben zu Kapitel 2

2.1 Definieren Sie die Begriffe Fehlerwirkung, Fehlerzustand, Fehlhandlung.

Fehlerwirkung (failure)
1. Wirkung eines Fehlerzustandes, die bei der Ausführung des Testobjekts nach "außen" in Erscheinung tritt.
2. Abweichung zwischen (spezifiziertem) Sollwert und (beobachtetem) Istwert (bzw. Soll- und Ist-Verhalten).

Fehlerzustand (fault)
1. Inkorrektes Teilprogramm, inkorrekte Anweisung oder Datendefinition, die Ursache für einen äußeren Fehler ist.
2. Zustand eines (Software)produktes oder einer seiner Komponenten, der unter spezifischen Bedingungen (z.B. bei einer hohen Belastung) eine geforderte Funktion des Produkts beeinträchtigen kann, bzw. zu einer Fehlerwirkung führt.

Fehlhandlung (error)
1. Die menschliche Handlung (des Entwicklers), die zu einem Fehlerzustand in der Software führt.
2. Eine menschliche Handlung (des Anwenders), die ein unerwünschtes Ergebnis (im Sinne von Fehlerwirkung) zur Folge hat (Fehlbedienung).
3. Unwissentlich, versehentlich oder absichtlich ausgeführte Handlung oder Unterlassung, die unter gegebenen Umständen (Aufgabenstellung, Umfeld) dazu führt, dass eine geforderte Funktion eines Produktes beeinträchtigt ist.

(s.a. Kap. 2.1.1 Fehlerbegriff)

zurück zur Frage

2.2 Was ist Fehlermaskierung?

Ein vorhandener Fehlerzustand wird durch einen oder mehrere andere Fehlerzustände in anderen Teilen des Testobjekts kompensiert, so dass dieser Fehlerzustand keine Fehlerwirkung hervorruft

(s.a. Kap. 2.1.1 Fehlerbegriff)

zurück zur Frage

2.3 Erläutern Sie den Unterschied zwischen Testen und Debugging.

Testen dient dem Nachweis der korrekten Umsetzung der Anforderungen und der Aufdeckung von Fehlerwirkungen. Debugging dient der Lokalisierung der Ursache der Fehlerwirkung, der Fehlerzustand wird ermittelt. Das Debugging wird in der Regel von den Entwicklern durchgeführt.

(s.a. Kap. 2.1.2 Testbegriff)

zurück zur Frage

2.4 Erläutern Sie, warum jeder Test eine stichprobenartige Prüfung ist.

Beim dynamischen Test wird das Testobjekt mit Eingabedaten versehen und zur Ausführung gebracht. Aussagen lassen sich nur bezüglich der durchgeführten Testfälle treffen. Ein vollständiges Testen mit allen möglichen Testdaten und Kombinationen ist praktisch nicht durchführbar. Jeder Test ist somit eine Stichprobe. Diese Stichproben sollen gewählt werden, dass das Spektrum der Eingaben möglichst umfassend berücksichtigt wird. Testintensität und -umfang sollen in Abhängigkeit vom erwarteten Risiko im Fehlerfall festgelegt werden.

(s.a. Kap. 2.1.4 Testaufwand)

zurück zur Frage

2.5 Nennen Sie die Hauptmerkmale der Softwarequalität nach ISO 9126.

Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit.

(s.a. Kap. 2.1.3 Softwarequalität)

zurück zur Frage

2.6 Definieren Sie den Begriff Zuverlässigkeit eines Systems.

Zuverlässigkeit beschreibt die Gesamtheit der Eigenschaften eines Systems, die sich auf die Eignung zur Erfüllung gegebener Erfordernisse unter gegebenen Bedingungen für ein gegebenes Zeitintervall beziehen.

(s. a. Kap. 2.1.3 Softwarequalität)

zurück zur Frage

2.7 Erläutern Sie die Phasen des fundamentalen Testprozesses.

Die Phasen des fundamentalen Testprozesses sind:
a) Testplanung
b) Testspezifikation
c) Testdurchführung
d) Testprotokollierung
e) Auswertung und Bewertung des Testendes

a) Testplanung
umfasst folgende Aktivitäten
- Planung von Umfang und Vorgehensweise beim Test, Planung der Ressourcen (Mitarbeiter, Hilfsmittel, Hard- und Software, …) und der zeitlichen Festlegung der intendierten Tests, dokumentiert im Testkonzept.
- Festlegung der Teststrategie und der Überdeckungsgrade der einzusetzenden Testmethoden
- Priorisierung der Tests
- ggf. Auswahl und Beschaffung von benötigten Werkzeugen

(s. a. Kap. 2.2.1 Testplanung)

b) Testspezifikation
Spezifikation der logischen und konkreten Testfälle.

(s.a. Kap. 2.2.2 Testspezifikation)

c) Testdurchführung
Nach der Prüfung der prinzipiellen Start- und Ablauffähigkeit der Testobjekts (ggf. in einem Testrahmen) werden die Hauptfunktionen getestet. Wenn keine gravierenden Fehler auftreten werden danach die spezifizierten Testfälle durchgeführt.

(s.a. Kap. 2.2.3 Testdurchführung)

d) Testprotokollierung
Exakte und vollständige Protokollierung der durchgeführten Testfälle. Aus dem Protokoll muss hervorgehen, welche Teile wann, von wem, wie intensiv und mit welchem Ergebnis getestet wurden.

(s.a. Kap. 2.2.4 Testprotokollierung)

c) Auswertung und Bewertung des Testendes
umfasst folgende Aktivitäten
- Feststellung, ob eine Fehlerwirkung vorliegt oder die Fehlerursache in einer ungenauen Testspezifikation, einer fehlerhaften Testinfrastruktur, einem fehlerhaften Testlauf liegt.
- Ist ein Fehler erkannt, ist die Fehlerklasse festzulegen und damit die Priorität der Fehlerbehebung.
- Es ist zu ermitteln, ob das Überdeckungskriterium erfüllt ist.
- Ggf. sind weitere Testendekriterien heranzuziehen.

(s.a. Kap. 2.2.5 Auswertung und Bewertung des Testendes)

zurück zur Frage

2.8 Was ist ein Testorakel?

Informationsquelle zur Ermittlung der jeweiligen Sollergebnisse eines Testfalls (kann beispielsweise die Anforderungsdefinition sein).

(s. a. Kap. 2.3 Sollwerte und Testorakel)

zurück zur Frage

2.9 Warum sollte ein Entwickler nicht seine eigenen Programme testen?

Weil der Entwickler "blind" gegenüber seinen eigenen Fehlern ist, er dem eigenen Produkt gegenüber nicht kritisch genug ist und meist auch Test-Fachwissen nicht in ausreichendem Maß vorhanden ist.

zurück zur Frage

Antworten zu den Übungsaufgaben zu Kapitel 3

3.1 Erläutern Sie die einzelnen Phasen des allgemeinen V-Modells.

Die Phasen des allgemeinen V-Modells sind:

a) Anforderungsdefinition
Wünsche und Anforderungen des Auftraggebers oder späteren Systemanwenders werden gesammelt, spezifiziert und verabschiedet. Zweck und gewünschte Leistungsmerkmale des zu erstellenden Softwaresystems liegen damit fest.

(s.a. Kap. 3.1 Das allgemeine V-Modell)

b) funktionaler Systementwurf
Abbildung aller Anforderungen auf Funktionen und Dialogabläufe.

(s.a. Kap. 3.1 Das allgemeine V-Modell)

c) technischer Systementwurf
Definition der Schnittstellen zur Systemumwelt und die Zerlegung des Systems in überschaubarere Teilsysteme (Systemarchitektur) die möglichst unabhängig voneinander entwickelt werden können.

(s.a. Kap. 3.1 Das allgemeine V-Modell)

d) Komponentenspezifikation
Definition der Aufgabe, Verhalten, innerer Aufbau einer jeden Komponente und deren Schnittstellen zu anderen Komponenten bzw. Teilsystemen.

(s.a. Kap. 3.1 Das allgemeine V-Modell)

e) Programmierung
Programmierung jedes spezifizierten Bausteins in einer Programmiersprache.

(s.a. Kap. 3.1 Das allgemeine V-Modell)

f) Komponententest
Prüfung, ob jede Komponente für sich den Vorgaben seiner Spezifikation entspricht.

(s.a. Kap. 3.2 Komponententest)

g) Integrationstest
Prüfung, ob Gruppen von Komponenten, wie sie im technischen Systementwurf vorgesehen sind, zusammen spielen.

(s.a. Kap. 3.3 Integrationstest)

h) Systemtest
Prüfung ob das implementierte System den spezifizierten Anforderungen entspricht.

(s.a. Kap. 3.4 Systemtest)

i) Abnahmetest
Prüfung, ob das System aus Kundensicht die vertraglich vereinbarten Leistungsmerkmale aufweist.

(s.a. Kap. 3.5 Abnahmetest)

zurück zur Frage

3.2 Definieren Sie die Begriffe Verifikation und Validierung.

Verifikation:
1. Prüfung, ob die Ergebnisse einer Entwicklungsphase die Vorgaben der Phaseneingangsdokumente erfüllen.
2. Mathematisch formaler Beweis der Korrektheit eines Programm(teil)s.

Validierung:
Prüfung, ob ein Entwicklungsergebnis die individuellen Anforderungen bezüglich einer speziellen beabsichtigten Nutzung erfüllt.

(s.a. Kap. 3.1 Das allgemeine V-Modell)

zurück zur Frage

3.3 Begründen Sie, warum Verifikation sinnvoll ist, auch wenn eine sorgfältige Validierung stattfindet (und umgekehrt).

Beim Validieren bewertet der Tester, ob ein (Teil-)Produkt eine festgelegte (spezifizierte) Aufgabe tatsächlich löst und deshalb für seinen Einsatzzweck tauglich bzw. nützlich ist. Mit diesen Tests wird aber nicht sichergestellt, dass die Spezifikationen korrekt umgesetzt wurden. Dazu sind zusätzliche Verifikationstests notwendig.

Verifikation ist im Gegensatz zur Validierung auf eine einzelne Entwicklungsphase bezogen und soll die Korrektheit und Vollständigkeit eines Phasenergebnisses relativ zu seiner direkten Spezifikation (Phaseneingangsdokumente) nachweisen. Mit diesen Tests wird aber nicht sichergestellt, dass das Produkt im Kontext der beabsichtigten Produktnutzung sinnvoll ist. Dazu sind zusätzliche Validierungstests notwendig.

(s.a. Kap. 3.1 Das allgemeine V-Modell)

zurück zur Frage

3.4 Charakterisieren Sie die typischen Testobjekte im Komponententest.

Kennzeichnend für den Komponententest ist, dass jeweils ein einzelner Softwarebaustein überprüft wird, und zwar isoliert von anderen Softwarebausteinen des Systems. Die Isolierung hat dabei den Zweck, komponentenexterne Einflüsse beim Test auszuschließen. Deckt der Test eine Fehlerwirkung auf, lässt sich deren Ursache dann klar der getesteten Komponente zuordnen (es sei denn, die Fehlerursache liegt im Testrahmen oder in einem fehlerhaften Testfall).

(s.a. Kap. 3.2.2 Testobjekte)

zurück zur Frage

3.5 Nennen Sie die Testziele des Integrationstests.

a) Schnittstellenfehler aufdecken
Probleme können schon beim Versuch der Integration zweier Bausteine auftreten, wenn diese sich nicht zusammenbinden lassen, weil ihre Schnittstellenformate nicht passen, weil einige Dateien fehlen oder die Entwickler das System in ganz andere Komponenten aufgeteilt haben, als spezifiziert war.

b) Fehlerzustände im Datenaustausch bzw. in der Kommunikation zwischen den Komponenten aufdecken
Eine Komponente übermittelt keine oder syntaktisch falsche Daten, so dass die empfangende Komponente nicht arbeiten kann oder abstürzt (funktionaler Fehler einer Komponente, inkompatible Schnittstellenformate, Protokollfehler). Die Kommunikation funktioniert, aber die beteiligten Komponenten interpretieren übergebene Daten unterschiedlich (funktionaler Fehler einer Komponente, widersprüchliche oder fehlerhaft interpretierte Spezifikationen). Die Daten werden richtig übergeben, aber zum falschen oder verspäteten Zeitpunkt (Timing-Problem) oder in zu kurzen Zeitintervallen (Durchsatz- oder Lastproblem).

(s.a. Kap.

zurück zur Frage

3.6 Welche Integrationsstrategien lassen sich unterscheiden?

a) Top-down-Integration
Der Test beginnt mit der Komponente des Systems, die weitere Komponenten aufruft, aber selbst (außer vom Betriebssystem) nicht aufgerufen wird. Die untergeordneten Komponenten sind dabei durch Platzhalter ersetzt. Sukzessive werden die Komponenten niedrigerer Systemschichten hinzu integriert. Die getestete höhere Schicht dient dabei jeweils als Testtreiber.

b) Bottom-up-Integration
Der Test beginnt mit den elementaren Komponenten des Systems, die keine weitere Komponenten aufrufen (außer Funktionen des Betriebssystems). Größere Teilsysteme werden sukzessive aus getesteten Komponenten zusammengesetzt, mit anschließendem Test dieser Integration.

c) Ad-hoc-Integration
Die Bausteine werden z. B. in der (zufälligen) Reihenfolge ihrer Fertigstellung integriert (s. o.).

(s.a. Kap. 3.3.5 Integrationsstrategien)

zurück zur Frage

3.7 Welche Gründe sprechen dafür, Tests in einer separaten Testumgebung durchzuführen?

a) Im Test werden Fehlerwirkungen auftreten. Dabei besteht immer die Gefahr, dass die Produktivumgebung des Kunden beeinträchtigt wird. Teure Systemausfälle und Datenverluste im produktiven Kundensystem können die Folge sein.

b) Die Tester haben keine oder nur geringe Kontrolle über Parameter und Konfiguration der Produktivumgebung. Durch den gleichzeitig zum Test weiter laufenden Betrieb der anderen Kundensysteme werden die Testbedingungen unter Umständen schleichend verändert. Die durchgeführten Systemtests sind schwer oder gar nicht mehr reproduzierbar.

(s.a. Kap. 3.4.2 Testobjekt und Testumgebung)

zurück zur Frage

3.8 Erläutern Sie anforderungsbasiertes Testen.

Das freigegebene Anforderungsdokument wird als Testbasis herangezogen. Zu jeder Anforderung wird mindestens ein Systemtestfall abgeleitet und in der Systemtestspezifikation dokumentiert. Auch die Systemtestspezifikation wird durch ein Review verifiziert. In der Regel wird mehr als nur ein Testfall benötigt, um eine Anforderung zu testen. Sind die einmal definierten Testfälle (bzw. eine in der Testspezifikation definierte Mindestanzahl davon) im Systemtest fehlerfrei gelaufen, wird das System als validiert (in Bezug auf den anforderungsbasierten Test) betrachtet.

(s.a. Kap. 3.4.4 Test funktionaler Anforderungen)

zurück zur Frage

3.9 Definieren Sie Lasttest, Performanztest, Stresstest. Was sind die Unterscheidungsmerkmale?

Lasttest:
Messung des Systemverhaltens in Abhängigkeit steigender Systemlast (z. B. Anzahl parallel arbeitender Anwender, Anzahl Transaktionen).

Performanztest:
Messung der Verarbeitungsgeschwindigkeit bzw. Antwortzeit für bestimmte Anwendungsfälle, in der Regel in Abhängigkeit steigender Last.

Stresstest:
Beobachtung des Systemverhaltens bei Überlastung.

(s.a. Kap. 3.4.5 Test nicht funktionaler Anforderungen)

zurück zur Frage

3.10 Worin unterscheiden sich Fehlernachtest und Regressionstest?

Fehlernachtest:
Wiederholung aller Tests, die Fehlerwirkungen erzeugt haben, deren Ursache der korrigierte Defekt war.

Regressionstest:
Erneuter Test eines bereits getesteten Programms nach dessen Modifikation mit dem Ziel nachzuweisen, dass durch die vorgenommenen Änderungen keine neuen Defekte eingebaut oder bisher maskierte Fehlerzustände freigelegt wurden.

(s.a. Kap. 3.6.3 Regressionstest)

zurück zur Frage

3.11 In welcher Projektphase nach allgemeinem V-Modell sollte das Testkonzept erstellt werden?

Die zugehörige Testvorbereitung wird parallel zu den Entwicklungsschritten durchgeführt, d.h. parallel zum funktionalen Systementwurf.

(s.a. Kap. 3.8.2 Testkonzept)

zurück zur Frage

Antworten zu den Übungsaufgaben zu Kapitel 4

4.1 Beschreiben Sie die grundlegenden Schritte die bei einem Review durchzuführen sind.

Grundlegende Schritte sind:
a) Planung
b) Einführung
c) Vorbereitung
d) Reviewsitzung
e) Nachbereitung

a) Planung
Vom Management ist zu entscheiden, welche Dokumente des Softwareentwicklungsprozesses welchem Reviewverfahren unterzogen werden sollen. Der zu veranschlagende Aufwand ist einzuplanen.

b) Einführung
Die Einführung kann in Form einer Vorbesprechung erfolgen. Die benötigten Dokumenten werden an die beteiligten Personen verteilt.

c) Vorbereitung
Die Personen des Reviewteams bereiten sich individuell auf die Sitzung vor. Nur bei guter Vorbereitung ist eine erfolgreiche Reviewsitzung überhaupt möglich. Die Gutachter setzen sich intensiv mit dem zu prüfenden Dokument auseinander und verwenden dabei die zur Verfügung gestellten Dokumente als Prüfgrundlage.

d) Reviewsitzung
Die Reviewsitzung wird von einem Moderator geführt. Sie ist auf einen festen Zeitrahmen (maximal 2 Stunden) beschränkt. Ziel ist die Beurteilung des Prüfobjektes in Bezug auf die Einhaltung und Umsetzung der Vorgaben und Richtlinien. Die Bewertung der einzelnen Befunde und die Gesamtbeurteilung soll von allen Gutachtern getragen werden. Das Ergebnis der Sitzung wird protokolliert.

e) Nachbereitung
Der Autor beseitigt auf Grundlage der Reviewergebnisse die Mängel im überprüften Dokument. Bei schwerwiegenden Mängeln kann ein weiteres Review zur Kontrolle der Überarbeitung angesetzt werden. Wiederkehrende oder häufig vorkommende Fehlerarten weisen auf Defizite im Softwareentwicklungsprozess oder im Fachwissen der jeweiligen Personen hin. Notwendige Verbesserungen des Entwicklungsprozesses sind entsprechend zu planen und umzusetzen. Mangel an Fachwissen ist durch Schulung auszugleichen.

(s.a. Kap. 4.1.3 Grundlegende Vorgehensweise)

zurück zur Frage

4.2 Welche Reviewarten werden unterschieden?

Walkthrough, Inspektion, technisches Review und informelles Review.

(s.a. Kap. 4.1.5 Reviewarten)

zurück zur Frage

4.3 Welche Rollen wirken an einem technischen Review mit?

Moderator, Autor, Gutachter und Protokollant. Beim technisches Review ist darauf zu achten, dass die Gutachter über ausreichende Fachkompetenz verfügen (meist direkte Kollegen des Autors).

(s.a. Kap. 4.1.4 Rollen und Verantwortlichkeiten und Kap. 4.1.5 Reviewarten)

zurück zur Frage

4.4 Warum sind Reviews ein effizientes Mittel zur Qualitätssicherung?

Mängel können frühzeitig, direkt nach ihrem Entstehen, erkannt und beseitigt werden. Reviews tragen somit zur Qualitätssteigerung bei und helfen Kosten zu sparen.

(s.a. Kap. 4.1.2 Reviews)

zurück zur Frage

4.5 Erklären Sie den Begriff statische Analyse.

Überprüfung, Vermessung und Darstellung eines Programms oder einer Komponente (bzw. eines Dokuments, das eine formale Struktur hat).

(s.a. Kap. 4.2. Statische Analyse)

zurück zur Frage

4.6 Wie stehen statische Analyse und Reviews in Zusammenhang?

Statische Analyse wird oft als Obergriff für alle Prüfverfahren verwendet, bei denen keine Ausführung des Testobjekts erfolgt. Besitzt das zu prüfende Dokument eine formale Struktur, so sollte vor dem Review eine werkzeuggestützte statische Analyse durchgeführt werden, da sich dadurch der Reviewaufwand verringert. So sollte vor einem Review eines Programmtextes ein Compilerlauf durchgeführt und die eventuellen Syntaxfehler beseitigt werden.

(s.a. Kap. 4 Statischer Test)

zurück zur Frage

4.7 Warum kann statische Analyse nicht alle in einem Programm enthaltenen Fehlerzustände aufdecken?

Weil einige Fehlerzustände erst bei der Ausführung entstehen. Ein Divisor kann beispielweise bei der Ausführung den Wert null annahmen und somit einen Laufzeitfehler verursachen, der durch Sichtung des Programmtextes nicht ermittelt werden kann.

(s.a. Kap. 4.2 Statische Analyse und Kap. 5. Dynamischer Test)

zurück zur Frage

4.8 Welche Arten von Datenflussanomalien werden unterschieden?

Drei Arten werden unterschieden:

ur-Anomalie:
Ein undefinierter Wert (u) einer Variablen wird auf einem Programmpfad gelesen (r).

du-Anomalie: Die Variable erhält einen Wert (d) der allerdings ungültig (u) wird, ohne das er zwischenzeitlich verwendet wurde.

dd-Anomalie: Die Variable erhält auf einem Programmpfad ein zweites Mal einen Wert (d), ohne dass der erste Wert (d) verwendet wurde.

(s. a. Kap. 4.2.3 Durchführung der Datenflussanalyse)

zurück zur Frage

Antworten zu den Übungsaufgaben zu Kapitel 5

5.1 Was ist ein dynamischer Test?

Die Prüfung des Testobjektes durch Ausführung auf einem Rechner.

(s.a. Kap. 5 Dynamischer Test)

zurück zur Frage

5.2 Wozu dient ein Testrahmen?

Ein Testrahmen wird benötigt, um ein Testobjekt, das kein vollständiges Programm ist, ausführen zu können. Der Testrahmen umfasst aller das Testobjekt umgebenden Programme (u.a. Testtreiber und Platzhalter), die notwendig sind, um Testfälle auszuführen, auszuwerten und Testprotokolle aufzuzeichnen.

(s.a. Kap. 5 Dynamischer Test)

zurück zur Frage

5.3 Wodurch unterscheiden sich Black-Box- und White-Box-Testverfahren?

Bei den Black-box-Verfahren wird das Testobjekt als schwarzer Kasten angesehen. Über den Programmtext und den inneren Aufbau sind keine Informationen notwendig. Beobachtet wird das Verhalten des Testobjektes von außen (PoO - Point of Observation liegt außerhalb des Testobjekts). Es ist keine Steuerung des Ablaufs des Testobjekts außer durch die entsprechende Wahl der Eingabetestdaten möglich (auch der PoC - Point of Control liegt außerhalb des Testobjekts). Die Überlegungen zu den Testfällen beruhen auf der Spezifikation bzw. den Anforderungen an das Testobjekt.

Bei den White-box-Verfahren wird auch auf den Programmtext zurückgegriffen. Während der Ausführung der Testfälle wird der innere Ablauf im Testobjekt analysiert (Point of Observation liegt innerhalb des Testobjektes). Ein Eingriff in den Ablauf des Testobjektes ist in Ausnahmefällen möglich, z. B. wenn Negativtests durchzuführen sind und über die Komponentenschnittstelle die zu provozierende Fehlbedienung nicht ausgelöst werden kann (Point of Control kann innerhalb des Testobjekts liegen). Testfälle können auf Grund der Programmstruktur des Testobjekts gewonnen werden.

(s.a. Kap. 5 Dynamischer Test, Kap. 5.1 Black-box-Verfahren, Kap. 5.2 White-box-Verfahren)

zurück zur Frage

5.4 Erklären Sie das Verfahren der Äquivalenzklassenbildung.

Die Menge der möglichen konkreten Eingabewerte für ein Eingabedatum wird in Äquivalenzklassen unterteilt. Die zugrunde liegende Idee dabei ist, dass das Testobjekt sich bei allen Eingabedaten, die zu einer Äquivalenzklasse gehören, gleich verhält. Der Test eines Repräsentanten einer Äquivalenzklasse wird als ausreichend angesehen, da davon ausgegangen wird, dass das Testobjekt für alle anderen Eingabewerte derselben Äquivalenzklasse keine andere Reaktion zeigt. Neben den Äquivalenzklassen, welche gültige Eingaben umfassen, sind auch solche für ungültige Eingaben zu berücksichtigen. Das gleiche Vorgehen kann auch für Ausgabewerte angewendet werden.

(s.a. Kap. 5.1.1 Äquivalenzklassenbildung)

zurück zur Frage

5.5 Was ist ein Repräsentant?

Ein Repräsentant repräsentiert die Menge der Daten einer Äquivalenzklasse. Es wird davon ausgegangen, dass das Testobjekt sich bei allen Daten einer Äquivalenzklasse gleich verhält und der Test mit einem Repräsentanten ausreicht.

(s.a. Kap. 5.1.1 Äquivalenzklassenbildung)

zurück zur Frage

5.6 Wie ist das Testendekriterium Äquivalenzklassenüberdeckung definiert?

Äquivalenzklassen-Überdeckung = (Anzahl getestete ÄK / Gesamtzahl ÄK) * 100 %

(s.a. Kap. 5.1.1 Äquivalenzklassenbildung)

zurück zur Frage

5.7 Warum ist die Grenzwertanalyse eine gute Ergänzung zur Äquivalenzklassenbildung?

Fehlerzustände in Programmen treten häufig an den Grenzbereichen der Äquivalenzklassen auf, da hier fehlerträchtige Fallunterscheidungen in den Programmen vorzusehen sind. Ein Test mit Grenzwerten deckt daher oft Fehlerwirkungen auf.

(s.a. Kap. 5.1.2 Grenzwertanalyse)

zurück zur Frage

5.8 Nennen Sie weitere Black-Box-Verfahren.

Zustandsbezogener Test, Ursache-Wirkungs-Graph-Analyse, Syntaxtest, Zufallstest und Smoke-Test

(s.a. Kap. 5.1.3 Zustandsbezogener Test, Kap. 4.1.5 Allgemeine Bewertung der Black-box-Verfahren)

zurück zur Frage

5.9 Erläutern Sie den Begriff Anweisungsüberdeckung.

Die einzelnen Anweisungen (statements) des Testobjekts stehen im Mittelpunkt der Untersuchung. Es sind Testfälle zu identifizieren, die eine zuvor festgelegte Mindestquote oder auch alle Anweisungen des Testobjekts zur Ausführung bringen. Die Anweisungsüberdeckung gehört zu den White-box-Verfahren.

(s.a. Kap. 5.2.1 Anweisungsüberdeckung)

zurück zur Frage

5.10 Worin unterscheiden sich Anweisungs- und Zweigüberdeckung?

Leere Else-Zweige bleiben bei der Anweisungsüberdeckung unberücksichtigt, da der Else-Zweig ja keine Anweisung enthält. Die Zweigüberdeckung fordert die Durchführung von Tests, bei denen die Bedingungen im Testobjekt jeweils den Wert wahr und falsch annehmen.

(s.a. Kap. 5.2.1 Anweisungsüberdeckung, Kap. 5.2.2 Zweigüberdeckung)

zurück zur Frage

5.11 Wozu dient eine Instrumentierung?

Eine Instrumentierung dient zur Ermittlung der durch die durchgeführten Testfälle erreichten Überdeckung und damit zur Feststellung, ob ein definiertes Testendekriterium erfüllt ist (bei den White-box-Verfahren).

(s.a. Kap. 5.2.6 Instrumentierung)

zurück zur Frage

Antworten zu den Übungsaufgaben zu Kapitel 6

6.1 Welche grundsätzlichen Modelle einer Aufgabenteilung zwischen Entwicklung und Test lassen sich unterscheiden?

Modelle zur Aufgabenteilung zwischen Entwicklung und Test:

1. Testen liegt ausschließlich in der Verantwortung des einzelnen Entwicklers. Jeder Entwickler testet seine eigenen Programmteile.

2. Testen liegt in der Verantwortlichkeit des Entwicklungsteams. Die Entwickler testen ihre Programmteile gegenseitig.

3. Mindestens ein Mitglied des Entwicklerteams ist für Testarbeiten abgestellt. Es erledigt alle Testarbeiten des Teams.

4. Es gibt ein oder mehrere dedizierte Testteams innerhalb des Projekts (die nicht an der Entwicklung beteiligt sind).

5. Eine separate Organisation (Testabteilung, externer Testdienstleister, Testlabor) übernimmt das Testen.

(s.a. Kap. 6.1 Organisation von Testteams)

zurück zur Frage

6.2 Welche Rollen sind beim Testen auszufüllen und mit speziell qualifizierten Mitarbeitern zu besetzen?

Folgende Rollen sind zu besetzen:
a) Testmanager
b) Testdesigner
c) Testautomatisierer
d) Testadministrator
e) Tester

a) Testmanager
Experte(n) für Testplanung und Teststeuerung mit Know-how/Erfahrung in den Bereichen Softwaretest, Qualitätsmanagement, Projektmanagement, Personalführung.

b) Testdesigner
Experte(n) für Testmethoden und Testspezifikation mit Know-how/Erfahrung in den Bereichen Softwaretest, Software Engineering und (formalen) Spezifikationsmethoden.

c) Testautomatisierer
Experte(n) für Testautomatisierung (Testgrundlagenwissen, Programmiererfahrung und mit sehr guter Kenntnis der eingesetzten Testwerkzeuge).

d) Testadministrator
Experte(n) für Installation und Betrieb der Testumgebung (Systemadministrator-Know-how).

e) Tester
Experte(n) für Testdurchführung und Fehlerberichte (IT-Grundlagen, Testgrundlagenwissen, Bedienung der eingesetzten Testwerkzeuge, Verständnis des Testobjekts).

(s.a. Kap. 6.2 Mitarbeiterqualifikation)

zurück zur Frage

6.3 Welche Aufgaben hat der Testmanager?

Ein Testmanager hat die Aufgabe Testzyklen zu initiieren, zu überwachen und zu steuern. Dabei kann je nach Projektgröße für jede Teststufe ein eigener Testmanager zuständig sein.

(s.a. Kap. 6.3 Management der Testarbeiten)

zurück zur Frage

6.4 Welche Arten von Metriken zur Überwachung des Testfortschritts lassen sich unterscheiden?

a) Fehlerbasierte Metriken:
Anzahl gefundener Fehlerzustände bzw. erstellter Fehlermeldungen (pro Testobjekt) im jeweiligen Release, in Abhängigkeit der Fehlerklasse und des Fehlerstatus, ggf. bezogen auf Größe des Testobjekts (lines of code),
Testdauer o. Ä.

b) Testfallbasierte Metriken:
Anzahl spezifizierter oder geplanter Tests, Anzahl blockierter Tests (z. B. wegen nicht beseitigter Fehlerzustände), Anzahl gelaufener, nicht Fehler aufdeckender Testfälle, Anzahl gelaufener Fehler aufdeckender Testfälle.

c) Testobjektbasierte Metriken:
Codeabdeckung, Dialogabdeckung, abgedeckte Installationsvarianten, Plattformen usw.

(s.a. Kap. 6.3.3 Testzyklusüberwachung)

zurück zur Frage

6.5 Welche Informationen sollte ein Teststatusbericht enthalten?

Ein Teststatusbericht sollte folgende Informationen enthalten:
- Testobjekt(e)
- Teststufe
- Testzyklus-Datum von ... bis
- Testfortschritt (geplante/gelaufene/blockierte Tests)
- Fehlerstatus (neue/offene/korrigierte Fehler)
- Risiken (neue/veränderte/bekannte Risiken)
- Ausblick (Planung des nächsten Testzyklus)
- Gesamtbewertung (Beurteilung der Freigabereife des Testobjekts)

(s.a. Kap. 6.3.3 Testzyklusüberwachung)

zurück zur Frage

6.6 Welche Daten sollte eine Fehlermeldung enthalten?

Eine Fehlermeldung sollte Angaben zur Identifikation und zur Klassifikation des Fehlers beinhalten und die Problembeschreibung selbst.

Identifikation:
- Nummer: laufende, eindeutige Meldungsnummer
- Testobjekt: Bezeichnung des Testobjekts
- Version: Identifikation der genauen Version des Testobjekts
- Plattform: Identifikation der HW-/SW-Plattform bzw. der Testumgebung
- Entdecker: Identifikation des Testers (ggf. mit Teststufe)
- Entwickler: Name des für das Testobjekt verantwortlichen Entwicklers oder Teams
- Erfassung: Datum, ggf. Uhrzeit, an dem das Problem beobachtet wurde

Klassifikation:
- Status: Bearbeitungsfortschritt der Meldung; möglichst mit Kommentar und Datum des Eintrags
- Klasse: Klassifizierung der Schwere des Problems
- Priorität: Klassifizierung der Dringlichkeit einer Korrektur
- Anforderung: Verweis auf die (Kunden-)Anforderung, die wegen der Fehlerwirkung nicht erfüllt oder verletzt ist
- Fehlerquelle: Soweit feststellbar, die Projektphase, in der die Fehlhandlung begangen wurde (Analyse, Design, Programmierung); nützlich zur Planung prozessverbessernder Maßnahmen

Problembeschreibung:
- Testfall: Beschreibung des Testfalls (Name, Nummer) bzw. der Schritte, die zur Reproduktion der Fehlerwirkung führen
- Problem: Beschreibung der Fehlerwirkung; erwartete vs. tatsächliche Ergebnisse bzw. Verhalten
- Kommentar: Stellungnahmen der Betroffenen zum Meldungsinhalt
- Korrektur: Korrekturmaßnahmen des zuständigen Entwicklers
- Verweis: Querverweise auf andere zugehörige Meldungen

(s.a. Kap. 6.4.2 Fehlermeldung)

zurück zur Frage

6.7 Was ist der Unterschied zwischen Fehlerpriorität und Fehlerklasse?

Fehlerpriorität:
Festlegung der Dringlichkeit von Korrekturmaßnahmen unter Berücksichtigung der Fehlerklasse, des erforderlichen Korrekturaufwands und der Auswirkungen auf den gesamten Entwicklungs- und Testprozess.

Fehlerklasse:
Einteilung der aufgedeckten Fehlerwirkungen nach Schwere der Fehlerwirkung aus Sicht des Anwenders (z.B. Grad der Behinderung des Produkteinsatzes).

(s.a. Kap. 6.4.3 Fehlerklassifikation)

zurück zur Frage

6.8 Wozu wird ein Fehlerstatusmodell benötigt?

Das Fehlerstatusmodell wird benötigt, um eine kontinuierliche Verfolgung des Fehleranalyse- und Korrekturprozesses über alle Stadien hinweg sicher zu stellen. Diese Verfolgung geschieht anhand des Fehlerstatus. Dabei durchläuft jede Fehlermeldung eine Reihe festgelegter Stati, die alle Schritte von der erstmaligen Erfassung bis zur erfolgreichen Fehlerkorrektur beinhalten.

(s.a. Kap. 6.4.4 Fehlerstatus)

zurück zur Frage

6.9 Welche Aufgabe hat ein Änderungskontrollausschuss?

Im Fehlermanagement wird eine Instanz benötigt, die Änderungsanforderungen genehmigt oder ablehnt. Diese Instanz heißt Änderungskontrollausschuss (change control board) und wird üblicherweise von Vertretern folgender Interessengruppen gebildet:
- Produktmanagement
- Projektmanagement
- Testmanagement
- Kundenvertreter

(s.a. Kap. 6.4.4 Fehlerstatus)

zurück zur Frage

6.10 Welche Anforderungen aus Sicht des Tests stellen sich an das Konfigurationsmanagement?

a) Versionenverwaltung:
Katalogisieren, Speichern und Wiederabrufen von unterschiedlichen Versionen eines Konfigurationsobjekts (z. B. Version 1.0 und 1.1 einer Datei). Hierzu gehört auch das Mitführen von Kommentaren, aus denen der jeweilige Änderungsgrund hervorgeht.

b) Konfigurationsverwaltung:
Bestimmung und Verwaltung aller Dateien (Konfigurationsobjekte) in der jeweils passenden Version, die zusammen ein Teilsystem bilden (Konfiguration). Voraussetzung hierfür ist eine Versionenverwaltung.

c) Statusverfolgung von Fehlern und Änderungen:
Aufzeichnung von Problemberichten und Änderungsanforderungen und die Möglichkeit, deren Umsetzung an den Konfigurationsobjekten nachzuvollziehen.

(s.a. Kap. 6.5 Anforderungen an das Konfigurationsmanagement)

zurück zur Frage

6.11 Welche grundsätzlichen Arten von Normen und Standards lassen sich unterscheiden?

a) Firmenstandards
Firmeninterne Richtlinien und Verfahrensanweisungen.

b) Best Practises
Nicht standardisierte, aber fachlich bewährte Vorgehensweisen und Verfahren, die den Stand der Technik in einem Anwendungsgebiet darstellen.

c) Qualitätsmanagementstandards
Branchenübergreifende Standards, die Mindestanforderungen an Prozesse spezifizieren, ohne konkrete Anforderungen bezüglich der Umsetzung zu formulieren.

d) Branchenstandards
Branchenspezifische Standards, die für eine bestimmte Produktkategorie oder ein Einsatzgebiet u. a.. festlegen, in welchem Mindestumfang Tests durchzuführen oder nachzuweisen sind.

e) Softwareteststandards
Prozessstandards, die produktunabhängig festlegen, wie Softwaretests fachgerecht durchzuführen sind.

(s.a. Kap. 6.6 Relevante Normen und Standards)

zurück zur Frage

Antworten zu den Übungsaufgaben zu Kapitel 7

7.1 Welche grundlegenden Funktionen bieten Testplanungswerkzeuge?

Testplanungswerkzeuge bieten Mechanismen zur bequemen Erfassung, Katalogisierung und Verwaltung der Testfälle und zu deren Priorisierung. Sie bieten evtl. auch Unterstützung für das anforderungsbasierte Testen, d.h. Erfassen von bzw. Verknüpung an Systemanforderungen und Verknüpfung mit den Tests, die die entsprechende Anforderung prüfen.

Weitere Aufgaben können durch die Werkzeuge übernommen werden:
- die Prüfung, ob jede Anforderung durch einen Testfall geprüft wird
- Überwachung der Stati der einzelnen Testfälle
- Ressourcen- und Zeitplanung und deren Anpassung im Projektverlauf

(s.a. Kap. 7.1.1 Werkzeuge für Testplanung und Testmanagement)

zurück zur Frage

7.2 Welche Typen von Testdatengeneratoren werden unterschieden?

a) Datenbankbasierte Testdatengeneratoren
verarbeiten Datenbankschemata und sind in der Lage, daraus Testdatenbestände zu generieren.

b) Codebasierte Testdatengeneratoren
generieren Testdaten, indem sie den Code des Testobjekts analysieren.

c) Schnittstellenbasierte Testdatengeneratoren
analysieren die Testobjektschnittstelle, erkennen die Definitionsbereiche der Schnittstellenparameter und leiten z. B. mittels Äquivalenzklassen- und Grenzwertanalyse daraus Testdaten ab.

d) Spezifikationsbasierte Testdatengeneratoren
leiten Testdaten und zugehörige Sollwerte aus einer Spezifikation ab.

(s.a. Kap. 7.1.2 Werkzeuge zur Testspezifikation)

zurück zur Frage

7.3 Welcher Typ von Testdatengenerator kann auch Sollwerte generieren? Warum können die anderen Typen das nicht?

Nur spezifikationsbasierte Testdatengeneratoren können Sollwerte aus einer Spezifikation ableiten. Voraussetzung ist natürlich, dass die Spezifikation in einer formalen Notation vorliegt. Einige Generatoren nutzen formale Modelle des Testobjekts, wie sie mit CASE-Tools erstellt werden können.

(s.a. Kap. 7.1.2 Werkzeuge zur Testspezifikation)

zurück zur Frage

7.4 Erläutern Sie die prinzipielle Funktionsweise eines Capture-Replay-Tools.

Ein Capture-and-Replay-Tool zeichnet während einer Testsitzung alle manuell durchgeführten Bedienschritte (Tastatureingaben, Mausklicks) auf, die der Tester am Testobjekt ausführt. Dabei werden nicht nur die x/y-Koordinaten der Mausklicks aufgezeichnet, sondern auch die an der grafischen Bedienoberfläche (GUI) ausgelösten Operationen (z. B. pressButton(»Start«)) sowie die zur Wiedererkennung des angeklickten Objekts benötigten Objekteigenschaften (Objektname, Objekttyp, Farbe, Beschriftung, x/y-Position u. a.). Diese Bedienschritte speichert das Werkzeug als Testskript.

(s.a. Kap. 7.1.3 Werkzeuge zur Testdurchführung)

zurück zur Frage

7.5 Aus welchen Schritten besteht der Prozess zur Auswahl eines Testwerkzeugs?

Prozess zur Auswahl eines Testwerkzeugs:
1. Anforderungsspezifikation für den Werkzeugeinsatz
2. Marktstudie (Aufstellen einer Übersichtsliste der Kandidaten)
3. Vorführung von Werkzeugdemos
4. Evaluierung der Werkzeuge der engeren Wahl
5. Review der Ergebnisse und Werkzeugauswahl

(s.a. Kap. 7.2.2 Werkzeugauswahl)

zurück zur Frage

7.6 Welche Schritte sind bei der Werkzeugeinführung zu beachten?

Schritte bei der Werkzeugeinführung:
1. Pilotprojekt
2. Review der Pilotprojekterfahrungen
3. Prozessanpassung
4. Anwenderschulung
5. Breiteneinführung
6. Begleitendes Coaching

(s.a. Kap. 7.2.3 Werkzeugeinführung)

zurück zur Frage