Übungsaufgaben zu Whitebox-Tests und Überdeckungsmaßen

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Whitebox-Tests und
Überdeckungsmaßen“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/codecoverage
- https://oer-informatik.de/blackboxtests
- https://oer-informatik.de/unit-tests
- https://oer-informatik.de/zyklomatische-komplexitaet
- Stilbeispiel: https://oer-informatik.de/whitebox-ueberdeckung-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Whitebox-Test
- Anweisungsüberdeckung
- Zweigüberdeckung
- Pfadüberdeckung
- Bedingungsüberdeckung
- Testabdeckung
- Unit-Test
- Softwaretest

Kompetenzstufe: Profilkompetenz (alternativ: Basiskompetenz, Kernkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Bei einem Whitebox-Test werden die Testfälle bzw. Testdaten anhand der inneren Struktur des Quelltextes (Anweisungen, Verzweigungen, Pfade) ausgewählt; die Testenden kennen den Code. Ziel ist, bestimmte Teile des Codes nachweislich zu durchlaufen (Überdeckung). Beim Blackbox-Test werden die Testfälle dagegen nur aus der Spezifikation abgeleitet.

Bewertung: Testdaten aus der Codestruktur 2 Punkte (auch „Code ist bekannt und wird gezielt durchlaufen“).

Mias Aussage stimmt nicht. Der Anweisungsüberdeckungsgrad setzt die Anweisungen, die bei den Tests überhaupt durchlaufen wurden, ins Verhältnis zu allen ausführbaren Anweisungen:

C_0 = \frac{\text{Anzahl der von den Tests ausgeführten Anweisungen}}{\text{Anzahl aller ausführbaren Anweisungen}}

checkIn() hat 12 ausführbare Anweisungen (01, 02, 03, 05, 06, 08, 09, 10, 12, 14, 15, 17); 75 % heißt also, dass 9 davon bei mindestens einem Test gelaufen sind und 3 noch nie. Über die Korrektheit sagt der Wert nichts: Auch eine ausgeführte Anweisung kann falsch rechnen, wenn kein Test das Ergebnis prüft. Er zeigt nur, welcher Code noch gar nicht getestet wurde.

Bewertung: Berechnungsvorschrift 1 Punkt, 9 von 12 Anweisungen 1 Punkt, Begründung „ausgeführt heißt nicht korrekt“ 1 Punkt.

Bewertung: je Testfall 2 Punkte (je fehlender oder falscher Anweisung 1 Punkt Abzug). Die Zeilen 04, 07, 11, 13 und 16 sind keine ausführbaren Anweisungen.

Geg.: ausführbare Anweisungen 01, 02, 03, 05, 06, 08, 09, 10, 12, 14, 15, 17, also n = 12; von T1 bis T3 ausgeführt: 01, 02, 03, 05, 06, 08, 09, 10, 14, 15, 17, also k = 11

Ges.: Anweisungsüberdeckungsgrad C_0

C_0 = \frac{k}{n}

C_0 = \frac{11}{12} \approx 0{,}917 = \underline{\underline{91{,}667\,\%}}

Bewertung: Anzahl aller Anweisungen 1 Punkt, Anzahl ausgeführter Anweisungen 1 Punkt, Ergebnis 1 Punkt. Folgefehler aus c) werden nicht erneut abgezogen.

Anweisung 12 (drucker.druckeBadge(a, "Teilnehmer*in")) wird nicht ausgeführt, weil kein Testfall eine Anmeldung prüft, deren Ticketart nicht „Referent“ ist und die noch nicht eingecheckt ist.

Bewertung: Anweisung 12 1 Punkt, Begründung 1 Punkt.

fa) T4 durchläuft 01, 02, 05, 08, 09, 12, 14, 15, 17 und führt damit auch Anweisung 12 aus.

Geg.: n = 12 Anweisungen, davon ausgeführt k = 12; vier binäre Verzweigungen (Zeilen 02, 05, 09, 14) mit z = 8 Zweigen

Ges.: Anweisungsüberdeckungsgrad C_0, Zweigüberdeckungsgrad C_1

C_0 = \frac{k}{n} = \frac{12}{12} = \underline{\underline{100\,\%}}

C_1 = \frac{\text{durchlaufene Zweige}}{z} = \frac{7}{8} = 0{,}875 = \underline{\underline{87{,}500\,\%}}

Bewertung: C_0 1 Punkt, C_1 2 Punkte.

