Softwaretest

Kommunikation identifizierter potenzieller Fehlerzustände (z.B. in einer Reviewsitzung)

• Beheben von im geprüften Arbeitsergebnis gefundenen Fehlerzuständen (üblicherweise durch den Autor)
• Abnahme von Arbeitsergebnis, wenn Endekriterienerreicht
• ggf. Folgereview

Management: Entscheidet über Durchführung, stellt Zeit bereit

Reviewleiter: Entscheidet über Teilnehmer, Ort, Zeit

Moderator: leitet und vermittelt die Sitzung

Autor: Hauptverantwortlicher des Dokuments

Gutachter: identifizieren Befunde

Protokollant: Dokumentation

Informelles Review: folgt keinem Ablauf und dokumentiert die Ergebnisse nicht formal

Walkthrough: Autor leitet die Reviewteilnehmer durch ein Arbeitsergebnis und die Teilnehmer stellen Fragen stellen und kommentieren potentielle Befunde

Technisches Review: (formal) durchgeführt von einem Team von technisch qualifiziertem Personal, das die Qualität eines Arbeitsergebnisses überprüft und Abweichungen von Spezifikationen oder Standards feststellt

Inspektion: (formal) Ziel ist die Identifizierung von Befunden in einem Arbeitsprodukt ist, und welche Messungen zur Verbesserung des Reviewprozesses und des Softwareentwicklungsprozesses liefert.

organisatorisch:

• klare Ziele
• richtige Reviewart
• Unterstützung vom Management
• Integriert in Prozesse

personenbezogen:

• richtige Teilnehmer
• Teilnehmer widmen Zeit und Aufmerksamkeit
• faieres Miteinander

Unstimmigkeit, die zu einer Fehlerwirkung führen kann, aber nicht zwingend dazu führt.

Kontrollflussanomalie:

• Sprünge aus Schleifen heraus
• Sprünge in Schleifen hinein
• Programmstücke mit mehreren Ausgängen

Voraussetzung: Graph nicht manuell, sondern von einem Werkzeug erstellt

Verwendung/Zustände:

• Undefiniert (u)
• Definiert (d)
• Referenziert (r)

Datenflussanomalien:

• ur-Anomalie:
• du-Anomalie
• dd-Anomalie

• es gibt Produktmetriken, Projektmetriken, Prozessmetriken
• Metriken geben eine Möglichkeit für Vergleiche
• Metriken liefern Abschätzungenfür Dauer, Kosten, etc.

• macht Aussagen über die Wartbarkeit ist die Verständlichkeit eines Programmstücks
• sollte nicht größer 10 sein

• Alle Werte einer Klasse zeigen äquivalentes Verhalten des Testobjekts
• Sinnvolle Stichprobe: nur ein Testwertpro ÄK

Minimierung:

• Minimalkriterium: Mindestens ein Repräsentant jeder Äquivalenzklasse in mindestens einem Testfall
• Repräsentanten ungültiger Äquivalenzklassen nicht mit Repräsentanten anderer ungültiger Äquivalenzklassen kombinieren

ÄK-Überdeckung = Anzahl getestete ÄK / Gesamtzahl ÄK

• in Verzweigungs-und Schleifenbedingungen gibt es oft Grenzbereiche, für welche die Bedingung gerade noch zutrifft (oder gerade nicht mehr)
• Beste Erfolge bei Kombination mit anderen Verfahren --> Äquivalenzklassen

GW-Überdeckung = Anzahl getestete GW / Gesamtzahl GW

Zustands-Konformanztest: Nachweis, dass sich das Testobjekt konform zum Zustandsdiagramm verhält

Zustands-Robustheitstest: Zusätzlich Test unter nicht-konformanten Benutzungen

Bedingungen | Regeln
------------------------------
Aktionen | Aktionszeiger

• ET vollständig: alle 2nKombinationen enthalten
• ET redundanzfrei: wenn speziellere Bedingungen zu anderen Aktionen führen
• ET widerspruchsfrei: wenn gleiche Bedingungen zu gleichen Aktionen führen

• Fehlerzustände in Anforderungen oder Spezifikationen werden nicht erkannt
• Nicht geforderte Funktionalität wird nicht erkannt
• Black-Box-Testverfahren auf Prüfung der Funktionalität des Testobjekts fokussiert

Testfälle anhand von Pfaden durch den Kontrollflussgraphen bestimmen

Anweisungsüberdeckung = Anzahl ausgeführter Anweisungen / Gesamtzahl ausführbarer Anweisungen

Testfälle anhand von Pfaden durch den Kontrollflussgraphen bestimmen

Entscheidungsüberdeckung = Anzahl getesteter Entscheidungsergebnisse / Gesamtzahl möglicher Entscheidungsergebnisse

Tester vermuten aufgrund von Erfahrung, Intuition und Kenntnissen über das Testobjekt, welche Fehlerwirkungen oder Fehlerzustände im Testobjekt aufgrund von Fehlhandlungen vorkommen

