Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Heribert Wernecke Geändert vor über 10 Jahren
1
Qualitätsmanagement in der Software-Entwicklung
Prof. Dr. Thomas Kudraß HTWK Leipzig Seminar PC-Ware AG Leipzig,
2
Motivation Kleine Bugs Große GAUs
Ein paar falsche Zahlen oder Zeilen und schon passiert‘s: 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
Agenda EINHEIT 1 EINHEIT 2 EINHEIT 3 EINHEIT 4
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
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
Was ist Qualität? Fünf verschiedene Ansätze
Transzendenter Ansatz Produktbezogener Ansatz Benutzerbezogener Ansatz Prozessbezogener Ansatz Kosten/Nutzen-bezogener Ansatz
6
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
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
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
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
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
Qualitätsmerkmale für Software-Produkte
Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit Quelle: DIN-Norm ISO 9126
12
Funktionalität Richtigkeit Angemessenheit Interoperabilität
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
Zuverlässigkeit Reife Fehlertoleranz Wiederherstellbarkeit
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
Benutzbarkeit Verständlichkeit Erlernbarkeit Bedienbarkeit
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
Effizienz Zeitverhalten Verbrauchsverhalten
Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausführung Verbrauchsverhalten Anzahl und Dauer der benötigten Betriebsmittel für die Funktionen
16
Änderbarkeit Analysierbarkeit Modifizierbarkeit Stabilität Prüfbarkeit
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
Ü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
FURPS Qualitätsmodell
Entwickelt von HP 1985 Merkmale (stark kundenorientiert definiert) Functionality Usability Reliability Performance Supportability
19
GQM-Ansatz: Goal-Question-Metric Vorgehensmodell
Definiere die Auswertungsziele für alle zu erfüllenden Qualitätsmerkmale Leite alle Fragestellungen ab, die zu einer Quantifizierung dieser Ziele führen können Leite alle Maße ab, die Informationen zur Beantwortung der Fragestellungen beitragen Entwerfe einen Mechanismus zur möglichst genauen Erfassung der Messwerte Validiere die Messwerte bezüglich aller primitiven Maße Interpretiere die Messergebnisse zur Gesamtbewertung der Qualitätsziele
20
Beispiel für ein Software-Bewertungsmodell
Auswertungsziele (goals) Z1 Z2 Z3 Z4 Abgeleitete Frage- stellungen(questions) F1 F2 F3 F4 F5 F6 M1 M2 M3 M4 M5 Primitive Maße (metrics)
21
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
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
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
Erweitertes GQM-Bewertungsmodell
Ziel (goal) Wir untersuchen Produkte und ... Weitere Qualitätsbäume Qualitätsbäume für jedes Zwischenprodukt Qualitätsbaum-Analyse Qualitätsbaum-Quellcode ... Testbarkeit Wartbarkeit ... ... Strukturiertheit ... Innere Struktur Fragen (questions) ... Größe des Programms? Kennzahlen (metrics) Lines of Codes
25
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 Ist gut strukturiert WB31 Ist eindeutig interpretierbar WB21 Jede Kompo-nente in sich gut strukturiert WB311 Hält vereinbarte Standards voll-ständig ein WB11 Techniken zur Er-stellung des SWS angemessen WB32 SWS leicht verständlich WB22 Beziehungen zwischen den Komponenten einfach WB312 Ist möglichst ein-heitlich realisiert WB12 Umfang des SWS entspricht optimal der Aufgabe WB33 Ist gut dokumentiert WB23
26
Qualitätszielbestimmung
Qualitätsstufen Wertebereich auf einer Skala zur Klassifizierung von Software entspr. Qualitätsanforderungen [ISO9126] Sehr gut Gut annehmbar Messwert Normal Schlecht nicht annehmbar Maßskala Qualitätsstufen
27
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
Qualitätsmanagement vs. Qualitätssicherung
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
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
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
Konstruktives Qualitätsmanagement
Maßnahmen, die a priori bestimmte Qualitäts-eigenschaften von Produkt / Prozess gewährleisten Konstruktives Qualitätsmanagement Organisatorische Maßnahmen Technische Maßnahmen Methoden Sprachen Werkzeuge Richtlinien Standards Checklisten
32
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
Maßnahmen zum analytischen Qualitätsmanagement
Analysierende Verfahren Testende Verfahren Statische Analyse Dynamischer Test Animation Symbolischer Test Programmverifikation Simulation Review Schreibtischtest Inspektion Walkthrough Durchsprache = manuell Audit
34
Aktivitäten des Qualitätsmanagement
Qualitätsplanung Qualitätslenkung und –sicherung Qualitätsprüfung
35
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
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
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
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
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
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
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
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
Frühzeitige Fehlerentdeckung und -behebung
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
Summation von Fehlern und Mängeln
Anforderungs- definition Korrekte Anforderungen Fehlerhafte Anforderungen System- spezifikation Korrekte Spezifikation Spezifikations- fehler Induzierte Fehler aus Anforderungen Korrekter Entwurf Entwurfs- fehler Induzierte Fehler aus Anforderungen | Spezifikation Entwurf Korrektes Programm Programm- fehler Induzierte Fehler aus Anforderungen | Spezifikation | Entwurf Realisierung Korrektes Verhalten Korrigierte Fehler Bekannte un- korrigierte Fehler Unbekannte Fehler Test und Integration
45
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
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
Entwicklungsbegleitende, integrierte Qualitätssicherung
Software-Entwicklung Software-Entwicklung Definieren Definieren Definieren Änderungen QS- Plan Produktmodell Produktmodell Produktmodell Prüfen und freigeben Entwerfen Entwerfen Entwerfen Änderungen Produktarchitektur Produktarchitektur Produktarchitektur Prüfen und freigeben Implementieren Implementieren Implementieren Änderungen Produkt Produkt Produkt Prüfen und freigeben
48
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
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
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
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
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
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
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
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
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
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
EINHEIT 2: Qualität in der SW-Entwicklung
V-Modell Submodell QS im V-Modell: Aktivitäten und Produkte Beispiel-Entwicklungsprozess
59
V-Modell Anwendungsszenarien Validation Testfälle Verifikation
Anforderungs-definition Abnahmetest Validation Testfälle Grobentwurf Systemtest Verifikation Testfälle Feinentwurf Integrationstest Testfälle Modulimple- mentation Modultest
60
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
Die drei Ebenen der Standardisierung
V-Modell Einführung Die drei Ebenen der Standardisierung
62
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
Zusammenwirken der 4 Submodelle
64
Arbeitsteilung zwischen SE und QS im V-Modell
65
Analytische Maßnahmen im V-Modell
Prüfung Selbstprüfung Verifikation Validation Prozessprüfung Produktprüfung
66
Rollenverteilung bei der Durchführung von Prüfaktivitäten
Produktersteller QS-Verant-wortlicher Prüfer AG/Anwender Selbstprüfung v Prozessprüfung m Produktprüfung b Validation v verantwortlich b beratend m mitwirkend
67
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
Formelle Prüfung Beteiligung QS-Verantwortlicher
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
69
Kritikalität = Bedeutung von Fehlverhalten
... bei administrativen Administrationssystemen ... bei technischen Systemen hoch macht 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 mittel kann die Gesundheit von Menschen gefährden oder zur Zerstörung von Sachgütern führen niedrig verhindert Zugang zu Informationen, die regelmäßig benötigt werden kann zur Beschädigung von Sachgütern führen, ohne jedoch Menschen zu gefährden keine beeinträchtigt die zugesicherten Eigenschaften nicht wesentlich gefährdet weder Gesundheit noch Sachgüter
70
Submodell QS Aktivitäten Produkte Planungsaktivitäten (QS1, QS2)
Prüfaktivitäten (QS3, QS4) Lenkungsaktivitäten (QS5) Produkte QS-Plan Prüfplan Prüfspezifikation Prüfprozedur Prüfprotokoll
71
Submodell QS im Überblick
QS 1 QS-Initialisierung QS 1.1 QS-Plan erstellen QS 1.2 Prüfplan erstellen QS-Plan QS 2 Prüfungsvorbereitung QS 2.1 Prüfmethoden und –kriterien festlegen QS 2.2 Prüfumgebung definieren Prüfplan QS 2.3 Prüffälle festlegen Prüfspezifikation QS 2.4 Prüfprozedur erstellen Prüfprozedur QS 3 Prozessprüfung von Aktivitäten Prüfprozedur QS 4 Produktprüfung QS 4.1 Prüfbarkeit feststellen QS 4.2 Produkt inhaltlich prüfen Prüfprotokoll QS 5 Berichtswesen Berichtsdokumente
72
QS 1: QS-Initialisierung
73
Inhalte eines QS-Plans im V-Modell
Qualitätsziele und Risiken im Projekt 2.1 Qualitätsziele für Produkte und Prozesse 2.2 Qualitätsrisiken 2.3 Maßnahmen aufgrund der Qualitätsziele und -risiken QS-Maßnahmen gemäß Kritikalität und IT-Sicherheit 3.1 Verwendete Richtlinien oder Normen 3.2 Einstufungsbedingte QS-Maßnahmen Entwicklungsbegleitende Qualitätssicherung 4.1 Zu prüfende Produkte 4.2 Zu prüfende Aktivitäten Spezifische Kontrollmaßnahmen 5.1 Eingangskontrolle von Fertigprodukten 5.2 Kontrolle von Unterauftragnehmern 5.3 Ausgangskontrolle der Softwarebausteine 5.4 Änderungskontrolle 5.5 Kontrolle von Bearbeitungskompetenzen 5.6 Kontrolle des Konfigurationsmanagements
74
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
QS 2: Prüfungsvorbereitung
76
Inhalte einer Prüfspezifikation im V-Modell
Anforderungen 2.1 Einstufung der Funktionseinheit hinsichtlich Kritikalität und IT-Sicherheit 2.2 Prüfanforderungen Methoden der Prüfung Prüfkriterien 4.1 Abdeckungsgrad 4.2 Checklisten 4.3 Endekriterien Prüffälle 5.1 Prüffallbeschreibung 5.2 Abdeckungsmatrix 5.2.1 Architektur-Elemente und Schnittstellen 5.2.2 Fachliche und technische Anforderungen
77
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
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
QS 4: Produktprüfung
80
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
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
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
EINHEIT 3: Qualität in Analyse & Design
aWas sind gute Business-Spezifikationen? B: Fall-Beispiel Seminarorganisation Manuelle Prüfmethoden Reviews u.a. Methoden Verbesserung der Prozess-Qualität (Überblick)
84
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
Seminar-Organisation Pflichtenheft
Ziele Produkteinsatz Produktumgebung Produktfunktionen Produktdaten Produktleistungen (nicht-funktionale Anforderungen) Benutzerschnittstelle Qualitätsziele Globale Testfälle (Use Cases) Entwicklungsumgebung
86
Seminar-Organisation Objektorientierte Analyse
OOA-Diagramm
87
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
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
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
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
Manuelle Prüfmethoden
Inspektion “formales Review“ Review Walkthrough “abgeschwächtes Review“ Stellungnahme
92
Reviews Definition Ziel
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
Reviews (Forts.) Objekte der Prüfung Referenzunterlagen
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
Reviews (Forts.) Beschreibungsform der Prüfung Ergebnisse Prüfobjekte
Informal (z.B. Pflichtenheft) Semiformal (z.B. Pseudocode) Formal (z.B. OOA-Modell, Quellcode) Bezugsobjekte Informal (z.B. Richtlinien) Formal (z.B. OOA-Modell) Ergebnisse Review-Protokolle Empfehlung über Freigabe an Manager Überarbeitetes Prüfobjekt
95
Reviews (Forts.) Teilnehmer Durchführung
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
Ablauf eines Reviews
97
Reviews Kosten und Nutzen
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
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
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
Review-Protokoll: Beispiel
Review Klassendiagramm “Seminar-Organisation“ Beispiel-Protokoll
101
Inspektion “formales Review“ [ANSI/IEEE Std.729-1983]
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
Walkthrough - Ablauf Defekte Prüfobjekt Walkthrough Individuelle
Vorbereitung & Prüfung Gutachter Walkthrough-Sitzung Autor, Gutachter Prüfobjekt Protokoll
103
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
Weitere Prüfmethoden Stellungnahme Round Robin Review Peer Review
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
Verbesserung der Prozessqualität (Überblick)
ISO 9000-Ansatz TQM (Total Quality Management) CMM (Capability Maturity Matrix) Business Engineering
106
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
Bewertung ISO 9000 Vorteile Nachteile
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
Totales Qualitätsmanagement
TQM-Ansatz Totales Qualitätsmanagement Prozessqualität Produktqualität Kontinuierliche Qualitätsverbesserung Bereichs- und funk- tionsübergreifend Kundenorientierung Einbeziehung aller Mitarbeiter T Q M Vorbildfunktion des Managements Qualität wird bei Management- entscheidungen gleichberechtigt zu Kosten und Terminen bewertet An Software-Entwicklung anpassen
109
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
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
CMM-Reifegradstufen Out In In Out In Out Out In In Out Stufe 5
Optimierender Prozess In Stufe 4 Gesteuerter Prozess In Out Stufe 3 Definierter Prozess In Out Stufe 2 Wiederhol- barer Prozess Out In Stufe 1 Initialer Prozess In Out
112
EINHEIT 4: Testende Verfahren
Grundbegriffe Klassifikation Strukturtest (White Box-Test) Funktionaler Test (Black Box-Test) Testmethodik Test-Arten Integrationstest Systemtest Testprozess und -dokumentation
113
Einführung Produktqualität = Produktqualität jeder Systemkomponente
Funktionalität Zuverlässigkeit (Änderbarkeit) Qualitätsmerkmale Konstruktive und analytische Maßnahmen Konstruktion Analyse Eigenschaften der Systemkomponente Produktqualität = Produktqualität jeder Systemkomponente Produktqualität der Beziehungen zwischen den Systemkomponenten
114
Fehler Definition Konstruktives Ziel Analytisches Ziel
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
Auswahl analytischer Maßnahmen
Funktionalität Zuverlässigkeit Analysierbarkeit Änderbarkeit Modifizierbarkeit Stabilität Prüfbarkeit Richtigkeit Reife Fehlertoleranz Qualitätsmerkmale Testende Verfahren Verifizierende Verfahren Analysierende Verfahren Beschreibung Komp.-Art Komponenteneigenschaft Klassen Datentyp-Module Datenobjekt-Module Funktionale Module Spezifikation (z.T. ermittelbar durch Metriken) Implementierung
116
Begriffe Prüfling, Testobjekt Testfall Testdatum Testtreiber
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
Weitere Begriffe Instrumentierung Überdeckungsgrad Regressionstest
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
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
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
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 } // end while }
121
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
Kontrollflussgraph nstart Knoten Zweig, Kante n1 Pfad n2 n3 n4 n5 n6
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; Pfad n2 n3 n4 n5 n6 nfinal
123
Anweisungsüberdeckung vs. Zweigüberdeckung
nstart nstart n1 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; n1 n2 n2 n3 n3 n4 n4 n5 n5 n6 n6 nfinal nfinal
124
Anweisungsüberdeckungstest C0-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
Zweigüberdeckungstest C1-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
Pfadüberdeckungstest
nstart p n1 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; n2 n3 q2 q1 n4 n5 n6 r nfinal
127
Pfadüberdeckungstest
Prinzip Ausführung aller unterschiedlichen Pfade des zu testenden Programms Pfad = Sequenz von Knoten (i,n1, n2, ..., nm) 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
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
Beispiel Boundary-Interior-Pfadtest
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‘, ‘,‘
130
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 2n Variationen große Anzahl Testfälle Minimale Mehrfach-Bedingungsüberdeckung: Jede Bedingung – atomar oder zusammengesetzt – muss mindestens einmal true und einmal false sein
131
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
Einfache Bedingungsüberdeckung
Variablenwerte Testfälle Variablen 1 2 3 Gesamtzahl 4 5 INT_MAX Zchn ‘A‘ ‘E‘ ‘I‘ ‘O‘ ‘U‘ ‘1‘ ‘a‘ ‘D‘ Zchn>=‘A‘ T F Zchn<=‘Z‘ Gesamtzahl < INT_MAX Zchn==‘A‘ - Zchn==‘E‘ Zchn==‘I‘ Zchn==‘O‘ Zchn==‘U‘ Atomare Bedingungen Wahrheitswerte der atomaren Bedingungen
133
Bedingungsüberdeckung Vollständige Prüfung d. Bedingungen
Testfälle Variablen 1 2 3 Gesamtzahl 4 5 6 INT_MAX Zchn ‘A‘ ‘E‘ ‘I‘ ‘O‘ ‘U‘ ‘B‘ ‘1‘ ‘a‘ ‘D‘ Zchn>=‘A‘ Zchn<=‘Z‘ T F Gesamtzahl < INT_MAX Bedingung a Zchn==‘A‘ - Zchn==‘E‘ Zchn==‘I‘ Zchn==‘O‘ Zchn==‘U‘ Bedingung b
134
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
Kontrollflussgraph - Datenflussdarstellung
nstart def (Gesamtzahl) def (VokalAnzahl) 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‘ nin def (Zchn) n1 p-use (Zchn) p-use (Gesamtzahl) n2 c-use (Gesamtzahl) def (Gesamtzahl) n3 n4 p-use (Zchn) c-use (VokalAnzahl) def (VokalAnzahl) n5 n6 def (Zchn) nout c-use (VokalAnzahl) c-use (Gesamtanzahl) nfinal
136
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
Analytische Verfahren – Black Box Tests (Funktionale Tests)
Funktionale Testverfahren Funktionale Äquivalenzklassenbildung Grenzwertanalyse Test spezieller Werte Kombination Funktion- und Strukturtest
138
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
Regeln zur Äquivalenzklassenbildung
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 < 1, Tage > 31 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 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
Regeln zur Äquivalenzklassenbildung (Forts.)
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 Äquivalenzklasse auftrennen, wenn deren Elemente unterschiedlich behandelt werden 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
Beispiel Äquivalenzklassen und Testfälle
Eingaben Äquivalenzklassen Gesamtzahl 1 0<=Gesamtzahl < INT_MAX 2 Gesamtzahl = INT_MAX VokalAnzahl 3 0<=VokalAnzahl<=Gesamtzahl Zchn 4a Zchn < ‘A‘ 4b Zchn > ‘Z‘ 5 ‘A‘ <= Zchn <= ‘Z‘ 6a Zchn = ‘A‘ 6b Zchn = ‘E‘ 6c Zchn = ‘I‘ 6d Zchn = ‘O‘ 6e Zchn = ‘U‘ Testfall 1 2 3 Getestete Äquivalenzkl. 1, 3, 5, 6a, 6b, 6c, 6d, 6e, 4a 1, 3, 4b 2, 3 Gesamtzahl 100 INT_MAX VokalAnzahl 50 Zchn ‘X‘,‘A‘,‘E‘,‘I‘,‘O‘,‘U‘,‘I‘ ‘a‘ - Soll: Gesamtzahl 106 Vokalanzahl 55 Testfälle für ZaehleZchn Äquivalenzklassen Für ZaehleZchn
142
Grenzwertanalyse Prinzip Eigenschaften Bewertung Beispiel
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<=m<=12), 2 ungültige (m<1,m>12) Testfälle: monat = 1; monat = 12; monat = 0; monat =13;
143
Test spezieller Werte Ziel Kriterien Beispiele
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
Zufallstest Prinzip Bewertung
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
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
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
Testmethodik Funktionstest
Testobjekt mit Testwerkzeug instrumentieren (protokolliert Überdeckung) Mit Hilfe Spezifikation bestimmen: Äquivalenzklassen, Grenzwerte, Spezialwerte, Testdaten Keine Implementierung! Testfälle mit Testobjekt durchführen: Soll-Ist-Vergleich Keine Überdeckungsrate betrachten
148
Testmethodik (Forts.) Strukturtest Regressionstest
Überdeckungsstatistik nach Funktionstest auswerten – Nichtabdeckungen untersuchen (z.B. Fehlerabfragen, “tote“ Zweige) Testfälle für noch nicht durchlaufene Zweige, Pfade, Bedingungen aufstellen Durchführung Testlauf für jeden Testfall Ende des Überdeckungstests bei Erreichen einer bestimmten Überdeckungsrate Regressionstest Falls Fehlerkorrektur: Regressionstest mit den bisherigen Testfällen (d.h. nochmalige Durchführung der protokollierten Testfälle und Soll-Ist-Vergleich)
149
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
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
Integrationsstrategien
big bang Nicht- inkrementell geschäftsprozess- orientiert bottom-up funktionsorientiert top-down Inkrementell inside-out hardest first nach der Verfügbarkeit outside-in vorgehensorientiert testzielorientiert
152
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: liest jeden Satz einer Datei und löscht dann C G: abstrakter Datentyp mit 2 Operatoren: LeseNaechstenSatz und LoescheSatz G
153
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
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) Max Teilnehmer, max Seminare Importschnittstelle für Massendaten
155
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 Datei nicht vorhanden bei Dateischnittstelle Datei zu groß
156
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) Anforderungen an User Interface aus Pflichtenheft 2 Rollen: Kundensachbearbeiter, Seminarsachbearbeiter Sicherheit Datenschutz-Mech. (Sicherheitstest), Passwörter, Zugriffsrechte
157
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
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
Testprozess und -dokumentation
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
Inhalt einer Testvorschrift
Einleitung 1.1 Zweck des Tests 1.2 Testumfang 1.3 Referenzierte Unterlagen Testumgebung 2.1 Überblick 2.2 Test-Software und -Hardware 2.3 Testdaten, Testdatenbanken 2.4 Personalbedarf Abnahmekriterien 3.1 Kriterien für Erfolg und Abbruch 3.2 Kriterien für Unterbrechungen 3.3 Voraussetzungen für Wiederaufnahme
161
Inhalt einer Testvorschrift (Forts.)
Testabschnitt 1 4.1 Einleitung 4.1.1 Zweck, Referenz zur Spezifikation 4.1.2 Getestete Software-Einheiten 4.1.3 Vorbereitungsarbeiten für den Testabschnitt 4.1.4 Aufräumarbeiten nach dem Testabschnitt 4.2 Testsequenz 1-1 4.2.1 Testfall 1-1-1 Eingabe, Anweisung, Soll-Ausgabe, Raum für Ist-Ausgabe und Befund 4.2.2 Testfall 1-1-2 4.3 Testsequenz 1-2 : 4.n Ergebnis des Abschnitts 1 Testabschnitt 2
162
Testzusammenfassung Allgemeine Daten Gegenstand und Zweck des Tests
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
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.