fb) Die Verzweigung in Zeile 14 hat keinen sonst-Teil. Ihr nein-Zweig ist leer und enthält keine Anweisung, deshalb wird er für die Anweisungsüberdeckung nicht benötigt. Weil T3 und T4 beide einen Barrierefreiheitsbedarf haben, wurde nie getestet, ob die Methode auch ohne Benachrichtigung des Infostands richtig arbeitet.

Ergänzung: T5 mit "BC27S006" (Fatma Öztürk, Ticketart Schueler, kein Bedarf, noch nicht eingecheckt). Erwartetes Ergebnis: Badge „Teilnehmer*in“ wird gedruckt, der Infostand wird nicht benachrichtigt, Rückgabe "Willkommen, Fatma". Alternativ ist "BC27R013" (Marco Brenner, Referent ohne Bedarf; Badge „Referent*in“, "Willkommen, Marco") richtig. Begründung: Die Anmeldung muss existieren, darf noch nicht eingecheckt sein und darf keinen Barrierefreiheitsbedarf haben, damit Zeile 14 mit nein ausgewertet wird. "BC27R005" eignet sich nicht, weil die Methode schon in Zeile 06 endet.

Bewertung: Erklärung leerer Zweig 2 Punkte, passender Testfall mit erwartetem Ergebnis 1 Punkt, Begründung 1 Punkt.

Der Merge Request wird nicht angenommen.

• Regel 4.1: checkIn() gehört zum Paket checkin. Die Anweisungsüberdeckung liegt mit T1 bis T4 bei 100 %, die Zweigüberdeckung aber nur bei 87,5 % (siehe fa). Verlangt sind 100 %, also blockiert die Pipeline.
• Regel 4.2: Genau das fehlt: Das wenn in Zeile 14 hat keinen sonst-Teil, und kein Test wertet seine Bedingung mit nein aus.
• Regel 4.3: checkIn() enthält keine Schleife, also ist je Pfad ein Test nötig. Die Methode hat 6 Pfade (siehe h); T1 bis T4 durchlaufen nur 4 davon (unbekannt, bereits eingecheckt, Referent*in mit Bedarf, Teilnehmer*in mit Bedarf). In der Beschreibung fehlt außerdem die Liste der Pfade.
• Regel 4.4 ist erfüllt, weil jeder Test eine Assertion enthält.

Nachliefern muss Mia zwei Tests ohne Barrierefreiheitsbedarf – einen für eine Referent*in (z. B. "BC27R013") und einen für eine Teilnehmer*in (z. B. "BC27S006") – sowie die Liste der 6 Pfade in der Beschreibung. Mit den beiden Tests sind auch 100 % Zweigüberdeckung erreicht.

Bewertung: Entscheidung mit Regel 4.1 und Zahlenwert 2 Punkte, Bezug zu Regel 4.2 1 Punkt, Regel 4.3 mit fehlenden Pfaden 2 Punkte, passende Nachlieferung 1 Punkt.

ha) Die Verzweigungen in den Zeilen 02 und 05 beenden die Methode im ja-Fall sofort mit return. Jede von ihnen liefert deshalb genau einen eigenen Pfad und teilt den weiteren Ablauf nicht auf. Erst wenn beide mit nein durchlaufen werden, folgen die Verzweigungen in den Zeilen 09 und 14. Sie liegen unabhängig hintereinander, ihre Ausgänge lassen sich also beliebig kombinieren:

p = 1 + 1 + 2 \cdot 2 = \underline{\underline{6}}

Der Kontrollflussgraph zeigt die Struktur: Die beiden ja-Zweige der Zeilen 02 und 05 führen direkt zum Ende, erst danach verzweigt der Ablauf zweimal unabhängig voneinander.

16 Pfade gäbe es nur, wenn alle vier Verzweigungen hintereinander durchlaufen würden, ohne dass eine die Methode vorzeitig beendet. Zur Kontrolle die sechs Pfade (die Nummern werden in i) verwendet):

Bewertung: zwei vorzeitige Pfade 1 Punkt, Kombination der Zeilen 09 und 14 1 Punkt, Ergebnis 6 1 Punkt, Erläuterung zu 16 1 Punkt. Eine richtige Aufzählung aller Pfade mit Zählung ist ebenfalls volle Punktzahl wert.

hb)

Geg.: p = 6 Pfade; T1 durchläuft Pfad 1, T2 Pfad 2, T3 Pfad 3, T4 Pfad 5, T5 Pfad 6 (mit "BC27S006") bzw. Pfad 4 (mit "BC27R013"), also d = 5 verschiedene Pfade

