• 100 %-Tests sind unmöglich. Kein Programm ist fehlerfrei.
  • Alle UseCases müssen beim Testen abgedeckt sein.
  • Möglichst früh (am besten nach jeder Änderung) testen.
  • Konzepte sind wichtiger als Tools (damit möglichst viele relevante Fälle getestet werden).
  • 30 – 50 % vom Gesamtaufwand der Softwareentwicklung sind Tests.

Definitionen

DefektNicht korrekter Code
Beispiel: Schreibfehler in Formel
Hinweis: Muss nicht immer zu einem Fehlzustand führen.
FehlzustandNicht korrekter Zustand (während der Laufzeit)
Beispiel: Falsche Berechnung des Ergebnisses
Voraussetzung: Defekt(e)
FehlfunktionNicht korrektes Verhalten (während der Laufzeit)
Beispiel: Ausgabe von falschen Werten
FehlerAbweichung von Forderung gemäß Qualitätsmerkmalen?
TestenExistenz von Fehlern beweisen (nicht deren Abwesenheit).
Genauer: Systematisch Fehlfunktionen heraufinden.
formaler Beweis (Mathematik)Zeigt Abwesenheit von Fehlern
TestfallPrüft mögliche Eingabe(n)
Test-First-AnsatzErst die Tests entwickeln, dann das Programm schreiben
TestsuiteSet aus vorgefertigten Programmtests

Qualitätsmerkmale von Software (laut ISO-Norm)

  • Laufzeit, Zuverlässigkeit (Fehlertoleranz, Wiederherstellbarkeit…)
  • Benutzerfreundlichkeit (Verständlichkeit, Erlernbarkeit und Bedienbarkeit)
  • Wartbarkeit/Ausbaufähigkeit/Änderbarkeit
  • Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Austauschbarkeit)
  • Effizienz (Zeit und der Verbrauch an Betriebsmitteln)
  • Funktionalität

Voraussetzungen

  • gute Planung
    • Test-First-Ansatz: Test vor Implementierung entwickeln
    • autom. Tests sollten bereits während Entwicklung durchgef. werden.
  • realistische Testdaten
    • Akzeptor/Transduktor
    • Aus UseCase-Textkarten (Testfälle und alternative-Courses)
  • Testfälle entwicklen
    • autom. Tests sollten möglich sein
    • Testumfang festlegen
    • sowohl statische als auch dynamische Tests sind (meist) notwendig
  • gute Testumgebung
  • Dokumentation

Testablauf

  1. Planung
    1. Wieviel?
    2. 100 % Test?
    3. WhiteBox vs. BlackBox?
  2. Auswertung
  3. Abnahme

Testmöglichkeiten

  • vorgegebene Checklisten
  • Reviews (extern)
  • Anwendertests
  • autom. Tests

statische Programmanalyse

weitergehende Analyse des ges. Programms (Dokumentation, Struktur, Quellcode etc.)

Kann etwas fehlendes nicht finden

Ziel: Endlosschleifen, falsche Variablen, Standardverletzungen etc. aufdecken

Beispiele: Audit, Review, Checklistenverfahren…

dynamischer Programmtest

Programm wird während der Ausführung getestet.

White Box Test

Sog. Entwicklertest, die Datenstruktur wird angeschaut

Voraussetzung: das UML-Kontrollflußdiagramm

Ablauf eines Programms (basierend auf Fällen) darstellen

Ziele für Zeile durchgehen (aufsteigend nummerieren + Start- und Endknoten festlegen), Knoten und Kanten (alle Möglichgkeiten abbilden).

ähnlich dem Aktivitätsdiagramm (dies ist nicht immer umfassend und hat mehr Beschreibungen). Wird oft als das selbe bezeichnet.

Anweisungsüberdeckung

Einmal alle Knoten ablaufen.

Schwierigkeit: Geht Programm in alle Bedingungen (IF) rein?

Beginn bei Start, möglichst alle Bedingungen abdecken. Reicht meist nicht als einziger Test aus.

Zweigüberdeckung

Alle Wege (Zweige/Kanten) gehen.

Ist detaillierter -> geht öfters alles durch um alle Wege zu zu „decken“

geht nicht immer (z. B. wenn Dinge immer true sind)

Pfadüberdeckung

Alle Möglichkeiten gehen, um zum Ziel zu kommen (es müssen nicht alle Elemente abgelaufen werden).

Ist am umfangreichsten, enthält Zweigüberdeckung.

geht nicht immer (z. B. wenn Dinge immer true sind) -> In Praxis werden nur Teile getestet

Black-Box-Test

Sog. Anwendertest

Testen ohne den Quellcode einsehen zu können. Benötigt eine lauffähige Implementation des Programmes

Modultest / Komponententest / Unit test

Test der einzelnen Softwareteile, welche erst später zusammengeführt werden. Möglichst kleine Ausschnitte wählen (einzelne Methoden etc.).
Wird vom Entwickler selbst (teilw. automatisch) durchgeführt. Am besten regelmäßig (z. B. vor jedem Einchecken).

Integrationstest

Alleiniger Test des Moduls (ohne Interaktion mit anderen Bestandteilen). Andere, notwendige Teile werden simuliert (gemockt, Mock-Objekte).

Andere Module sollten auch Fehlerhaft gemockt werden, um Verhalten des Programms bei Fehlern zu testen.

Regressionstest

Erneutes Testen nach einer Programmcode-Änderung. Nur relevante Tests werden durchgeführt. Jede Programmfunktion sollte einen eigenen Testfall haben.

Hinweis: Eventuell ergeben sich durch die Programmänderung neue Testfälle!

Arten von Regressionstests

Fault-Revealing Testfalldeckt Fehler auf (der Test erzeugte eine inkorrekte Ausgabe)
Modification Revealingdeckt andere Ausgabe von zwei (eigentlich identischen) Programmen auf
Modification Traversingdeckt anderes Verhalten von zwei (eigentlich identischen) Programmen auf

obsolete Testfälle

Treten auf bei:

  • Funktion entfernt oder geändert
  • neuen Schnittstellen
  • neuer Defintionsbereich (Dabei auch den existierenden Test ändern/ergänzen)
  • Umgebung geändert

Anhand eines Datenflussgraphens kann bestimmt werden, welche Testfälle eine Änderung betreffen.

Priorisierungsstrategien (Auswahl)

  • neue Testfälle
  • Fehlerträchtige Testfälle
  • Für die Funktion/Sicherheit essentielle Testfälle

Programmslicing

  • Problem: Abhängigkeit im Code von falschen/geänderten Daten
  • Zerlegung in Kontroll- und Datenabhängigkeiten
  • Programmslice ist eine Teilmenge allen Codes, der von etw. abhängig ist.
  • Herausfinden eines Slice:
  • Rückwärts-Methode (wo kommt Variable vor? Welche Abhängigkeiten hat die Variable? Damit immer weiter nach oben gehen.) oder/und Vorwärts -Methode (Beeinflussen oder Abhängig) durchgehen.
    • Es gibt versch. Grade der Genauigkeit.
    • Beachtet auch nichterreichbare Bedingungen!
    • Bei Kontrollflussabhängigkeit, auch Schleifen etc. nicht vergessen
  • Testdaten werden nach Slice ausgewählt. Also alle Testfälle, welche diesen Slice berühren ausführen

Dein Kommentar