Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Qualitätsmanagement in der Software-Entwicklung Prof. Dr. Thomas Kudraß HTWK Leipzig Seminar PC-Ware AG Leipzig, 26.01.2002.

Ähnliche Präsentationen


Präsentation zum Thema: "Qualitätsmanagement in der Software-Entwicklung Prof. Dr. Thomas Kudraß HTWK Leipzig Seminar PC-Ware AG Leipzig, 26.01.2002."—  Präsentation transkript:

1 Qualitätsmanagement in der Software-Entwicklung Prof. Dr. Thomas Kudraß HTWK Leipzig Seminar PC-Ware AG Leipzig,

2 © Prof. T. Kudraß, HTWK Leipzig Motivation Kleine Bugs Große GAUs Ein paar falsche Zahlen oder Zeilen und schon passierts: – Explosion Ariane 5 (1996) – Verlorengegangene Venus-Sonde Mariner1 (1962) – Koffer-Debakel am Flughafen Denver – Bank-Bugs Neues Computer System bei US Fed (Fehlbuchungen 4 Mrd $) Kundendaten frei im Internet bei Credit Suisse (Image-Schaden) Wall-Street-Crash (1987) Spendable Geldautomaten bei Postbank-Service Card (2002)

3 © Prof. T. Kudraß, HTWK Leipzig Agenda EINHEIT 1 – Einführung Qualitätsmanagement EINHEIT 2 – Qualitätssicherung im Software-Entwicklungsprozess (V-Modell) – Beispiel EINHEIT 3 – Qualitätssicherung in Analyse & Design A: Qualität von Business-Spezifikationen B: Manuelle Prüfmethoden (Reviews) mit Beispiel EINHEIT 4 – Qualitätssicherung in der Programmierung: Test-Verfahren – Arten von Tests

4 © Prof. T. Kudraß, HTWK Leipzig EINHEIT 1: Einführung Qualitätsmanagement Qualitätsbegriff Qualitätsmerkmale von Softwareprodukten Qualitätsmodelle Maßnahmen von Qualitätssicherung und Qualitätsmanagement Prinzipien der Software-Qualitätssicherung Organisatorische Einbettung der QS

5 © Prof. T. Kudraß, HTWK Leipzig Was ist Qualität? Fünf verschiedene Ansätze Transzendenter Ansatz Produktbezogener Ansatz Benutzerbezogener Ansatz Prozessbezogener Ansatz Kosten/Nutzen-bezogener Ansatz

6 © Prof. T. Kudraß, HTWK Leipzig Produktbezogener Ansatz Qualität = messbare, genau spezifizierbare Größe, beschreibt das Produkt Keine Berücksichtigung von subjektiven Wahrnehmungen und Beobachtungen Berücksichtigt nur das Endprodukt – nicht den Kunden! Ermöglicht Ranking von Produkten gleicher Kategorie

7 © Prof. T. Kudraß, HTWK Leipzig Benutzerbezogener Ansatz Qualität durch den Benutzer festgelegt (fitness for use) Unterschiedliche Wünsche und Bedürfnisse verschiedener Benutzer Problem für Hersteller – Vage Vorstellungen der Anwender – Bedürfnisse der Benutzer rechtzeitig erkennen

8 © Prof. T. Kudraß, HTWK Leipzig Prozessbezogener Ansatz Qualität des Produkts hängt ab vom richtigen Prozess der Erstellung Spezifikation und Kontrolle des Erstellungs- prozesses Ständige Anpassung des Prozess an neue Kundenbedürfnisse

9 © Prof. T. Kudraß, HTWK Leipzig Definition Qualität Qualität [DIN 55350, Teil 11] Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht Software-Qualität [DIN ISO 9126] ist die Gesamtheit der Merkmale und Merkmals- werte eines SW-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen

10 © Prof. T. Kudraß, HTWK Leipzig Aufbau von FCM-Qualitätsmodellen Software-Qualität Q-Merkmal 1 ( factor 1 ) Q-Merkmal 2 ( factor 2 ) Q-Merkmal n ( factor n )... Q-Teilmerkmal 1 ( criterion 1 ) Q-Teilmerkmal 2 ( criterion 2) Q-Teilmerkmal 3 ( criterion 3) Q-Teilmerkmal n ( criterion n) Q-Indikatoren ( metrics)

11 © Prof. T. Kudraß, HTWK Leipzig Qualitätsmerkmale für Software- Produkte Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit Quelle: DIN-Norm ISO 9126

12 © Prof. T. Kudraß, HTWK Leipzig Funktionalität Richtigkeit – Liefert richtige oder vereinbarte Ergebnisse Angemessenheit – Eignung der Funktionen für spezifizierte Aufgaben Interoperabilität – Zusammenwirken mit vorgegebenen Systemen Ordnungsmäßigkeit – Erfüllung von Normen, Vereinbarungen, gesetzl. Vorschriften Sicherheit – Unberechtigten Zugriff auf Programme und Daten verhindern

13 © Prof. T. Kudraß, HTWK Leipzig Zuverlässigkeit Reife – Geringe Versagenshäufigkeit durch Fehlerzustände Fehlertoleranz – Bewahrt Leistungsniveau bei Fehlern oder Nichteinhaltung Schnittstelle Wiederherstellbarkeit – Wiederherstellung des Leistungsniveaus bei einem Versagen – Wiedergewinnung der betroffenen Daten – Erforderliche Zeit und Aufwand berücksichtigen

14 © Prof. T. Kudraß, HTWK Leipzig Benutzbarkeit Verständlichkeit – Aufwand für den Benutzer, Konzept und Anwendung zu verstehen Erlernbarkeit – Aufwand für den Benutzer, die Anwendung zu erlernen (z.B. Bedienung, Ein-/Ausgabe) Bedienbarkeit

15 © Prof. T. Kudraß, HTWK Leipzig Effizienz Zeitverhalten – Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausführung Verbrauchsverhalten – Anzahl und Dauer der benötigten Betriebsmittel für die Funktionen

16 © Prof. T. Kudraß, HTWK Leipzig Änderbarkeit Analysierbarkeit – Aufwand zur Fehlerdiagnose oder zur Bestimmung änderungsbedürftiger Teile zu bestimmen Modifizierbarkeit – Aufwand für Verbesserung, Fehlerbeseitigung, Anpassung an Umgebungsänderungen Stabilität – Wahrscheinlichkeit für unerwartete Wirkungen bei Änderungen Prüfbarkeit – Aufwand zur Prüfung der geänderten Software

17 © Prof. T. Kudraß, HTWK Leipzig Übertragbarkeit (Portierbarkeit) Anpassbarkeit – Anpassung der Software an verschiedene, festgelegte Umgebungen (organisatorisch, Hardware, Software) Installierbarkeit – Aufwand zum Installieren der SW in einer festgelegten Umgebung Konformität – Erfüllung von Normen oder Vereinbarungen zur Übertrag- barkeit durch die Software Austauschbarkeit – Verwendung der Software anstelle einer anderen in deren Umgebung

18 © Prof. T. Kudraß, HTWK Leipzig FURPS Qualitätsmodell Entwickelt von HP 1985 Merkmale (stark kundenorientiert definiert) Functionality Usability Reliability Performance Supportability

19 © Prof. T. Kudraß, HTWK Leipzig GQM-Ansatz: Goal-Question-Metric Vorgehensmodell 1. Definiere die Auswertungsziele für alle zu erfüllenden Qualitätsmerkmale 2. Leite alle Fragestellungen ab, die zu einer Quantifizierung dieser Ziele führen können 3. Leite alle Maße ab, die Informationen zur Beantwortung der Fragestellungen beitragen 4. Entwerfe einen Mechanismus zur möglichst genauen Erfassung der Messwerte 5. Validiere die Messwerte bezüglich aller primitiven Maße 6. Interpretiere die Messergebnisse zur Gesamtbewertung der Qualitätsziele

20 © Prof. T. Kudraß, HTWK Leipzig Beispiel für ein Software- Bewertungsmodell Z1 F2 M1 Z2Z3Z4 F1F3F4F5F6 M2M3M4M5 Auswertungsziele (goals) Abgeleitete Frage- stellungen(questions) Primitive Maße (metrics)

21 © Prof. T. Kudraß, HTWK Leipzig G: Muster zur Formulierung von Zielen im GQM-Ansatz Zweck der Studie – Prozess, Produkt, Modell, Maß Blickwinkel der Studie – Entwickler, Manager, SW-QS, Auftraggeber, Firmenleitung Umgebung der Studie – Aspekte des Prozesses, Personal, Anwendung, Methoden, Werkzeuge u.a. Faktoren

22 © Prof. T. Kudraß, HTWK Leipzig Q1: Auswertungsfragen zur Charakterisierung von Prozessen Qualität der Durchführung Anwendungsbereich – Beurteile Objekte des Prozesses sowie Kenntnis des Personals darüber Aufwand der Durchführung Ergebnis der Durchführung Rückkopplung von der Durchführung

23 © Prof. T. Kudraß, HTWK Leipzig Q2: Auswertungsfragen zur Charakterisierung von Produkten Definition des Produkts – Physische Eigenschaften, z.B. Umfang, Komplexität, Programmiersprache – Kosten, z.B. Zeitaufwand, Entwicklungsphasen, Aktivitäten – Änderungen, z.B. Fehlerursachen, Fehler, Fehlverhalten – Umfeld, z.B. zu erwartendes Benutzerprofil Bewertung des Produkts – Relativ zu einem bestimmten Qualitätsmerkmal, z.B. Zuverlässigkeit, Korrektheit, Zufriedenheit der Benutzer

24 © Prof. T. Kudraß, HTWK Leipzig Erweitertes GQM-Bewertungsmodell Wir untersuchen Produkte und... Qualitätsbaum-Quellcode TestbarkeitWartbarkeit Strukturiertheit Innere Struktur Größe des Programms? Lines of Codes Qualitätsbaum-Analyse Weitere Qualitätsbäume... Ziel ( goal ) Qualitätsbäume für jedes Zwischenprodukt Fragen ( questions ) Kennzahlen ( metrics )

