Eingabemethode showInputDialog

Für die grafikbasierte Eingabe wird die Klassenmethode showInputDialog

der Klasse

In der API-Dokumentation ist die Methode showInputDialog

folgendermaßen

angegeben:

Methodenaufruf:

Um die Methode showInputDialog

zu verwenden müssen die selben Punkte

nacheinander überlegt werden, wie bei selbstgeschriebenen Methoden.

1. Überprüfen, ob es sich um eine Klassenmethode handelt:

   Ist das Schlüsselwort static in der Methodendokumentation

   vorhanden?

   Bei dieser Methode: Ja, d.h. es ist eine Klassenmethode, damit hat

   der Aufruf die Struktur:

   Klassenname.Methodenname oder konkret: JOptionPane.showInputDialog

2. Für jeden Formalparameter in der Methodendefinition muss ein

   Aktualparameter (= aktueller Wert) festgelegt werden:

   1. Erster Parameter: dieser ist vom Objekttyp Component

      (erkennbar am

      großen Anfangsbuchstaben). Hier kann man angeben zu welcher

      grafischen Oberflächenkomponente der Eingabedialog dazu gehört.

      Nachdem wir erst viel, viel später grafische Oberflächen

      verwenden, kann derzeit der Wert

      null

      (ausgeschrieben, nicht

      die Ziffer 0) angegeben werden, der bei Objekten als Ersatz für

      "nichts" verwendet wird.

   2. Zweiter Parameter: Ebenfalls ein Objekttyp, der dafür steht, dass

      man irgendeine beliebige Nachricht als Objekt angegeben kann.

      Nachdem String ein Objektdatentyp ist, können auch Variablen

      oder Literale vom Typ String dafür verwendet werden, z.B:

      "Eingabe bitte:"

3. Überprüfen, ob eine Auffangvariable benötigt wird (Rückgabetyp ≠

   void) oder nicht (Rückgabetyp = void):
   Welchen Rückgabetyp hat die Methode?

   Bei dieser Methode:

   String

   , d.h. es wird eine Auffangvariable vom

   Typ

   String benötigt.

Ergänze folgende Zusammenfassung:

• Die Methode für die grafikbasierten Eingabedialoge ist in der Klasse definiert.

• Der Name der Methode für die grafikbasierten Eingabedialoge lautet .

• Das Schlüsselwort in der API-Dokumentation dieser Methode zeigt an, dass es sich um eine

  Objektmethode

  Klassenmethode
  handelt.

• Klassenmethoden werden grundsätzlich mit . aufgerufen.

• Diese Methode wird daher konkret mit . aufgerufen.

• Für den ersten Parameter werden wir derzeit immer den Wert einsetzen, weil wir keine selbst programmierte grafische Oberfläche haben, mit der wir unseren Eingabedialog verbinden wollen.

• Als zweiter Parameter wird

  das Symbolbild im Eingabedialog

  der Text der angezeigt werden soll

  der Titel in der Titelleiste des Eingabedialogs
  angegeben.

• Diese Methode benötigt

  eine

  keine
  Auffangvariable, weil der Rückgabetyp in der Methodendokumentation
  nicht void

  void
  ist.

• Der Rückgabetyp der Methode ist , deshalb muss auch die Auffangvariable den Typ haben.

Programmausführung fortsetzen oder abbrechen:

1. Fortsetzen bzw. Continue:

   Hierbei wird die schrittweise Ausführung des Programms unterbrochen

   und das Pro­gramm wird in normaler Geschwindigkeit fortgesetzt,

   solange bis die Ausführung des Programms wieder zu einem Breakpoint

   kommt.

2. Abbrechen bzw. Terminate:

   Die Programmausführung wird komplett abgebrochen und damit beendet.

Ergänze folgende Zusammenfassung:

• Durch das Anklicken von wird der Debugmodus unterbrochen und das Programm in "normaler" Weise fortgesetzt.

• Auch wenn Continue angeklickt wurde, kann die Programmausführung durch einen erneut unterbrochen werden.

• Durch das Auswählen von wird die Programmausführung komplett gestoppt und beendet.

Programm schrittweise ausführen:

Durch Anklicken eines Buttons kann man nun die nächste Anweisung

ausführen und damit das Programm um einen Schritt weiter schalten. Dafür

gibt es 2 Varianten:

1. Schritt hinein bzw. Step into:

   Dabei wird ein Programmschritt - eine Programmanweisung -

   ausgeführt. Danach wird das Programm wieder angehalten, so dass man

   sich die Veränderung im Programm, die dieser Schritt bewirkt hat,

   ansehen kann. Wenn der Programmschritt, der ausgeführt werden soll,

   ein Methodenaufruf ist, so wird die Ausführung innerhalb der Methode

   fortgesetzt, sofern die Methodendefinition verfügbar ist. Dies ist

   normalerweise bei selbst geschriebenen Methoden der Fall. Methoden

   der Java-Bibliothek, die aufgerufen werden, werden daher immer als

   ein Schritt ausgeführt.

    

   