Ges.: Pfadüberdeckungsgrad C_2

C_2 = \frac{d}{p}

C_2 = \frac{5}{6} \approx 0{,}833 = \underline{\underline{83{,}333\,\%}}

Es fehlt der Pfad, der Zeile 09 mit ja und Zeile 14 mit nein durchläuft (Referent*in ohne Barrierefreiheitsbedarf, Pfad 4), wenn T5 mit "BC27S006" gewählt wurde. Wurde T5 mit "BC27R013" gewählt, fehlt der Pfad mit Zeile 09 nein und Zeile 14 nein (Teilnehmer*in ohne Bedarf, Pfad 6).

Bewertung: Anzahl durchlaufener Pfade 1 Punkt, Ergebnis 1 Punkt, fehlender Pfad mit beiden Verzweigungsergebnissen 2 Punkte.

• Anweisungsüberdeckung: 4 Testfälle. Die Anweisungen 03 und 06 liegen auf Pfaden, die vorzeitig enden; dafür sind zwei eigene Testfälle nötig. Die Anweisungen 10 und 12 schließen sich gegenseitig aus, also werden zwei weitere Testfälle benötigt, die bis Zeile 17 laufen; Anweisung 15 kann in einem davon mit ausgeführt werden (z. B. Pfade 1, 2, 3 und 6).

• Zweigüberdeckung: 4 Testfälle. Wie oben braucht man zwei Testfälle für die ja-Zweige der Zeilen 02 und 05. Die beiden durchlaufenden Testfälle müssen zusammen die Zweige von Zeile 09 und Zeile 14 je einmal mit ja und nein abdecken, z. B. Pfade 3 und 6 oder Pfade 4 und 5.

• Pfadüberdeckung: 6 Testfälle, weil jeder Testfall genau einen Pfad durchläuft und es 6 Pfade gibt.

Bewertung: je Maß 1 Punkt für die Anzahl und 1 Punkt für die Begründung.

Für checkIn() ist eine Pfadüberdeckung machbar und sinnvoll: Die Methode hat keine Schleife, nur 6 Pfade und ist für den Einlass am Veranstaltungstag kritisch; Pfadtests prüfen auch die Kombinationen aus Ticketart und Barrierefreiheitsbedarf. Für die gesamte Software ist eine vollständige Pfadüberdeckung nicht realistisch, weil viele Methoden Schleifen enthalten (z. B. über alle Räume, Slots oder Anmeldungen) und jeder weitere Schleifendurchlauf neue Pfade erzeugt; die Zahl der Pfade ist praktisch unbegrenzt. Als verbindliches Mindestmaß bietet sich die Zweigüberdeckung an (wie in der Richtlinie aus g für die Pakete checkin und programm), ergänzt um Pfadtests für kurze, kritische Methoden und um Blackbox-Tests mit Grenzwerten.

Bewertung: Einschätzung für checkIn() mit Begründung 1 Punkt, Ablehnung für die gesamte Software mit Begründung (Schleifen) 1 Punkt, Vorschlag Zweigüberdeckung 1 Punkt. Andere schlüssig begründete Stellungnahmen sind möglich.

Geg.: ausführbare Anweisungen 01, 02, 03, 04, 05, 06, 07, 11, also n = 8; von T1 ausgeführt 01, 02, 03, 04, 05, 11, also k = 6

Ges.: Anweisungsüberdeckungsgrad C_0

C_0 = \frac{k}{n}

C_0 = \frac{6}{8} = 0{,}75 = \underline{\underline{75{,}000\,\%}}

Es fehlen die Anweisungen 06 und 07, weil in T1 kein Kostenbeitrag über seiner Grenze liegt (Angebot 1: 1,80 € bei einer Grenze von 1,86 €; Angebot 4: 1,70 € bei 1,79 €). Die Bedingung in Zeile 05 ist deshalb nie erfüllt.

Bewertung: Ergebnis mit Rechenweg 2 Punkte, Begründung über Zeile 05 1 Punkt.

Angebot 3 ist nicht abgesagt (Status „voll“) und hat eine Entfernung über 0 km, Zeile 03 ist also erfüllt. Die Grenze beträgt 15,2 km · 0,10 €/km = 1,52 €. Der Kostenbeitrag von 1,50 € liegt darunter, Zeile 05 ist nicht erfüllt. Die Anweisungen 06 und 07 laufen also wieder nicht, der Überdeckungsgrad von T1 und dem neuen Testfall zusammen bleibt bei 6/8 = 75\,\%. Der Vorschlag hilft nicht.

