7.6 Welche Schritte sind bei der Werkzeugeinführung zu beachten?
Schritte bei der Werkzeugeinführung:1. Pilotprojekt2. Review der Pilotprojekterfahrungen3. Prozessanpassung4. Anwenderschulung5. Breiteneinführung6. Begleitendes Coaching (s.a. Kap. 7.2.3 Werkzeugeinführung)
7.5 Aus welchen Schritten besteht der Prozess zur Auswahl eines Testwerkzeugs?
Prozess zur Auswahl eines Testwerkzeugs:1. Anforderungsspezifikation für den Werkzeugeinsatz2. Marktstudie (Aufstellen einer Übersichtsliste der Kandidaten)3. Vorführung von Werkzeugdemos4. Evaluierung der Werkzeuge der engeren Wahl5. Review der Ergebnisse und Werkzeugauswahl (s.a. Kap. 7.2.2 Werkzeugauswahl)
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)
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)
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)
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)
6.11 Welche grundsätzlichen Arten von Normen und Standards lassen sich unterscheiden?
a) FirmenstandardsFirmeninterne Richtlinien und Verfahrensanweisungen. b) Best PractisesNicht standardisierte, aber fachlich bewährte Vorgehensweisen und Verfahren, die den Stand der Technik in einem Anwendungsgebiet darstellen. c) QualitätsmanagementstandardsBranchenübergreifende Standards, die Mindestanforderungen an Prozesse spezifizieren, ohne konkrete Anforderungen bezüglich der Umsetzung zu formulieren. d) BranchenstandardsBranchenspezifische Standards, die für eine bestimmte Produktkategorie oder ein Einsatzgebiet u. a.. festlegen, in welchem Mindestumfang Tests durchzuführen oder nachzuweisen sind. e) SoftwareteststandardsProzessstandards, die produktunabhängig festlegen, wie Softwaretests fachgerecht durchzuführen sind. (s.a. Kap. 6.6 Relevante Normen und Standards)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
6.2 Welche Rollen sind beim Testen auszufüllen und mit speziell qualifizierten Mitarbeitern zu besetzen?
Folgende Rollen sind zu besetzen:a) Testmanagerb) Testdesignerc) Testautomatisiererd) Testadministratore) Tester a) TestmanagerExperte(n) für Testplanung und Teststeuerung mit Know-how/Erfahrung in den Bereichen Softwaretest, Qualitätsmanagement, Projektmanagement, Personalführung. b) TestdesignerExperte(n) für Testmethoden und Testspezifikation mit Know-how/Erfahrung in den Bereichen Softwaretest, Software Engineering und (formalen) Spezifikationsmethoden. c) TestautomatisiererExperte(n) für Testautomatisierung (Testgrundlagenwissen, Programmiererfahrung und mit sehr guter Kenntnis der eingesetzten Testwerkzeuge). d) TestadministratorExperte(n) für Installation und Betrieb der Testumgebung (Systemadministrator-Know-how). e) TesterExperte(n) für Testdurchführung und Fehlerberichte (IT-Grundlagen, Testgrundlagenwissen, Bedienung der eingesetzten Testwerkzeuge, Verständnis des Testobjekts). (s.a. Kap. 6.2 Mitarbeiterqualifikation)
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)
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)
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)
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)
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)
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)
5.6 Wie ist das Testendekriterium Äquivalenzklassenüberdeckung definiert?
Äquivalenzklassen-Überdeckung = (Anzahl getestete ÄK / Gesamtzahl ÄK) * 100 % (s.a. Kap. 5.1.1 Äquivalenzklassenbildung)
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)
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)
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)
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)
5.1 Was ist ein dynamischer Test?
Die Prüfung des Testobjektes durch Ausführung auf einem Rechner. (s.a. Kap. 5 Dynamischer Test)
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)
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)
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)
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)
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)
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)
4.2 Welche Reviewarten werden unterschieden?
Walkthrough, Inspektion, technisches Review und informelles Review. (s.a. Kap. 4.1.5 Reviewarten)
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)
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)
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)
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)
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)
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)
3.6 Welche Integrationsstrategien lassen sich unterscheiden?
a) Top-down-IntegrationDer 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-IntegrationDer 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-IntegrationDie Bausteine werden z. B. in der (zufälligen) Reihenfolge ihrer Fertigstellung integriert (s. o.). (s.a. Kap. 3.3.5 Integrationsstrategien)
3.5 Nennen Sie die Testziele des Integrationstests.
a) Schnittstellenfehler aufdeckenProbleme 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 aufdeckenEine 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).
3.5 Nennen Sie die Testziele des Integrationstests.
a) Schnittstellenfehler aufdeckenProbleme 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 aufdeckenEine 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).