25 © Prof. T. Kudraß, HTWK Leipzig Qualitätsbaum Wartbarkeit SWS ist leicht wartbar WB SWS höchstmöglich standardisiert WB1 SWS leicht verständlich WB2 SWS gut änderbar WB3 SWS gut testbar TB Hält vereinbarte Standards voll- ständig ein WB11 Ist möglichst ein- heitlich realisiert WB12 Ist eindeutig interpretierbar WB21 SWS leicht verständlich WB22 Ist gut dokumentiert WB23 Ist gut strukturiert WB31 Techniken zur Er- stellung des SWS angemessen WB32 Umfang des SWS entspricht optimal der Aufgabe WB33 Jede Kompo- nente in sich gut strukturiert WB311 Beziehungen zwischen den Komponenten einfach WB312

26 © Prof. T. Kudraß, HTWK Leipzig Qualitätszielbestimmung Qualitätsstufen – Wertebereich auf einer Skala zur Klassifizierung von Software entspr. Qualitätsanforderungen [ISO9126] Messwert Maßskala Qualitätsstufen Sehr gut Gut Normal Schlecht annehmbar nicht annehmbar

27 © Prof. T. Kudraß, HTWK Leipzig Qualitätsanforderungen Ergeben sich aus den Qualitätszielen – Welche Qualitätsmerkmale relevant? – Welche Qualitätsstufe muss erreicht werden? Auswirkungen auf den SW-Entwicklungsprozess – Produktorientierte Anforderungen Einfluss auf: Methoden, Werkzeuge, Richtlinien, Checklisten im Entwicklungsprozess – Prozessorientierte Anforderungen Änderung des SW-Entwicklungsprozesses

28 © Prof. T. Kudraß, HTWK Leipzig Qualitätsmanagement vs. Qualitätssicherung Qualitätsmanagement – Alle managementbezogenen Tätigkeiten, die Qualitätspolitik, Ziele und Verantwortungen im Rahmen eines QM-Systems festlegen – Mittel: Q-Planung, Q-Lenkung, Q-Sicherung, Q-Prüfung Qualitätssicherung – Alle technikorientierten Aktivitäten innerhalb des QM-Systems zur Erfüllung der Qualitätsanforderungen – Analytische Maßnahmen in der SW-Entwicklung

29 © Prof. T. Kudraß, HTWK Leipzig Produktorientiertes Qualitätsmanagement Inhalt – Überprüfung von SW-Produkten und Zwischen-ergebnissen auf festgelegte Qualitätsmerkmale – Sind Gegenstand der Zertifizierung Maßnahmen (Beispiele) – Templates für Pflichtenheft (Richtlinie) – Einsatz von Strukturierter Analyse (SA) (Methode) – Programmierrichtlinien Kein GOTO Überprüfung aller Eingabegrößen (defensives Programmieren) Wiederverwendung von SW-Bausteinen bei OO Programmierung

30 © Prof. T. Kudraß, HTWK Leipzig Prozessorientiertes Qualitätsmanagement Inhalt – Bezieht sich auf den Erstellungsprozess der Software – Permanente Anpassung an dynamische Qualitätsanforderungen Maßnahmen (Beispiele) – Standardisierter Entwicklungsprozess Welche Teilprodukte (deliverables) wann und von wem? – Einsatz von Konfigurationsmanagement – Festlegung eines Vorgehensmodells

31 © Prof. T. Kudraß, HTWK Leipzig Konstruktives Qualitätsmanagement Maßnahmen, die a priori bestimmte Qualitäts- eigenschaften von Produkt / Prozess gewährleisten Konstruktives Qualitätsmanagement Technische Maßnahmen Organisatorische Maßnahmen MethodenSprachenWerkzeugeRichtlinienStandardsChecklisten

32 © Prof. T. Kudraß, HTWK Leipzig Analytisches Qualitätsmanagement Diagnostische Maßnahmen zur Prüfung und Bewertung der Qualität der Prüfobjekte Messen vorhandenes Qualitätsniveau, Ausmaß und Ort der Defekte Klassifikation – Bezug der Prüfung (Produkt- oder Prozessprüfung) – Automatisierungsgrad (manuell und/oder Einsatz von Software-Werkzeugen) – Nachvollziehbarkeit der Prüfung (Selbstprüfung oder Nachweisführung) – Einsatzbereich der Prüfung: Definitions-,Entwurfs-,Imple

33 © Prof. T. Kudraß, HTWK Leipzig Maßnahmen zum analytischen Qualitätsmanagement Analysierende Verfahren Programmverifikation Statische Analyse Animation Dynamischer Test Testende Verfahren Review Inspektion Durchsprache Walkthrough Audit Symbolischer Test Simulation Schreibtischtest = manuell

34 © Prof. T. Kudraß, HTWK Leipzig Aktivitäten des Qualitätsmanagement Qualitätsplanung Qualitätslenkung und –sicherung Qualitätsprüfung

35 © Prof. T. Kudraß, HTWK Leipzig Qualitätsplanung Festlegung der Qualitätsanforderungen an Produkt und Prozess – Auswahl und Festlegung eines Qualitätsmodells – Festlegung von Soll-Qualitätsstufen für Qualitätsindikatoren z.B. Zuverlässigkeit – Anzahl Fehler pro Monat – 0.01 – Festlegung von Prioritäten bei gegenläufigen Anforderungen Festlegung von allgemeinen und produkt-spezifischen Q-Lenkungs- und –Sicherungs-Maßnahmen – z.B. Messpunkte im Entwicklungsprozess zur Vorhersage der Ziele, Auswahl von Methoden und Werkzeugen zur Erfassung der Messwerte

36 © Prof. T. Kudraß, HTWK Leipzig Qualitätslenkung Umsetzung der Qualitätsplanung Steuert, überwacht und korrigiert den Entwicklungsprozess, um Q-Anforderungen zu erfüllen Überwacht Qualitätsprüfung nach Plan Auswertung der Ergebnisse durch Vergleich Soll-Ist Eng verknüpft mit SW-Management

37 © Prof. T. Kudraß, HTWK Leipzig Qualitätsprüfung Führt die im Rahmen der Q-Planung festgelegten Maßnahmen durch zur Bestimmung Ist Überwacht Umsetzung der konstruktiven Maßnahmen Aktivitäten – Erfassung von Messdaten über Werkzeuge, Formblätter / Interviews – Test (zur Erfassung dynamischer Produktmerkmale) – Inspektionen, Reviews, Walkthroughs – Mängel- und Fehleranalysen auf Basis von Problemberichten

38 © Prof. T. Kudraß, HTWK Leipzig Qualitätssicherungsplan Was muss gesichert werden? – Identifizierung der relevanten Q-Merkmale und ihre Quantifizierung in Form von Metriken Wann muss gesichert werden? – Festlegung der Zeitpunkte für Datenerfassung während Entwicklungsprozess Wie muss gesichert werden? – Auswahl der Techniken und Methoden Von wem muss gesichert werden? – Festlegung von Verantwortlichkeiten (Rollen)

39 © Prof. T. Kudraß, HTWK Leipzig Prinzipien der Software- Qualitätssicherung Prinzip der produkt- und prozessabhängigen Qualitätszielbestimmung Prinzip der quantitativen Qualitätssicherung Prinzip der maximalen konstruktiven Qualitätssicherung Prinzip der frühzeitigen Fehlerentdeckung und –behebung Prinzip der entwicklungsbegleitenden, integrierten Qualitätssicherung Prinzip der unabhängigen Qualitätssicherung

40 © Prof. T. Kudraß, HTWK Leipzig Produkt- und prozessabhängige Qualitätszielbestimmung Qualitätsziele explizit und transparent vor Entwicklungsbeginn festlegen – Vorteile für Auftraggeber (Kostentransparenz, Festlegung der Anforderungen) – Vorteile für Lieferant Maßnahmen für Entwicklungsprozess und Q-Prüfung Wahl geeigneter Methoden und Werkzeuge – Planungs- und Kalkulationssicherheit für beide

41 © Prof. T. Kudraß, HTWK Leipzig Quantitative Qualitätssicherung Messen ist zwar schwer, aber nützlich für... – besseres Verständnis unterschiedlicher Q-Merkmale (deskriptive Modelle) – bessere Planung und Sicherung von Q-Merkmalen (präskriptive Modelle) – Verbesserung von Entwicklungsansätze Methoden und Werkzeuge zur Planung und Durch- führung der Datenerfassung sowie zur statistischen Auswertung / Präsentation von Messdaten Metriken sind ziel- und kontextabhängig!

42 © Prof. T. Kudraß, HTWK Leipzig Maximale konstruktive Qualitätssicherung Vorbeugen ist besser als heilen! Viel konstruktiv – wenig analytisch! Beispiele: – Vollständige Zweigüberdeckung, wenn Verzweigungslogik nicht zu komplex – Explizite Vereinbarung aller Variablen mit Typfestlegung Vorteile: – Direkte Verbesserung der Produktqualität – Reduziert und ermöglicht analytische Maßnahmen – Vermeidung von Fehlern

43 © Prof. T. Kudraß, HTWK Leipzig Frühzeitige Fehlerentdeckung und -behebung Fehler – Jede Abweichung von den Anforderungen des Auftraggebers – Jede Inkonsistenz in den Anforderungen Jede Verzögerung bei Entdeckung exponentieller Kostenanstieg Ziel: QM-Maßnahmen (konstruktiv / analytisch) verstärkt am Beginn der SW-Entwicklung einsetzen Vermeidung von Summationseffekten in nach- folgenden Phasen

44 © Prof. T. Kudraß, HTWK Leipzig Summation von Fehlern und Mängeln Fehlerhafte Anforderungen Korrekte Anforderungen Spezifikations- fehler Korrekte Spezifikation Entwurfs- fehler Korrekter Entwurf Programm- fehler Korrektes Programm Korrigierte Fehler Korrektes Verhalten Anforderungs- definition System- spezifikation Entwurf Realisierung Test und Integration Induzierte Fehler aus Anforderungen Induzierte Fehler aus Anforderungen | Spezifikation Induzierte Fehler aus Anforderungen | Spezifikation | Entwurf Bekannte un- korrigierte Fehler Unbekannte Fehler

