- 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
| Defekt | Nicht korrekter Code Beispiel: Schreibfehler in Formel Hinweis: Muss nicht immer zu einem Fehlzustand führen. |
| Fehlzustand | Nicht korrekter Zustand (während der Laufzeit) Beispiel: Falsche Berechnung des Ergebnisses Voraussetzung: Defekt(e) |
| Fehlfunktion | Nicht korrektes Verhalten (während der Laufzeit) Beispiel: Ausgabe von falschen Werten |
| Fehler | Abweichung von Forderung gemäß Qualitätsmerkmalen? |
| Testen | Existenz von Fehlern beweisen (nicht deren Abwesenheit). Genauer: Systematisch Fehlfunktionen heraufinden. |
| formaler Beweis (Mathematik) | Zeigt Abwesenheit von Fehlern |
| Testfall | Prüft mögliche Eingabe(n) |
| Test-First-Ansatz | Erst die Tests entwickeln, dann das Programm schreiben |
| Testsuite | Set 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
- Planung
- Wieviel?
- 100 % Test?
- WhiteBox vs. BlackBox?
- Auswertung
- 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 Testfall | deckt Fehler auf (der Test erzeugte eine inkorrekte Ausgabe) |
| Modification Revealing | deckt andere Ausgabe von zwei (eigentlich identischen) Programmen auf |
| Modification Traversing | deckt 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