IV Software-Qualitätssicherung

Transkript

1 Softwaretechnik- Praktikum: 11. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management Software Qualitätssicherung Zusammenfassung Zusatz: Praxisvorträge von dspace Hella V10-2 Softwaretechnikpraktikum: IV Software-Qualitätssicherung (Fortsetzung) Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de IV Software-Qualitätssicherung IV.1 Grundlagen IV.2 Analytisches Qualitätsmanagement IV.2.1 Analysierende Verfahren IV.2.2 Testende Verfahren IV.3 Konstruktives Qualitätsmanagement IV.5 Prozessqualität IV.6 Diskussion & Zusammenfassung IV.7 Literaturhinweise V10-4 Prinzipien (1) Analytische & Konstruktive Maßnahmen (2) Qualität muss geplant werden (3) Produkt- & Prozessqualität (4) Frühzeitige Maßnahmen / kontinuierliche Qualitätssicherung (5) Unabhängige Qualitätssicherung (6) Quantitative Qualitätssicherung (Metriken) (1) Analytische vs. Konstruktive Maßnahmen Analytische Qualitätsmanagement/Maßnahmen Untersuchen das fertige Produkt, ob es bezüglich bestimmter Qualitätsmerkmale die gewünschte Stufe erreicht Beispiel: Tests sind eine analytische Maßnahme zur Qualitätssicherung, die ggf. die Qualität sicherstellen aber keine Qualität erzeugen (sie können nur schlechte Qualität aussortieren) Konstruktive Qualitätsmanagement/Maßnahmen Sorgen während des Erstellungsprozesses dafür, dass direkt bei der Entwicklung die benötigten Qualitätsmerkmale möglichst erfüllt werden V10-5 V10-6 1

2 Analytische Maßnahmen (2) Qualität muss geplant werden Analysierende Verfahren (Kapitel IV.2.1) Überprüfen die Qualität, ohne das Produkt auszuführen (insbes. Bei Dokumenten möglich) Beispiele: Statische Analyse, Programmverifikation, Reviews Testende Verfahren (Kapitel IV.2.2) Führen das Produkt (das Programm) zum Überprüfen der Qualität aus Beispiele: dynamischer Test, Bemerkung: Der Übergang zwischen testenden und analysierenden Verfahren ist fließend. Beispiele: Simulation, Modelchecking, Slicing, Qualitätsmanagement (QM): Es umfasst alle Maßnahmen und Tätigkeiten, Qualität zu erzeugen Qualitätsplanung: Welches Teilprodukt (Dokument) muss wann, wie und von wem bezüglich welcher Qualitätsanforderungen überprüft werden! Qualitätslenkung: Arbeitstechniken und Tätigkeiten, die zur Erfüllung der Qualitätsanforderungen angewendet werden (dies sind in erster Linie konstruktive Maßnahmen) Qualitätssicherung (QS): Maßnahmen und Tätigkeiten, die Vertrauen schaffen, dass das Produkt die Qualitätsanforderungen erfüllt. V10-7 V10-8 (3) Produkt und Prozess (4) Frühzeitige Maßnahmen Produktorientiertes QM: Qualität unmittelbar am Produkt gewährleisten ( QS). Prozessorientiertes QM: Qualität des Prozesses gewährleistet, dass auch das durch den Prozess erzeugte Produkt die nötige Qualität besitzt (siehe Kapitel IV.5) Erfahrung zeigt: Rein produktorientiertes QM hat sich für Softwareprodukte als sehr unzweckmäßig erwiesen. Beobachtung: Je früher ein Fehler gefunden und beseitigt wird, desto weniger Folgekosten verursacht er. Schlussfolgerung: Man sollte versuchen Fehler möglichst früh zu entdecken! [Pressman2004] V10-9 V10-10 Fehlerbeseitigung und Zeit (5) Unabhängige Qualitätssicherung Einige Autoren sehen sogar eine Korrelation zwischen Zeit und Defekt-Rate (s. [McConnell 1996]) Niemand macht gern das eigene Produkt kaputt ( Psychologie des Testens )! Wer beim Entwickeln einen Fall vergißt, vergißt ihn auch beim Testen. Deshalb sollten QS-Maßnahmen wenn möglich nicht vom Entwickler selbst durchgeführt werden! V10-11 V