45 © Prof. T. Kudraß, HTWK Leipzig Vorzeitige Fehlerentdeckung Vorteile Vermeidung von Fehlern in späteren Phasen Reduzierung von Kosten – 55% aller Fehler entstehen in der Anforderungs- und Entwurfsphase [IEEE Software, Jan.1985] – 35% dieser Fehler bei Abnahme / im Betrieb gefunden – Fehlerbeseitigung 100fach höher als in der Definitionsphase Mit höherer Wahrscheinlichkeit Fehlerkorrektur richtig Reduzierung der Fehlerfortpflanzung Fehler besser vermeiden – oder zumindest frühzeitig erkennen!

46 © Prof. T. Kudraß, HTWK Leipzig Entwicklungsbegleitende, integrierte Qualitätssicherung Q-Sicherung begleitet gesamte SW-Entwicklung in jeder Phase Vorteile: – Einbettung der Q-Sicherung in das organisatorische Ablauf- modell der SW-Entwicklung – QS findet dann statt, wenn sie angebracht ist – QS natürlicher Teil der Software-Erstellung – Teilprodukt erst dann in der nächster Phase verfügbar, wenn eine bestimmte Qualität gesichert ist – Qualitätsniveau zu jedem Zeitpunkt sichtbar – Realistische Beurteilung des Entwicklungsfortschritts

47 © Prof. T. Kudraß, HTWK Leipzig Entwicklungsbegleitende, integrierte Qualitätssicherung Produktmodell Definieren Entwerfen Produktarchitektur Implementieren Produkt Änderungen Prüfen und freigeben Änderungen Prüfen und freigeben Änderungen Software-Entwicklung Produktmodell Definieren Entwerfen Produktarchitektur Implementieren Produkt Produktmodell Definieren Entwerfen Produktarchitektur Implementieren Produkt Software-Entwicklung QS- Plan

48 © Prof. T. Kudraß, HTWK Leipzig Unabhängige Qualitätssicherung testing is a destructive process, even a sadistic process,... [Myers, 1979] 2 Alternativen – QS organisatorisch unabhängig von der Entwicklung – QS ist Teil der Entwicklung Vor- und Nachteile beider Ansätze

49 © Prof. T. Kudraß, HTWK Leipzig Alternative 1: QS unabhängig von Entwicklung Vorteile – Entwicklung kann keinen Druck auf die QS ausüben – QS ist neutral – Klare Budgetaufteilung möglich – Bedeutung der QS (kein Anhängsel der Entwicklung) Nachteile – Gefahr der Isolierung von der Entwicklung – gleichmäßige Personalauslastung schwierig

50 © Prof. T. Kudraß, HTWK Leipzig Alternative 2: QS Teil der Entwicklung Vorteile – Personal kann flexibler eingesetzt werden – QS nicht im Abseits, sondern bekommt alles mit – Gemeinsame Teamarbeit und vertrauensvollere Zusammenarbeit leichter möglich Nachteile – Entwicklungs-Management kann Druck auf die QS ausüben – Mögliche Umverteilung der Budgetmittel zugunsten der Entwicklung

51 © Prof. T. Kudraß, HTWK Leipzig Personal-Alternativen Personal für die Qualitätssicherung eingestellt und nur in der QS tätig Jeder Mitarbeiter rotiert in festgelegten Abständen zwischen QS und Entwicklung Jeder Mitarbeiter arbeitet sowohl in Entwicklung als auch in der QS bei anderen Entwicklungen

52 © Prof. T. Kudraß, HTWK Leipzig Alternative 1: Nur in QS tätig Vorteile – Mitarbeiter mit entsprechender Neigung und Ausbildung einstellen – Hoher Spezialisierungsgrad möglich Nachteile – Mitarbeiter entfernen sich von Anwendungs- problemen – Mitarbeiter haben keine Erfahrung mit der Entwicklung von Software

53 © Prof. T. Kudraß, HTWK Leipzig Alternative 2: Rotation Vorteile – Jeder Mitarbeiter sieht auch die Probleme der anderen Seite – Systematischer Wissenstransfer sichergestellt – Vermeidet schlechtes Image der QS (Motto: Alle, die nicht gut entwickeln, kommen in die QS) Nachteile – Mitarbeiten müssen auch Tätigkeiten ausführen, zu denen sie keine Lust haben – Mitarbeiter u.U, überfordert, beide Tätigkeiten professionell durchzuführen wegen der verschiedenen Spezialkenntnisse

54 © Prof. T. Kudraß, HTWK Leipzig Alternative 3: QS & Entwicklung parallel Vorteile – Flexibler Personaleinsatz möglich – Kein Overhead für die Qualitätssicherung Nachteile – Vermischung von Entwicklungsarbeit und QS keine Arbeit wird richtig gemacht – Dauernder Wechsel zwischen verschiedenen Tätigkeiten

55 © Prof. T. Kudraß, HTWK Leipzig Aufteilung der Verantwortung zwischen Entwicklung und QS QS zuständig für Überprüfung – Entwickler konzentriert sich auf konstruktive Aspekte – Sinkende Sorgfalt bei Entwicklung (Lass die anderen meine Fehler finden!) Entwicklung für definierte Qualität zuständig – Weitere Überprüfung durch die QS erst bei best. Qualitätsgrad – Vorteile: Klar definierte Verantwortlichkeiten Entwickler muss sein eigenes Produkt überprüfen Höhere Eigenverantwortlichkeit der Entwickler – Nachteil Erfordert messbare Qualitätsstufen

56 © Prof. T. Kudraß, HTWK Leipzig Quantitative Qualitätssicherung Entlastet QS, da Maße die Überprüfung der Q- Maßnahmen erleichtern – z.B. Zweigüberdeckung von 80% in Programmen – Alle Analyseberichte fehlerfrei (von Tool erzeugt) Zusätzliche Aktivitäten – Sammlung von Daten (Maßen) – Validierung dieser Daten – Einrichten einer quantitativ orientierten Entwickungs- datenbank

57 © Prof. T. Kudraß, HTWK Leipzig Eigenständige Organisationseinheit Qualitätssicherung Teil der Entwicklung oder eigenständige organisatorische Einheit Kritische Mitarbeiterzahl (mind. 15% der Entwicklungs-Einheit) Vorteile – Objektive, unabhängige Qualitätssicherung – Heilsame Wirkung auf die Entwicklung, wenn eigenes Produkt noch von der QS überprüft wird – Qualitätsvergleiche über mehrere Produkte möglich

58 © Prof. T. Kudraß, HTWK Leipzig EINHEIT 2: Qualität in der SW-Entwicklung V-Modell Submodell QS im V-Modell: Aktivitäten und Produkte Beispiel-Entwicklungsprozess

59 © Prof. T. Kudraß, HTWK Leipzig V-Modell AbnahmetestAnforderungs- definition Grobentwurf Feinentwurf Modulimple- mentation Systemtest Integrationstest Modultest Validation Verifikation Anwendungsszenarien Testfälle

60 © Prof. T. Kudraß, HTWK Leipzig V-Modell (Forts.) Erweiterung des Wasserfallmodells: Integration der Qualitätssicherung Bestandteile – Vorgehensmodell Was ist zu tun? – die Methodenzuordnung Wie ist etwas zu tun? – funktionale Werkzeuganforderungen Womit ist etwas zu tun? Entwicklung durch BMVg, BMI – Anwendung auch in der Industrie – regelmäßige Weiterentwicklung Öffentlich zugänglich

61 © Prof. T. Kudraß, HTWK Leipzig V-Modell Einführung Die drei Ebenen der Standardisierung

62 © Prof. T. Kudraß, HTWK Leipzig Submodelle im V-Modell Software-Erstellung (SE) erstellt das System bzw. die Software. Qualitätssicherung (QS) gibt Qualitätsanforderungen, Prüffälle und -kriterien vor und untersucht die Produkte und die Einhaltung der Standards Konfigurationsmanagement (KM) verwaltet die erzeugten Produkte Projektmanagement (PM) plant, kontrolliert und informiert die Submodelle SE, QS und KM

63 © Prof. T. Kudraß, HTWK Leipzig Zusammenwirken der 4 Submodelle

64 © Prof. T. Kudraß, HTWK Leipzig Arbeitsteilung zwischen SE und QS im V-Modell

65 © Prof. T. Kudraß, HTWK Leipzig Analytische Maßnahmen im V-Modell Prüfung SelbstprüfungVerifikation ProzessprüfungProduktprüfung Validation

66 © Prof. T. Kudraß, HTWK Leipzig Rollenverteilung bei der Durchführung von Prüfaktivitäten PrüfaktivitätProdukterstellerQS-Verant- wortlicher PrüferAG/Anwender Selbstprüfungv Prozessprüfungvm Produktprüfungbmv Validationmvm v verantwortlichb beratendm mitwirkend

67 © Prof. T. Kudraß, HTWK Leipzig Selbstprüfungen Art der Vorgaben für den Entwickler Verpflichtungen seitens des Entwicklers Keine Vorgaben (außer generell Nachvollziehbarkeit) Dokumentation in freier Form Statistische Vorgaben (z.B. Mindestabdeckung) zur Durchführung der Prüfung Dokumentation muss den Vorgaben entsprechen Genaue Spezifikation der Vorbereitung, Durchführung und Auswertung der Prüfung Prüfprotokoll gemäß Submodell QS

68 © Prof. T. Kudraß, HTWK Leipzig Formelle Prüfung Beteiligung QS-Verantwortlicher B1 – QS-Verantw. führt formelle Prüfung selbst durch – QS-Verantw. entscheidet über Annahme (akzeptiert) oder Ablehnung (in Bearb.) B2 – QS-Verantw. begleitet die Durchführung der Prüfung – QS-Verantw. entscheidet über Annahme der Prüfung – Durchführung der Prüfung durch Entwicklungsteam-Mitglied B3 – QS-Verantw. entscheidet allein aufgrund der Prüfdokumentation – Durchführung der Prüfung durch Entwicklungsteam-Mitglied

