Zusammenfassung der Testarten

Größe: px

Ab Seite anzeigen:

Download "Zusammenfassung der Testarten"

Brit Ackermann
vor 8 Jahren
Abrufe

1 oftware-test Zusammenfassung der Testarten Komponententest Integrationstest Systemtest Grenztest Black Box Test zustands basierter Test White Box Test Pfadtest Strategie: Urknall Top Down Bottom Up Sandwich Funktionstest Feldtest Installationstest Leistungstest Akzeptanztest Äquivalenztest Härtetest Sicherheitstest Erholungstest Volumentest Zeitvorgabentest Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 47 / 84

Funktionstest Feldtest Installationstest Leistungstest Akzeptanztest Äquivalenztest Härtetest

2 oftware-test Testdokumentation: Aufzeichnung der Testaktivitäten Testplan: Projektplan fürs Testen Testfallspezifikation: Dokumentation eines jeden Testfalls Testvorfallbericht (Testprotokoll): Ergebnisse des Tests und Unterschiede zu erwarteten Ergebnissen Testübersicht: Auflistung aller Fehler (entdeckt und noch zu untersuchen) Analyse und Priorisierung aller Fehler und deren Korrekturen Testplan und Testfallspezifikation können sehr früh schon erstellt werden. Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 48 / 84

Testübersicht: Auflistung aller Fehler (entdeckt und noch zu untersuchen) Analyse und Priorisierung aller Fehler und deren Korrekturen

3 oftware-test Testplan (IEEE Std ) 1. Einführung 2. Beziehung zu anderen Dokumenten 3. Systemüberblick 4. Merkmale, die getestet/nicht getestet werden müssen 5. Abnahmekriterien 6. Vorgehensweise 7. Aufhebung und Wiederaufnahme 8. Zu prüfendes Material (Hardware-/Softwareanforderungen) 9. Testfälle 10. Testzeitplan: Verantwortlichkeiten, Personalausstattung und Weiterbildungsbelange, Risiken und Schadensmöglichkeiten, Zeitplan Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 49 / 84

Zu prüfendes Material (Hardware-/Softwareanforderungen) 9. Testfälle 10.

4 oftware-test Testfallspezifikation Testfallbezeichner: eindeutiger Name des Testfalls; am Besten Namenskonventionen benutzen Testobjekte: Komponenten (und deren Merkmale), die getestet werden sollen Eingabespezifikationen: erwartete Eingaben Ausgabespezifikationen: erwartete Ausgaben Umgebungserfordernisse: notwendige Software- und Hardware-Plattform sowie Testrümpfe und -stümpfe Besondere prozedurale Anforderungen: Einschränkungen wie Zeitvorgaben, Belastung oder Eingreifen durch den Operateur Abhängigkeiten zwischen Testfällen Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 50 / 84

Umgebungserfordernisse: notwendige Software- und Hardware-Plattform sowie Testrümpfe und -stümpfe Besondere prozedurale Anforderungen: Einschränkungen

5 oftware-test Testschadensbericht welche Merkmale wurden getestet? wurden sie erfüllt? bei Störfällen: wie können sie reproduziert werden? Sammlung und Priorisierung in der Testübersicht Test Fehlersuche bzw. -korrektur! Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 51 / 84

Sammlung und Priorisierung in der Testübersicht Test Fehlersuche bzw.

6 oftware-test Quizz Woher kommt der englische Begriff Bug für Fehler? Auflösung: Bug wird auf Grace Hopper zurückgeführt; bezeichnet einen Fehler, der auftrat als ein Nachtfalter mit einem Rechnerrelais in Konflikt geriet mit dem Effekt, dass ein Programm anhielt. Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 52 / 84

auftrat als ein Nachtfalter mit einem Rechnerrelais in Konflikt geriet mit dem

7 Implementierung 2 Implementierung Motivation Architekturkonformität Bauhaus-Werkzeug zur Reflektionsmethode Programmierrichtlinien Anhang Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 54 / 84

