modul:m450:learningunits:lu01:grundlagen

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
modul:m450:learningunits:lu01:grundlagen [2024/10/29 12:49] – msutermodul:m450:learningunits:lu01:grundlagen [2026/11/11 10:52] (aktuell) – Überarbeitet: Struktur, Lernziele, Fehlerbegriffe, Äquivalenzklassen/Grenzwerte, Begriffe, Kontrollfragen admin
Zeile 1: Zeile 1:
 ====== LU01a - Grundlagen des Testens ====== ====== LU01a - Grundlagen des Testens ======
-===== Einleitung ===== +<WRAP center round info 80%> 
-<WRAP center round info 60%> +**Auf einen Blick**\\ 
-Testen ist das Ausführen eines Programms mit dem Ziel, Fehler zu finden.+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.
 </WRAP> </WRAP>
  
 +===== 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.
  
-Testen ist ein Teil der Qualitätssicherung in der Softwareentwicklung. +===== Warum testen? ===== 
-Beim Testen suchen wir gezielt nach Fehlern in einem Programm. +Software steuert Bankkonten, Stundenpläne, Ampeln und Medizingeräte. Fehler sind deshalb nicht nur ärgerlich, sondern können teuer oder gefährlich werden.
-Beim Testen geht es nicht darum, zu beweisen, dass ein Programm fehlerfrei ist. +
-Das ist zum einen fast unmöglich und zum anderen wenig motivierend.+
  
-==== Vorgehensweise ==== +Je später ein Fehler entdeckt wird, desto teurer wird er:
-Manche Programmierer haben seltsame Vorstellungen vom Testen eines Programms. +
-Sie geben irgendwelche Daten ein und schauen, was passiert.+
  
-<WRAP center round box 60%> +^ Fehler wird entdeckt ...           ^ Folge                                                         ^ Aufwand  ^ 
-Ihr Motto ist: Schiess einen Pfeil ab und alles, was du triffst, nennst du ein Ziel. +| beim Programmieren                 | Entwickler korrigiert den Code sofort                          | Minuten  | 
-</WRAP>+| 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:
  
 +<WRAP center round important 80%>
 +Testen kann zeigen, dass Fehler vorhanden sind, aber nie, dass ein Programm fehlerfrei ist.
 +</WRAP>
  
-Beim Testen legen wir zunächst fest, was wir testen wollen. +Wir testen also nicht, um zu beweisen, dass alles funktioniert. Wir testen, um möglichst viele Fehler zu finden, **bevor** sie jemand anderes findet.
-Man schreibt auf, welches Ergebnis man erwartet oder wie das Programm reagieren soll. +
-Das nennen wir Testfall.+
  
->> Sie wollen zum Beispiel testen, wie das Programm reagiert, wenn Sie eine negative Menge eingeben. +===== Was ist ein Fehler? ===== 
->> Im Testfall legen Sie fest, dass Sie im Feld "Menge" den Wert "-4" eingeben. +Im Alltag sagen wir für alles «Fehler» oder «Bug». In der Softwareentwicklung unterscheidet man drei Stufen:
->> Sie erwarten, dass das Programm die Fehlermeldung "Menge muss grösser als 0 sein" ausgibt.+
  
-Nachdem Sie einige Testfälle beschrieben haben, führen Sie diese Testfälle aus. +^ Begriff                          ^ Bedeutung                                         ^ Beispiel                                                               ^ 
-Dabei notieren Sie, wie das Programm tatsächlich reagiert hat. +| **Fehlhandlung** (Irrtum)        | Ein Mensch macht etwas falsch.                    | Die Programmiererin verwechselt ''>'' und ''>=''.                       | 
-Indem Sie die erwartete Reaktion (SOLL) mit der tatsächlichen Reaktion (IST) vergleichen, +| **Fehlerzustand** (Defekt, Bug)  | Der Irrtum steckt jetzt im Code.                  | Im Code steht ''if alter > 18:'' statt ''if alter >= 18:''.              | 
-können Sie beurteilen, ob das Programm korrekt funktioniert.+| **Fehlerwirkung** (Ausfall)      | Das Programm verhält sich beim Ausführen falsch.  | Eine 18-jährige Person wird als minderjährig abgewiesen.                |
  
-===== Psychologie des Testens =====+Beim Testen beobachten wir immer nur die **Fehlerwirkung**. Den Fehlerzustand im Code suchen und korrigieren die Entwicklerinnen und Entwickler.
  