69 © Prof. T. Kudraß, HTWK Leipzig Kritikalität = Bedeutung von Fehlverhalten Kritikalität... bei administrativen Administrationssystemen... bei technischen Systemen hochmacht sensitive Daten für unberechtigte Personen zugänglich, verhindert administrative Vorgänge (z.B. Gehaltsauszahlung), führt zu Fehlentscheidungen infolge fehlerhafter Daten kann zum Verlust von Menschenleben führen mittelkann die Gesundheit von Menschen gefährden oder zur Zerstörung von Sachgütern führen niedrigverhindert Zugang zu Informationen, die regelmäßig benötigt werden kann zur Beschädigung von Sachgütern führen, ohne jedoch Menschen zu gefährden keinebeeinträchtigt die zugesicherten Eigenschaften nicht wesentlich gefährdet weder Gesundheit noch Sachgüter

70 © Prof. T. Kudraß, HTWK Leipzig Submodell QS Aktivitäten – Planungsaktivitäten (QS1, QS2) – Prüfaktivitäten (QS3, QS4) – Lenkungsaktivitäten (QS5) Produkte – QS-Plan – Prüfplan – Prüfspezifikation – Prüfprozedur – Prüfprotokoll

71 © Prof. T. Kudraß, HTWK Leipzig Submodell QS im Überblick QS 1QS-Initialisierung QS 1.1 QS-Plan erstellen QS 1.2Prüfplan erstellen QS-Plan QS 2Prüfungsvorbereitung QS 2.1 Prüfmethoden und –kriterien festlegen QS 2.2Prüfumgebung definieren Prüfplan QS 2.3 Prüffälle festlegen Prüfspezifikation QS 2.4Prüfprozedur erstellen Prüfprozedur QS 3Prozessprüfung von Aktivitäten Prüfprozedur QS 4Produktprüfung QS 4.1 Prüfbarkeit feststellen QS 4.2Produkt inhaltlich prüfen Prüfprotokoll QS 5Berichtswesen Berichtsdokumente

72 © Prof. T. Kudraß, HTWK Leipzig QS 1: QS-Initialisierung

73 © Prof. T. Kudraß, HTWK Leipzig Inhalte eines QS-Plans im V-Modell 2.Qualitätsziele und Risiken im Projekt 2.1 Qualitätsziele für Produkte und Prozesse 2.2Qualitätsrisiken 2.3 Maßnahmen aufgrund der Qualitätsziele und -risiken 3.QS-Maßnahmen gemäß Kritikalität und IT-Sicherheit 3.1Verwendete Richtlinien oder Normen 3.2Einstufungsbedingte QS-Maßnahmen 4.Entwicklungsbegleitende Qualitätssicherung 4.1Zu prüfende Produkte 4.2Zu prüfende Aktivitäten 5.Spezifische Kontrollmaßnahmen 5.1Eingangskontrolle von Fertigprodukten 5.2Kontrolle von Unterauftragnehmern 5.3Ausgangskontrolle der Softwarebausteine 5.4Änderungskontrolle 5.5Kontrolle von Bearbeitungskompetenzen 5.6Kontrolle des Konfigurationsmanagements

74 © Prof. T. Kudraß, HTWK Leipzig Prüfplan im V-Modell Prüfgegenstände Aufgaben und Verantwortlichkeiten bei den Prüfungen Zeitliche Planung Erforderliche Ressourcen Welche Produkte und Aktivitäten in welchem Zustand werden wann, von wem und womit geprüft?

75 © Prof. T. Kudraß, HTWK Leipzig QS 2: Prüfungsvorbereitung

76 © Prof. T. Kudraß, HTWK Leipzig Inhalte einer Prüfspezifikation im V-Modell 2.Anforderungen 2.1 Einstufung der Funktionseinheit hinsichtlich Kritikalität und IT-Sicherheit 2.2Prüfanforderungen 3.Methoden der Prüfung 4.Prüfkriterien 4.1Abdeckungsgrad 4.2Checklisten 4.3Endekriterien 5.Prüffälle 5.1Prüffallbeschreibung 5.2Abdeckungsmatrix 5.2.1Architektur-Elemente und Schnittstellen 5.2.2Fachliche und technische Anforderungen

77 © Prof. T. Kudraß, HTWK Leipzig Prüfprozedur Arbeitsseinleitung Für jeden Prüfungsgegenstand festgelegt Inhalt – Genaue Anweisungen für jede einzelne Prüfung – Definiert einzelne Schritte der Prüfung – Festlegung der zu erwartenden Prüfergebnisse – Vorschriften zur Prüfungsvor- und -nachbereitung

78 © Prof. T. Kudraß, HTWK Leipzig QS 3: Prozessprüfung Prüfung von Aktivitäten auf Einhaltung vorgegebener Vorgehensweisen und Projektstandards Umfasst: SE, QS, KM, PM (besonders Konfigurationsmanagement) Bei Prüfung von QS-Aktivitäten – Rollenverteilung absichern!

79 © Prof. T. Kudraß, HTWK Leipzig QS 4: Produktprüfung

80 © Prof. T. Kudraß, HTWK Leipzig QS 4.1: Prüfbarkeit feststellen Checkliste für Produkt – Ist das Produkt gut verstehbar und übersichtlich gestaltet? – Sind alle Produkte, aus denen das zu prüfende Produkt hervorging, verfügbar? – Sind die Anforderungen, gegen die das Produkt geprüft werden soll,alle dokumentiert, klar und verständlich? – Wurden die anzuwendenden Richtlinien und Normen eingehalten?

81 © Prof. T. Kudraß, HTWK Leipzig QS 4.2: Produkt inhaltlich prüfen Prüfprotokoll Pro Prüfgegenstand Pro Prüfung Aufzeichnungen über den Verlauf der Prüfung Gegenüberstellung von Soll- und Ist-Ergebnis

82 © Prof. T. Kudraß, HTWK Leipzig QS 5: QS-Berichtswesen Auswertung der Prüfprotokolle – Anzahl der Probleme – Schwere der Probleme – Klassifikation der Probleme (gleichartige Probleme auch woanders?) – Ursache der Probleme, z.B. fehlende Ressourcen und Qualifikation, ungeeignete Tools Bewahrung von Erfahrungen über Projektgrenzen hinweg Erfahrungen mit QS-Maßnahmen Projektabschluss- bericht

83 © Prof. T. Kudraß, HTWK Leipzig EINHEIT 3: Qualität in Analyse & Design A: Was sind gute Business-Spezifikationen? B: Fall-Beispiel Seminarorganisation Manuelle Prüfmethoden – Reviews u.a. Methoden Verbesserung der Prozess-Qualität (Überblick)

84 © Prof. T. Kudraß, HTWK Leipzig Fall-Beispiel Seminarorganisation Die Firma Teachware veranstaltet öffentliche und firmeninterne Seminare mit externen Dozenten. Sie besteht aus: – Geschäftsführer: verantwortlich für Planung und Verwaltung der Seminare und Dozenten – Kundensachbearbeiter: verwaltet Kunden und Buchungen – Kundenbetreuer: betreut Kunden und Dozenten vor Ort

85 © Prof. T. Kudraß, HTWK Leipzig Seminar-Organisation Pflichtenheft Pflichtenheft 1. Ziele 2. Produkteinsatz 3. Produktumgebung 4. Produktfunktionen 5. Produktdaten 6. Produktleistungen (nicht-funktionale Anforderungen) 7. Benutzerschnittstelle 8. Qualitätsziele 9. Globale Testfälle (Use Cases) 10. Entwicklungsumgebung

86 © Prof. T. Kudraß, HTWK Leipzig Seminar-Organisation Objektorientierte Analyse OOA-Diagramm

87 © Prof. T. Kudraß, HTWK Leipzig Manuelle Prüfmethoden Eigenschaften – Produkte und Teilprodukte manuell analysiert, geprüft und begutachtet – Ziel: Auffinden von Fehlern, Defekten, Inkonsistenzen und Unvollständigkeiten – Überprüfung in Gruppensitzung durch kleines Team mit definierten Rollen

88 © Prof. T. Kudraß, HTWK Leipzig Manuelle Prüfmethoden Voraussetzungen Aufwand und Zeit fest einplanen Jedes Mitglied des Prüfteams muss in der Prüfmethode geschult sein Prüfergebnisse nicht zur Beurteilung von Mitarbeitern benutzen Prüfmethode schriftlich festlegen Hohe Priorität (kurzfristig durchführen nach Beantragung) Keine Vorgesetzten und Zuhörer bei den Prüfungen

89 © Prof. T. Kudraß, HTWK Leipzig Manuelle Prüfmethoden - Vorteile Einzige Möglichkeit zur Überprüfung von Semantik Effizientes Mittel zur Qualitätssicherung Notwendige Ergänzung werkzeuggestützter Prüfungen Verantwortung für Produktqualität aufs ganze Team übertragen Da Überprüfung in Gruppensitzung, wird Wissensbasis der Teilnehmer verbreitert Jedes Mitglied des Prüfteams lernt Arbeitsweise der anderen kennen Bemühen um verständliche Ausdrucksweise Mehr Prüfungen Weniger Fehler

90 © Prof. T. Kudraß, HTWK Leipzig Manuelle Prüfmethoden - Nachteile Hoher Aufwand – Bis zu 20% der Erstellungskosten für das Prüfobjekt – Overhead (zusätzliche Protokolle, Auswertungen) Situation für die Autoren – Psychologisch manchmal schwierig Anklagebank

91 © Prof. T. Kudraß, HTWK Leipzig Manuelle Prüfmethoden Inspektion formales Review Review Walkthrough abgeschwächtes Review Stellungnahme

