Versandkostenrechner-Übungsaufgabe zur Testfallerstellung nach Whitebox-Systematik

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 „Versandkostenrechner-
Übungsaufgabe zur Testfallerstellung nach Whitebox-Systematik“.

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/zyklomatische-komplexitaet
- Stilbeispiel: https://oer-informatik.de/whitebox-testfall-uebung-shippingcost

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Whitebox-Test
- Anweisungsüberdeckung
- Zweigüberdeckung
- Kontrollflussgraph
- McCabe-Zahl
- Code-Coverage
- JaCoCo
- JUnit
- Short-Circuit-Evaluation

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.

Der Kontrollfluss lässt sich wie folgt darstellen (ausführlich kommentierte Fassung – eigentlich sind nur Knoten und Kanten erforderlich):

Eine kleine Gemeinheit hier ist die Short-Circuit-Evaluation (die zusammengesetzte Bedingung mit dem ||-Operator): Bei der Bedingung ((totalWeight >10) || (shippingCost >50)) wird der zweite Teil (shippingCost >50) nur ausgewertet, wenn der erste Teil (totalWeight >10) false ergibt. Wenn sich die Bedingungen lediglich aus Werten zusammensetzen, ist das unerheblich; sind die Bedingungen selbst Methodenaufrufe, beeinflusst das den Kontrollfluss jedoch entscheidend.

Der Kontrollfluss weist 5 binäre Verzweigungen auf, somit ergibt sich die McCabe-Zahl zu

M = b + 1 = 5 + 1 = 6

(Hinweis: Wenn man die Short-Circuit-Evaluation nicht einbezieht, sind es lediglich 4 binäre Verzweigungen und damit M = 5. JaCoCo kommt in der Spalte „Cxty“ ebenfalls auf 6, weil es jede Teilbedingung als eigene Verzweigung zählt.)

Die beiden Anweisungen shippingCost += 0.3; und shippingCost = 50; werden nicht erreicht (Knoten 4 und 10 im Kontrollflussgraphen). Insgesamt sind es – je nach Zählweise – 11 Anweisungen bzw. Anweisungsblöcke, die Anweisungsüberdeckung beträgt also 9 von 11 (9/11 ≈ 82 %).

Wie bei allen Überdeckungsmetriken gilt auch hier: Der Bruch ist aussagekräftiger als die Prozentzahl, weil man Einblicke in die Berechnung bekommt.

JaCoCo zählt die einzelnen Bytecode-Instruktionen und kommt auf 65 von 72 Instruktionen (≈ 90 %), bei den Zweigen auf 6 von 10 (60 %):

Im Detail werden folgende Zeilen/Zweige nicht erreicht:

Nicht erreicht werden die Zweige (pos.getQuantity()*pos.getWeight() < 0.5) (Kante c, Knoten 3) und else (Kante h, Knoten 5) sowie ((totalWeight >10) || (shippingCost >50)) (Kanten j und l zu Knoten 10). Insgesamt sind es 8 Zweige, von denen 3 nicht erreicht werden; wenn man die Short-Circuit-Bedingung (s. u.) bedenkt, sind es sogar 10 Zweige, von denen 4 nicht erreicht werden. Die Zweigüberdeckung beträgt also 5 von 8 (62,5 %) bzw. 6 von 10 (60 %).

Eine kleine Gemeinheit hier ist, dass bei der Bedingung ((totalWeight >10) || (shippingCost >50)) der zweite Teil (shippingCost >50) nur ausgewertet wird, wenn der erste Teil (totalWeight >10) false ergibt. Wenn sich die Bedingungen wie hier lediglich aus Werten zusammensetzen, ist das unerheblich.

Es wäre jedoch auch denkbar, dass die Bedingungsabfrage in Methoden ausgelagert wird:

if (istGewichtZuGross() || sindKostenUeberMaximum()) {...}

Nach dieser Refaktorisierung ändert sich der Kontrollfluss abhängig davon, ob die erste Bedingung als true ausgewertet wird oder nicht. sindKostenUeberMaximum() würde ggf. nie aufgerufen und müsste über einen weiteren Test gesondert überdeckt werden.

Es fehlen Tests für die beiden Anweisungen shippingCost += 0.3; und shippingCost = 50; (Knoten 4 und 10 im Kontrollflussgraphen). Um sie zu erreichen, benötigen wir eine sehr leichte und eine sehr schwere ShippingPosition.

Denkbar wäre, diese in einem einzigen Testfall zu übergeben:

ShippingPosition[] positions = {new ShippingPosition(2, 0.2), new ShippingPosition(1, 11)};