Bewertung: Grenze berechnet 1 Punkt, Vergleich mit dem Kostenbeitrag 1 Punkt, Schlussfolgerung 1 Punkt.

T2: Aufruf mit der Liste [Angebot 5].

Angebot 5 ist nicht abgesagt und 19,4 km entfernt, die Grenze liegt bei 19,4 km · 0,10 €/km = 1,94 €. Der Kostenbeitrag von 2,50 € ist höher, also werden 06 und 07 ausgeführt.

Erwartetes Ergebnis: eine Liste, die genau Angebot 5 enthält; Angebot 5 trägt danach den Hinweis „Kostenbeitrag über 0,10 € je km“.

Bewertung: passendes Angebot 1 Punkt, Begründung mit Grenze 1 Punkt, erwartetes Ergebnis 1 Punkt.

T1 und T2 führen zusammen alle 8 Anweisungen aus: C_0 = 8/8 = 100\,\%. Tatsächlich erreicht T2 die 100 % sogar allein, weil die Schleife schon bei einem einzigen Element jede Anweisung einmal durchläuft. Für die Anweisungsüberdeckung ist T1 also überflüssig.

Löschen sollte man ihn trotzdem nicht: Nur T1 prüft den Fall, dass ein Kostenbeitrag nicht zu hoch ist und das Angebot unmarkiert bleibt. Dieser leere sonst-Zweig von Zeile 05 enthält keine Anweisung und taucht in der Anweisungsüberdeckung deshalb nicht auf; ohne T1 würde ein Fehler, der jedes Angebot markiert, nicht bemerkt.

Bewertung: 100 % 1 Punkt, T2 allein genügt für C_0 1 Punkt, Begründung für den Erhalt von T1 1 Punkt.

ea)

Bewertung: je zwei richtige Zeilen 1 Punkt.

eb) T3: [Angebot 1, Angebot 4, Angebot 5, Angebot 7]. Gegenüber T1 und T2 kommt das abgesagte Angebot 7 hinzu; für dieses Angebot ist die Bedingung in Zeile 03 nicht erfüllt. Damit sind alle 6 Zweige durchlaufen (C_1 = 6/6 = 100\,\%). Erwartet wird eine Liste, die genau Angebot 5 enthält.

Ein Testfall genügt, weil die Schleife für jedes Angebot der Liste einmal durchlaufen wird und die verschiedenen Angebote dabei verschiedene Zweige nehmen. Kürzer geht es auch mit [Angebot 5, Angebot 7, Angebot 1].

Bewertung: passende Liste mit Angebot 7 1 Punkt, erwartetes Ergebnis 1 Punkt, Begründung über die Schleifendurchläufe 1 Punkt.

Die Zweigüberdeckung betrachtet nur das Gesamtergebnis der Bedingung in Zeile 03: Es genügt, dass sie einmal wahr und einmal falsch ist. Die Bedingungsüberdeckung verlangt, dass jede atomare Teilbedingung (a.getStatus() != "abgesagt" und a.getEntfernungKm() > 0) für sich einmal wahr und einmal falsch ausgewertet wird.

Mit den Testdaten aus eb) ist die erste Teilbedingung wahr (Angebote 1, 4, 5) und falsch (Angebot 7). Die zweite Teilbedingung ist nur wahr; bei Angebot 7 wird sie wegen der Kurzschlussauswertung von und gar nicht erst geprüft. Zusätzlich nötig ist daher ein nicht abgesagtes Angebot mit einer Entfernung von 0 km (z. B. ein eigens angelegtes Testangebot an einem Haltepunkt, dessen Entfernung fehlerhaft mit 0 km gepflegt ist). Erwartet wird, dass dieses Angebot nicht in der Ergebnisliste erscheint.

Bewertung: Unterschied 2 Punkte, zusätzliches Testangebot mit Begründung 2 Punkte.

Lösung in Java mit JUnit 5 bzw. in Python mit pytest (Pseudocode mit gleichem Aufbau ist ebenso richtig):

Java Python all none