92 © Prof. T. Kudraß, HTWK Leipzig Reviews Definition – Manuelle, semiformale Prüfmethode, um Stärken und Schwächen eines schriftlichen Dokuments anhand von Referenzunterlagen zu identifizieren und durch den Autor beheben zu lassen Ziel – Feststellung von Mängeln, Fehlern, Inkonsistenzen, Unvollständigkeiten – Auffinden von Verstößen gegen Vorgaben, Richtlinien, Standards, Pläne – Formale Planung und Strukturierung des Bewertungs- prozesses und formale Abnahme des Prüfobjekts

93 © Prof. T. Kudraß, HTWK Leipzig Reviews (Forts.) Objekte der Prüfung – Jeder lesbare Teil von Software, z.B. Dokument, Quellcode- Modul, Spezifikation Referenzunterlagen – Ursprungsprodukt – Vorgaben für die Erstellung des Prüfobjekts – Relevante Richtlinien und Standards – Fragenkataloge mit Listen von Fragen, die im Review beantwortet werden (Checklisten) – Evtl. Anleitung für Durchführung des Reviews

94 © Prof. T. Kudraß, HTWK Leipzig Reviews (Forts.) Beschreibungsform der Prüfung – Prüfobjekte Informal (z.B. Pflichtenheft) Semiformal (z.B. Pseudocode) Formal (z.B. OOA-Modell, Quellcode) – Bezugsobjekte Informal (z.B. Richtlinien) Semiformal (z.B. Pseudocode) Formal (z.B. OOA-Modell) Ergebnisse – Review-Protokolle – Empfehlung über Freigabe an Manager – Überarbeitetes Prüfobjekt

95 © Prof. T. Kudraß, HTWK Leipzig Reviews (Forts.) Teilnehmer – Review-Team mit 4-7 Personen: Moderator, Autor, Protokollführer, 2-5 Gutachter Durchführung – Eingangsprüfung – Evtl. Einführungssitzung: Vorstellung von Prüfobjekt – Individuelle Vorbereitung – Review-Sitzung – Überarbeitung des Prüfobjekts (durch den Autor) – Bei gravierenden Mängeln erneute Review-Sitzung

96 © Prof. T. Kudraß, HTWK Leipzig Ablauf eines Reviews

97 © Prof. T. Kudraß, HTWK Leipzig Reviews Kosten und Nutzen Kosten – 15-20% des Erstellungsaufwands des Prüfobjekts Beispiel: – Dokument mit 50 Seiten – 5 Gutachter (+Mod.+Autor), Vorb. 10 Seiten/Std., 2 Std. Sitzung – Summe Review-Aufwand 5 Personentage, Erstellungsaufwand 25 Personentage (bei 2 Seiten/Tag) Nutzen – 60-70% der Fehler in Dokument gefunden – Reduktion der Fehlerkosten in der Entwicklung von ca. 75% Code-Review: ähnliche Zahlen

98 © Prof. T. Kudraß, HTWK Leipzig Fallbeispiel Seminar-Organisation Unterlagen für Review Prüfobjekt – Klassen-Diagramm Seminarorganisation V1.1 Referenzunterlagen – Ursprungsprodukt: Pflichtenheft Seminar- organisation V 2.2 – Erstellungsregeln: OOA-Methode – Checklisten: Klassen, Attribute, Operationen, Assoziation & Aggregration

99 © Prof. T. Kudraß, HTWK Leipzig Inhalt des Review-Protokolls Datum Name von Moderator und Teilnehmer Prüfobjekt Referenzunterlagen Defekte mit folgenden Angaben: – Kurzbeschreibung des Defekts – Ort des Defekts – Bezug zu Regeln und Checklisten – Fehlergrad (leicht / schwer) – Wann identifiziert? (Sitzung / Vorbereitung) – Verbesserungsvorschläge (z.B. für Regeln, Checklisten) – Fragen an den Autor

100 © Prof. T. Kudraß, HTWK Leipzig Review-Protokoll: Beispiel Review Klassendiagramm Seminar- Organisation Beispiel-Protokoll

101 © Prof. T. Kudraß, HTWK Leipzig Inspektion formales Review [ANSI/IEEE Std ] Zusätzliche Eigenschaften: – Verbesserung der Entwicklungsregeln und des Entwicklungsprozesses – Metriken ermitteln (mit Hilfe von Statistiken über Erkennung von Defekten) – Inspektionsprotokoll stärker formalisiert als beim Review – Freigabe erfolgt durch Moderator

102 © Prof. T. Kudraß, HTWK Leipzig Walkthrough - Ablauf Prüfobjekt Individuelle Vorbereitung & Prüfung Gutachter Walkthrough-Sitzung Autor, Gutachter ProtokollPrüfobjekt Defekte Walkthrough

103 © Prof. T. Kudraß, HTWK Leipzig Walkthrough - Bewertung Vorteile – Geringer Aufwand – Auch für kleine Entwicklungsteams geeignet (<= 5Mitarbeiter) – Sinnvoll für unkritische Dokumente – Einbeziehung von Endbenutzern als Gutachter Erkennung von Unvollständigkeiten und Missverständnissen – Wissen über ein Dokument auf breite Basis stellen Nachteile – Nur wenige Defekte identifiziert – Autor kann Walkthrough-Sitzung dominieren und Gutachter blenden – Überarbeitung des Prüfobjekts im Ermessen des Autors, wird nicht nachgeprüft

104 © Prof. T. Kudraß, HTWK Leipzig Weitere Prüfmethoden Stellungnahme – Kommentare zum Prüfobjekt an den Autor auf dessen Bitte hin – Ungeplant, zwischen normalen Tätigkeiten Round Robin Review – Review-Sitzung mit umgekehrten Vorzeichen (Argumente für die Güte des Prüfobjekts suchen) Peer Review – Review-Team organisiert selbst Aufgabenteilung und Vorgehensweise – Ein Moderator: Sitzungsleitung, Organisation

105 © Prof. T. Kudraß, HTWK Leipzig Verbesserung der Prozessqualität (Überblick) ISO 9000-Ansatz TQM (Total Quality Management) CMM (Capability Maturity Matrix) Business Engineering

106 © Prof. T. Kudraß, HTWK Leipzig ISO 9000 Ansatz: Prozessqualität Allgemeingültige Anforderungen für Aufbau- und Ablauforganisation eines Unternehmens Definiert wichtige Dokumente und Inhalte Regelung von Zuständigkeiten, Befugnissen, Verantwortungsbereichen Orientiert sich am Auftraggeber-Lieferanten-Verhältnis Fordert organisatorische Unabhängigkeit der QS Integriert QS in die gesamte Organisation Ziel: reproduzierbare Entwicklungsprozesse Zertifikat: für betriebliche Abläufe (nicht Produkt!)

107 © Prof. T. Kudraß, HTWK Leipzig Bewertung ISO 9000 Vorteile – Externe Zertifizierung und Wiederholungsaudits QM- System aufrecht erhalten! – Erleichtert Akquisition von Aufträgen (Werbung) – Niedrigeres Produkthaftungsrisiko – Qualitätsbewusstsein Nachteile – Unsystematisch: Mischung von Tätigkeiten und Dokumenten – Keine saubere Trennung der QS- von anderen Aufgaben – Gefahr der Software-Bürokratie – Benötigt Unterstützung durch CASE-Werkzeuge – Standardisierte Verfahrensabläufe und Dokumente, oft zu starr

108 © Prof. T. Kudraß, HTWK Leipzig TQM-Ansatz M QT Totales Qualitätsmanagement Prozessqualität Produktqualität Kontinuierliche Qualitätsverbesserung Bereichs- und funk- tionsübergreifend Kundenorientierung Einbeziehung aller Mitarbeiter Vorbildfunktion des Managements Qualität wird bei Management- entscheidungen gleichberechtigt zu Kosten und Terminen bewertet An Software-Entwicklung anpassen

109 © Prof. T. Kudraß, HTWK Leipzig TQM: Einige Methoden Qualitätszirkel / Brainstorming Pareto-Analyse – 80:20 Regel (80% des Aufwandes für 20% der Probleme) Ursache-Wirkungs-Diagramm – Ishikawa-Diagramm (Fishbone Chart) QFD-Konzept (Quality Function Deployment)

110 © Prof. T. Kudraß, HTWK Leipzig CMM (Capability Maturity Model) Beschreibt Qualität des Software-Entwicklungs- prozesses Unterscheidet 5 Qualitätsstufen von Entwicklungsprozessen – Höherer Reifegrad höhere Termintreue geringere Schwankungsbreite – Ermittlung der Reifegrade anhand von Hauptkriterien (key process areas) und Aspekten (key practices)

111 © Prof. T. Kudraß, HTWK Leipzig CMM-Reifegradstufen In Out Stufe 5 Optimierender Prozess Stufe 4 Gesteuerter Prozess Stufe 3 Definierter Prozess Stufe 2 Wiederhol- barer Prozess Stufe 1 Initialer Prozess OutIn

112 © Prof. T. Kudraß, HTWK Leipzig EINHEIT 4: Testende Verfahren Grundbegriffe Klassifikation – Strukturtest (White Box-Test) – Funktionaler Test (Black Box-Test) Testmethodik Test-Arten – Integrationstest – Systemtest Testprozess und -dokumentation

113 © Prof. T. Kudraß, HTWK Leipzig Einführung Produktqualität = Produktqualität jeder Systemkomponente Produktqualität der Beziehungen zwischen den Systemkomponenten Qualitätsmerkmale Konstruktive und analytische Maßnahmen Eigenschaften der Systemkomponente KonstruktionAnalyse Funktionalität Zuverlässigkeit (Änderbarkeit)

114 © Prof. T. Kudraß, HTWK Leipzig Fehler Definition – Abweichung der tatsächlichen Ausprägung eines Qualitätsmerkmals von der vorgesehenen Soll-Ausprägung – Inkonsistenz zwischen Spezifikation und Implementierung – Entspricht Richtigkeit (Funktionalität) und Reife und Fehlertoleranz (Zuverlässigkeit) [DIN ISO 9126] Konstruktives Ziel – Fehlerfreie Software-Komponenten entwickeln Analytisches Ziel – Fehlerfreiheit einer Software-Komponente nachweisen – Vorhandene Fehler finden