-<WRAP center round info 60%> +===== Vorgehen: SOLL mit IST vergleichen ===== 
-Beim Testen +Manche Programmierer «testen», indem sie irgendwelche Daten eingeben und schauen, was passiert. 
-  * Sei hart und unerbittlich zum Programm: Deine Aufgabe ist es, so viele Fehler wie möglich zu finden. + 
-  * Sei nett zum Programmierer: Du findest die Fehler in seiner Arbeit und nicht beim Menschen.+<WRAP center round box 80%> 
 +//Ihr Motto: Schiess einen Pfeil ab und nenne alles, was du triffst, ein Ziel.//
 </WRAP> </WRAP>
  
-Viele Programmierer fühlen sich angegriffen, wenn ihre Arbeit kritisiert wird. +Systematisches Testen geht anders: 
-Deshalb muss der Tester bei der Erstellung des Testprotokolls mit Fingerspitzengefühl vorgehen: +  - **Planen:** Wir legen fest, welche Situation wir testen wollen. 
-  * Abweichungen zwischen erwartetem und tatsächlichem Ergebnis aufzeigen. +  - **Testfall beschreiben:** Wir notieren die konkreten Eingaben und das erwartete Ergebnis (SOLL). Siehe [[.:testfall|LU01c - Aufbau eines Testfalls]]. 
-  * Vorschläge zur Korrektur des Programms vermeiden.+  - **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]].
  
-Hier ein gutes und ein schlechtes Beispiel, wie ein Fehler im Testprotokoll festgehalten werden kann:+**Beispiel:**
  
-  * Gut: Zahl = 0 führt zu einem Absturz. +^ Was wir testen               ^ Eingabe              ^ SOLL                                           ^ IST                        ^ Ergebnis    ^ 
-  * Schlecht: Die Bedingung zur Überprüfung der Eingabe ist falsch.+| Negative Menge wird abgelehnt | Feld «Menge»: ''-4'' | Meldung «Menge muss grösser als 0 sein»         | Bestellung über -4 Stück   | Fehler      |
  
-===== Definitionen ===== +===== Gute Testdaten finden ===== 
-=== Testen ist ... === +Wir können nie alle möglichen Eingaben testen. Zwei einfache Techniken helfen, mit wenigen Testfällen viel abzudecken.
-... die gezielte Suche nach Fehlern in einem Programm.+
  
-<WRAP center round info 60%> +==== Äquivalenzklassen ==== 
-Keine Software der Welt ist völlig frei von Fehlern, es gibt nur Software, deren Fehler noch nicht gefunden oder behoben wurden.</WRAP>.+Wir teilen die möglichen Eingaben in Gruppen (Klassen) ein, die das Programm gleich behandeln sollte. Aus jeder Klasse testen wir **einen** Vertreter.
  
-Beim Testen geht es nicht darum, zu beweisen, dass ein Programm fehlerfrei ist. +Beispiel Feld «Betrag» im Programm [[.:aufgaben:testfaelle|British Inheritance Tax]]:
-Das ist zum einen unmöglich und zum anderen wenig motivierend.  +
-> Testen ist das Ausführen eines Programms mit dem Ziel, Fehler zu finden.+
  
-=== Testfall === +^ Klasse                                   ^ Art                    ^ Vertreter   ^ 
-Ein Testfall beschreibt die Daten, mit denen ein Test durchgeführt wird. +| Betrag bis 325'000                       | gültig                 | ''200000''  | 
-Um ein Programm zu testen, benötigt man mehrere Testfälle.+| 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'' |
  
-=== Testprotokoll === +==== Grenzwerte ==== 
-Jedes Mal, wenn sie eine Reihe von Testfällen ausführen, wird ein separates Protokoll erstellt. +Fehler passieren besonders häufig an den **Grenzen** zwischen zwei Klassen, zum Beispiel wenn ''<'' und ''<='' verwechselt werden. 
-Dieses enthält Informationen über den Zeitpunkt, die ausgeführten Testfälle und das Ergebnis des Tests.+Deshalb testen wir zusätzlich die Werte direkt an der Grenze und knapp daneben: ''324999'', ''325000'', ''325001''.
  
-=== Blackbox-Test === +===== Psychologie des Testens ===== 
-Bei einem Blackbox-Test werden die Testfälle aus den Anforderungen generiert. +<WRAP center round tip 80%> 
-Die Struktur des Quellcodes wird nicht berücksichtigt. +  * **Sei hart zum Programm:** Deine Aufgabe ist es, möglichst viele Fehler zu finden. 
-Das Programm wird als Blackbox betrachtet, die bei einer bestimmten Eingabe eine erwartete Ausgabe liefern soll.+  * **Sei nett zum Menschen:** Du kritisierst die Arbeit, nicht die Person. 
 +</WRAP>
  
