====== LU01a - Grundlagen des Testens ======
**Auf einen Blick**\\
Testen heisst, ein Programm mit dem Ziel auszuführen, **Fehler zu finden**.
Vor dem Test legen wir fest, mit welchen Daten wir testen und welches Ergebnis wir erwarten (**SOLL**).
Beim Test vergleichen wir das tatsächliche Ergebnis (**IST**) mit dem SOLL.
===== Lernziele =====
Sie können
* erklären, warum Testen Fehler sucht und nicht die Fehlerfreiheit beweist,
* Fehlhandlung, Fehlerzustand und Fehlerwirkung unterscheiden,
* Blackbox- und Glassbox-Tests unterscheiden,
* mit Äquivalenzklassen und Grenzwerten sinnvolle Testdaten finden,
* den Ablauf von den Testfällen bis zur Freigabe beschreiben.
===== Warum testen? =====
Software steuert Bankkonten, Stundenpläne, Ampeln und Medizingeräte. Fehler sind deshalb nicht nur ärgerlich, sondern können teuer oder gefährlich werden.
Je später ein Fehler entdeckt wird, desto teurer wird er:
^ Fehler wird entdeckt ... ^ Folge ^ Aufwand ^
| beim Programmieren | Entwickler korrigiert den Code sofort | Minuten |
| beim Testen vor der Auslieferung | Fehler wird protokolliert, korrigiert und erneut getestet | Stunden |
| beim Kunden im Betrieb | Support, Notfall-Update, Imageschaden, eventuell Schadenersatz | Tage bis Wochen |
Testen ist ein Teil der **Qualitätssicherung**. Dabei gilt ein Grundsatz, der auf den Informatiker Edsger W. Dijkstra zurückgeht:
Testen kann zeigen, dass Fehler vorhanden sind, aber nie, dass ein Programm fehlerfrei ist.
Wir testen also nicht, um zu beweisen, dass alles funktioniert. Wir testen, um möglichst viele Fehler zu finden, **bevor** sie jemand anderes findet.
===== Was ist ein Fehler? =====
Im Alltag sagen wir für alles «Fehler» oder «Bug». In der Softwareentwicklung unterscheidet man drei Stufen:
^ Begriff ^ Bedeutung ^ Beispiel ^
| **Fehlhandlung** (Irrtum) | Ein Mensch macht etwas falsch. | Die Programmiererin verwechselt ''>'' und ''>=''. |
| **Fehlerzustand** (Defekt, Bug) | Der Irrtum steckt jetzt im Code. | Im Code steht ''if alter > 18:'' statt ''if alter >= 18:''. |
| **Fehlerwirkung** (Ausfall) | Das Programm verhält sich beim Ausführen falsch. | Eine 18-jährige Person wird als minderjährig abgewiesen. |
Beim Testen beobachten wir immer nur die **Fehlerwirkung**. Den Fehlerzustand im Code suchen und korrigieren die Entwicklerinnen und Entwickler.
===== Vorgehen: SOLL mit IST vergleichen =====
Manche Programmierer «testen», indem sie irgendwelche Daten eingeben und schauen, was passiert.
//Ihr Motto: Schiess einen Pfeil ab und nenne alles, was du triffst, ein Ziel.//
Systematisches Testen geht anders:
- **Planen:** Wir legen fest, welche Situation wir testen wollen.
- **Testfall beschreiben:** Wir notieren die konkreten Eingaben und das erwartete Ergebnis (SOLL). Siehe [[.:testfall|LU01c - Aufbau eines Testfalls]].
- **Ausführen:** Wir führen das Programm mit genau diesen Eingaben aus und notieren das tatsächliche Ergebnis (IST).
- **Vergleichen:** Stimmen SOLL und IST überein, ist der Test bestanden. Sonst haben wir einen Fehler gefunden. Siehe [[.:testprotokoll|LU01d - Aufbau eines Testprotokolls]].
**Beispiel:**
^ Was wir testen ^ Eingabe ^ SOLL ^ IST ^ Ergebnis ^
| Negative Menge wird abgelehnt | Feld «Menge»: ''-4'' | Meldung «Menge muss grösser als 0 sein» | Bestellung über -4 Stück | Fehler |
===== Gute Testdaten finden =====
Wir können nie alle möglichen Eingaben testen. Zwei einfache Techniken helfen, mit wenigen Testfällen viel abzudecken.
==== Äquivalenzklassen ====
Wir teilen die möglichen Eingaben in Gruppen (Klassen) ein, die das Programm gleich behandeln sollte. Aus jeder Klasse testen wir **einen** Vertreter.
Beispiel Feld «Betrag» im Programm [[.:aufgaben:testfaelle|British Inheritance Tax]]:
^ Klasse ^ Art ^ Vertreter ^
| Betrag bis 325'000 | gültig | ''200000'' |
| Betrag über 325'000 | gültig | ''500000'' |
| Betrag 0 oder negativ | formal korrekt, ungültig | ''-100'' |
| keine Zahl | formal falsch | ''abc'' |
| Zahl mit Tausendertrennzeichen | formal falsch | ''500'000'' |
==== Grenzwerte ====
Fehler passieren besonders häufig an den **Grenzen** zwischen zwei Klassen, zum Beispiel wenn ''<'' und ''<='' verwechselt werden.
Deshalb testen wir zusätzlich die Werte direkt an der Grenze und knapp daneben: ''324999'', ''325000'', ''325001''.
===== Psychologie des Testens =====
* **Sei hart zum Programm:** Deine Aufgabe ist es, möglichst viele Fehler zu finden.
* **Sei nett zum Menschen:** Du kritisierst die Arbeit, nicht die Person.
Viele Programmierer fühlen sich angegriffen, wenn ihre Arbeit kritisiert wird. Im Testprotokoll gilt deshalb:
* Wir beschreiben **was** passiert, sachlich und nachvollziehbar.
* Wir schreiben keine Vermutungen, **warum** es passiert, und keine Lösungsvorschläge.
^ Gut ^ Schlecht ^
| Eingabe ''0'' im Feld «Zahl» führt zu einem Absturz. | Die Bedingung zur Prüfung der Eingabe ist falsch. |
| Bei Beträgen über 1 Mio. fehlen die Nachkommastellen. | Da hat jemand mal wieder schlampig programmiert. |
Ausserdem gilt: Wer ein Programm geschrieben hat, sieht die eigenen Fehler schlecht. Deshalb ist es sinnvoll, wenn eine **andere Person** die Testfälle durchführt.
===== Blackbox und Glassbox =====
^ ^ Blackbox-Test ^ Glassbox-Test (Whitebox-Test) ^
^ Grundlage | Anforderungen und Spezifikation | Quellcode |
^ Sicht auf das Programm | Wie eine schwarze Kiste: nur Eingabe und Ausgabe | Wie eine Glaskiste: der Code ist sichtbar |
^ Typische Frage | Macht das Programm, was es soll? | Wurde jede Anweisung und jede Bedingung ausgeführt? |
^ Techniken | Äquivalenzklassen, Grenzwerte, Zustandsdiagramme | Anweisungs-, Zweig-, Bedingungsabdeckung ([[modul:m450:learningunits:lu02:coverage|LU02c]]) |
^ Wer testet meistens? | Testerinnen und Tester, Kundinnen und Kunden | Entwicklerinnen und Entwickler |
Beide Arten ergänzen sich: Der Blackbox-Test findet fehlende Funktionen, der Glassbox-Test findet ungetesteten Code.
===== Ablauf eines Tests =====
{{:modul:m450:learningunits:lu01:testablauf.png?600|}}
- **Analyse:** Die Anforderungen an das Programm werden ermittelt. Sie sind die Grundlage für das Programm **und** für die Testfälle.
- **Testfälle erstellen:** Aus den Anforderungen entstehen die Testfälle, meistens parallel zur Programmierung.
- **Programmieren:** Die Entwicklerin erstellt das Programm.
- **Testdurchlauf:** Die Testerin führt jeden Testfall einmal aus und hält das Ergebnis im Testprotokoll fest.
- **Entscheid:** Nach dem Testdurchlauf entscheidet die Testerin, ob das Programm in Ordnung ist oder überarbeitet werden muss.
- **Korrektur und erneuter Test:** Muss das Programm überarbeitet werden, korrigiert die Entwicklerin die Fehler. Danach werden **alle** Testfälle erneut durchgeführt und in einem **neuen** Testprotokoll festgehalten.
Warum alle Testfälle und nicht nur die fehlgeschlagenen? Eine Korrektur kann an einer anderen Stelle neue Fehler verursachen. Diesen erneuten Test nennt man **Regressionstest**.
===== Normen: IEEE 829 =====
{{https://upload.wikimedia.org/wikipedia/commons/2/2f/IEEE829_Uebersicht_Deutsch.png?600}}
Die Norm [[wpde>Software_Test_Documentation|IEEE 829]] beschreibt, welche Dokumente beim Testen entstehen. Die wichtigsten davon kennen Sie aus diesem Modul:
^ Dokument ^ Inhalt ^ Im Modul ^
| Testkonzept / Testplan | Was wird wann, wie und von wem getestet? | LU02 |
| Testfallspezifikation | Die einzelnen Testfälle mit Eingaben und SOLL | LU01c |
| Testprotokoll | Die Ergebnisse eines Testdurchlaufs (IST) | LU01d |
| Testabschlussbericht | Zusammenfassung und Empfehlung zur Freigabe | Fazit im Testprotokoll |
IEEE 829 wurde inzwischen durch die internationale Normenreihe ISO/IEC/IEEE 29119 abgelöst. Die Grundidee ist gleich geblieben.
===== Begriffe =====
^ Begriff ^ Bedeutung ^
| Testen | Ausführen eines Programms mit dem Ziel, Fehler zu finden. |
| Testfall | Beschreibung einer Situation mit konkreten Eingaben und erwartetem Ergebnis. |
| Testdurchlauf | Einmaliges Ausführen aller Testfälle. |
| Testprotokoll | Ergebnisse eines Testdurchlaufs. |
| SOLL / IST | Erwartetes / tatsächliches Ergebnis. |
| Positivtest | Test mit gültigen Eingaben: Funktioniert das Programm wie gewünscht? |
| Negativtest | Test mit ungültigen Eingaben: Reagiert das Programm richtig auf Fehler? |
| Regressionstest | Erneuter Test nach einer Änderung, um neue Fehler zu entdecken. |
===== Kontrollfragen =====
- Warum kann Testen nicht beweisen, dass ein Programm fehlerfrei ist?
- Eine Webseite zeigt bei Bestellungen am 29. Februar ein falsches Lieferdatum. Ist das eine Fehlhandlung, ein Fehlerzustand oder eine Fehlerwirkung?
- Bilden Sie Äquivalenzklassen für ein Eingabefeld «Alter» (ganze Zahl zwischen 0 und 120). Welche Grenzwerte testen Sie?
- Formulieren Sie den Satz «Die Validierung ist komplett falsch programmiert» so um, dass er in ein Testprotokoll passt.
- Warum werden nach einer Korrektur alle Testfälle erneut durchgeführt?
----
{{tag>M450-LU01}}
[[https://creativecommons.org/licenses/by-nc-sa/4.0/|{{https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png}}]] Marcel Suter