115 © Prof. T. Kudraß, HTWK Leipzig Auswahl analytischer Maßnahmen Funktionalität RichtigkeitReife Zuverlässigkeit Fehlertoleranz Qualitätsmerkmale Analysierbarkeit Änderbarkeit Modifizierbarkeit Stabilität Prüfbarkeit Testende VerfahrenVerifizierende VerfahrenAnalysierende Verfahren Spezifikation Implementierung Klassen Datentyp-Module Datenobjekt-Module Funktionale Module BeschreibungKomp.-Art (z.T. ermittelbar durch Metriken) Komponenteneigenschaft

116 © Prof. T. Kudraß, HTWK Leipzig Begriffe Prüfling, Testobjekt – Software-Komponente, die getestet werden soll Testfall – Satz von Testdaten, der die vollständige Ausführung eines Programms bewirkt Testdatum – Eingabewert für Eingabeparameter oder Eingabevariable des Testobjekts Testtreiber – Testrahmen zum interaktiven Aufrufen einer Prozedur/Funktion

117 © Prof. T. Kudraß, HTWK Leipzig Weitere Begriffe Instrumentierung – Ziel: Protokollierung ausgeführter Testfälle – Analyse des Quellcodes des Prüflings durch ein Testwerkzeug – Einbau von Zählern und Auswertung der Zählerstände (Protokoll) Überdeckungsgrad – Grad der Vollständigkeit eines Test in einem Testverfahren Regressionstest – Wiederholung aller Testfälle nach Änderung des Prüflings mit Soll/Ist-Ergebnisvergleich

118 © Prof. T. Kudraß, HTWK Leipzig Klassifikation testender Verfahren Dynamische Verfahren Strukturtest ( White Box -Test, Glass Box -Test) Kontrollflussorientierter Test Anweisungsüberdeckungstest Zweigüberdeckungstest Pfadüberdeckungstest (vollständig, strukturiert, boundary interior ) Bedingungsüberdeckungstest (einfach, minimal, mehrfach, mehrfach) Datenflussorientierter Test Defs / Uses -Verfahren Funktionaler Test ( Black Box -Test) funktionale Äquivalenzklassenbildung Grenzwertanalyse Test spezieller Wert Zufallstest

119 © Prof. T. Kudraß, HTWK Leipzig Beispiel C++ Prozedur ZaehleZchn Programm ZaehleZchn (Spezifikation / Header) Die Prozedur liest solange Zeichen von der Tastatur, bis ein Zeichen erkannt wird, das kein Großbuchstabe ist, oder Gesamtzahl den größten durch den Datentyp int darstellbaren Wert INT_MAX erreicht. Ist ein gelesenes Zeichen ein Großbuchstabe zwischen A und Z, dann wird Gesamtzahl um 1 erhöht. Ist der Großbuchstabe ein Vokal, dann wird auch Vokalanzahl um 1 erhöht. Ein/Ausgabeparameter sind Gesamtzahl und Vokalanzahl. Randbedingung: Das aufrufende Programm stellt sicher, dass Gesamtzahl stets größer oder gleich Vokalanzahl ist.

120 © Prof. T. Kudraß, HTWK Leipzig Beispielprogramm ZaehleZchn void ZaehleZchn (int &VokalAnzahl, int &Gesamtzahl) { char Zchn; cin >> Zchn; while((Zchn >= A) && (Zchn <= Z) && (Gesamtzahl < INT_MAX)) { Gesamtzahl = Gesamtzahl + 1; if ((Zchn == A) || (Zchn == E) || (Zchn == I) || (Zchn == O) || (Zchn == U)) { VokalAnzahl = VokalAnzahl + 1; } // end if cin >> Zchn; } // end while }

121 © Prof. T. Kudraß, HTWK Leipzig Beispielprogramm ZaehleZchn (2) void main { int AnzahlVokale = 0; int AnzahlZchn = 0; cout << Programm ZaehleZchn << endl; cout << Zeichen bitte eingeben: << endl; ZaehleZchn(AnzahlVokale, AnzahlZchn); cout << Anzahl Vokale: << AnzahlVokale << endl; cout << Anzahl Zeichen: << AnzahlZchn << endl; }

122 © Prof. T. Kudraß, HTWK Leipzig Kontrollflussgraph n1 n2 n3 n4 n5 Knoten Zweig, Kante Pfad n final n start cin >> Zchn; while ((Zchn >= A) && (Zchn <= Z) && (Gesamtzahl < INT_MAX)) Gesamtzahl = Gesamtzahl + 1; if ((Zchn == A) || (Zchn == E) || (Zchn == I) || (Zchn == O) || (Zchn == U)) VokalAnzahl = VokalAnzahl + 1; cin >> Zchn; n6

123 © Prof. T. Kudraß, HTWK Leipzig Anweisungsüberdeckung vs. Zweigüberdeckung n1 n2 n3 n4 n5 n final n start cin >> Zchn; while ((Zchn >= A) && (Zchn <= Z) && (Gesamtzahl < INT_MAX)) Gesamtzahl = Gesamtzahl + 1; if ((Zchn == A) || (Zchn == E) || (Zchn == I) || (Zchn == O) || (Zchn == U)) VokalAnzahl = VokalAnzahl + 1; cin >> Zchn; n6 n1 n2 n3 n4 n5 n final n6 n start

124 © Prof. T. Kudraß, HTWK Leipzig Anweisungsüberdeckungstest C 0 -Test Prinzip – Mindestens einmalige Ausführung aller Anweisungen des Programms (d.h. alle Knoten) Eigenschaften – Kontrollstrukturen / Datenabhängigkeiten nicht geprüft – Jede Anweisung gleichgewichtig gewertet – Notwendiges, aber nicht hinreichendes Testkriterium – Nicht ausführbarer Code kann gefunden werden – Als eigenständiges Testverfahren nicht geeignet Leistungsfähigkeit – Geringste Fehleridentifizierungsquote (18%)

125 © Prof. T. Kudraß, HTWK Leipzig Zweigüberdeckungstest C 1 -Test Prinzip – Ausführung aller Zweige des zu testenden Programms, d.h. Durchlaufen aller Kanten des Kontrollflussgraphen – Das minimale Testkriterium Leistungsfähigkeit – Findet nicht ausführbare Programmzweige – Kontrolliert Korrektheit an den Verzweigungsstellen – Erkennt und optimiert häufig durchlaufene Programmteile – Bessere Fehleridentifizierungsquote (35%) Schwächen – Unzureichend für den Test von Schleifen – Berücksichtigt nicht Abhängigkeiten zwischen Zeigen, sondern betrachtet einzelne Zweige – Unzureichend für den Test komplexer, d.h. zusammengesetzter Bedingungen

126 © Prof. T. Kudraß, HTWK Leipzig Pfadüberdeckungstest n1 n2 n3 n4 n5 n final n start cin >> Zchn; while ((Zchn >= A) && (Zchn <= Z) && (Gesamtzahl < INT_MAX)) Gesamtzahl = Gesamtzahl + 1; if ((Zchn == A) || (Zchn == E) || (Zchn == I) || (Zchn == O) || (Zchn == U)) VokalAnzahl = VokalAnzahl + 1; cin >> Zchn; n6 p q2 q1 r

127 © Prof. T. Kudraß, HTWK Leipzig Pfadüberdeckungstest Prinzip – Ausführung aller unterschiedlichen Pfade des zu testenden Programms – Pfad = Sequenz von Knoten (i,n 1, n 2,..., n m ) Leistungsfähigkeit – Ist das mächtigste kontrollflussorientierte Verfahren (über 60% Identifizierungsquote) Schwächen – Pfadanzahl wächst bei Wiederholungsanweisungen für den Test von Schleifen – ohne feste Wiederholungszahl – Teil der konstruierbaren Pfade nicht ausführbar Vollständigkeit nicht gesichert – Keine praktische Bedeutung aufgrund eingeschränkter Durchführbar- keit ( eingeschränktere Ansätze zum Testen verfolgen)

128 © Prof. T. Kudraß, HTWK Leipzig Boundary-Interior-Pfadtest Prinzip – Schwächere Version des Pfadüberdeckungstests – Keine Überprüfung von Pfaden, die durch mehr als einmalige Schleifenwiederholung erzeugt werden – Gezieltere Überprüfung von Schleifen praktikabel Eigenschaften – Grenztest-Gruppe (boundary test): Alle Pfade, die die Schleife zwar betreten, sie aber nicht wiederholen; Ausführung aller unterschiedlichen Pfade innerhalb des Schleifenkörpers – Gruppe zum Test des Schleifeninneren (interior test): Alle Pfade, die mindestens eine Schleifenwiederholung beinhalten; Ausführung aller unterschiedlichen Pfade während der ersten beiden Ausführungen des Schleifenkörpers

129 © Prof. T. Kudraß, HTWK Leipzig Testfall für den Pfad außerhalb der Schleife – Aufruf mit Gesamtzahl = INT_MAX Testfall für den Grenztest – Aufruf mit Gesamtzahl = 0, Zchn = A, 1 – Aufruf mit Gesamtzahl = 0, Zchn = B, 1 Testfälle für den Schleifenkörper: mindestens eine Schleifenwiederholung, 4 mögliche Pfade bei 2 Ausführungen des Schleifenkörpers – Zchn = E, I, N, * – Zchn = A H, ! – Zchn = H, A, + – Zchn = X, X,, Beispiel Boundary-Interior-Pfadtest

130 © Prof. T. Kudraß, HTWK Leipzig Bedingungsüberdeckungstest- Verfahren Prinzip – Benutzen Bedingungen in Wiederholungs- und Auswahlkonstrukten zur Definition von Tests Eigenschaften – Einfache Bedingungsüberdeckung: Überdeckung aller atomaren Bedingungen. Evaluation aller atomarer Bedingungen muss mindestens einmal true und false ergeben – Mehrfach-Bedingungsüberdeckung: Bildung aller Variationen der atomaren Bedingungen. Bei n Bedingungen 2 n Variationen große Anzahl Testfälle – Minimale Mehrfach-Bedingungsüberdeckung: Jede Bedingung – atomar oder zusammengesetzt – muss mindestens einmal true und einmal false sein

131 © Prof. T. Kudraß, HTWK Leipzig Bedingungsüberdeckung Beispiel Zwei Bedingungen a) 3 atomare Bedingungen ((Zchn >= A) && (Zchn <= Z) && (Gesamtzahl < INT_MAX)) b) 5 atomare Bedingungen ((Zchn == A) || (Zchn == E) || (Zchn == I) ||(Zchn == O) || (Zchn == U))

