3. Statische Prüftechniken und der Testprozess Flashcards
Statische Tests
Anders als das dynamische Testen, welches die Ausführung der Software voraussetzt, beruhen statische Prüftechniken auf der „manuellen“ Überprüfung (Reviews) oder automatisierten Analysen (statische
Analyse) des Codes oder anderer Projektdokumentation,ohne den Programmcode auszuführen.
Reviews
Ein Review kann komplett als manuelle Aktivität durchgeführt, aber ebenso durch Werkzeuge unterstützt werden.
Die wichtigste manuelle Tätigkeit ist die Prüfung und Kommentierung des Arbeitsergebnisses.
Jedes Arbeitsergebnis der Softwareentwicklung kann einem Review unterzogen werden, einschließlich Anforderungsspezifikationen, Designspezifikationen, Quellcode, Testkonzepte, Testspezifikationen,
Testfälle, Testskripte, Anwenderhandbücher oder Web-Seiten.
Reviews, statische Analyse und dynamische Tests
Reviews, statische Analyse und dynamischer Test haben das gleiche Ziel, nämlich Fehlerzustände zu identifizieren.
Sie ergänzen sich: Die verschiedenen Methoden können verschiedene Arten von Fehlern wirksam und effizient aufdecken.
Verglichen mit dem dynamischen Test finden statische Prüftechniken eher Ursachen der Fehlerwirkungen (Fehlerzustände) als Fehlerwirkungen selbst.
Vorteile von Reviews
Vorteile von Reviews sind:
- frühe Aufdeckung und Korrektur von Fehlerzuständen
- Verbesserung der Softwareentwicklungsproduktivität
- reduzierte Entwicklungsdauer
- reduzierte Testkosten und -dauer
- Reduzierung der Kosten während der Lebensdauer
- weniger Fehlerzustände und
- verbesserte Kommunikation.
Reviews können beispielsweise Auslassungen in Anforderungen aufdecken (z.B. fehlende Funktionen), die durch einen dynamischen Test vermutlich nicht gefunden würden.
Typische Fehlerzustände
die durch Reviews aufgedeckt werden
Zu den typische Fehlerzuständen, die effektiver und effizienter durch Reviews als durch dynamische Tests zu finden sind, gehören:
- Abweichungen von Standards
- Fehlerzustände in Anforderungen
- Fehlerzustände im Design
- unzureichende Wartbarkeit und
- fehlerhafte Schnittstellenspezifikationen.
Mögliche Ziele eines Reviews
- Finden von Fehlerzuständen
- Erwerben von Verständnis
- Ausbildung von Testern und neuen Teammitgliedern oder
- einer Diskussion und Entscheidungsfindung im Konsens.
Aktivitäten eines formalen Reviews
- Planen
- Kickk-off
- Individuelle Vorbereitung
- Prüfen/Bewerten/Festhalten der Ergebnisse (Reviewsitzung)
- Überarbeitung
- Nachbearbeitung
Aktivitäten eines formalen Reviews
Planen
- Festlegen von Review-/Prüfkriterien
- Auswahl der beteiligten Personen
- Besetzen der Rollen
- Festlegen der Eingangs- und Endekriterien bei mehr formalen Reviewarten (z.B. Inspektion)
- Auswahl der zu prüfenden Dokumententeile
- Prüfen der Eingangskriterien (bei formaleren Reviewarten)
Aktivitäten eines formalen Reviews
Kick-off
- Verteilen der Dokumente
- Erläutern der Ziele, des Prozesses und der Dokumente den Teilnehmern gegenüber
Aktivitäten eines formalen Reviews
Individuelle Vorbereitung
- Vorbereiten der Reviewsitzung durch Prüfung des/der Dokuments/e
- Notieren von potenziellen Fehlerzuständen, Fragen und Kommentaren
Aktivitäten eines formalen Reviews
- *Prüfen/Bewerten/Festhalten der Ergebnisse**
- *(Reviewsitzung)**
- Diskussion oder Protokollierung, mit dokumentierten Ergebnissen oder Protokollen (bei formaleren Reviewarten)
- Festhalten von Fehlerzuständen, Empfehlungen zum Umgang mit ihnen oder Entscheidungen über die Fehlerzustände
- Prüfen/Bewerten und Protokollieren von Problemen während eines physischen Treffens oder Nachverfolgen von elektronischer Gruppenkommunikation
Aktivitäten eines formalen Reviews
Überarbeiten
- Beheben der gefundenen Fehlerzustände typischerweise durch den Autor
- Protokollieren des aktualisierten Fehlerstatus (in formalen Reviews)
Aktivitäten eines formalen Reviews
Nachbereiten
- Prüfen, ob Fehlerzustände zugewiesen wurden
- Sammeln von Metriken
- Prüfen von Endekriterien (bei formaleren Reviewarten)
Formale Reviews
Rollen und Verantwortlichkeiten
Bei einem typischen formalen Review findet man folgende Rollen:
- Manager
- Moderator
- Autor
- Gutachter
- Protokollant
Formale Reviews - Rollen
Manager
Die Person, die
- über die Durchführung von Reviews entscheidet,
- Zeit im Projektplan zur Verfügung stellt und
- überprüft, ob die Reviewziele erfüllt sind.
Formale Reviews - Rollen
Moderator
Die Person, die
- das Review eines Dokuments bzw. von einigen zusammengehörenden Dokumenten leitet, einschließlich der Reviewplanung, der Leitung der Sitzung und der Nachbereitung nach der Sitzung.
- Falls nötig, kann der Moderator zwischen den verschiedenen Standpunkten vermitteln.
- Er ist häufig die Person, von der der Erfolg des Reviews abhängt.
Formale Reviews - Rollen
Autor
Der Verfasser oder die Person, die für das/die zu prüfende/n Dokument/e hauptverantwortlich ist.
Formale Reviews - Rollen
Gutachter
- Personen mit einem spezifischen technischen oder fachlichen Hintergrund (auch Prüfer oder Inspektoren genannt), die nach der nötigen Vorbereitung im Prüfobjekt Befunde identifizieren und beschreiben (z.B. Fehlerzustände).
- Gutachter sollten so gewählt werden, dass verschiedene Sichten und Rollen im Reviewprozess vertreten sind.
- Sie sollten an allen Reviewsitzungen teilnehmen können.
Formale Reviews - Rollen
Protokollant
- Die Person, die alle Ergebnisse, Probleme und offenen Punkte dokumentiert, die im Verlauf der Sitzung identifiziert werden.
Reviews und Checklisten
Softwareprodukte oder darauf bezogene Arbeitsergebnisse aus verschiedenen Perspektiven zu betrachten und Checklisten zu nutzen, kann Reviews wirksamer und effizienter machen.
So kann eine Checkliste helfen, bisher unentdeckte Probleme aufzudecken, wenn sie typische Anforderungsprobleme enthält und unterschiedliche Perspektiven einnimmt, beispielsweise vom Benutzer, Wartungspersonal,
Tester oder Operator.
Reviewarten
- Informelles Review
- Walkthrough
- Technisches Review
- Inspektion
Informelles Review
- kein formaler Prozess
- kann in Form des Programmierens in Paaren (pair programming) durchgeführt werden oder ein technischer Experte unterzieht Entwurf und Quellcode einem Review
- Ergebnisse können dokumentiert werden
- Nutzen variiert abhängig von den Gutachtern
- Hauptzweck: Günstiger Weg eine Verbesserung zu erreichen
Walkthrough
- Sitzung geleitet durch den Autor
- kann in Form von Szenarien, Probeläufen oder im Kreis gleichgestellter Mitarbeiter (Peer Review) stattfinden
- Open-End-Sitzungen
- wahlweise der Sitzung vorausgehende Vorbereitung der Gutachter
- wahlweise Vorbereitung eines Reviewberichts, der eine Liste der Befunde enthält
- wahlweise Protokollant (der aber nicht der Autor ist)
- kann in der Praxis von informell bis sehr formal variieren
-
Hauptzweck:
- Lernen
- Verständnis erzielen
- Fehlerzustände finden
Technisches Review
- dokumentierter und definierter Fehlerfindungsprozess, der gleichgestellte Mitarbeiter und technische Experten sowie optional Personen aus dem Management einschließt
- kann als Peer Review ohne Teilnahme des Managements ausgeführt werden
- idealerweise durch einen geschulten Moderator geleitet (nicht der Autor)
- Vorbereitung vor der Sitzung durch Gutachter
- wahlweise Nutzung von Checklisten
- Vorbereitung eines Reviewberichts, der folgende Punkte enthält:
- die Liste der Befunde,
- eine Gesamtbewertung, inwieweit das Softwareprodukt die Anforderungen erfüllt, und
- Empfehlungen in Bezug auf die Befunde, wo angebracht
- kann in der Praxis von informell bis sehr formal variieren
-
Hauptzweck:
- Diskussion
- Entscheidungen treffen
- Alternativen bewerten
- Fehlerzustände finden,
- technische Probleme lösen und
- prüfen, ob Übereinstimmung mit Spezifikationen, Plänen, Bestimmungen und Standards existiert
Inspektion
- geleitet durch einen geschulten Moderator (nicht der Autor)
- gewöhnlich durchgeführt als Prüfung durch gleichgestellte Mitarbeiter
- definierte Rollen
- schließt das Sammeln von Metriken ein
- formaler Prozess basierend auf Regeln und Checklisten
- spezifizierte Eingangs- und Endekriterien für die Abnahme des Softwareprodukts
- Vorbereitung vor der Sitzung
- Inspektionsbericht mit Liste der Befunde
- formaler Prozess für Folgeaktivitäten (optional mit Komponenten zur Prozessverbesserung)
- wahlweise Vorleser
- Hauptzweck: Fehlerzustände finden
Erfolgsfaktoren für Reviews
- Jedes Review hat klar definierte Ziele.
- Abhängig von den Reviewzielen werden geeignete Personen ausgewählt.
- Tester sind geschätzte Gutachter, die einen Beitrag zum Review leisten. Weiterhin lernen sie auch das Produkt kennen, was sie befähigt Tests früher vorzubereiten.
- Gefundene Fehlerzustände werden positiv aufgenommen und werden objektiv zur Sprache gebracht.
- Menschliche und psychologische Aspekte werden beachtet, es beispielsweise als eine positive Erfahrung für den Autor zu gestalten.
- Das Review wird in einer Atmosphäre des Vertrauens durchgeführt, das Ergebnis dient nicht zur Beurteilung der Teilnehmer.
- Es werden die Reviewtechniken angewendet, die zur Erreichung der Reviewziele, für Art und Stufe von Arbeitsergebnissen der Softwareentwicklung und für die Gutachter geeignet sind.
- Wenn sie geeignet sind, die Effektivität der Fehleridentifikation zu steigern, werden Checklisten oder Rollen verwendet.
- Es finden Schulungen in Reviewtechniken statt, besonders für die formaleren Methoden wie Inspektionen.
- Das Management unterstützt einen guten Reviewprozess, indem es beispielsweise angemessene Zeit für Reviewaktivitäten im Projektplan einräumt.
- Es liegt eine Betonung auf Lernen und Prozessverbesserung.
Statische Analyse
Das Ziel der statischen Analyse ist es, Fehlerzustände in Softwarequellcode und in den Softwaremodellen zu finden.
Statische Analyse wird durchgeführt, ohne dass die untersuchte Software tatsächlich durch das Werkzeug ausgeführt wird; dynamischer Test führt Softwarecode aus.
Statische Analyse kann Fehlerzustände lokalisieren, die durch dynamisches Testen schwer zu finden sind.
Ebenso wie Reviews findet die statische Analyse Fehlerzustände eher als Fehlerwirkungen.
Statische Analysewerkzeuge analysieren Programmcode (z.B. Kontrollfluss und Datenfluss), ebenso wie generierte HTML- und XML-Ausgaben.
Vorteile der statischen Analyse
- frühes Erkennen von Fehlerzuständen vor der Testdurchführung
- frühe Warnung vor verdächtigen Aspekten in Code oder Design wie hohes Komplexitätsmaß durch Berechnen von Metriken
- Identifizieren von Fehlerzuständen, die durch dynamischen Test nicht effektiv und effizient aufzudecken sind
- Aufdecken von Abhängigkeiten und Inkonsistenzen in Softwaremodellen, beispielsweise tote Links
- verbesserte Wartbarkeit von Code und Design
- Vorbeugen von Fehlerzuständen, wenn sich das aus Erfahrung Gelernte in der Entwicklung niederschlägt
Statische Analyse
Typische Fehlerzustände
Typische Fehlerzustände, die durch eine werkzeuggestützte statische Analyse gefunden werden können:
- Referenzierung einer Variablen mit nicht definiertem Wert
- inkonsistente Schnittstellen zwischen Modulen und Komponenten
- Variablen, die nicht verwendet oder nicht korrekt deklariert werden
- unerreichbarer (toter) Code
- fehlende oder falsche Logik (mögliche Endlosschleifen)
- übermäßig komplizierte Konstrukte
- Verletzung von Programmierkonventionen
- Sicherheitsschwachstellen
- Syntax-Verletzungen von Code und Softwaremodellen
Werkzeuge für statische Analysen
Werkzeuge für statische Analysen werden typischerweise entwicklungsbegleitend und vor Komponenten- und Integrationstests oder beim Einchecken von Code in Konfigurationsmanagementwerkzeuge
genutzt (Prüfen gegen vordefinierte Regeln oder Programmierstandards), und durch Designer während der Softwaremodellierung.
Werkzeuge für statische Analysen können große Mengen von Warnungen
und Hinweisen erzeugen, die gut verwaltet werden müssen, um eine effektive Nutzung des Werkzeugs zu erlauben.
Compiler können auch eine gute Unterstützung für eine statische Analyse bieten, u.a. durch Berechnen von Metriken.
