T4 Statischer Test. Siemens AG Österreich 2005 All Rights Reserved. Statischer Test - Allgemein. Kennzeichen: Testen, ohne das Testobjekt auszuführen

Transkript

1 T4 Statischer Test Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test Statischer Test - Allgemein Kennzeichen: Testen, ohne das Testobjekt auszuführen Ziele: Kostenreduktion durch frühe Fehlerfindung Testaufwand, Einsatz, Kundenzufriedenheit Beschleunigung des Gesamtprojektes Entwicklungsprozess optimieren Teilziele Fehler gegenüber Spezifikationen erkennen Abweichungen gegenüber Standards erkennen Messgrössen und ermitteln Fehler pro Seite,

2 Grundlagen Benutzung der menschlichen Analysefähigkeit Intensives Lesen und Nachvollziehen Verschiedene n, je nach: Intensität Benötigte Ressourcen Personen Zeit Ziele zusätzlich zu den allgemeinen Zielen: Wissensaustausch zwischen Projektmitgliedern Präzisierung der Spezifikationen Verstösse gegen Projektplanung erkennen 3 Begriff "Review": Synonym zu strukturierte Gruppenprüfungen Bezeichnung für ein bestimmtes Vorgehen Kosten und Nutzen Folgende Angaben aus der Literatur Kosten: 10%-15% des Entwicklungsbudgets Einsparung: 14%-25% (obige Kosten eingerechnet) Fehlerfindung: 70% in Dokumenten ==> Reduktion der Fehlerkosten in der Entwicklung 4 2

3 Planung Welche Dokumente Status der Dokumente (ready_for_review) Welches Review-Verfahren Walkthrough Inspektion (bekannt: nach Fagan) Technisches Review Informelles Review Welche Personen Ort, Zeit 5 Initialisierung und Vorbereitung Initialisierung: Zweck des Vorstellung der zu prüfenden Dokumente Dokumente, gegen die geprüft wird zb. Richtlinien, Standards Prüfkriterien zb. Checklisten Vorbereitung der Sitzung: Intensive Auseinandersetzung mit zu prüfenden Dokumenten Auf Basis der Richtlinien, Standards,... Notierung aller Mängel Fragen 6

4 Sitzung und Nachbereitung 7 Wichtige Aspekte der Review-Sitzung: Fester Zeitrahmen Führung durch die Moderator/in Das Dokument und nicht die Autor/in werden reviewt Keine Diskussion von Lösungen Konsens aller Beteiligten ist anzustreben Protokoll anfertigen Gemeinsame Bewertung des Reviewobjektes: akzeptieren, weiteres Review nötig,... Nachbereitung Bezogen auf das Review Autor/in behebt Mängel Eventuell neuerliches Review, sonst Freigabe des Dokumentes Generell Immer wieder kehrende Fehlerarten? ==> grundsätzliche Verbesserungen im SW- Entwicklungsprozess Moderator/in Leitung der Sitzung Vermittelt zwischen Teilnehmer/innen Darf eigenen Standpunkt nicht einbringen Autor/in Sollte Kritik nie persönlich nehmen "Normale" Review-Teilnehmer/innen Projektmitarbeiter/innen Expert/innen (Gutachter/innen) Für schwierige Fragen Protokollant/in Schreibt alle Ergebnisse präzise mit Sollte nicht gleichzeitig Moderator/in sein 8

5 Walkthrough Vorbereitung minimal oder entfällt ganz In der Sitzung wird das Review-Objekt durchgegangen Inspektion Formales Sitzungsreview Mit allen oben genannten Technisches Review, "Peer Review" Technische Aspekte im Vordergrund Hoher Vorbereitungs-Aufwand Informelles Review Keine formalen Kriterien Aufwand je nach Anlass 9 - Allgemein Ziele gleich wie bei Unterschiede zu : Dokument muss eine formale Struktur haben ist Werkzeug-gestützt Beispiel: Statische Programmanalyse Erkennbare Fehler Abweichungen von Kontrollfluss-Anomalien Datenfluss-Anomalien Nicht immer erkennbar: Wert einer Variablen = 0? (bei Divisionen) Konkurrierender Zugriff auf gemeinsame Speicherbereiche 10

6 Compiler und Code-Analysatoren Compiler Typischerweise ein schwaches Analysewerkzeug Prüft nur auf Syntaktische Korrektheit Wenige darüber hinaus gehende Aspekte Informationsverlust bei Datentyp- Konvertierungen, unbenutzte lokale Variablen,... Statische Code-Analysewerkzeuge Prüfen auf Einhaltung von Standards Problem: Konfiguration des Werkzeuges Kaum alle im Analyse- Werkzeug erfassbar Analyse-Werkzeug prüft an anderen Stellen wieder zu streng 11 Datenfluss-Analyse Untersuchung der Verwendung von Daten Verwendungsarten u undefined: der Wert einer Variablen ist undefiniert d define: die Variable wird mit einem Wert belegt r read: der Wert einer Variablen wird verwendet Datenfluss-Anomalien ur ein undefinierter Wert wird verwendet du ein Wert wird definiert, nicht verwendet, und dann ungültig dd ein zweiter Wert wird def., ohne dass der erste verwendet wurde Beispiel: void vertausche (integer a, integer b) { integer hilf; if (a!= b) { b:= hilf; b:= a; hilf:= b; } } 12

7 Kontrollfluss-Analyse Untersuchung des Kontrollflusses Kontrollfluss-Graf: Knoten: Anweisungen oder Folgen von Anweisungen Kanten: Verzweigungen des Kontrollflusses, zb: if, while,.. Kontrollfluss-Anomalien Sprünge aus Schleifen heraus Mehrere Ausgänge 1... Beispiel: Es existieren über 100 SW- Programmcode (Lines of Code) Kommentaranteil Komplexität (McCabe, Halstead) McCabe's zyklomatische Komplexität Grundlage: Kontrollfluss-Graf Misst die strukturelle Komplexität eines Programmes Entspricht der Anzahl linear unabhängiger vollständiger Pfade identifiziert SW, die schwierig zu verstehen/ändern ist hilft, die SW zu beherrschen (zb Indikator für Auftrennen in Module) Korreliert mit Anzahl der Fehler laut Praxis-Studien nützlich für Prioritätsplanung der Testfälle Schwäche: Komplexität der Bedingungen nicht bewertet 14

8 Zyklomatische Komplexität z(p)= e - n + 2p P Programm e (edges) Anzahl der Kanten des Kontrollfluss- Grafen n (nodes) Anzahl der Knoten des Kontrollfluss-Grafen p Anzahl verbundener Kontrollfluss-Grafen Beispiel (Folie 13, ohne Anomalien) e = 9 n = 8 (inkl. Start- und End- Knoten) p = 1 Ergebnis: z(p) = 3 Empfohlen: <= Nutzen statischer Analysemethoden Entdeckung von Fehlern in den Anforderungen und im Design Fehlererkennung ohne das Programm auszuführen Aufdecken von Anomalien Ableitung von Maßnahmen zur Verbesserung des Entwicklungsprozesses Priorisierung der Tests möglich Nachteil Laufzeitfehler werden nicht erkannt 16