132 © Prof. T. Kudraß, HTWK Leipzig Einfache Bedingungsüberdeckung Variablen123 Gesamtzahl INT_MAX ZchnAEIOU1aD Zchn>=ATTTTTFTT Zchn<=ZTTTTTTFT Gesamtzahl < INT_MAX TTTTTTTF Zchn==ATFFFF--- Zchn==EFTFFF--- Zchn==IFFTFF--- Zchn==OFFFTF--- Zchn==UFFFFT--- Testfälle Variablenwerte Atomare BedingungenWahrheitswerte der atomaren Bedingungen

133 © Prof. T. Kudraß, HTWK Leipzig Bedingungsüberdeckung Vollständige Prüfung d. Bedingungen Variablen123 Gesamtzahl INT_MAX ZchnAEIOUB1aD Zchn>=A Zchn<=Z TTTT TTTT TTTT TTTT TTTT TTTT FTFT TFTF TTTT Gesamtzahl < INT_MAX TTTTTTTTF Bedingung aTTTTTTFFF Zchn==ATFFFFF--- Zchn==EFTFFFF--- Zchn==IFFTFFF--- Zchn==OFFFTFF--- Zchn==UFFFFTF--- Bedingung bTTTTTF--- Testfälle

134 © Prof. T. Kudraß, HTWK Leipzig Datenflussorientierte Strukturtestverfahren Prinzip – Dynamisches Strukturtestverfahren – Nutzt Definition von Variablen sowie lesende und schreibende Zugriffe auf Variablen in Anweisungen und Bedingungen für Testziele – Geeignet zum Test von Datenobjekt- und Datentypmodulen Defs/Uses-Verfahren, 3 Kategorien – Wertzuweisung / Definition (def) – Berechnung von Werten innerhalb eines Ausdrucks (computational-use, c-use) – Bildung von Wahrheitswerten in Bedingungen (predicate-use, p-use)

135 © Prof. T. Kudraß, HTWK Leipzig Kontrollflussgraph - Datenflussdarstellung n start Import von VokalAnzahl und Gesamtzahl char Zchn; cin >> Zchn; while ((Zchn >= A) && (Zchn <= Z) && (Gesamtzahl < INT_MAX)) Gesamtzahl = Gesamtzahl + 1; if ((Zchn == A) || (Zchn == E) || (Zchn == I) || (Zchn == O) || (Zchn == U)) VokalAnzahl = VokalAnzahl + 1; cin >> Zchn; Export von VokalAnzahl und Gesamtzahl n1 n2 n3 n4 n5 n final n6 def (Gesamtzahl) def (VokalAnzahl) def (Zchn) p-use (Zchn) p-use (Gesamtzahl) c-use (Gesamtzahl) def (Gesamtzahl) p-use (Zchn) c-use (VokalAnzahl) def (VokalAnzahl) def (Zchn) c-use (VokalAnzahl) c-use (Gesamtanzahl) n in n out

136 © Prof. T. Kudraß, HTWK Leipzig Datenflussorientierte Testverfahren all defs-Kriterium – Jede Variablendefinition benutzen all p-uses-Kriterium – Jede Kombination Variablenbenutzung + prädikative Variablenbenutzung (zweigüberdeckend) all c-uses-Kriterium – Ausführung mindestens eines definitionsfreien Pfades all c-uses / some p-uses-Kriterium – Test aller Kombinationen Variablendefinition + berechnende Variablenbenutzung

137 © Prof. T. Kudraß, HTWK Leipzig Analytische Verfahren – Black Box Tests (Funktionale Tests) Funktionale Testverfahren – Funktionale Äquivalenzklassenbildung – Grenzwertanalyse – Test spezieller Werte Kombination Funktion- und Strukturtest

138 © Prof. T. Kudraß, HTWK Leipzig Funktionale Äquivalenzklassenbildung Prinzip – Dynamisches funktionales Testverfahren, das Tests aus der funktionalen Spezifikation ableitet (Black Box-Test) Eigenschaften – Äquivalenzklassen der Eingabewerte durch Zerlegung des Definitionsbereichs gebildet – Bildung von Ausgabe-Äquivalenzklassen – Repräsentant für einen Testfall irgendein Element aus Äquivalenzklasse Bewertung – Geeignetes Verfahren für Ableitung von Testfällen – Basis für Grenzwertanalyse – Aufteilung in Äquivalenzklassen nicht immer mit Programmstruktur identisch – Nur Betrachtung von Ein- und Ausgabe, aber nicht Ursache-Wirkung!

139 © Prof. T. Kudraß, HTWK Leipzig Regeln zur Äquivalenzklassenbildung 1.Ein zusammenhängender Wertebereich eine gültige Äquivalenzklasse und 2 ungültige Äquivalenzklassen Eingabebereich: 1 <= Tage <= 31 Tage 1 gültige Klasse: 1 <= Tage <= 31 2 ungültige Klassen: Tage 31 2.Anzahl von Werten 1 gültige und 2 ungültige Äquivalenzklassen Eingabebereich: 1..6 Besitzer eines Autos 1 gültige Klasse: 1..6 Besitzer 2 ungültige Klassen: Kein Besitzer, Mehr als 6 Besitzer 3.Anzahl von n Werten mit unterschiedlicher Behandlung n gültige und 1 ungültige Äquivalenzklasse Tasteninstrumente: Klavier, Cembalo, Spinett, Orgel 4 gültige Klassen: Klavier, Cembalo, Spinett, Orgel 1 ungültige Klasse: z.B. Violine

140 © Prof. T. Kudraß, HTWK Leipzig Regeln zur Äquivalenzklassenbildung (Forts.) 4.Situation, die zwingend erfüllt sein muss 1 gültige und 1 ungültige Äquivalenzklasse Das erste Zeichen muss ein Buchstabe sein 1 gültige Klasse: Das erste Zeichen ist ein Buchstabe 1 ungültige Klasse: Das erste Zeichen ist kein Buchstabe 5.Äquivalenzklasse auftrennen, wenn deren Elemente unterschiedlich behandelt werden 6.Bildung von Ausgabe-Äquivalenzklassen (1-5 analog) Eingabewert Ausgabewert? Ausgabewert in Wertebereich? Ausgabebereich: 1 <= Wert <= 99 1 gültige Klasse: Alle Eingaben, die Ausgaben zwischen 1 und 99 erzeugen 2 ungültige Klassen: - Alle Eingaben, die Ausgaben kleiner als 1 erzeugen - Alle Eingaben, die Ausgaben größer als 99 erzeugen

141 © Prof. T. Kudraß, HTWK Leipzig Beispiel Äquivalenzklassen und Testfälle EingabenÄquivalenzklassen Gesamtzahl1 0<=Gesamtzahl < INT_MAX 2 Gesamtzahl = INT_MAX VokalAnzahl3 0<=VokalAnzahl<=Gesamtzahl Zchn4a Zchn < A 4b Zchn > Z 5 A <= Zchn <= Z 6a Zchn = A 6b Zchn = E 6c Zchn = I 6d Zchn = O 6e Zchn = U Testfall123 Getestete Äquivalenzkl. 1, 3, 5, 6a, 6b, 6c, 6d, 6e, 4a 1, 3, 4b2, 3 Gesamtzahl1001INT_MAX VokalAnzahl501 ZchnX,A,E,I,O,U,I a- Soll: Gesamtzahl 1061INT_MAX Vokalanzahl55150 Äquivalenzklassen Für ZaehleZchn Testfälle für ZaehleZchn

142 © Prof. T. Kudraß, HTWK Leipzig Grenzwertanalyse Prinzip – Dynamisches funktionales Testverfahren, das Tests aus der funktionalen Spezifikation ableitet (Black Box-Test) – Basiert auf Äquivalenzklassenbildung Eigenschaften – Jeder Rand der Äquivalenzklasse getestet Setzt eine natürliche Ordnung der Elemente in Äquivalenzklasse voraus Bewertung – Sinnvolle Erweiterung und Verbesserung Äquivalenzklassenbildung – Identifiziert wichtige Typen von Testfällen Beispiel void setzeMonat (short Monat); // Eingabeparameter – 1 gültige Äquivalenzklasse (1 12) – Testfälle: monat = 1; monat = 12; monat = 0; monat =13;

143 © Prof. T. Kudraß, HTWK Leipzig Test spezieller Werte Ziel – Aufstellung von fehlersensitiven Testfällen aus der Erfahrung heraus (Spezialfälle) Kriterien – Grenzwertanalyse – Zero values-Kriterium – Distinct values-Kriterium Beispiele – Wert 0 als Eingabe- oder Ausgabewert – Sonder- oder Steuerzeichen bei der Eingabe von Zeichenketten – NULL-Werte in Tabellen

144 © Prof. T. Kudraß, HTWK Leipzig Zufallstest Prinzip – Erzeugung zufälliger Testfälle aus dem Wertebereich der Eingabedaten – Werkzeugnutzung (Testdatenerzeugung) Bewertung – Schließt menschliches Fehlverhalten bei Testdatenerzeugung aus, da regellose Testdatenerzeugung – Als alleiniges Verfahren nicht ausreichend (minimale Testkriterien nicht erfüllt) – Nur als ergänzendes Verfahren geeignet, z.B. in Kombination mit Äquivalenzklassen