2. Schritt über bzw. Step:

   Dieser Befehl funktioniert ähnlich wie "Step Into", nur dass ein

   Methodenaufruf immer in einem Schritt bearbeitet wird, und die

   Ausführung nie in der Methode fortgesetzt wird.

    

   

Unabhängig davon, ob man Step oder Step Into

wählt, wird in BlueJ

die gerade aktive Zeile markiert. Wenn allerdings beim Aufruf einer

selbst definierten Methode

Nachdem Step Into

ausgewählt wurde, wird der Quellcode der Methode

erhoehen in der Klasse Zaehlen geöffnet.

Wie hier gut zu sehen ist, sind die Variablen der main-Methode innerhalb

der Methode erhoehen nicht mehr gültig. Die beiden Methoden (main und

erhoehen) haben komplett getrennte Variablenbereiche, die nichts

voneinander wissen. Nur durch den Aufruf (siehe Bild darüber) wurde der

Wert der Variablen anzNegativ in den Wert der Variablen zahl (diese ist

der 1. Parameter) kopiert und die Parameter-Variable damit

initialisiert. Die Variable des zweiten Parameters namens wert wurde

durch den Aufruf mit der Zahl 1 initialisiert.

Auch wenn sich die Ausführung innerhalb einer Methode befindet, kann die

Debugger-Ansicht in die main-Methode gewechselt werden, um z.B. die

Variablenwerte oder die Aufrufzeile zu kontrollieren:

Nach dem die Methode mit Step

schrittweise abgearbeitet wurde, wird

sie beendet und das Programm kehrt zu der Zeile zurück, in der die

Methode aufgerufen wurde.

Das Debuggen kann nun fortgesetzt werden, bis der entsprechende Fehler

gefunden wurde.

Ergänze folgende Zusammenfassung:

• Mit "Step" und "Step Into" kann das Programm im Debugmodus

  schrittweise

  auf ein Mal
  ausgeführt werden.

• Wenn das Programm bei keinem Methodenaufruf steht, gibt es auch

  einen

  keinen
  Unterschied zwischen "Step" und "Step Into".

• Wenn das Programm bei einem Methodenaufruf steht, dann wird durch das Anklicken von "Step",

  in die Methode gesprungen und dort weitergemacht

  die Methode in einem Schritt ausgeführt

• Wenn das Programm bei einem Methodenaufruf steht, dann wird durch das Anklicken von "Step Into",

  die Methode in einem Schritt ausgeführt

  in die Methode gesprungen und dort weitergemacht

• Wenn man sich innerhalb einer Methode befindet, kann auf die

  Dokumentationsansicht

  aufrufende Methode
  gewechselt werden, um die Aufrufzeile und die dortigen Variablen zu untersuchen.

Debuggen

Die meisten IDEs haben eine Möglichkeit Programme in Einzelschritten

auszuführen. Dies kann aus folgenden Gründen notwendig sein:

1. Mein Programm hat einen Fehler im Programmablauf, den ich finden und

   beheben möchte

2. Man sieht vor sich ein unbekanntes Programm und möchte es verstehen

Das Programm, mit dem man den Quellcode eines Programms Schritt für

Schritt ausführen kann, nennt man

Die Schritte um mit dem Debugger zu arbeiten sind in den folgenden

Abschnitten beschrieben.

Haltepunkt bzw. Breakpoint setzen:

Durch einen Breakpoint wird die normale Programmausführung unterbrochen