-Als Grundlage für die Testfälle dienen +Viele Programmierer fühlen sich angegriffen, wenn ihre Arbeit kritisiert wird. Im Testprotokoll gilt deshalb: 
-  * Spezifikation der Anwendung +  * Wir beschreiben **was** passiert, sachlich und nachvollziehbar. 
-  * Zustandsdiagramme+  * Wir schreiben keine Vermutungen, **warum** es passiert, und keine Lösungsvorschläge.
  
-=== Glassbox-Tests === +^ Gut                                                    ^ Schlecht                                            ^ 
-Bei einem Glassbox-Test (auch Whitebox-Test genannt) werden die Testfälle aus dem Quellcode generiert.  +| Eingabe ''0'' im Feld «Zahl» führt zu einem Absturz.     | Die Bedingung zur Prüfung der Eingabe ist falsch.    | 
-Ziel solcher Tests ist es, dass möglichst jeder Befehl und jede Bedingung einmal ausgeführt wird.  +| Bei Beträgen über 1 Mio. fehlen die Nachkommastellen.  | Da hat jemand mal wieder schlampig programmiert.     |
-Solche Testfälle sind ohne spezielle Software nur sehr aufwendig zu erstellen.+
  
 +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.
  
-==== Ablauf ====+===== 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|}} {{:modul:m450:learningunits:lu01:testablauf.png?600|}}
  
-  - In der Analyse werden die Anforderungen an das Programm ermittelt. Diese Anforderungen dienen als Grundlage für die Erstellung der Testfälle und des Programms. +  - **Analyse:** Die Anforderungen an das Programm werden ermittelt. Sie sind die Grundlage für das Programm **und** für die Testfälle. 
-  - Nachdem der Programmierer den Quellcode erstellt hat, wird das Programm systematisch getestet. Bei kleineren Projekten kann es sein, dass Programmierer und Tester ein und dieselbe Person sind. Oft werden jedoch bessere Ergebnisse erzielt, wenn eine zweite Person die Testfälle durchführt. +  - **Testfälle erstellen:** Aus den Anforderungen entstehen die Testfälle, meistens parallel zur Programmierung. 
-  - Dazu benötigt der Tester die zuvor erstellten Testfälle. Beim Testen startet man das Programm und gibt dem Programm die festgelegten Testdaten ein. +  - **Programmieren:** Die Entwicklerin erstellt das Programm. 
-  - Bei einem Testdurchlauf wird jeder Testfall einmal ausgeführt. Für jeden Testfall halten Sie das tatsächliche Ergebnis in einem Testprotokoll fest. +  - **Testdurchlauf:** Die Testerin führt jeden Testfall einmal aus und hält das Ergebnis im Testprotokoll fest. 
-  - Wenn alle Testfälle ausgeführt wurden, entscheidet der Tester:   +  - **Entscheid:** Nach dem Testdurchlauf entscheidet die Testerin, ob das Programm in Ordnung ist oder überarbeitet werden muss. 
-    * das Programm muss überarbeitet werden +  - **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.
-    * das Programm ist in Ordnung +
-  - Wenn das Programm überarbeitet werden muss, wird es an den Programmierer zurückgeschickt. Dieser nimmt die Verbesserungen vor und übergibt die neue Programmversion wieder dem Tester. Der Tester führt nun **alle** Testfälle erneut durch und hält die Ergebnisse in einem **neuen** Testprotokoll fest.+
  
 +<WRAP center round info 80%>
 +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**.
 +</WRAP>
  
-===== IEEE 829 =====+===== Normen: IEEE 829 =====
 {{https://upload.wikimedia.org/wikipedia/commons/2/2f/IEEE829_Uebersicht_Deutsch.png?600}} {{https://upload.wikimedia.org/wikipedia/commons/2/2f/IEEE829_Uebersicht_Deutsch.png?600}}
  
-Die Grafik zeigt die Dokumente und Prozessschritte nach [[wpde>Software_Test_Documentation|IEEE 829]].+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}} {{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 [[https://creativecommons.org/licenses/by-nc-sa/4.0/|{{https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png}}]] Marcel Suter
  
  • modul/m450/learningunits/lu01/grundlagen.txt
  • Zuletzt geändert: 2026/11/11 10:52
  • von admin