Qualitätsmanagement in der Software-Entwicklung Prof. Dr. Thomas Kudraß HTWK Leipzig Seminar...
-
Upload
heribert-wernecke -
Category
Documents
-
view
111 -
download
3
Transcript of Qualitätsmanagement in der Software-Entwicklung Prof. Dr. Thomas Kudraß HTWK Leipzig Seminar...
Qualitätsmanagement in der Software-Entwicklung
Prof. Dr. Thomas Kudraß
HTWK Leipzig
Seminar PC-Ware AG Leipzig, 26.01.2002
© Prof. T. Kudraß, HTWK Leipzig
MotivationKleine 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)
© 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-SpezifikationenB: Manuelle Prüfmethoden (Reviews) mit Beispiel
EINHEIT 4– Qualitätssicherung in der Programmierung: Test-Verfahren– Arten von Tests
© 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
© 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
© 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
© 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
© 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
© 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
© 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)
© Prof. T. Kudraß, HTWK Leipzig
Qualitätsmerkmale für Software-Produkte
Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit
Quelle: DIN-Norm ISO 9126
© 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
© 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
© 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
© 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
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
FURPS Qualitätsmodell
Entwickelt von HP 1985
Merkmale (stark kundenorientiert definiert) Functionality Usability Reliability Performance Supportability
© Prof. T. Kudraß, HTWK Leipzig
GQM-Ansatz: Goal-Question-MetricVorgehensmodell
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
© Prof. T. Kudraß, HTWK Leipzig
Beispiel für ein Software-Bewertungsmodell
Z1
F2
M1
Z2 Z3 Z4
F1 F3 F4 F5 F6
M2 M3 M4 M5
Auswertungsziele(goals)
Abgeleitete Frage-stellungen(questions)
Primitive Maße(metrics)
© 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
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
Erweitertes GQM-Bewertungsmodell
Wir untersuchen Produkte und ...
Qualitätsbaum-Quellcode
Testbarkeit Wartbarkeit
Strukturiertheit
Innere Struktur
Größe des Programms?
Lines of Codes
Qualitätsbaum-AnalyseWeitere Qualitätsbäume
...
......
...
...
Ziel(goal)
Qualitätsbäumefür jedesZwischenprodukt
Fragen(questions)
Kennzahlen(metrics)
© Prof. T. Kudraß, HTWK Leipzig
Qualitätsbaum “Wartbarkeit“
SWS ist leicht wartbarWB
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 eindeutiginterpretierbar
WB21
SWS leicht verständlich WB22
Ist gut dokumentiert WB23
Ist gut strukturiertWB31
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
© 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
© 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
© 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
© 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
© 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
© 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
OrganisatorischeMaßnahmen
Methoden Sprachen Werkzeuge Richtlinien Standards Checklisten
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
Aktivitäten des Qualitätsmanagement
Qualitätsplanung Qualitätslenkung und –sicherung Qualitätsprüfung
© 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
© 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
© 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
© 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)
© 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
© 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
© 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!
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
Summation von Fehlern und Mängeln
Fehlerhafte Anforderungen
Korrekte Anforderungen
Spezifikations- fehler
Korrekte Spezifikation
Entwurfs- fehler
KorrekterEntwurf
Programm-fehler
Korrektes Programm
Korrigierte Fehler
Korrektes Verhalten
Anforderungs-definition
System-spezifikation
Entwurf
Realisierung
Test undIntegration
Induzierte Fehler aus Anforderungen
Induzierte Fehler aus Anforderungen | Spezifikation
Induzierte Fehler ausAnforderungen | Spezifikation | Entwurf
Bekannte un-korrigierte Fehler
Unbekannte Fehler
© Prof. T. Kudraß, HTWK Leipzig
Vorzeitige FehlerentdeckungVorteile
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!
© 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
© Prof. T. Kudraß, HTWK Leipzig
Entwicklungsbegleitende, integrierte Qualitätssicherung
Produktmodell
Definieren
Entwerfen
Produktarchitektur
Implementieren
Produkt
Änderungen
Prüfen und freigeben
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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
V-Modell
AbnahmetestAnforderungs-definition
Grobentwurf
Feinentwurf
Modulimple- mentation
Systemtest
Integrationstest
Modultest
Validation
Verifikation
Anwendungsszenarien
Testfälle
Testfälle
Testfälle
© 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
© Prof. T. Kudraß, HTWK Leipzig
V-Modell Einführung
Die drei Ebenen der Standardisierung
Werkzeug- anforderungen
Methoden
Vorgehensweise
Konfigurationsmanagement
Qualitätssicherung
Systemerstellung
Projektmanagement
© 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
© Prof. T. Kudraß, HTWK Leipzig
Zusammenwirken der 4 Submodelle
Konfigurations- struktur
Projekt planen und kontrollieren
PM
SE
QS KM
Plandaten Istdaten SEU
SEU
QS- Ergebnis
Ist- daten
QS-Anforderung
Produkt
Produkt entwickeln
QS- Anforderungen
vorgeben
Produkte prüfen
Produkte/ Rechte
verwalten
Produktstruktur planen
Plan- daten
SEU SEU Plan- daten
Plan- daten
Ist- daten
Ist- daten
Produkt
Rechte
Voraussetzungen schaffen und Softwareentwicklungs-
umgebung (SEU) bereitstellen
© Prof. T. Kudraß, HTWK Leipzig
Arbeitsteilung zwischen SE und QSim V-Modell
© Prof. T. Kudraß, HTWK Leipzig
Analytische Maßnahmen im V-Modell
Prüfung
Selbstprüfung Verifikation
Prozessprüfung Produktprüfung
Validation
© Prof. T. Kudraß, HTWK Leipzig
Rollenverteilung bei der Durchführung von Prüfaktivitäten
Prüfaktivität Produktersteller QS-Verant-wortlicher
Prüfer AG/Anwender
Selbstprüfung v
Prozessprüfung v m
Produktprüfung b m v
Validation m v m
v verantwortlich b beratend m mitwirkend
© 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
© Prof. T. Kudraß, HTWK Leipzig
Formelle PrüfungBeteiligung 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
© Prof. T. Kudraß, HTWK Leipzig
Kritikalität = Bedeutung von Fehlverhalten
Kritikalität ... 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
Submodell QS im Überblick
QS 1 QS-InitialisierungQS 1.1 QS-Plan erstellenQS 1.2 Prüfplan erstellen QS-Plan
QS 2 PrüfungsvorbereitungQS 2.1 Prüfmethoden und –kriterien festlegenQS 2.2 Prüfumgebung definieren PrüfplanQS 2.3 Prüffälle festlegen PrüfspezifikationQS 2.4 Prüfprozedur erstellen Prüfprozedur
QS 3 Prozessprüfung von Aktivitäten Prüfprozedur
QS 4 ProduktprüfungQS 4.1 Prüfbarkeit feststellenQS 4.2 Produkt inhaltlich prüfen Prüfprotokoll
QS 5 Berichtswesen Berichtsdokumente
© Prof. T. Kudraß, HTWK Leipzig
QS 1: QS-Initialisierung
© Prof. T. Kudraß, HTWK Leipzig
Inhalte eines QS-Plans im V-Modell
2. Qualitätsziele und Risiken im Projekt2.1 Qualitätsziele für Produkte und Prozesse2.2 Qualitätsrisiken2.3 Maßnahmen aufgrund der Qualitätsziele und -risiken
3. QS-Maßnahmen gemäß Kritikalität und IT-Sicherheit3.1 Verwendete Richtlinien oder Normen3.2 Einstufungsbedingte QS-Maßnahmen
4. Entwicklungsbegleitende Qualitätssicherung4.1 Zu prüfende Produkte4.2 Zu prüfende Aktivitäten
5. Spezifische Kontrollmaßnahmen5.1 Eingangskontrolle von Fertigprodukten5.2 Kontrolle von Unterauftragnehmern5.3 Ausgangskontrolle der Softwarebausteine5.4 Änderungskontrolle5.5 Kontrolle von Bearbeitungskompetenzen5.6 Kontrolle des Konfigurationsmanagements
© 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?
© Prof. T. Kudraß, HTWK Leipzig
QS 2: Prüfungsvorbereitung
© Prof. T. Kudraß, HTWK Leipzig
Inhalte einer Prüfspezifikation im V-Modell
2. Anforderungen2.1 Einstufung der Funktionseinheit hinsichtlich Kritikalität und IT-Sicherheit2.2 Prüfanforderungen
3. Methoden der Prüfung
4. Prüfkriterien4.1 Abdeckungsgrad 4.2 Checklisten4.3 Endekriterien
5. Prüffälle5.1 Prüffallbeschreibung5.2 Abdeckungsmatrix5.2.1 Architektur-Elemente und Schnittstellen5.2.2 Fachliche und technische Anforderungen
© 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
© 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!
© Prof. T. Kudraß, HTWK Leipzig
QS 4: Produktprüfung
© 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?
© 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
© 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
© 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)
© Prof. T. Kudraß, HTWK Leipzig
Fall-BeispielSeminarorganisation
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
© Prof. T. Kudraß, HTWK Leipzig
Seminar-OrganisationPflichtenheft
1. Ziele2. Produkteinsatz3. Produktumgebung4. Produktfunktionen5. Produktdaten6. Produktleistungen (nicht-funktionale Anforderungen)7. Benutzerschnittstelle8. Qualitätsziele9. Globale Testfälle (Use Cases)10. Entwicklungsumgebung
© Prof. T. Kudraß, HTWK Leipzig
Seminar-OrganisationObjektorientierte Analyse
OOA-Diagramm
© 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
© Prof. T. Kudraß, HTWK Leipzig
Manuelle PrüfmethodenVoraussetzungen
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
© 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
© 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“
© Prof. T. Kudraß, HTWK Leipzig
Manuelle Prüfmethoden
Inspektion “formales Review“ Review Walkthrough “abgeschwächtes Review“ Stellungnahme
© 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
© 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
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig Ursprungsprodukt
Entw icklungsphase i
Manager Autor
Prüfobjekt
Ein-gangsprü-
fung
EinführungssitzungModerator, Autor,
Gutachter
IndividuelleVorbereitung & Prüfung
Gutachter
Prüfobjekt m itMarkierungen Gutachter
Review-SitzungModerator, Autor,
Gutachter, Protokollführer
Freigabe-empfehlung an
Manager
freigegebenesPrüfobjekt
Erstellungsregeln
Reviewplan
Fragenkataloge
ÜberarbeitungAutor
NachüberprüfungModerator / Gutachter
Protokoll
Defekte
1/2 - 1 h
nicht OK
< 2 h
akzeptiert m .Überarbeitung
Gutachter
nicht akzeptiert
ManagerReview
Ablauf eines Reviews
© 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
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
Review-Protokoll: Beispiel
Review Klassendiagramm “Seminar-Organisation“
Beispiel-Protokoll
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
Walkthrough - Ablauf
Prüfobjekt
Individuelle Vorbereitung & PrüfungGutachter
Walkthrough-SitzungAutor, Gutachter
Protokoll Prüfobjekt
Defekte
Walkthrough
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
Verbesserung der Prozessqualität (Überblick)
ISO 9000-Ansatz TQM (Total Quality Management) CMM (Capability Maturity Matrix) Business Engineering
© 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!)
© 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
© 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
© 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)
© 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)
© Prof. T. Kudraß, HTWK Leipzig
CMM-Reifegradstufen
In
In
In
In
Out
Out
Out
Out
Stufe 5Optimierender Prozess
Stufe 4Gesteuerter Prozess
Stufe 3Definierter Prozess
Stufe 2Wiederhol-barer Prozess
Stufe 1Initialer Prozess
OutIn
© 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
© 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
Konstruktion Analyse
FunktionalitätZuverlässigkeit(Änderbarkeit)
© 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
© Prof. T. Kudraß, HTWK Leipzig
Auswahl analytischer Maßnahmen
Funktionalität
Richtigkeit Reife
Zuverlässigkeit
Fehlertoleranz
Qualitätsmerkmale
Analysierbarkeit
Änderbarkeit
Modifizierbarkeit
Stabilität
Prüfbarkeit
Testende Verfahren Verifizierende Verfahren Analysierende Verfahren
Spezifikation
ImplementierungKlassenDatentyp-ModuleDatenobjekt-ModuleFunktionale Module
Beschreibung Komp.-Art
(z.T. ermittelbar durch Metriken)
Komponenteneigenschaft
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
Klassifikation testender Verfahren
Dynamische VerfahrenStrukturtest (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
© 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.
© 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 ifcin >> Zchn;
} // end while}
© 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;
}
© Prof. T. Kudraß, HTWK Leipzig
Kontrollflussgraph
n1
n2
n3
n4
n5
Knoten Zweig, Kante
Pfad
nfinal
nstart
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
© Prof. T. Kudraß, HTWK Leipzig
Anweisungsüberdeckung vs. Zweigüberdeckung
n1
n2
n3
n4
n5
nfinal
nstart
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
nfinal
n6
nstart
© Prof. T. Kudraß, HTWK Leipzig
AnweisungsüberdeckungstestC0-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%)
© Prof. T. Kudraß, HTWK Leipzig
ZweigüberdeckungstestC1-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
© Prof. T. Kudraß, HTWK Leipzig
Pfadüberdeckungstest
n1
n2
n3
n4
n5
nfinal
nstart
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
q2q1
r
© Prof. T. Kudraß, HTWK Leipzig
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)
© 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
© 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
© 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 2n Variationen große Anzahl Testfälle
– Minimale Mehrfach-Bedingungsüberdeckung:Jede Bedingung – atomar oder zusammengesetzt – muss mindestens einmal true und einmal false sein
© Prof. T. Kudraß, HTWK Leipzig
BedingungsüberdeckungBeispiel
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‘))
© Prof. T. Kudraß, HTWK Leipzig
Einfache Bedingungsüberdeckung
Variablen 1 2 3
Gesamtzahl 0 1 2 3 4 5 0 INT_MAX
Zchn ‘A‘ ‘E‘ ‘I‘ ‘O‘ ‘U‘ ‘1‘ ‘a‘ ‘D‘
Zchn>=‘A‘ T T T T T F T T
Zchn<=‘Z‘ T T T T T T F T
Gesamtzahl < INT_MAX
T T T T T T T F
Zchn==‘A‘ T F F F F - - -
Zchn==‘E‘ F T F F F - - -
Zchn==‘I‘ F F T F F - - -
Zchn==‘O‘ F F F T F - - -
Zchn==‘U‘ F F F F T - - -
Testfälle Variablenwerte
Atomare Bedingungen Wahrheitswerte der atomaren Bedingungen
© Prof. T. Kudraß, HTWK Leipzig
Bedingungsüberdeckung Vollständige Prüfung d. Bedingungen
Variablen 1 2 3
Gesamtzahl 0 1 2 3 4 5 6 0 INT_MAX
Zchn ‘A‘ ‘E‘ ‘I‘ ‘O‘ ‘U‘ ‘B‘ ‘1‘ ‘a‘ ‘D‘
Zchn>=‘A‘
Zchn<=‘Z‘
T
T
T
T
T
T
T
T
T
T
T
T
F
T
T
F
T
T
Gesamtzahl < INT_MAX
T T T T T T T T F
Bedingung a T T T T T T F F F
Zchn==‘A‘ T F F F F F - - -
Zchn==‘E‘ F T F F F F - - -
Zchn==‘I‘ F F T F F F - - -
Zchn==‘O‘ F F F T F F - - -
Zchn==‘U‘ F F F F T F - - -
Bedingung b T T T T T F - - -
Testfälle
© 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)
© Prof. T. Kudraß, HTWK Leipzig
Kontrollflussgraph - Datenflussdarstellung
nstartImport 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
nfinal
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)
nin
nout
© 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
© Prof. T. Kudraß, HTWK Leipzig
Analytische Verfahren – Black Box Tests (Funktionale Tests)
Funktionale Testverfahren– Funktionale Äquivalenzklassenbildung– Grenzwertanalyse– Test spezieller Werte
Kombination Funktion- und Strukturtest
© 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!
© 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 Tage1 gültige Klasse: 1 <= Tage <= 312 ungültige Klassen: Tage < 1, Tage > 31
2. Anzahl von Werten 1 gültige und 2 ungültige ÄquivalenzklassenEingabebereich: 1..6 Besitzer eines Autos1 gültige Klasse: 1..6 Besitzer2 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
© 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 sein1 gültige Klasse: Das erste Zeichen ist ein Buchstabe1 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 erzeugen2 ungültige Klassen: - Alle Eingaben, die Ausgaben kleiner als 1 erzeugen- Alle Eingaben, die Ausgaben größer als 99 erzeugen
© Prof. T. Kudraß, HTWK Leipzig
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 1 INT_MAX
VokalAnzahl 50 1 50
Zchn ‘X‘,‘A‘,‘E‘,‘I‘,‘O‘,‘U‘,‘I‘
‘a‘ -
Soll: Gesamtzahl
106 1 INT_MAX
Vokalanzahl 55 1 50
ÄquivalenzklassenFür ZaehleZchn
Testfälle fürZaehleZchn
© 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
Beispielvoid 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;
© 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
© 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
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
Testmethodik
1. Funktionstesta) 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
© Prof. T. Kudraß, HTWK Leipzig
Testmethodik (Forts.)
2. Strukturtesta) Ü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 Testfalld) Ende des Überdeckungstests bei Erreichen einer bestimmten
Überdeckungsrate
3. RegressionstestFalls Fehlerkorrektur: Regressionstest mit den bisherigen Testfällen (d.h. nochmalige Durchführung der protokollierten Testfälle und Soll-Ist-Vergleich)
© 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)
© 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
© 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
© 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
GG: abstrakter Datentyp mit 2 Operatoren: LeseNaechstenSatz und LoescheSatz
C: liest jeden Satz einer Datei und löscht dann
© Prof. T. Kudraß, HTWK Leipzig
Integrationstest-Verfahren
DynamischTest der integrierten Komponenten mit konkreten Eingabewerten
Strukturorientiert– Kontrollflussorientiert– Datenflussorientiert
Funktionalzu wenig Funktionalität / zu viel Funktionalität / falsche Funktionalität
WertbezogenTest mit extremen Werten (vgl. Grenzwertanalyse, Test spezieller Werte)
© 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. 50.000 Teilnehmer, max. 10.000 Seminare Importschnittstelle für Massendaten
© 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ß
© 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: 100.000 Teilnehmern, 50.000 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
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
Testprozess und -dokumentation
Testprozess– Testplanung– Testdurchführung– Testkontrolle
Dokumente– Testplan und
Testvorschrift– Testbericht
Testbericht [ANSI/IEEE Std. 829-1983]– Testzusammenfassung– Testprotokoll (ergibt sich aus Testvorschrift)– Liste der Problemmeldungen– Liste der Software-Einheiten
© Prof. T. Kudraß, HTWK Leipzig
Inhalt einer Testvorschrift
1. Einleitung1.1 Zweck des Tests1.2 Testumfang1.3 Referenzierte Unterlagen
2. Testumgebung2.1 Überblick2.2 Test-Software und -Hardware2.3 Testdaten, Testdatenbanken2.4 Personalbedarf
3. Abnahmekriterien3.1 Kriterien für Erfolg und Abbruch 3.2 Kriterien für Unterbrechungen3.3 Voraussetzungen für Wiederaufnahme
© Prof. T. Kudraß, HTWK Leipzig
Inhalt einer Testvorschrift (Forts.)
4. Testabschnitt 14.1 Einleitung4.1.1 Zweck, Referenz zur Spezifikation4.1.2 Getestete Software-Einheiten4.1.3 Vorbereitungsarbeiten für den Testabschnitt4.1.4 Aufräumarbeiten nach dem Testabschnitt4.2 Testsequenz 1-14.2.1 Testfall 1-1-1
Eingabe, Anweisung, Soll-Ausgabe, Raum für Ist-Ausgabe und Befund4.2.2 Testfall 1-1-24.3 Testsequenz 1-2:4.n Ergebnis des Abschnitts 1
5. Testabschnitt 2:
© 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