erfahrungsbasierte Testverfahren sind:

• Intuitive Testfallermittlung(errorguessing)
• Exploratives Testen(exploratorytesting)
• Checklistenbasiertes Testen

Informelles Testen ohne vorbereitete Testfälle

Geeignet, wenn

• zu wenig oder ungeeignete Spezifikationen vorhanden
• Test unter hohem Zeitdruck steht
• andere, formalere Testverfahren zu unterstützen/ergänzen sind

Charta: Gibt Ziele und Zweck einer Sitzung vor

Sitzung: 60/90/120 min mit Doku (Fehlerberichte etc)

Endekriterium = Checkliste vollständig abgearbeitet

Das sichtbare Auftreten des Fehlers

Ursache einer Fehlerwirkung

einer Person: Ursache eines Fehlerzustands

ein Fehlerzustand verhindert die Aufdeckung eines anderen

• Arbeitsergebnisse bewerten
• Fehler in den Arbeitsergebnissen identifizieren
• Verifizieren, ob alle spezifischen Anforderungen erfüllt sind
• Vollständigkeit des Testobjekts prüfen
• Validieren des Testobjekts gegen Erwartungen der Benutzer und anderer Stakeholder
• Risiken aufgrund einer unzureichenden Softwarequalität reduzieren

Bestätigung durch Bereitstellung eines objektiven Nachweises, dass die Anforderungen für einen spezifischen beabsichtigten Gebrauch oder eine spezifische beabsichtigte Anwendung erfüllt worden sind.

Haben wir das richtige Systemrealisiert? -> für beabsichtige Produktnutzung sinnvoll?

Bestätigung durch Bereitstellung eines objektiven Nachweises, dass festgelegte Anforderungen erfüllt worden sind.

Haben wir das System richtig realisiert? -> Anforderung erfüllt?

Der Grad, zu dem eine Komponente oder ein System die expliziten und impliziten Bedürfnisse seiner verschiedenen Stakeholder erfüllt.

• Funktionalität
  • Vollständigkeit
  • Korrektheit
• Zuverlässigkeit
  • Verfügbarkeit
  • Fehlertoleranz
• Gebrauchstauglichkeit
  • Erlernbarkeit
  • Zugänglichkeit
• IT-Sicherheit
  • Vertraulichkeit
  • Integrität
• Kompatibilität
  • Interoperabilität
  • Koexistenz
• Übertragbarkeit
  • Installierbarkeit
  • Austauschbarkeit
• Wartbarkeit
  • Wiederverwendbarkeit
  • Testbarkeit
• Performanz
  • Zeitverhalten
  • Ressourcennutzung

1. Testen zeigt die Anwesenheit von Fehlerzuständen, nicht deren Abwesenheit
2. Vollständiges Testen ist nicht möglich
3. Frühes Testen spart Zeit und Geld
4. Häufung von Fehlerzuständen
5. Vorsicht vor dem Pestizid-Paradoxon
6. Testen ist kontextabhängig
7. Trugschluss: „Keine Fehler“ bedeutet ein brauchbares System

• Kombination von Schadenshöhe und Eintrittswahrscheinlichkeit
• Priorität der Anforderungen durch den Kunden
• Gewichtung der Qualitätsmerkmale durch den Kunden
• Priorität der Testfälle aus Sicht der Entwicklung
• Hohes Projektrisiko

1. Testplanung
2. Testüberwachung und -steuerung
3. Testanalyse
4. Testentwurf
5. Testrealisierung
6. Testdurchführung
7. Testabschluss

• Aufgaben:
  • Festlegung der Teststrategie
  • Detaillierung der Testplanung
• Ergebnisse:
  • Testkonzept

• Aufgaben:
  • Messen und Analysieren der Ergebnisse
  • Überwachen und Dokumentieren von Testfortschritt, erreichter Testabdeckung und der Endekriterien
• Ergebnisse:
  • Testfortschrittsberichte
  • Testabschlussberichte

• Aufgaben:
  • Review der Testbasis
  • Bewertung der Testbarkeit von Anforderungen und System
• Ergebnisse:
  • Testbedingungen

• Aufgaben
  • Spefizikation / Priorisierung von TF
  • TF umfasst Vorbedingung, Ergebnis und Nachbedingungen
• Ergebnis:
  • Testfälle

• Aufgaben:
  • Entwicklung der Testabläufe
  • Aufbau der Testumgebung
  • Erstellung automatischer Testfälle
• Ergebnisse:
  • Testsuite
  • Testausführungsplan

• Aufgaben:
  • Vergleich der Istergebnisse mit den erwarteten Ergebnissen
  • Fehlerschweregrad (Fehlerklasse) bestimmen
  • Priorität für Beseitigung festlegen
• Ergebnisse:
  • Dokumentation des Status der TF
  • Testprotokoll
  • Fehlerbericht

• Aufgaben:
  • Prüfung ob Fehlerberichte abgeschlossen
  • Archivierung
• Ergebnisse:
  • Testabschlussberichte