Reflektionsmethode Programmierrichtlinien Anhang

8 Lernziele Feinentwurf eines Systems durchführen können Programmierrichtlinien entwerfen, kennen und einhalten Verständnis für Codequalität entwickeln Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 55 / 84

Verständnis für Codequalität entwickeln Rainer Koschke

9 Feinentwurf Der Feinentwurf ist die Brücke zwischen abstrakter Architektur und detailliertem Code. Er legt fest: Datenstrukturen Klassendiagramme mit zusätzlichen Implementierungsdetails; (z.b. Navigierbarkeit, Implementierung von Assoziationen, Behandlung von Mehrfachvererbung oder weiteren Implementierungsklassen etc.) Abläufe Zustandsautomaten Aktivitätsdiagramme Sequenzdiagramme Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 56 / 84

Navigierbarkeit, Implementierung von Assoziationen, Behandlung von Mehrfachvererbung oder weiteren

10 Architekturkonformität Architekturbeschreibung und Quellcode sind zwei voneinander abhängige, aber separate Dokumente in der Weiterentwicklung werden oft Änderungen im Quellcode gemacht, die in der Architekturbeschreibung nicht nachgezogen werden Folge: Architekturbeschreibung wird obsolet Planung erfolgt aber meist auf Basis der Architekturbeschreibung Folge: böses Erwachen in der Umsetzung Reflektionsmethode von Murphy u. a. (1995, 2001) zur Synchronisation von Modulsicht und Quellcode Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 57 / 84

Architekturbeschreibung wird obsolet Planung erfolgt aber meist auf Basis der Architekturbeschreibung Folge: böses Erwachen in der Umsetzung

11 Reflektionsmethode (Murphy u. a. 2001) 1 Stelle Architekturmodell auf 2 Extrahiere Implementierungsmodell 3 Bilde Modelle aufeinander ab 4 Berechne Reflektionsmodell 5 Verfeinere/korrigiere Beispiel H1 H2 H3 Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 58 / 84

Implementierungsmodell 3 Bilde Modelle aufeinander ab 4 Berechne

12 Reflektionsmethode (Murphy u. a. 2001) 1 Stelle Architekturmodell auf 2 Extrahiere Implementierungsmodell 3 Bilde Modelle aufeinander ab 4 Berechne Reflektionsmodell 5 Verfeinere/korrigiere Beispiel H1 H2 H3 Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 58 / 84

13 Reflektionsmethode (Murphy u. a. 2001) 1 Stelle Architekturmodell auf 2 Extrahiere Implementierungsmodell 3 Bilde Modelle aufeinander ab 4 Berechne Reflektionsmodell 5 Verfeinere/korrigiere Beispiel H1 H2 H3 Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 58 / 84

14 Reflektionsmethode (Murphy u. a. 2001) 1 Stelle Architekturmodell auf 2 Extrahiere Implementierungsmodell 3 Bilde Modelle aufeinander ab 4 Berechne Reflektionsmodell 5 Verfeinere/korrigiere Beispiel H1 H2 H3 Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 58 / 84

15 Reflektionsmethode (Murphy u. a. 2001) 1 Stelle Architekturmodell auf 2 Extrahiere Implementierungsmodell 3 Bilde Modelle aufeinander ab 4 Berechne Reflektionsmodell 5 Verfeinere/korrigiere Beispiel H1 H2 H3 Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 58 / 84

16 Reflektionsmethode (Murphy u. a. 2001) 1 Stelle Architekturmodell auf 2 Extrahiere Implementierungsmodell 3 Bilde Modelle aufeinander ab 4 Berechne Reflektionsmodell 5 Verfeinere/korrigiere Beispiel H1 H2 H3 Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2006/07 58 / 84

Ähnliche Dokumente

Software-Projekt. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen

Software-Projekt. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Software-Projekt Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Wintersemester 2008/09 Überblick I 1 Software-Test Software-Test 1 Software-Test