(engl.

Ein Breakpoint kann in BlueJ durch Anklicken der entsprechenden Zeile in

der Seitenleiste gesetzt werden, solange der Quellcode schon kompiliert

wurde (erkennbar an der weißen Seitenleiste):

Wenn das Programm ausgeführt wird, stoppt es dann automatisch an der

Stelle, wo der Breakpoint gesetzt wurde. Dabei wird auch der Debugger

geöffnet:

Im Debugger werden die Methoden und all ihre Variablen mit ihren Werten

angezeigt.

Ergänze folgende Zusammenfassung:

• Um die Fehlersuche in Programmen zu unterstützen, bieten die meisten IDEs einen an.

• Mit dem Debugger kann man ein Programm

  schrittweise

  schneller

  langsamer
  ausführen.

• Um mit dem Debugger zu arbeiten muss man zunächst einen setzen.

• Durch den Breakpoint

  endet

  pausiert

  läuft
  die Programmausführung bei der Zeile, wo der Breakpoint gesetzt wurde.

• Ein Breakpoint kann bei folgenden Anweisungen nicht gesetzt werden:

  Methodenkopfzeilen
  Variablendeklarationen (ohne Initialisierung)
  Variableninitialisierungen
  Methodenaufrufen

• Bevor ein Breakpoint gesetzt werden kann, muss der Quellcode

  kompiliert

  ausgeführt

  interpretiert
  werden.

• Im Debugger-Fenster sieht man die folgenden Informationen:

  die Werte der lokalen Variablen
  die Programmanweisungen
  die Dokumentationskommentare
  in welcher Methode man sich befindet

Beispielablauf:

Für das vorige Beispiel wurde ein erster Programmentwurf mit folgendem Quellcode geschrieben:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

import
 javax.swing.JOptionPane;
/**
 * In diesem Programm wird die Anzahl der positiven und die Anzahl
 * der negativen Zahlen in einer Zahlenfolge ausgegeben. Die 
 * Gesamtanzahl der Zahlen in der Zahlenfolge muss zuvor eingegeben
 * werden.
 * @author Lisa Vittori
 * @version 2017-03-28
 */
public class
 PositiveNegative {
  public static void
 main(String[] args) {
    String eingabe;
    int
 anzahl, zahl, anzPositiv, anzNegativ;
    anzPositiv = 0
;
    anzNegativ = 0
;
    eingabe = JOptionPane.showInputDialog(null, "Wie viele"
 + 
        " Zahlen solle eingegeben werden?"
);
    anzahl = Integer.parseInt
(eingabe);
    if(anzahl >= 0
) {
      for(;anzahl >= 0
; anzahl--) {
        eingabe = JOptionPane.showInputDialog(null, "Bitte"
 +
            " geben Sie eine zu überprüfende Zahl ein."
);
        zahl = Integer.parseInt
(eingabe);
        if(zahl > 0
) {
          anzPositiv++;
        }
        else
 {
          anzNegativ++;
        }
      }
      JOptionPane.showMessageDialog(null, anzPositiv + " positive"
 
          + " Zahl(en), " + anzNegativ + " negative Zahl(en)"
);
    }
    else
 {
      JOptionPane.showMessageDialog(null, "Als Anzahl sind"
 +
          " nur positive Zahlen (größer als 0) erlaubt!"
);
    }
  }
}

Wenn man mit dem obigen Programm die einzelnen Testfälle im

Testprotokoll durchgeht, dann ist folgendes Ergebnis zu sehen:

Die fehlgeschlagenen Testfälle liefern statt des erwarteten Ergebnisses

folgendes Ergebnis:

• Testfall 1: 6 Zahlen können eingegeben werden
• Testfall 2: 2 Zahlen können eingegeben werden
• Testfall 3: 1 Zahl kann eingegeben werden
• Testfall 5: 2 Zahlen können eingegeben werden
• Testfall 6: 2 Zahlen können eingegeben werden
• Testfall 7: 2 Zahlen können eingegeben werden
• Testfall 8: 2 Zahlen können eingegeben werden
• Testfall 9: 2 Zahlen können eingegeben werden
• Testfall 10: 6 Zahlen können eingegeben werden

Aus der Fehlerart kann man unter Umständen schnell auf den Fehler

schließen. So funktioniert offenbar die Wiederholung der Eingabe nicht

richtig und es wird die Eingabe zu oft wiederholt. Die Zeile, die für

das Wiederholen der Eingabe zuständig ist, ist der Schleifenkopf in

Zeile 20. Hier kann mit der Korrektur angesetzt werden. Die neue Zeile

20 sieht folgendermaßen aus (

for(;anzahl > 0; anzahl--) {

Nach Ausbessern dieses Fehlers muss das Testen wiederholt werden. Im

Testprotokoll wird der Erfolg oder Misserfolg neuerlich festgehalten:

Tatsächliche Ergebnisse:

• Testfall 3: keine Fehlermeldung, statt dessen Ausgabe: "0 positive

  Zahl(en), 0 negative Zahl(en)"

• Testfall 9: Ausgabe: "0 positive Zahl(en), 1 negative Zahl(en)"
• Testfall 10: Ausgabe: "2 positive Zahl(en), 3 negative Zahl(en)"

Das Ergebnis dieses Testablaufs ist schon besser, aber das Programm ist

offenbar noch immer fehlerhaft. Es sind also noch weitere Korrekturen

mit nachfolgenden Tests notwendig. Der Prozess wird so lange wiederholt,

bis keine Fehler mehr auftreten.

In professionellen Programmierumgebungen werden solche Tests möglichst

automatisiert abgearbeitet. Damit wird vermieden, dass das Ausbessern

eines Bugs, eine Reihe weiterer neuer Bugs nach sich zieht.

Beim Test Driven Development

werden solche Tests auch entworfen,

bevor noch der Quellcode begonnen wird. Das Ziel ist dann mit jedem

Entwicklungsschritt mehr Testfälle auf "OK" bzw. grün zu setzen. Auch

abseits davon entspricht es guter Programmierpraxis, die Testfälle zu

entwerfen bevor mit der eigentlichen Programmentwicklung begonnen wird.

Durch das Entwerfen der Testfälle werden bestimmte Bereiche der

Aufgabenstellung bereits gründlich analysiert und auf besonders zu

berücksichtigende Fälle eingegangen. Dies kann bei der

Programmentwicklung helfen.

Beantworte die folgenden Fragen:

• Welche Programmzeile muss geändert werden, um den verbleibenden Fehler, der durch Testfall 3 erkannt wird, zu beheben?

• Was muss statt der fehlerhaften Zeile geschrieben werden, um den Fehler, der durch Testfall 3 erkannt wird, zu beheben (ohne führende Leerzeichen/Tabs)?

• Welche Programmzeile muss geändert werden, um den verbleibenden Fehler, der durch die Testfälle 9 und 10 erkannt wird, zu beheben (es gibt natürlich mehrere Lösungsvarianten, aber nur eine, wo nur eine Programmzeile geändert werden muss)?

• Was muss statt der fehlerhaften Zeile geschrieben werden, um den Fehler, der durch die Testfälle 9 und 10 erkannt wird, zu beheben (ohne führende Leerzeichen/Tabs)?

• Wie nennt man die Herangehensweise beim Programmieren, bei der zuerst die Testfälle entworfen werden, und dann bei jedem weiteren Schritt versucht wird, einen weiteren Testfall auf "OK" zu setzen?

Beispielablauf:

Für das vorige Beispiel wurde ein erster Programmentwurf mit folgendem Quellcode geschrieben:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

import
 javax.swing.JOptionPane;
/**
 * In diesem Programm wird die Anzahl der positiven und die Anzahl
 * der negativen Zahlen in einer Zahlenfolge ausgegeben. Die 
 * Gesamtanzahl der Zahlen in der Zahlenfolge muss zuvor eingegeben
 * werden.
 * @author Lisa Vittori
 * @version 2017-03-28
 */
public class
 PositiveNegative {
  public static void
 main(String[] args) {
    String eingabe;
    int
 anzahl, zahl, anzPositiv, anzNegativ;
    anzPositiv = 0
;
    anzNegativ = 0
;
    eingabe = JOptionPane.showInputDialog(null, "Wie viele"
 + 
        " Zahlen solle eingegeben werden?"
);
    anzahl = Integer.parseInt
(eingabe);
    if(anzahl >= 0
) {
      for(;anzahl >= 0
; anzahl--) {
        eingabe = JOptionPane.showInputDialog(null, "Bitte"
 +
            " geben Sie eine zu überprüfende Zahl ein."
);
        zahl = Integer.parseInt
(eingabe);
        if(zahl > 0
) {
          anzPositiv++;
        }
        else
 {
          anzNegativ++;
        }
      }
      JOptionPane.showMessageDialog(null, anzPositiv + " positive"
 
          + " Zahl(en), " + anzNegativ + " negative Zahl(en)"
);
    }
    else
 {
      JOptionPane.showMessageDialog(null, "Als Anzahl sind"
 +
          " nur positive Zahlen (größer als 0) erlaubt!"
);
    }
  }
}

Wenn man mit dem obigen Programm die einzelnen Testfälle im

Testprotokoll durchgeht, dann ist folgendes Ergebnis zu sehen:

Die fehlgeschlagenen Testfälle liefern statt des erwarteten Ergebnisses

folgendes Ergebnis:

• Testfall 1: 6 Zahlen können eingegeben werden
• Testfall 2: 2 Zahlen können eingegeben werden
• Testfall 3: 1 Zahl kann eingegeben werden
• Testfall 5: 2 Zahlen können eingegeben werden
• Testfall 6: 2 Zahlen können eingegeben werden
• Testfall 7: 2 Zahlen können eingegeben werden
• Testfall 8: 2 Zahlen können eingegeben werden
• Testfall 9: 2 Zahlen können eingegeben werden
• Testfall 10: 6 Zahlen können eingegeben werden

Aus der Fehlerart kann man unter Umständen schnell auf den Fehler

schließen. So funktioniert offenbar die Wiederholung der Eingabe nicht

richtig und es wird die Eingabe zu oft wiederholt. Die Zeile, die für

das Wiederholen der Eingabe zuständig ist, ist der Schleifenkopf in

Zeile 20. Hier kann mit der Korrektur angesetzt werden. Die neue Zeile

20 sieht folgendermaßen aus (

for(;anzahl > 0; anzahl--) {

Nach Ausbessern dieses Fehlers muss das Testen wiederholt werden. Im

Testprotokoll wird der Erfolg oder Misserfolg neuerlich festgehalten:

Tatsächliche Ergebnisse:

• Testfall 3: keine Fehlermeldung, statt dessen Ausgabe: "0 positive

  Zahl(en), 0 negative Zahl(en)"

• Testfall 9: Ausgabe: "0 positive Zahl(en), 1 negative Zahl(en)"
• Testfall 10: Ausgabe: "2 positive Zahl(en), 3 negative Zahl(en)"

Das Ergebnis dieses Testablaufs ist schon besser, aber das Programm ist

offenbar noch immer fehlerhaft. Es sind also noch weitere Korrekturen

mit nachfolgenden Tests notwendig. Der Prozess wird so lange wiederholt,

bis keine Fehler mehr auftreten.

In professionellen Programmierumgebungen werden solche Tests möglichst

automatisiert abgearbeitet. Damit wird vermieden, dass das Ausbessern

eines Bugs, eine Reihe weiterer neuer Bugs nach sich zieht.

Beim Test Driven Development

werden solche Tests auch entworfen,

bevor noch der Quellcode begonnen wird. Das Ziel ist dann mit jedem

Entwicklungsschritt mehr Testfälle auf "OK" bzw. grün zu setzen. Auch

abseits davon entspricht es guter Programmierpraxis, die Testfälle zu

entwerfen bevor mit der eigentlichen Programmentwicklung begonnen wird.

Durch das Entwerfen der Testfälle werden bestimmte Bereiche der

Aufgabenstellung bereits gründlich analysiert und auf besonders zu

berücksichtigende Fälle eingegangen. Dies kann bei der

Programmentwicklung helfen.

Beantworte die folgenden Fragen:

• Welche Programmzeile muss geändert werden, um den verbleibenden Fehler, der durch Testfall 3 erkannt wird, zu beheben?

• Was muss statt der fehlerhaften Zeile geschrieben werden, um den Fehler, der durch Testfall 3 erkannt wird, zu beheben (ohne führende Leerzeichen/Tabs)?

• Welche Programmzeile muss geändert werden, um den verbleibenden Fehler, der durch die Testfälle 9 und 10 erkannt wird, zu beheben (es gibt natürlich mehrere Lösungsvarianten, aber nur eine, wo nur eine Programmzeile geändert werden muss)?

• Was muss statt der fehlerhaften Zeile geschrieben werden, um den Fehler, der durch die Testfälle 9 und 10 erkannt wird, zu beheben (ohne führende Leerzeichen/Tabs)?

• Wie nennt man die Herangehensweise beim Programmieren, bei der zuerst die Testfälle entworfen werden, und dann bei jedem weiteren Schritt versucht wird, einen weiteren Testfall auf "OK" zu setzen?

Programmbeispiel:

Schreibe ein Programm, das eine beliebige Anzahl an Zahlen eingeben

lässt und dann ausgibt, wie viele positive und wie viele negative Zahlen

eingegeben wurden. Am Beginn muss zusätzlich eingegeben werden, wie

viele Zahlen insgesamt für das Zählen eingegeben werden sollen.

Anforderungsanalyse und Definition der Testfälle

Die Aufgabenstellung ist bewusst etwas vage gehalten, um nicht zu viel

vorwegzunehmen. Aber auch Aufgabenstellungen in der Praxis sind im

ersten Anlauf oft nicht vollständig (mehr dazu im Gegenstand

„Informationstechnische Projekte"). In der gegebenen Aufgabenstellung

kommen 2 grundsätzlich verschiedene Eingaben vor:

1. Die Anzahl der einzugebenden Zahlen

2. Die jeweilige Zahl, die gezählt werden soll.

Für die Anzahl

sind keine genauen Kriterien definiert, aber ein paar

wichtige Bedingungen ergeben sich aus dem logischen Zusammenhang:

1. eine negative Anzahl ist nicht sinnvoll

2. 0 als Anzahl ist ebenfalls nicht sinnvoll

Damit ergeben sich folgende Werte, die zu testen sind:

• NF: ein beliebiger positiver Wert

• FF: ein beliebiger negativer Wert

• GF (FF): 0 (ist noch ein Fehlerfall, aber an der Grenze zum NF)

• GF (NF): 1 (ist schon ein gültiger Normalfall, aber an der Grenze zum

  FF)

Für die zweite Eingabe - die Zahl

, die gezählt werden soll - sind andere Fälle wichtig. Wir haben 2

Kategorien, die gezählt werden:

1. positive Zahlen

2. negative Zahlen

3. und was ist mit 0? Diese Zahl ist weder positiv noch negativ und darf bei

   keinem gezählt werden.

Damit ergeben sich als zu testende Werte:

• NF: beliebige positive Zahl

• NF: beliebige negative Zahl

• GF (NF): 1 (kleinste positive Zahl und damit an der Grenze zur

  neutralen Zahl)

• GF (NF): 0 (ist keine falsche Eingabe, aber darf nicht gezählt werden)

• GF (NF): -1 (größte negative Zahl und damit an der Grenze zur neutralen

  Zahl)

• NF: mehrere verschiedene Werte (notwendig, um die Anforderung

  "Zählen" wirklich zu überprüfen)

Mit diesen Überlegungen kann man nun einen Testplan aufstellen. Ein

Testprotokoll enthält mögliche Eingabewerte und die dazu erwarteten

Ergebnisse. Zusätzlich empfiehlt es sich die Testfälle

durchzunummerieren, damit man sich später darauf beziehen kann.

Löse folgende Aufgabenstellung:

Führe eine Anforderungsanalyse für folgende Aufgabenstellung durch:

Für ein Zeiterfassungssystem sollen die Arbeitszeiten berechnet werden. Die Arbeitszeit beginnt jeden Tag um 8:00. Die Endzeit ist flexibel. Lies bei dem Programm zuerst ein, wie viele Arbeitstage erfasst werden sollen. Lies anschließend zu jedem Arbeitstag die Endzeit ein, indem du zuerst die Stunde und dann die Minuten einliest (also, wenn die Arbeitszeit um 12:45 endet, wird zuerst 12 und dann 45 eingelesen). Anschließend soll die Summe der Arbeitszeiten für jeden Tag berechnet und im Format Stunden:Minuten (hh:mm) ausgegeben werden.

• Welche grundsätzlichen Eingabewerte umfasst das Programm:

  Stundenwert
  Anzahl der Arbeitstage
  Minutenwert
  Endzeit im Format Stunden:Minuten (hh:mm)
  Summe der Arbeitszeit

• Bei welchen der folgenden möglichen Werte, handelt es sich für die Anzahl der Arbeitstage um einen Normalfall

  (Achtung, auch Grenzfälle können entweder Normalfälle oder Fehlerfälle sein):

  -10
  15
  0
  1
  -1
  2

• Bei welchen der folgenden möglichen Werte, handelt es sich für die Anzahl der Arbeitstage um einen Fehlerfall

  (Achtung, auch Grenzfälle können entweder Normalfälle oder Fehlerfälle sein):

  1
  -1
  15
  2
  -10
  0

• Bei welchen der folgenden möglichen Werte, handelt es sich für die Anzahl der Arbeitstage um einen Grenzfall

  (Achtung, auch Normalfälle oder Fehlerfälle können Grenzfälle sein):

  1
  2
  15
  0
  -10
  -1

• Bei welchen der folgenden möglichen Werte, handelt es sich für die Stundenwerte um einen Normalfall

  (Achtung, auch Grenzfälle können entweder Normalfälle oder Fehlerfälle sein):

  12
  -1
  7
  15
  0
  8

• Bei welchen der folgenden möglichen Werte, handelt es sich für die Stundenwerte um einen Fehlerfall

  (Achtung, auch Grenzfälle können entweder Normalfälle oder Fehlerfälle sein):

  0
  8
  -1
  15
  12
  7

• Bei welchen der folgenden möglichen Werte, handelt es sich für die Stundenwerte um einen Grenzfall

  (Achtung, auch Normalfälle oder Fehlerfälle können Grenzfälle sein):

  8
  15
  -1
  0
  12
  7

• Bei welchen der folgenden möglichen Werte, handelt es sich für die Minutenwerte um einen Normalfall

  (Achtung, auch Grenzfälle können entweder Normalfälle oder Fehlerfälle sein):

  59
  0
  123
  60
  -1
  35

• Bei welchen der folgenden möglichen Werte, handelt es sich für die Minutenwerte um einen Fehlerfall

  (Achtung, auch Grenzfälle können entweder Normalfälle oder Fehlerfälle sein):

  -1
  59
  0
  123
  60
  35

• Bei welchen der folgenden möglichen Werte, handelt es sich für die Minutenwerte um einen Grenzfall

  (Achtung, auch Normalfälle oder Fehlerfälle können Grenzfälle sein):

  123
  60
  0
  59
  -1
  35

Testfälle:

Testfälle beschreiben die durchzuführenden Tests und bilden damit die Testszenarien:

Ein Testfall ist eine Reihe von Eingabewerten mit ihren erwarteten

Ergebnissen.

Auch notwendige Vorbedingungen bzw. abschließende Handlungen, die für

den Test gelten und notwendig sind, werden im Testfall angegeben. In

diesem ersten Betrachten des Themas "Testen" genügt allerdings die

gegebene einfache Definition.

Ausgangspunkt für das Erstellen von Testfällen sind die Anforderungen an

das Programm. Deshalb ist die Anforderungsanalyse der erste Schritt, um

überhaupt Tests definieren zu können. Dabei muss möglichst für jede

Anforderung an das Programm mindestens einen Testfall definiert werden.

Der Begriff

Eingabewerte

Es ist bei Programmen oft unmöglich alle möglichen Eingabewerte zu

testen. Deswegen ist es üblich die Eingabewerte in Gruppen bzw. Blöcke

zu unterteilen, die so gewählt werden, dass eine möglichst vollständige

• Normalfälle (NF): Eingabewerte, die sicher ein gültiges Ergebnis

  liefern

• Grenzfälle(GF): Eingabewerte, die an Grenze zwischen den Blöcken oder

  an Grenzen von Normalfällen zu Fehlerfällen liegen.

• Fehlerfälle (FF): Fehlerfälle, sind Eingabe-Werte, die außerhalb des

  sinnvollen Bereiches liegen und im Programm zu einer gewollten

  Fehlermeldung führen. Diese sind auch oft ein ganz eigener Block.

Ergänze folgende Zusammenfassung:

• Ein stellt ein einzelnes Testszenario dar.

• Dabei beschreibt der Testfall welche verwendet werden und welche zu diesen Werten herauskommen sollen, also erwartet werden.

• Der erste Schritt zur Entwicklung der Testfälle ist die . Durch sie werden die Eingaben mit ihren erwarteten Ergebnissen beschrieben.

• Die Anforderungen sollen durch die Tests möglichst vollständig abgedeckt werden. Wenn dies gut gelingt, spricht man von einer guten .

• Da man bei den meisten Programmen unmöglich alle möglichen Eingabewerte testen kann, werden diese Eingabewerte in unterteilt.

• Für jede Testklasse sollen zunächst einmal die

  Normalfälle

  Fehlerfälle

  Grenzfälle
  betrachtet werden. Dabei handelt es sich um Eingabewerte, die sicher ein gültiges Ergebnis liefern.

• Es ist aber auch wichtig

  Normalfälle

  Grenzfälle

  Fehlerfälle
  zu testen. Das sind Fälle, wo die Eingabewerte ungültig sind, und das Programm dabei auch eine Fehlermeldung ausgeben muss.

• Normalfälle

  Grenzfälle

  Fehlerfälle
  sind Eingabewerte, die genau am Übergang vom Normalfall zum Fehlerfall oder aber auch am Übergang zwischen verschiedenen Testklassen liegen.

• Bei den Grenzfällen passieren die

  wenigsten

  meisten
  Fehler. Sie müssen daher besonders gut getestet werden.

Testen und Debuggen

Testen

Testen ist die systematische Suche nach Fehlern. Damit soll ein

möglichst sicherer Umgang mit dem Programm gewährleistet werden. Nachdem

alle Programme von Menschen entwickelt werden, kommen Fehler in

Programmen vor. Je mehr Zeilen ein Programm besitzt, desto

wahrscheinlicher ist das Auftreten von Fehlern. Es gibt zwei wichtige

Arten:

• Syntax-Fehler: Programmanweisungen, die nicht den Regeln der

  Programmiersprache entsprechend geschrieben wurden; Solche Fehler kann

  der Compiler gut erkennen. Sie werden deswegen auch als

  Compiler-Fehler oder auch grammatikalische Fehler bezeichnet.

• Semantik-Fehler: Fehler, die in der Bedeutung des Programms liegen,

  d.h. in der Programm-Logik. Diese Fehler können vom Compiler nicht

  erkannt werden. Sie werden deshalb oft auch als Logik-Fehler oder

  umgangssprachlich als Bugs bezeichnet.

Beim Testen geht es um das Aufspüren von semantischen Fehlern.

Damit Fehler gefunden werden können, muss ein Programmablauf immer

wieder mit verschiedensten Szenarien durchgespielt werden. Um die

Chancen zu erhöhen, mit diesen Szenarien auch wirklich die Fehler zu

finden, müssen diese Szenarien nach einem bestimmten System entwickelt

werden. Je nach Herangehensweise werden prinzipiell 2 Arten von Tests

unterschieden:

• Black-Box-Testen: Dabei wird das Programm als "schwarze Box"

  betrachtet, dessen Innenleben nicht bekannt ist. Allein aus der

  Programmbeschreibung bzw. Aufgabenstellung werden die Szenarien

  abgeleitet, die für das Testen herangezogen werden.

• White-Box-Testen: Hier werden die Testfälle und Testverfahren aus dem

  Wissen über den internen Aufbau des Programms abgeleitet.

Da oft keine klaren Grenzen gezogen werden können, wurde als Begriff

Gray-Box-Testen eingeführt bzw. wird in moderner Literatur die obige

Unterscheidung gar nicht mehr getroffen (vgl.

Ein Zugang, der von vielen Anfängern verwendet wird, ist das

"Ausprobieren" von Software. Beim Ausprobieren wird oft nur ein

einziger typischer Programmablauf durchgeführt und wenn dieser das

gewünschte Ergebnis liefert, wird das Ausprobieren beendet. Die

Wahrscheinlichkeit dabei Fehler zu finden ist nicht sehr groß.

Ergänze folgende Zusammenfassung:

• Im Gegensatz zum Ausprobieren werden beim Testen die Fehler gesucht.

• Das Testen dient nicht dazu, -Fehler aufzuspüren, denn diese werden vom Compiler erkannt.

• Beim Testen können hingegen logische Fehler, d.h. -Fehler, gefunden werden.

• Die einfachere Herangehensweise beim Testen ist das -Testen, weil dabei nur von der Aufgabenstellung bzw. der Programmbeschreibung ausgegangen wird.

• Beim -Testen wird auf die genauen Programmablauf im Quellcode eingegangen, um die Testszenarien zu entwerfen.

• Da aber oft die Entwickler selbst die Tests entwerfen und dabei natürlich die Kenntnis über den Quellcode einfließen lassen, spricht man auch öfters von -Testen.

• Ausprobieren ist mit Testen gleichzusetzen, da das Ausprobieren oft nur ein Szenario umfasst und nicht systematisch abläuft.

Testen und Debuggen

Testen

Testen ist die systematische Suche nach Fehlern. Damit soll ein

möglichst sicherer Umgang mit dem Programm gewährleistet werden. Nachdem

alle Programme von Menschen entwickelt werden, kommen Fehler in

Programmen vor. Je mehr Zeilen ein Programm besitzt, desto

wahrscheinlicher ist das Auftreten von Fehlern. Es gibt zwei wichtige

Arten:

• Syntax-Fehler: Programmanweisungen, die nicht den Regeln der

  Programmiersprache entsprechend geschrieben wurden; Solche Fehler kann

  der Compiler gut erkennen. Sie werden deswegen auch als

  Compiler-Fehler oder auch grammatikalische Fehler bezeichnet.

• Semantik-Fehler: Fehler, die in der Bedeutung des Programms liegen,

  d.h. in der Programm-Logik. Diese Fehler können vom Compiler nicht

  erkannt werden. Sie werden deshalb oft auch als Logik-Fehler oder

  umgangssprachlich als Bugs bezeichnet.

Beim Testen geht es um das Aufspüren von semantischen Fehlern.

Damit Fehler gefunden werden können, muss ein Programmablauf immer

wieder mit verschiedensten Szenarien durchgespielt werden. Um die

Chancen zu erhöhen, mit diesen Szenarien auch wirklich die Fehler zu

finden, müssen diese Szenarien nach einem bestimmten System entwickelt

werden. Je nach Herangehensweise werden prinzipiell 2 Arten von Tests

unterschieden:

• Black-Box-Testen: Dabei wird das Programm als "schwarze Box"

  betrachtet, dessen Innenleben nicht bekannt ist. Allein aus der

  Programmbeschreibung bzw. Aufgabenstellung werden die Szenarien

  abgeleitet, die für das Testen herangezogen werden.

• White-Box-Testen: Hier werden die Testfälle und Testverfahren aus dem

  Wissen über den internen Aufbau des Programms abgeleitet.

Da oft keine klaren Grenzen gezogen werden können, wurde als Begriff

Gray-Box-Testen eingeführt bzw. wird in moderner Literatur die obige

Unterscheidung gar nicht mehr getroffen (vgl.

Ein Zugang, der von vielen Anfängern verwendet wird, ist das

"Ausprobieren" von Software. Beim Ausprobieren wird oft nur ein

einziger typischer Programmablauf durchgeführt und wenn dieser das

gewünschte Ergebnis liefert, wird das Ausprobieren beendet. Die

Wahrscheinlichkeit dabei Fehler zu finden ist nicht sehr groß.

Ergänze folgende Zusammenfassung:

• Im Gegensatz zum Ausprobieren werden beim Testen die Fehler gesucht.

• Das Testen dient nicht dazu, -Fehler aufzuspüren, denn diese werden vom Compiler erkannt.

• Beim Testen können hingegen logische Fehler, d.h. -Fehler, gefunden werden.

• Die einfachere Herangehensweise beim Testen ist das -Testen, weil dabei nur von der Aufgabenstellung bzw. der Programmbeschreibung ausgegangen wird.

• Beim -Testen wird auf die genauen Programmablauf im Quellcode eingegangen, um die Testszenarien zu entwerfen.

• Da aber oft die Entwickler selbst die Tests entwerfen und dabei natürlich die Kenntnis über den Quellcode einfließen lassen, spricht man auch öfters von -Testen.

• Ausprobieren ist mit Testen gleichzusetzen, da das Ausprobieren oft nur ein Szenario umfasst und nicht systematisch abläuft.