Jedoch überschreibt der Sperrgut-Versandpreis den Preis für leichte Lieferungen. Sinnvoller ist es also, beides gesondert zu testen (auch wenn die Aufgabenstellung hier eine Lösung in einem Test zuließe).

Zwei komplett ausgeschriebene Testfälle mit erwartetem Ergebnis wären:

    @Test
    void testShippingCostsLight() {
        //given
        ShippingPosition[] positions = {new ShippingPosition(2, 0.2)};

        //when
        double result = App.shippingCalculator(positions);

        //then
        double expected = 4.4;   // 3.9 + 0.3 + 0.2
        double delta = 0.001;    // Rundungsgenauigkeit: Schwankung 0.1ct sind ok
        assertEquals(expected, result, delta);
    }

    @Test
    void testShippingCostsHeavy() {
        //given
        ShippingPosition[] positions = {new ShippingPosition(1, 11)};

        //when
        double result = App.shippingCalculator(positions);

        //then
        double expected = 50;    // Sperrgut
        double delta = 0.001;    // Rundungsgenauigkeit: Schwankung 0.1ct sind ok
        assertEquals(expected, result, delta);
    }

Nach dem ersten Testfall in c) fehlten die Zweige (pos.getQuantity()*pos.getWeight() < 0.5) (Kante c, Knoten 3) und else (Kante h, Knoten 5) sowie ((totalWeight >10) || (shippingCost >50)) (Kanten j und l zu Knoten 10).

Mit den Testfällen aus d) sind beide Zweige von Knoten 3 komplett überdeckt (die leichte Lieferung) sowie die Kanten h und j (die schwere Lieferung).

Wenn wir die Short-Circuit-Bedingung außer Acht lassen, wären wir also bereits fertig, denn es fehlt nur noch diese Kante (l).

Wir benötigen also einen Testfall, bei dem das Gesamtgewicht höchstens 10 beträgt, die Versandkosten aber trotzdem über 50 liegen. Das gelingt mit vielen, sehr leichten Artikeln:

ShippingPosition[] positions = {new ShippingPosition(500, 0.001)};

Als ausgeschriebener Testfall mit erwartetem Ergebnis wäre das:

    @Test
    void testShippingManyPositions() {
        //given
        ShippingPosition[] positions = {new ShippingPosition(500, 0.001)};

        //when
        double result = App.shippingCalculator(positions);

        //then
        double expected = 50;    // 3.9 + 500*0.1 + 1.0 = 54.9 (Positionsgewicht 0.5 ist nicht < 0.5), begrenzt auf 50
        double delta = 0.001;    // Rundungsgenauigkeit: Schwankung 0.1ct sind ok
        assertEquals(expected, result, delta);
    }

Ein fertiges Maven-Projekt mit der Methode, den vier Testfällen aus c), d) und e) und eingebundenem JaCoCo-Plugin findest Du im Repository unter jacoco-metrik-shippingCost. Mit mvn test laufen die Tests, den Bericht legt JaCoCo unter target/site/jacoco/index.html ab.

Mit allen vier Testfällen meldet JaCoCo für shippingCalculator() 72 von 72 Instruktionen (100 %) und 10 von 10 Zweigen (100 %); die zyklomatische Komplexität (Spalte „Cxty“) beträgt 6. Nur der leere Standardkonstruktor App() und die leere main()-Methode werden nicht durchlaufen, deshalb zeigt die Klasse insgesamt 72 von 76 Instruktionen (≈ 94 %).

Aus dem Code ergeben sich je Position (Positionsgewicht = Menge * Gewicht) diese Äquivalenzklassen: Positionsgewicht unter 0.5 (Zuschlag 0.30), von 0.5 bis unter 2.5 (Zuschlag 1.00) und ab 2.5 (kein Zuschlag); dazu für die ganze Bestellung: Gesamtgewicht über 10 oder Versandkosten über 50 (Sperrgutpreis 50). Grenzwerte liegen bei 0.5, 2.5, 10 und 50.

Es werden zwar Versandkosten für Menge*Gewicht < 0.5 und Menge*Gewicht < 2.5 angesetzt, sobald der Wert aber 2.5 erreicht oder übersteigt, werden keine weiteren Kosten fällig (erst bei einem Gesamtgewicht über 10 gilt der Sperrgutpreis). Eine Bestellung mit einem Artikel des Gewichts 5 kostet so 4.00 Versand, eine mit einem Artikel des Gewichts 2 dagegen 5.00.

Whitebox-Tests können derartige Spezifikationsprobleme nicht aufdecken, hierzu ist eine gesonderte Blackbox-Betrachtung hilfreich: Das Aufstellen von Äquivalenzklassen deckt solche Lücken in der Spezifikation auf.