145 © Prof. T. Kudraß, HTWK Leipzig Strukturtest vs. Funktionstest Nachteil Strukturtest – Fehlende Funktionalität nicht erkannt (stattdessen triviale Testfälle z.B. bei Zweigüberdeckung) Nachteil Funktionstest – Implementierung nicht geeignet berücksichtigt – Nur Teil aller Zweige berücksichtigt Kombination Strukturtest + Funktionstest! Sicht des Programmierers/Testers vs. Sicht des Managements

146 © Prof. T. Kudraß, HTWK Leipzig Anforderungen an die Testmethodik Erfüllen von anerkannten Minimalkriterien – Ausführung aller Zweige (Zweigüberdeckungstest) – Test anhand von Spezifikation (Funktionstest) Erzeugung von fehlersensitiven Testdaten Erzeugung von Testdaten, die das korrekte Funktionieren zeigen Wirtschaftlichkeit der Prüfung Systematik des Tests Nachvollziehbarkeit Verwendung eines geeigneten Werkzeugs – Testprotokollierung, Testmetrik, Regressionstest

147 © Prof. T. Kudraß, HTWK Leipzig Testmethodik 1. Funktionstest a) Testobjekt mit Testwerkzeug instrumentieren (protokolliert Überdeckung) b) Mit Hilfe Spezifikation bestimmen: -Äquivalenzklassen, Grenzwerte, Spezialwerte, Testdaten -Keine Implementierung! c) Testfälle mit Testobjekt durchführen: -Soll-Ist-Vergleich -Keine Überdeckungsrate betrachten

148 © Prof. T. Kudraß, HTWK Leipzig Testmethodik (Forts.) 2. Strukturtest a) Überdeckungsstatistik nach Funktionstest auswerten – Nichtabdeckungen untersuchen (z.B. Fehlerabfragen, tote Zweige) b) Testfälle für noch nicht durchlaufene Zweige, Pfade, Bedingungen aufstellen c) Durchführung Testlauf für jeden Testfall d) Ende des Überdeckungstests bei Erreichen einer bestimmten Überdeckungsrate 3. Regressionstest Falls Fehlerkorrektur: Regressionstest mit den bisherigen Testfällen (d.h. nochmalige Durchführung der protokollierten Testfälle und Soll-Ist-Vergleich)

149 © Prof. T. Kudraß, HTWK Leipzig Allgemeine Tipps zum Testen Testwerkzeuge / Hoher Automatisierungsgrad Konstruktive Voraussicht bei Entwurf und Spezifikation Funktionstest im Entwurf berücksichtigen (Herleitung der Testfälle ohne Blick in den Quellcode) Funktionstests sorgfältig vorbereiten Strukturtest nach dem Funktionstest zielgerichtet möglich Einzeltests mit jeder Systemkomponente vor Integrationstest Einbau der Testwerkzeuge in den Entwicklungs- prozess (Richtlinien, Checklisten)

150 © Prof. T. Kudraß, HTWK Leipzig Integrationstest – Einführung und Überblick Aufgabe: – Fehlerfreies Zusammenwirken der Systemkomponenten testen Voraussetzung: – Jede Systemkomponente bereits überprüft Unterschiedliche Integrationsstrategien Klassifikation von Integrationstests: – Dynamisch vs. Statisch – Black Box vs. White Box

151 © Prof. T. Kudraß, HTWK Leipzig Integrationsstrategien bottom-up top-down inside-out hardest first outside-in big bang geschäftsprozess- orientiert funktionsorientiert nach der Verfügbarkeit Nicht- inkrementell Inkrementell vorgehensorientiert testzielorientiert

152 © Prof. T. Kudraß, HTWK Leipzig Testtreiber und Platzhalter Testtreiber (Driver) – Zum Test einer Systemkomponente, deren Dienst nicht direkt vom User Interface (mit Parametern) aufgerufen wird Platzhalter (Dummies, Stubs) – Beim Aufruf von Systemkomponenten, die noch nicht implementiert sind, sondern nur spezifiziert Beispiel C G G: abstrakter Datentyp mit 2 Operatoren: LeseNaechstenSatz und LoescheSatz C: liest jeden Satz einer Datei und löscht dann

153 © Prof. T. Kudraß, HTWK Leipzig Integrationstest-Verfahren Dynamisch Test der integrierten Komponenten mit konkreten Eingabewerten Strukturorientiert – Kontrollflussorientiert – Datenflussorientiert Funktional zu wenig Funktionalität / zu viel Funktionalität / falsche Funktionalität Wertbezogen Test mit extremen Werten (vgl. Grenzwertanalyse, Test spezieller Werte)

154 © Prof. T. Kudraß, HTWK Leipzig Prüfziele eines Systemtests Vollständigkeit – Alle funktionalen und nicht-funktionalen Anforderungen aus dem Pflichtenheft. Funktionale Anforderungen Funktionstest – Beispiel: Produktfunktionen lt. Pflichtenheft Globale Testfälle (Funktionssequenzen) Volumen – Test mit umfangreichen Datenmengen (Massentest) – Beispiel: Max Teilnehmer, max Seminare Importschnittstelle für Massendaten

155 © Prof. T. Kudraß, HTWK Leipzig Prüfziele eines Systemtests (2) Zeit – Antwortzeiten und Durchsatzraten bei starker Systembelastung (Zeittest) – Beispiel: Reaktionszeiten < 2 sec Verarbeitungsfunktionen max. 15 sec Zuverlässigkeit – Test des Systems unter Spitzenbelastung über längere Zeit hinweg (Lasttest), im grünen Bereich – Beispiel: Datei nicht vorhanden bei Dateischnittstelle Datei zu groß

156 © Prof. T. Kudraß, HTWK Leipzig Prüfziele eines Systemtests (3) Fehlertoleranz, Robustheit – Test des Systems unter Überlast, im roten Bereich (Stresstest) – Simulierte Situationen: geringerer Speicher, Plattenausfall – Beispiel: Was passiert bei: Teilnehmern, Seminaren? Benutzbarkeit – Verständlichkeit, Erlernbarkeit, Bedienbarkeit aus der Sicht des Endbenutzers (Benutzbarkeitstest) – Beispiel: Anforderungen an User Interface aus Pflichtenheft 2 Rollen: Kundensachbearbeiter, Seminarsachbearbeiter Sicherheit – Datenschutz-Mech. (Sicherheitstest), Passwörter, Zugriffsrechte

157 © Prof. T. Kudraß, HTWK Leipzig Prüfziele eines Systemtests (4) Interoperabilität – Zusammenarbeit des Systems mit anderen Systemen, Kompatibilität von Schnittstellen und Daten (Interoperabilitätstest) – Beispiel: Zusammenarbeit Seminarorganisation mit Buchhaltungssystem Konfiguration – System für unterschiedliche HW/SW-Plattformen und Konfigurationen geeignet Dokumentation – Vorhandensein, Güte und Angemessenheit der Benutzer- und Wartungsdokumentation (Dokumentenprüfung) Installations- und Wiederinbetriebnahmetest

158 © Prof. T. Kudraß, HTWK Leipzig Abnahmetest (Acceptance Test) Test des Systems – Unter Mitwirkung und Federführung des Auftraggebers – In der realen Einsatzumgebung beim Auftraggeber – Möglichst mit echten Daten des Auftraggebers Arten: – Werkabnahme (Ausführung aller vorgesehenen Testfälle) – Abnahme in der realen Umgebung – Betriebsabnahme (Pilotphase) – endgültiger Inbetriebnahme

159 © Prof. T. Kudraß, HTWK Leipzig Testprozess und -dokumentation Testprozess – Testplanung – Testdurchführung – Testkontrolle Dokumente – Testplan und Testvorschrift – Testbericht Testbericht [ANSI/IEEE Std ] – Testzusammenfassung – Testprotokoll (ergibt sich aus Testvorschrift) – Liste der Problemmeldungen – Liste der Software-Einheiten

160 © Prof. T. Kudraß, HTWK Leipzig Inhalt einer Testvorschrift 1.Einleitung 1.1 Zweck des Tests 1.2Testumfang 1.3Referenzierte Unterlagen 2.Testumgebung 2.1 Überblick 2.2Test-Software und -Hardware 2.3Testdaten, Testdatenbanken 2.4Personalbedarf 3.Abnahmekriterien 3.1Kriterien für Erfolg und Abbruch 3.2Kriterien für Unterbrechungen 3.3Voraussetzungen für Wiederaufnahme

161 © Prof. T. Kudraß, HTWK Leipzig Inhalt einer Testvorschrift (Forts.) 4.Testabschnitt 1 4.1Einleitung 4.1.1Zweck, Referenz zur Spezifikation 4.1.2Getestete Software-Einheiten 4.1.3Vorbereitungsarbeiten für den Testabschnitt 4.1.4Aufräumarbeiten nach dem Testabschnitt 4.2Testsequenz Testfall Eingabe, Anweisung, Soll-Ausgabe, Raum für Ist-Ausgabe und Befund 4.2.2Testfall Testsequenz 1-2 : 4.nErgebnis des Abschnitts 1 5.Testabschnitt 2 :

162 © Prof. T. Kudraß, HTWK Leipzig Testzusammenfassung Allgemeine Daten – Nr., Beginn, Ende, Dauer Gegenstand und Zweck des Tests – Projekt, Release-Nr. – Geliefert von: Einzeltest, Integrationstest, Systemtest, Abnahmetest Testvorschrift (siehe dort) Empfehlung – Akzeptieren / Nicht akzeptieren (d.h. Testwiederholung)? Beilagen – Liste der getesteten Software-Einheiten – Liste der Problemmeldungen


Herunterladen ppt "Qualitätsmanagement in der Software-Entwicklung Prof. Dr. Thomas Kudraß HTWK Leipzig Seminar PC-Ware AG Leipzig, 26.01.2002."

Ähnliche Präsentationen


Google-Anzeigen