3 (6) Quantitative Qualitätssicherung Qualitätsindikator: (objektive) Eigenschaft eines Produktes zur Bewertung eines Qualitäts(teil)merkmals Kommentare, Struktur des Codes, Anzahl Methoden, Klassen etc. Qualitätsmaß: Skala und Verfahren zur Bestimmung des Wertes eines Qualitätsindikators (s. Software-Metriken) Qualitätsanforderung: Legt für jedes Qualitätsmerkmal das mind. erreichte Qualitätsmaß (Qualitätsstufe) fest IV.2 Analytisches Qualitätsmanagement Analysierende Verfahren: Untersuchung auf konzeptioneller Ebene ohne Ausführung der konkreten Software Auch Modellierung (mathematische Darstellung) Testende Verfahren (Dynamische Analyse): Ausführung der konkreten Software oder von Teilen, um Abweichung von erwarteten Verhalten zu identifizieren V10-13 V10-14 Verfahren und Phasen der Entwicklung IV.2.1 Analysierende Verfahren Phase Anforderungsdefinition Analyse Entwurf Implementierung Testen (Verifikation) Testen (Validation) Testen Analyse Modellierung [Storey1996] Reviews und Inspections persönliche Review, Walkthroughs, Inspections, Formale technische Reviews, Audit, (siehe II.3. Reviewtechniken) Statische Codeanalyse Kontrolfluss- und Datenflussanalyse, Symbolische Ausführung, Timinganalysen, Modellierung mit üblichen Notationen Zustandsdiagramme, Datenflussdiagramme, Strukturdiagramme, Modellierung der Umgebung und Simulation der Modelle Modellierung mit formalen Methoden Diskrete Mathematik, Logik, temporal Logiken, Prozessalgebren, Modelchecking, Theorem Proving, Voll- oder semi-automatische Analyse formaler Modelle bzgl. einer formalen Spezifikation V10-15 V10-16 IV.2.2 Testende Verfahren Der Prozess des Testens Siehe II.4 Testtechniken Phasen: (1) Festlegen des Ansatzes für das Testen (2) Planung der Tests (3) Entwicklung der Tests (4) Umsetzung der Tests V10-17 V

4 (1) Ansatzes für das Testen Festlegung des Ansatzes hängt ab von der Anwendungdomäne und von den Risiken, die vom Produkt ausgehen. Festlegung der Teststrategien Big Bang, Bottom-Up, Top-Down, Wo sollen Glassbox Tests verwendet werden (2) Planung der Tests Für Modultest, Integrationstest, Systemtest Muss addressieren: a) Was soll getestet werden? b) Welche Quellen sollen verwendet werden? c) Wer führt die Tests durch? d) Wo werden die Tests durchgeführt? e) Wann sollte man die Tests beenden? V10-19 V10-20 a) Was soll getestet werden? Muss adressieren: Welche Module sollen getestet werden? Welche Integrationsergebnisse sollen getestet werden? Festlegung der Prioritäten für die Zuweisung von Ressourcen zu den einzelnen Aufgaben Bewertung: Schadensstufen = Schwere eine Modulversagens Wahrscheinlichkeit des Auftreten des Fehlers Risiko = Schadensstufen * Wahrscheinlichkeit b) Welche Quellen sollen für die Tests genutzt werden? Alternativen: Zufällige Stichproben aus dem wirklichen Leben Aus dem realen Kontext der Anwendung Bezieht sich auf existierende Kunden etc. Synthetische Tests Explizit entwickelt Leitet sich aus der Kombination aus System- und Betriebsparametern ab Entwickelt um alle bekannten/erwartetet Betriebssituationen abzudecken V10-21 V10-22 c) Wer führt die Tests durch? Modultest: Entwickler Integrationstest: Entwickler oder Tester Systemtest: unabhängiger Tester Große Systeme: Mehrere Testteams Kleine Organisationen: Tests durch ein anderen Entwicklerteam Outsourcing des Testen Entwickler Versteht das System, aber wird eher gnädig testen, da er an der Fertigstellung interessiert ist. unabhängiger Tester Muss sich erst in das System einarbeiten, aber ist an der Qualität orientiert und ist motiviert Fehler zu finden. d) Wo werden die Tests durchgeführt? Modultests & Integrationstest: Beim Entwickler Systemtest: Beim Entwickler oder in der Zielumgebung? Bei externen Testern: dort Man muss versuchen die Zielumgebung so gut wie möglich zu simulieren Trotzdem sind Fehler bei der Systeminstallation nicht auszuschließen V10-23 V