@Test
void zuHoheBeitraege_markiertNurZuHohenBeitrag() {
    // given: Vorbereitung
    Angebot a1 = testdaten.angebot(1);
    Angebot a4 = testdaten.angebot(4);
    Angebot a5 = testdaten.angebot(5);
    Angebot a7 = testdaten.angebot(7);
    List<Angebot> angebote = List.of(a1, a4, a5, a7);

    // when: Ausführung
    List<Angebot> ergebnis = pruefung.zuHoheBeitraege(angebote);

    // then: Prüfung
    assertEquals(1, ergebnis.size());
    assertTrue(ergebnis.contains(a5));
    assertEquals("Kostenbeitrag über 0,10 € je km", a5.getHinweis());
    assertNull(a1.getHinweis());
    assertNull(a4.getHinweis());
    assertNull(a7.getHinweis());
}

def test_zu_hohe_beitraege_markiert_nur_zu_hohen_beitrag():
    # given: Vorbereitung
    a1 = testdaten.angebot(1)
    a4 = testdaten.angebot(4)
    a5 = testdaten.angebot(5)
    a7 = testdaten.angebot(7)
    angebote = [a1, a4, a5, a7]

    # when: Ausführung
    ergebnis = pruefung.zu_hohe_beitraege(angebote)

    # then: Prüfung
    assert ergebnis == [a5]
    assert a5.get_hinweis() == "Kostenbeitrag über 0,10 € je km"
    assert a1.get_hinweis() is None
    assert a4.get_hinweis() is None
    assert a7.get_hinweis() is None

Bewertung: Vorbereitung der Liste mit den vier Angeboten 1 Punkt, Aufruf der Methode 1 Punkt, Prüfung der Listenlänge bzw. des Inhalts 2 Punkte, Prüfung der Hinweise 1 Punkt, sinnvoller Testname bzw. Gliederung 1 Punkt.

Jeder Schleifendurchlauf kann auf drei Wegen verlaufen (Zeile 03 nicht erfüllt; Zeile 03 erfüllt und Zeile 05 nicht erfüllt; beide erfüllt). Bei einer Liste mit n Angeboten gibt es daher 3^n Pfade, schon bei bis zu zwei Angeboten 1 + 3 + 9 = 13. Da die Länge der Liste nicht begrenzt ist, ist die Zahl der Pfade unbegrenzt; eine vollständige Pfadüberdeckung ist nicht erreichbar und der Pfadüberdeckungsgrad nicht einmal bestimmbar.

Geeignet ist die Zweigüberdeckung: Sie ist mit einem einzigen Testfall vollständig erreichbar, prüft auch die leeren sonst-Zweige der Zeilen 03 und 05 und schließt die Anweisungsüberdeckung ein. Sinnvoll ergänzt wird sie durch Tests mit 0, 1 und mehreren Angeboten (leere Liste, ein Element, viele Elemente).

Bewertung: Begründung über die Schleife 2 Punkte, Zweigüberdeckung mit Begründung 2 Punkte.

Nein. Eine Zweigüberdeckung von 100 % zeigt nur, dass jeder Zweig durchlaufen wurde, nicht, dass die Methode richtig rechnet. Ob ein Fehler auffällt, hängt von den gewählten Testdaten und den Prüfungen (Assertions) ab.

Beispiel: Stünde in Zeile 05 versehentlich >= statt >, würde ein Kostenbeitrag von genau 0,10 € je km fälschlich als zu hoch markiert. Alle bisherigen Tests bestünden trotzdem, weil keines der Angebote genau auf der Grenze liegt (1,80 € < 1,86 €; 2,50 € > 1,94 €). Erst ein Grenzwerttest aus der Blackbox-Sicht, z. B. 1,94 € bei 19,4 km, deckt den Fehler auf. (Vorsicht bei der Umsetzung mit Gleitkommazahlen: 19,4 · 0,10 ergibt in Java und Python zwar genau den double-Wert von 1,94, 18,6 · 0,10 aber 1,8600000000000003. Ein Grenzwerttest mit 1,86 € bei 18,6 km fände den Fehler deshalb auch mit >= nicht. Geldbeträge rechnet man besser in ganzen Cent oder mit BigDecimal, und für Grenzwerttests wählt man Werte, deren Ergebnis man nachgeprüft hat, etwa 1,94 € bei 19,4 km oder 2,00 € bei 20 km.) Ebenso kann ein Whitebox-Test keine fehlende Anforderung finden: Angebote mit einer Entfernung von 0 km werden stillschweigend übergangen; ob sie stattdessen als Datenfehler gemeldet werden sollen, muss mit Andrea Wolf geklärt werden.

Bewertung: Stellungnahme mit Begründung 2 Punkte, passendes Beispiel 2 Punkte.