63
Fachinformatiker Anwendungsentwicklung (Fach) / Softwaretest (Lektion)
Anzeige
- 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)
- 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)
- 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)
- 3.1 Erläutern Sie die einzelnen Phasen des allgemeinen V-Modells. Die Phasen des allgemeinen V-Modells sind: a) AnforderungsdefinitionWü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 SystementwurfAbbildung aller Anforderungen auf Funktionen und Dialogabläufe. (s.a. Kap. 3.1 Das allgemeine V-Modell) c) technischer SystementwurfDefinition 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) KomponentenspezifikationDefinition 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) ProgrammierungProgrammierung jedes spezifizierten Bausteins in einer Programmiersprache. (s.a. Kap. 3.1 Das allgemeine V-Modell) f) KomponententestPrüfung, ob jede Komponente für sich den Vorgaben seiner Spezifikation entspricht. (s.a. Kap. 3.2 Komponententest) g) IntegrationstestPrüfung, ob Gruppen von Komponenten, wie sie im technischen Systementwurf vorgesehen sind, zusammen spielen. (s.a. Kap. 3.3 Integrationstest) h) SystemtestPrüfung ob das implementierte System den spezifizierten Anforderungen entspricht. (s.a. Kap. 3.4 Systemtest) i) AbnahmetestPrüfung, ob das System aus Kundensicht die vertraglich vereinbarten Leistungsmerkmale aufweist. (s.a. Kap. 3.5 Abnahmetest)
- 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.
- 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)
- 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)
- 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)
- 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)
- 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)
- Anzeige
- 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)
- 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)
- 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)