5 e) Wann sollte man die Tests beenden? Alternativen: i. Komplete Implementierung ii. Mathematische Schätzmodelle iii. Error Seeding iv. Unabhängige Testteams v. Wenn kein Geld mehr da ist i. Komplete Implementierung Testen wird beendet wenn: Der gesamte Testplan ausgeführt wurde Fehlerfreie Ergebnisse für alle Regressionstests vorliegen Passt zum Ansatz der Perfektion Missachtet Geld- und Zeitrestriktionen V10-25 V10-26 ii. Mathematische Schätzmodelle Ein mathematisches Modell wird benutz um den Prozentsatz unentdeckter Fehler zu schätzen Schätzung der Fehler auf Basis des Umfangs Betrachtung der Fehlererkennungsrate über die Zeit Festlegen einer akzeptablen Restfehlerquote Festlegen eines Abbruchkriteriums, dass dieser Restfehlerquote entspricht Testen wird beendet wenn das Kriterium erfüllt wird Die mathematischen Modelle repräsentieren meist nicht alle Charakteristika von Projekten Einfache Models bieten keine Aussagen über die Schwere der unerkannten Fehler iii. Error Seeding Fehler verschiedenen Typs werden in der zu testenden Software vor dem Test versteckt (seeded) Annahmen: Prozentsatz der erkannten versteckten Fehler korrespondiert zur Prozentzahl der erkannten realen Fehler Festlegen einer akzeptablen Restfehlerquote Festlegen eines Abbruchkriteriums, dass dieser Restfehlerquote entspricht Testen wird beendet wenn das Kriterium erfüllt wird Zusätzlicher Testaufwand wegen der versteckten Fehler Die Verteilung der versteckten Fehler wird in der Regel an vorherigen Projekten orientiert. In der Praxis können aber auch neue Fehlertypen auftreten nur anwendbar bei ähnlichen Projekten V10-27 V10-28 iv. Unabhängige Testteams Zwei Teams setzen des Testprozess unabhängig um Festlegen der akzeptablen Restfehlerrate Festlegen eines Abbruchkriteriums, dass dieser Restfehlerquote entspricht Annahme: statistisch unabhängiges Testen der beiden Teams sowie zufällige Fehlererkennung Testen wird beendet wenn das Kriterium erfüllt wird Nur anwendbar wenn man zwei wirklich unabhängige Testteams hat zufällige Fehlererkennung ist eine starke Annahme Methodologische Basis ist fragwürdig, wenn beide Teams ähnliche Erfahrung haben oder den selben Ansatz zum Testen verwenden v. Wenn kein Geld mehr da ist Testen wird einfach beendet, wenn kein Geld oder Zeit mehr dafür da ist Eigentlich nicht akzeptables Vorgehen (aber nicht unüblich) Systematische Nachbearbeitung (in allen Fällen sinnvoll): Datenerfassung aüber erkannte Fehler während der Entwicklung und Benutzung (ersten 6 bis 12 Monate) Analyse der Daten: Vergleich der Schätzung mit den realen Daten Vergleich der Schwere der Fehler: Sind die im Betrieb entdeckten Fehler (ersten 6 bis 12 Monate) gravierender als die während der Entwicklung entdeckten? V10-29 V

6 (4) Umsetzung der Tests Tests können wie folgt ausgeführt werden: Ad hoc & manuell Systematisch & manuell Systematisch & semi-automatisch Systematisch & voll-automatisch Aktivitäten bei der Testausführung: Auswahl der Tests Vorbedingungen des Tests herstellen Testdaten vorbereiten Test ausführen (wie vorher definiert) Aufzeichnung/Erfassung der Ausführung und Ergebnisse Zusätzliche Überprüfung erwarteter Nachbedingungen Überprüfung der Ausgaben des Tests und ggf. Dokumentierung der Probleme Dokumentierung jeder Testausführung Literaturhinweise [Balzert1996] Helmut Balzert: Lehrbuch der Software-Technik: Software- Entwicklung. Spektrum Akademischer Verlag [Balzert1998] Helmut Balzert: Lehrbuch der Software-Technik: Software- Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag [Beck 2004] Beck, K., and Gamma, E. Test Infected: Programmers Love Writing Tests, [Binder 1999] Binder, R.V., Testing Object-Oriented Systems, Addison- Wesley, D. Galin, Software Quality Assurance: From theory to implementation. Harlow, England: Pearson Addison Wesley, [Sommerville2004] Ian Sommerville. Software Engineering. Addison Wesley. 7 ed., [Whittaker2002] Whittaker, James (2002) Why Software Fails, Addison- Wesley. V10-31 V10-32 Aufgaben/Abgaben: Softwaretechnikpraktikum: Aktuelle Aufgaben und Fragerunde V10-34 Fragen? V