Block 05 · Testen & Qualitätssicherung

A · Erklärungssatz

Testen und Qualitätssicherung kommen in 8 von 9 Prüfungen vor, und zwar auf zwei Arten: In Teil 1 sind es meist Wissensfragen mit 3–6 Punkten (Testarten, Testkonzept, Qualitätsmerkmale, QS-Maßnahmen). In Teil 2 gibt es immer wieder eine komplette Aufgabe mit 20–25 Punkten, die nach demselben Drehbuch abläuft: Gegeben ist eine (fehlerhafte) Methode mit Zeilennummern und eine Spezifikation → Schreibtischtest mit Testdaten → Fehler mit Zeilennummer nennen → korrigieren → Fragen zu Unit-Test und Überdeckung (S22 T2 A2, S23 T2 A3, S24 T2 A3, W25 T2 A3). Diese Punkte sind gut planbar, weil das Vorgehen immer gleich ist.

TQ-01 · Testarten Meistens

Vorkommen: 7/9 · Prüfungen: W21, S22, W22, S23, W23, S24, W25 (fehlte nur in W24 und S26) · Teil 1 und Teil 2, meist 3–6 Punkte je Teilaufgabe

Warum testen? Grundbegriffe

Testen ist die geplante, nachvollziehbare Ausführung bzw. Prüfung eines Programms mit dem Ziel, Fehler zu finden und nachzuweisen, dass die Anforderungen erfüllt sind. Ein Test kann die Anwesenheit von Fehlern zeigen, aber nie ihre Abwesenheit beweisen (sinngemäß nach E. W. Dijkstra) – deshalb kommt es auf gut gewählte Testfälle an.

• Fehlhandlung (Irrtum des Entwicklers) → Fehlerzustand (der Defekt im Code, „Bug“) → Fehlerwirkung (das sichtbare Fehlverhalten beim Ausführen, „Failure“).
• Testen ≠ Debuggen: Testen deckt Fehlerwirkungen auf, Debuggen sucht und behebt die Ursache im Code.
• Testfall = Vorbedingungen + Eingabedaten + erwartetes Ergebnis (+ Nachbedingungen). Ohne vorher festgelegtes erwartetes Ergebnis ist es kein Test, sondern Ausprobieren.
• Verifikation („Bauen wir das Produkt richtig?“ – entspricht es der Spezifikation?) vs. Validierung („Bauen wir das richtige Produkt?“ – erfüllt es den tatsächlichen Zweck des Kunden?).

Teststufen und das V-Modell

Das V-Modell ordnet jeder Entwurfsphase (linker Ast) eine Teststufe (rechter Ast) zu. Die Testfälle einer Stufe werden aus dem Dokument derselben Ebene abgeleitet und prüfen gegen dieses Dokument.

Varianten des Abnahmetests: Alpha-Test (künftige Nutzer testen beim Hersteller), Beta-Test (ausgewählte Nutzer testen in ihrer eigenen Umgebung vor der allgemeinen Freigabe).

Statisch und dynamisch, Black-Box und White-Box

Grey-Box-Test: Mischform – Testfälle aus der Spezifikation, aber mit Wissen über die innere Struktur (z. B. beim Integrationstest die Schnittstellen kennen).

Weitere Testarten

Funktionale Tests prüfen, was das System tut (Ergebnisse). Nicht-funktionale Tests prüfen, wie gut es das tut (Last, Usability, Sicherheit, Kompatibilität) – das sind genau die Qualitätsmerkmale aus TQ-04.

Manuell oder automatisiert?

Testkonzept / Testplan

Das Testkonzept (Testplan, vgl. IEEE 829 bzw. ISO/IEC/IEEE 29119) legt vor dem Testen fest, was, wie, womit, von wem und wann getestet wird. Typische Inhalte:

• Testobjekte und Testumfang: welche Komponenten/Funktionen getestet werden – und welche ausdrücklich nicht.
• Testziele und Teststrategie: welche Teststufen, welche Testmethoden (Black-/White-Box, Überdeckungsgrad z. B. 80 % Zweigüberdeckung), Priorisierung nach Risiko.
• Testumgebung: Hardware, Software, Testdatenbank, Geräte, Netz; Art und Umfang der Testautomatisierung und der Werkzeuge.
• Testdaten: Herkunft, Anonymisierung (keine echten personenbezogenen Daten!), Bereitstellung.
• Rollen und Verantwortlichkeiten: wer testet was (Testplan: wer, was, wann, in welchem Umfang).
• Zeitplan, Aufwands- und Kostenschätzung, Abstimmung mit den übrigen Projektaktivitäten.
• Eingangs- und Endekriterien (wann darf der Test beginnen, wann ist genug getestet, z. B. „keine offenen Fehler der Klasse 1“), Abbruch- und Wiederaufnahmekriterien.
• Fehlermanagement: Fehlerklassen (kritisch/schwer/leicht), Meldeweg, Werkzeug (Ticketsystem).
• Testdokumentation: Testfallbeschreibungen, Testprotokolle, Testbericht; Vorlagen (Templates); wie die Ergebnisse ausgewertet werden.
• Risiken des Testprojekts und Gegenmaßnahmen.

Aufbau eines Testfalls (z. B. im Testprotokoll): ID · Testobjekt · Vorbedingung · Eingabe/Testschritte · erwartetes Ergebnis · tatsächliches Ergebnis · Status (bestanden/fehlgeschlagen) · Tester, Datum.

Konformität zu einer Spezifikation prüfen

Wenn ein System eine fremde, vorgegebene Spezifikation erfüllen muss (Datenformat, Norm, Schnittstelle eines Partners, z. B. die eRechnung in W25), reicht es nicht, „irgendwie“ zu testen:

• Formale Validierung gegen das maschinenlesbare Schema (XSD bei XML, JSON-Schema bei JSON) – automatisiert bei jeder erzeugten Datei.
• Testfälle systematisch aus der Spezifikation ableiten (Black-Box) – jede Regel, jedes Pflichtfeld, jeder Sonderfall bekommt einen Testfall; Rückverfolgbarkeit Anforderung ↔ Testfall.
• Offizielle Prüfwerkzeuge, Referenz- und Beispieldateien des Herausgebers nutzen (Validatoren, Testsuiten); Ausgaben mit Referenzausgaben vergleichen.
• Integrationstest mit der Gegenstelle in deren Testumgebung, ggf. Zertifizierung/Abnahme durch den Partner.

TQ-02 · Code analysieren / Fehler finden Meistens

Vorkommen: 6/9 · Prüfungen: W21 (Struktogramm checkPassword, 3 Fehler), S22 (fehlerhafte Bedingungen), W22 (rekursive Funktion), S23 (Monatsstatistik, 13 P Korrektur), S24 (Pfade notieren), W25 (fehlerhafte Minimum-Funktion) · meist Teil 2

Fehlerarten

Das Wort „semantisch“ (W25 T2 A3bb: „zwei semantische Fehler“) meint genau diese Logikfehler: Der Code ist syntaktisch korrekt, bedeutet aber etwas anderes, als gemeint war.

Katalog der typischen Fehler in Prüfungsaufgaben

So gehst du vor

1. Spezifikation lesen und für die gegebenen Testdaten das erwartete Ergebnis selbst ausrechnen (ohne auf den Code zu schauen).
2. Schreibtischtest (TQ-05) mit denselben Testdaten: Code Zeile für Zeile durchspielen, Variablenwerte notieren → tatsächliches Ergebnis.
3. Abweichung? Die Stelle finden, an der die Werte zum ersten Mal von deiner Erwartung abweichen.
4. Den Katalog oben durchgehen: Initialisierung, Schleifengrenzen, Vergleiche, Formel, Rückgabe, Sonderfälle, Gruppenwechsel.
5. Jeden Fehler mit Zeilennummer, Ursache und Auswirkung benennen und die korrigierte Zeile vollständig hinschreiben (bei fehlenden Anweisungen: „nach Zeile 18 einfügen: …“).
6. Korrektur mit den Testdaten erneut prüfen (gedanklicher Fehlernachtest) und an einen Randfall denken (leer, ein Element, negativ).

Beispiel (Wetterstation): Die Funktion soll die höchste Temperatur eines Tages liefern. Es gibt mindestens einen Messwert, Werte können negativ sein.

01 funktion hoechstwert(werte : double[]) : double
02   max : double := 0
03   zähle i von 0 bis werte.length
04     wenn werte[i] > max dann
05       max := werte[i]
06     Ende wenn
07     rückgabe max
08   Ende zähle
09 Ende funktion

Hinweis: Der Fehler in Zeile 03 fällt mit diesen Testdaten gar nicht auf, weil Zeile 07 die Schleife vorher beendet. Fehler können sich gegenseitig verdecken – nach jeder Korrektur erneut testen.

Gruppenwechsel erkennen

Viele Auswertungen (Statistik je Monat, je Filiale, je Kurs) laufen über eine nach dem Gruppenbegriff sortierte Liste. Das Muster: Gruppenbegriff des ersten Elements merken; in der Schleife bei einem Wechsel die bisherige Gruppe auswerten, Gesamtwerte fortschreiben, alle Gruppenvariablen zurücksetzen und den neuen Gruppenbegriff merken; danach das aktuelle Element verarbeiten; nach der Schleife die letzte Gruppe auswerten. Beim Prüfen eines solchen Codes gezielt fragen: Wird jede Gruppenvariable zurückgesetzt? Wird die letzte Gruppe ausgegeben? Werden die Gesamtwerte durch die richtige (Gesamt-)Anzahl geteilt? Was passiert bei leerer Liste (Zugriff auf das erste Element)?

TQ-03 · Unit-Test / Überdeckungsmaße Oft

Vorkommen: 5/9 · Prüfungen: S22, W22, S23, S24, W25 · fast immer Teil 2, oft als Teil einer 20–25-Punkte-Testaufgabe

Was ist ein Unit-Test?

Ein Unit-Test (Komponenten-, Modultest) ist ein automatisierter Test der kleinsten testbaren Einheit eines Programms – meist einer Methode oder Klasse – isoliert vom Rest des Systems. Er ruft die Einheit mit festgelegten Eingaben auf und vergleicht das tatsächliche mit dem erwarteten Ergebnis. Unit-Tests werden von den Entwicklern selbst geschrieben, meist mit einem Framework (Java: JUnit, C#: NUnit/xUnit, Python: unittest/pytest).

Wozu? Fehler früh und genau lokalisiert finden (man weiß, welche Methode fehlschlägt) · bei jeder Änderung automatisch erneut ausführen (Regressionstest, z. B. in der CI-Pipeline) · Absicherung beim Refactoring · ausführbare Dokumentation, wie eine Methode benutzt wird · zwingt zu testbarem, lose gekoppeltem Design.

Weitere Merkmale guter Unit-Tests: ein Test prüft genau einen Sachverhalt (aussagekräftiger Name wie leererWarenkorbKostetNichts), lesbar, wartbar, deckt Normal-, Grenz- und Fehlerfälle ab.

Stub = Platzhalter, der feste Antworten liefert (z. B. statt der Datenbank immer drei Testkunden). Mock = Platzhalter, der zusätzlich prüft, ob und wie er aufgerufen wurde. Testtreiber = Code, der die zu testende Einheit aufruft (bei JUnit: die Testklasse).

Aufbau: Arrange – Act – Assert

Jede Testmethode folgt demselben Dreischritt: Arrange (Vorbereiten: Objekte anlegen, Ausgangszustand und Testdaten herstellen) → Act (Ausführen: genau die zu testende Methode aufrufen) → Assert (Prüfen: tatsächliches mit erwartetem Ergebnis vergleichen). Beispiel aus einem Bank-Szenario:

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class KontoTest {

    @Test
    void einzahlungErhoehtKontostand() {
        Konto konto = new Konto(100.00);                  // Arrange
        konto.einzahlen(50.00);                           // Act
        assertEquals(150.00, konto.getStand(), 0.001);    // Assert (Delta bei double)
    }

    @Test
    void negativeAbhebungWirdAbgelehnt() {
        Konto konto = new Konto(100.00);                  // Arrange
        assertThrows(IllegalArgumentException.class,      // Act + Assert:
                     () -> konto.abheben(-20.00));        // erwartete Exception
    }
}

Test-Driven Development (TDD)

Vorteile: jede Zeile Code ist durch einen Test begründet (hohe Abdeckung), Anforderungen werden vorab präzisiert, kleine Schritte, sicheres Refactoring. Nachteile: anfangs mehr Aufwand, Disziplin nötig, bei unklaren Anforderungen oder GUI-lastigem Code schwierig.

Kontrollflussgraph

White-Box-Überdeckungsmaße werden am Kontrollflussgraphen erklärt: Knoten = Anweisungen bzw. Bedingungen (oft mit Zeilennummer beschriftet), Kanten = mögliche Übergänge. Eine Bedingung hat zwei ausgehende Kanten (wahr/falsch) – auch ein wenn ohne sonst: Seine falsch-Kante führt direkt hinter das Ende wenn.

01 funktion versandkosten(gewicht : double,
         express : boolean) : double
02   kosten : double := 4.90
03   wenn gewicht > 10 dann
04     kosten := kosten + 6.00
05   Ende wenn
06   wenn express dann
07     kosten := kosten + 8.00
08   Ende wenn
09   rückgabe kosten
10 Ende funktion

Die drei Überdeckungsmaße

Ergänzend gibt es die Bedingungsüberdeckung (condition coverage): Bei zusammengesetzten Bedingungen wie a > 0 und b > 0 muss jede Teilbedingung einmal wahr und einmal falsch werden (Mehrfachbedingungsüberdeckung: alle Kombinationen). Achtung Bezeichnung: In deutschen Lehrbüchern steht C2 meist für Pfad-, C3 für Bedingungsüberdeckung; manche englischen Quellen nummerieren anders. In der Prüfung werden die Begriffe ausgeschrieben.

So bestimmst du die Mindestanzahl der Testfälle

1. Kontrollflussgraph skizzieren oder im Code jede Bedingung (B1, B2 …) und jede Anweisung im Zweig (A1, A2 …) markieren – so macht es auch die IHK (S24 T2 A3c).
2. C0: Welche Anweisungen schließen sich gegenseitig aus (z. B. dann- und sonst-Teil derselben Bedingung, oder ein Zweig, in dem man früh mit rückgabe/Exception aussteigt)? Mindestens so viele Testfälle wie sich gegenseitig ausschließende Anweisungsgruppen; dann so kombinieren, dass jeder Testfall möglichst viele Anweisungen mitnimmt.
3. C1: Zusätzlich muss jede Bedingung auch ihren „leeren“ falsch-Zweig nehmen. Gezielt prüfen, ob die bisherigen Testfälle jede Bedingung einmal wahr und einmal falsch machen.
4. C2: Pfade zählen. Faustregel ohne Schleifen: nacheinander stehende, unabhängige Verzweigungen → Pfadzahlen multiplizieren (2 · 2 = 4); alternative Zweige (dann/sonst, verschachtelt) → Pfadzahlen der Zweige addieren. Danach die Pfade einzeln aufschreiben und zählen.
5. Testdaten angeben, die genau diesen Pfad erzwingen, und prüfen, ob der Pfad überhaupt möglich ist (manche Kombinationen sind logisch unmöglich).

Schleifen: Jede weitere Wiederholung erzeugt einen neuen Pfad – vollständige Pfadüberdeckung ist dann praktisch unmöglich. Man begrenzt sich z. B. auf Schleife 0-mal, 1-mal und mehrmals durchlaufen (Boundary-Interior-Test). Für C0 und C1 reicht oft ein Testfall, der die Schleife mehrmals durchläuft, plus einer, der sie nicht betritt.

Englische Begriffe (kommen im Fachtext vor, S24): statement coverage, branch coverage / decision coverage, path coverage, condition coverage, test case, test suite, assertion, expected/actual result, coverage tool, executed / not executed.

TQ-04 · Qualitätsmerkmale ISO/IEC 25010 Oft

Vorkommen: 4/9 · Prüfungen: W21 (Effizienz und Änderbarkeit), S23 (Qualitätsmerkmale nach ISO 9126!), S24 (Qualität/QS-Maßnahmen), S26 (Zuverlässigkeit + weiteres Merkmal) · Teil 1, 4–5 Punkte

Die Norm ISO/IEC 25010 („SQuaRE“, Nachfolger der ISO/IEC 9126) beschreibt ein Produktqualitätsmodell: Software-Qualität wird in Merkmale und Untermerkmale zerlegt, damit man sie beschreiben, als nicht-funktionale Anforderung festlegen und prüfen kann. Die Fassung von 2011 hat 8 Merkmale:

Neben dem Produktqualitätsmodell definiert die Norm die Nutzungsqualität (quality in use): Effektivität, Effizienz, Zufriedenheit, Freiheit von Risiken, Kontextabdeckung – also die Qualität, die der Nutzer im tatsächlichen Einsatz erlebt.

Ältere Norm ISO/IEC 9126 und Neufassung 2023

Jedes 9126-Merkmal hat zusätzlich das Untermerkmal „Konformität“ (Einhaltung von Normen). Neu als eigene Hauptmerkmale in 25010: Sicherheit und Kompatibilität.

ISO/IEC 25010:2023 erweitert auf 9 Merkmale: Benutzbarkeit heißt nun Interaktionsfähigkeit (interaction capability, u. a. mit Inklusivität und Selbstbeschreibungsfähigkeit), Übertragbarkeit heißt Flexibilität (neu mit Skalierbarkeit), Reife heißt Fehlerfreiheit (faultlessness), Sicherheit erhält „Widerstandsfähigkeit“ (resistance), und neu ist Safety (Betriebssicherheit: Schutz von Menschen und Umwelt, z. B. sicherer Zustand bei Ausfall, Gefahrenwarnung). Die bisherigen Prüfungen haben die Begriffe der Fassung 2011 (bzw. sogar der ISO 9126) verwendet – lerne diese sicher und kenne die Umbenennungen.

Qualitätsanforderungen messbar machen

„Die App soll schnell und zuverlässig sein“ ist nicht prüfbar. Eine Qualitätsanforderung braucht eine Messgröße, einen Zielwert und Messbedingungen:

Verfügbarkeit = MTBF ÷ (MTBF + MTTR). Rechenbeispiel: 99,5 % pro Monat mit 30 Tagen erlaubt 0,5 % · 30 · 24 h = 3,6 h Ausfall.

Zielkonflikte zwischen Merkmalen sind typisch und müssen abgewogen werden: Sicherheit ↔ Benutzbarkeit (Zwei-Faktor-Anmeldung ist sicherer, aber umständlicher), Leistungseffizienz ↔ Wartbarkeit (hoch optimierter Code ist schwerer verständlich), Übertragbarkeit ↔ Leistung (plattformübergreifendes Framework statt nativer App), Sicherheit ↔ Leistung (Verschlüsselung kostet Rechenzeit).

TQ-05 · Schreibtischtest Oft

Vorkommen: 4/9 · Prüfungen: S22 (assertEquals-Fälle durchrechnen), W22 (rekursive Umwandlung Dezimal → Binär), S23 (Datenverlaufstabelle zur Monatsstatistik), W25 (erwartetes und tatsächliches Ergebnis für fünf Testdaten, 10 P) · Teil 2

Beim Schreibtischtest (Trockentest, „dry run“) spielt man einen Algorithmus von Hand ohne Computer mit konkreten Testdaten durch und notiert nach jedem Schritt die Werte aller Variablen in einer Tabelle. Weil das Programm dabei nicht ausgeführt wird, zählt er zu den statischen Prüfverfahren. Er dient dazu, die Arbeitsweise zu verstehen, das tatsächliche Ergebnis zu ermitteln und so Logikfehler zu finden.

Drei Tabellenformen, die in Prüfungen vorkommen

1. Trace-Tabelle (am häufigsten): eine Spalte je Variable bzw. Bedingung, eine Zeile je Schritt oder Schleifendurchlauf.
2. Datenverlaufstabelle (S23): eine Zeile je Variable, in der Spalte „Werteverlauf“ alle Werte nacheinander, durch Kommas getrennt.
3. Testtabelle (W25): je Zeile ein Satz Testdaten mit erwartetem (aus der Spezifikation) und tatsächlichem Ergebnis (aus dem Code).

So gehst du vor

1. Alle Variablen (auch Laufvariablen) als Spalten anlegen; bei Bedarf eine Spalte für das Ergebnis jeder Bedingung (wahr/falsch).
2. Erste Zeile: Anfangswerte nach der Initialisierung.
3. Den Code Zeile für Zeile ausführen – nicht „im Kopf abkürzen“. Bei jeder Zuweisung den neuen Wert eintragen; unveränderte Werte darf man in der Trace-Tabelle wiederholen oder leer lassen (Hauptsache eindeutig).
4. Schleifen: Bedingung vor jedem Durchlauf prüfen (bei zähle: ist der Endwert erreicht?). Die Laufvariable ändert sich erst am Ende des Durchlaufs.
5. Integer-Rechnung beachten (7 div 2 = 3, 7 mod 2 = 1, in Java 7 / 2 = 3).
6. Am Ende Rückgabewert/Ausgabe angeben und mit dem erwarteten Ergebnis vergleichen.

Beispiel Schleife – Anzahl der Anstiege in einer Messreihe:

01 funktion zaehleAnstiege(werte : integer[]) : integer
02   anzahl : integer := 0
03   zähle i von 1 bis werte.length - 1
04     wenn werte[i] > werte[i - 1] dann
05       anzahl := anzahl + 1
06     Ende wenn
07   Ende zähle
08   rückgabe anzahl
09 Ende funktion

Rückgabe: 3. Dieselbe Rechnung als Datenverlaufstabelle:

Beispiel verschachtelte Schleifen: Die innere Schleife läuft bei jedem Durchlauf der äußeren vollständig ab. Variablen, die in der äußeren Schleife initialisiert werden, beginnen bei jedem äußeren Durchlauf neu.

01 summe : integer := 0
02 zähle i von 0 bis 2
03   zähle j von i bis 2
04     summe := summe + j
05   Ende zähle
06 Ende zähle

Beispiel Rekursion: eine Zeile je Aufruf; erst alle Aufrufe nach unten bis zum Basisfall notieren, dann die Rückgabewerte von unten nach oben einsetzen. Euklidischer Algorithmus ggT(a, b): wenn b = 0 dann rückgabe a sonst rückgabe ggT(b, a mod b).

TQ-06 · Äquivalenzklassen / Testfälle Wahrscheinlich

Vorkommen: 3/9 · Prüfungen: S22 (Testdaten aus zwei weiteren Äquivalenzklassen), S23 (Testdaten für volle Anweisungsüberdeckung anpassen), W25 (Testdaten mit Sonderfällen) · Teil 2, 4–10 Punkte

Alle möglichen Eingaben zu testen ist unmöglich (schon ein int-Parameter hat über 4 Milliarden Werte). Man braucht deshalb wenige, aber gut gewählte Testfälle. Die beiden wichtigsten Black-Box-Verfahren:

Äquivalenzklassenbildung

Der Wertebereich jeder Eingabe wird in Äquivalenzklassen (ÄK) zerlegt: Mengen von Werten, für die sich das Programm laut Spezifikation gleich verhält. Man nimmt an: Findet ein Wert der Klasse einen Fehler, finden ihn alle; findet einer keinen, findet ihn keiner. Deshalb genügt ein Repräsentant je Klasse.

• Gültige ÄK: zulässige Eingaben, die zu einem regulären Ergebnis führen – je unterschiedlichem Verhalten (z. B. je Tarifstufe) eine eigene Klasse.
• Ungültige ÄK: unzulässige Eingaben, die abgewiesen werden müssen (Fehlermeldung, Exception, Rückgabe −1).
• Regeln: Wertebereich (z. B. 1–99) → 1 gültige + 2 ungültige (zu klein, zu groß). Aufzählung (z. B. Land ∈ {DE, AT, CH}) → je Wert mit eigenem Verhalten eine gültige + 1 ungültige (anderer Wert). Formale Fehler: falscher Typ (Text statt Zahl, Kommazahl statt Ganzzahl), leere Eingabe, null → je eine ungültige Klasse.

Grenzwertanalyse

Fehler sitzen besonders oft an den Rändern der Klassen (< statt <=, Off-by-one). Deshalb testet man zusätzlich die Grenzwerte: den Wert genau auf der Grenze und den direkt benachbarten Wert auf der anderen Seite (bei Ganzzahlen ±1, bei Beträgen ±0,01). Für den Bereich 1–99: 0, 1, 99, 100 (strenge Variante zusätzlich 2 und 98).

Beispiel: Notenschlüssel – eine Funktion note(punkte : integer) : integer rechnet 0–100 Punkte in eine Note um (1: 92–100, 2: 81–91, 3: 67–80, 4: 50–66, 5: 30–49, 6: 0–29), sonst Fehlermeldung.

Ergebnis: 9 Testfälle aus Äquivalenzklassen plus 14 Grenzwerte (einige fallen zusammen, z. B. 0 und 100 sind gleichzeitig Repräsentanten).

Mehrere Parameter – Beispiel Online-Shop versandpreis(gewichtKg : double, land : string): Gewicht > 0 bis 31,5 kg in drei Preisstufen (bis 2 kg, bis 10 kg, darüber), Land ∈ {„DE“, „AT“, „CH“}. Testfalltabelle nach der Regel „gültige kombinieren, ungültige einzeln“:

Weitere Hinweise zur Testfallauswahl

• Sonderfälle immer mitdenken: null, leeres Array/leere Liste/leerer Text, genau ein Element, alle Werte gleich, Maximum am Anfang oder Ende, negative Werte, sehr große Werte, Sonderzeichen und Umlaute.
• Entscheidungstabelle: Wenn das Ergebnis von Kombinationen mehrerer Bedingungen abhängt, werden alle Kombinationen (Regeln) als Spalten aufgelistet; jede Regel ergibt einen Testfall.
• Testdaten für eine Überdeckung (White-Box, S23): Für jede noch nicht ausgeführte Anweisung überlegen, welche Bedingung dafür wahr bzw. falsch sein muss, und einen Datensatz so ändern oder ergänzen, dass genau dieser Fall eintritt. Die Änderung begründen („damit die Bedingung in Zeile … erfüllt ist“).
• Ein Testfall ist nur vollständig mit erwartetem Ergebnis, das aus der Spezifikation stammt – nicht aus dem (vielleicht fehlerhaften) Code.

TQ-07 · Codequalität / Reviews Wahrscheinlich

Vorkommen: 2/9 · Prüfungen: W21 (Dokumentation einer Bibliothekserweiterung; Bewertung „nur automatische Code-Reviews und Unit-Tests“), S24 (drei qualitätssichernde Maßnahmen) · dazu S23 T1 A1e (QS-Maßnahmen) · Teil 1, 4–6 Punkte

Qualitätssicherung im Entwicklungsprozess

Für die Prüfung gilt: Eine Maßnahme erläutern heißt, sie zu benennen und zu beschreiben, wie sie die Qualität verbessert (z. B. „Code-Reviews: Jede Änderung wird vor dem Zusammenführen von einem zweiten Entwickler geprüft; so werden Logikfehler und Verstöße gegen Richtlinien früh gefunden und das Wissen im Team verteilt“).

Code-Review

Beim Code-Review lesen und bewerten andere Entwickler den Code, bevor er übernommen wird (Vier-Augen-Prinzip). Heute meist als Pull-Request-/Merge-Request-Review im Git-Workflow.

Pair Programming: Zwei Entwickler arbeiten an einem Rechner; der Driver schreibt den Code, der Navigator prüft laufend, denkt voraus und achtet auf Fehler; die Rollen wechseln regelmäßig. Es ist damit ein „Review in Echtzeit“. Vorteile: weniger Fehler, besseres Design, Wissensverteilung, schnelle Einarbeitung neuer Kollegen. Nachteile: zwei Personen für eine Aufgabe (höherer Personalaufwand), anstrengend, Paare müssen harmonieren.

Statische Codeanalyse und Metriken

Werkzeuge wie SonarQube, Checkstyle, SpotBugs oder ESLint („Linter“) untersuchen den Quelltext automatisch – meist in der IDE und in der CI-Pipeline bei jedem Commit.

Metriken: Codezeilen (LOC) · zyklomatische Komplexität nach McCabe = Anzahl der binären Entscheidungen + 1 (bzw. Kanten − Knoten + 2 im Kontrollflussgraphen); Werte über 10 gelten als schwer test- und wartbar; die Zahl ist zugleich eine obere Grenze für die Testfälle, die man für vollständige Zweigüberdeckung braucht · Testabdeckung · Anteil duplizierten Codes · Kopplung zwischen Klassen.

Konventionen und Dokumentation

• Java-Namenskonventionen: Klassen PascalCase (Kunde), Methoden und Variablen camelCase (berechneSumme, anzahlKunden), Konstanten UPPER_SNAKE_CASE (MAX_VERSUCHE), Pakete klein. Methoden mit Verb, boolesche Methoden mit ist…/hat….
• Einheitliche Einrückung, geschweifte Klammern auch bei einzeiligen ifs, eine Anweisung pro Zeile, begrenzte Zeilenlänge.
• Kommentare erklären das Warum (Grund einer Entscheidung, fachliche Regel), nicht das Was, das schon im Code steht. Veraltete Kommentare sind schlimmer als keine.
• Javadoc für öffentliche Klassen und Methoden; daraus wird eine HTML-API-Dokumentation erzeugt. Wichtige Tags: @param (Parameter), @return (Rückgabewert), @throws (ausgelöste Exception), @author, @version, @since, @see, @deprecated.
• Zur Dokumentation einer Bibliothek bzw. Bibliothekserweiterung (W21) gehören außerdem: README mit Zweck, Installation und Einbindung, Anwendungsbeispiele, Beschreibung der Schnittstellen (API-Doku), Änderungshistorie (Changelog) mit Versionsnummern, Hinweise zu Abhängigkeiten und Lizenz.

/**
 * Prüft, ob ein Jahr nach dem gregorianischen Kalender ein Schaltjahr ist.
 *
 * @param jahr Jahreszahl, muss größer als 1582 sein
 * @return true, wenn das Jahr ein Schaltjahr ist, sonst false
 * @throws IllegalArgumentException wenn jahr kleiner oder gleich 1582 ist
 * @since 1.2
 */
public static boolean istSchaltjahr(int jahr) { … }

Clean Code

Vorher

// berechnet
double b(double n) {
    return n + n * 0.19;   // n plus 19 %
}

Nachher

private static final double MWST_SATZ = 0.19;

/** Liefert den Bruttobetrag zum Nettobetrag (Regelsteuersatz). */
double bruttoBetrag(double nettoBetrag) {
    return nettoBetrag * (1 + MWST_SATZ);
}

Refactoring = Struktur verbessern, ohne das Verhalten zu ändern. Voraussetzung sind Tests (Regressionstest), die vorher und nachher grün sind.

Automatische Prüfungen allein – reicht das?

Jedes Verfahren hat einen „blinden Fleck“: Statische Analyse prüft Form und bekannte Muster, aber keine Fachlogik. Unit-Tests prüfen nur, was jemand als Testfall formuliert hat, und nur einzelne Einheiten – nicht das Zusammenspiel, nicht Last, Bedienbarkeit oder die Anforderungen des Kunden. Eine hohe Testabdeckung sagt nichts über die Qualität der Assertions. Menschliche Reviews erkennen Verständlichkeit, Design- und Anforderungsfehler, verteilen Wissen – sind aber langsamer und nicht vollständig. In der Praxis werden die Verfahren deshalb kombiniert: Automatik als schnelles, lückenloses Sicherheitsnetz in der CI-Pipeline, Reviews und höhere Teststufen für das, was Automatik nicht sieht.

B · Belegsatz

Enthält nur, was dir auch die IHK beilegen würde bzw. was in der Prüfung auf einem heraustrennbaren Blatt stünde: die Pseudocode-Konventionen (wie im Belegsatz S24) und die Anlagen zur Ausgangssituation (Spezifikationen, Code-Listings mit Zeilennummern, Testdaten, englischer Fachtext). Eine Notationshilfe speziell zum Testen legt die IHK nicht bei. Keine Erklärungen.

Pseudocode, prozedurale Programmierung

wenn [ Bedingung ] dann
   [ Anweisung ]
sonst
   [ Anweisung ]
Ende wenn

zähle [ Variable ] von [ Startwert ] bis [ Endwert ]
   [ Schleifeninhalt ]
Ende zähle

solange [ Bedingung ]
   [ Schleifeninhalt ]
Ende solange

wiederhole
   [ Schleifeninhalt ]
solange [ Bedingung ]

:=

=; <; >; <=; >=; <>

integer
double
string
boolean
array

In den Listings dieses Blocks gilt außerdem: und, oder, nicht sind logische Operatoren (Auswertung von links nach rechts; steht das Ergebnis fest, wird der Rest nicht mehr ausgewertet); / ist die normale Division (Ergebnis Kommazahl); ausgabe(text) gibt eine Zeile aus, + verkettet dabei Zeichenketten; rückgabe beendet die Funktion. Die Zeilennummern gehören nicht zum Code.

01 public double beitrag(int alter, String tarif) {
02     if (alter < 14 || alter > 120) {
03         throw new IllegalArgumentException("Alter ungültig");
04     }
05     double grundbeitrag;
06     if (tarif.equals("BASIC")) {
07         grundbeitrag = 29.90;
08     } else if (tarif.equals("PREMIUM")) {
09         grundbeitrag = 49.90;
10     } else {
11         throw new IllegalArgumentException("Tarif unbekannt");
12     }
13     if (alter <= 17) {
14         return grundbeitrag * 0.5;
15     }
16     if (alter > 65) {
17         return grundbeitrag * 0.8;
18     }
19     return grundbeitrag;
20 }

01 prozedur kursStatistik(termine : List<Termin>)
02   ausgabe("Kursstatistik")
03   kurs : string := termine.get(0).getKurs()
04   anzahl : integer := 0
05   summe : integer := 0
06   max : integer := 0
07   anzahlGesamt : integer := 0
08   summeGesamt : integer := 0
09   zähle i von 0 bis termine.size() - 1
10     t : Termin := termine.get(i)
11     wenn t.getKurs() <> kurs dann
12       ausgabe(kurs + ": " + anzahl + " Termine, max. " + max
13               + ", Ø " + summe / anzahl)
14       anzahlGesamt := anzahlGesamt + anzahl
15       summeGesamt := summeGesamt + summe
16       kurs := t.getKurs()
17       anzahl := 0
18       summe := 0
19     Ende wenn
20     anzahl := anzahl + 1
21     summe := summe + t.getTeilnehmer()
22     wenn t.getTeilnehmer() > max dann
23       max := t.getTeilnehmer()
24     Ende wenn
25   Ende zähle
26   ausgabe("Gesamt: " + anzahlGesamt + " Termine, Ø "
27           + summeGesamt / anzahl)
28 Ende prozedur

01 public String zugangPruefen(Mitglied m, String bereich) {
02     String meldung = "Kein Zutritt";
03     if (m.istVertragAktiv()) {                          // B1
04         meldung = "Zutritt Trainingsbereich";           // A1
05         if (bereich.equals("Sauna")) {                  // B2
06             if (m.hatPremium()) {                       // B3
07                 meldung = "Zutritt Sauna";              // A2
08             } else {
09                 meldung = "Sauna nur mit Premium";      // A3
10             }
11         }
12         if (m.getOffenerBetrag() > 0) {                 // B4
13             meldung = meldung + " (Zahlung offen)";     // A4
14         }
15     } else {
16         protokolliereVersuch(m);                        // A5
17     }
18     return meldung;
19 }

C · Aufgaben

Alle Aufgaben beziehen sich auf die Ausgangssituation in Anlage 1. Spezifikationen, Listings und Testdaten stehen in den Anlagen 2 bis 8. Algorithmen und Korrekturen dürfen in Pseudocode nach den Konventionen des Belegsatzes oder in Java formuliert werden.

TQ-01 · Testarten

TQ-02 · Code analysieren / Fehler finden

01 public double belastungsDurchschnitt(int[] puls, int grenze) {
02     int summe = 0;
03     int anzahl = 0;
04     for (int i = 1; i < puls.length; i++) {
05         if (puls[i] > grenze) {
06             summe = summe + puls[i];
07             anzahl++;
08         }
09     }
10     if (anzahl == 0) {
11         return 0.0;
12     }
13     return (double) summe / puls.length;
14 }

TQ-03 · Unit-Test / Überdeckungsmaße

@Test
void buchungVerringertFreiePlaetze() {
    Kurs kurs = new Kurs("Yoga", 12);          // (1)
    kurs.buchen(3);                            // (2)
    assertEquals(9, kurs.getFreiePlaetze());   // (3)
}

01 public int freiePlaetze(int kapazitaet, int gebucht) {
02     int frei = -1;
03     if (kapazitaet > 0 && gebucht > 0) {
04         if (gebucht < kapazitaet) {
05             frei = kapazitaet - gebucht;
06         }
07     }
08     return frei;
09 }

@Test
void testeFreiePlaetze() {
    assertEquals(5, freiePlaetze(20, 15));      // Testfall 1
    assertEquals(20, freiePlaetze(20, 0));      // Testfall 2
    assertEquals(0, freiePlaetze(20, 20));      // Testfall 3
    assertEquals(-1, freiePlaetze(20, 21));     // Testfall 4
    assertEquals(-1, freiePlaetze(0, 0));       // Testfall 5
    assertEquals(19, freiePlaetze(20, 1));      // Testfall 6
}

TQ-04 · Qualitätsmerkmale ISO/IEC 25010

TQ-05 · Schreibtischtest

01 funktion bonuspunkte(minuten : integer[]) : integer
02   punkte : integer := 0
03   zähle i von 0 bis minuten.length - 1
04     wenn minuten[i] >= 60 dann
05       punkte := punkte + 3
06     sonst
07       wenn minuten[i] >= 30 dann
08         punkte := punkte + 1
09       Ende wenn
10     Ende wenn
11   Ende zähle
12   rückgabe punkte
13 Ende funktion

01 funktion spitzenphasen(besucher : integer[][], grenze : integer) : integer
02   anzahl : integer := 0
03   folge : integer := 0
04   zähle tag von 0 bis besucher.length - 1
05     zähle std von 0 bis besucher[tag].length - 1
06       wenn besucher[tag][std] > grenze dann
07         folge := folge + 1
08         wenn folge = 2 dann
09           anzahl := anzahl + 1
10         Ende wenn
11       sonst
12         folge := 0
13       Ende wenn
14     Ende zähle
15   Ende zähle
16   rückgabe anzahl
17 Ende funktion

01 public int laengsteSerie(boolean[] trainiert) {
02     if (trainiert == null) {
03         throw new IllegalArgumentException("keine Daten");
04     }
05     int serie = 0;
06     int max = 0;
07     for (int i = 0; i < trainiert.length; i++) {
08         if (trainiert[i]) {
09             serie++;
10         } else {
11             if (serie > max) {
12                 max = serie;
13             }
14             serie = 0;
15         }
16     }
17     return max;
18 }

01 funktion serieAb(t : boolean[], i : integer) : integer
02   wenn i >= t.length oder nicht t[i] dann
03     rückgabe 0
04   Ende wenn
05   rückgabe 1 + serieAb(t, i + 1)
06 Ende funktion

TQ-06 · Äquivalenzklassen / Testfälle

TQ-07 · Codequalität / Reviews

01 // Preis
02 public double p(int n, boolean e, boolean s) {
03     double x = 0;
04     if (e == true) {
05         x = 10.0 * n;
06         if (n >= 10) {
07             x = 10.0 * n - 10.0 * n * 0.1;
08         }
09     } else {
10         x = 15.0 * n;
11         if (n >= 10) {
12             x = 15.0 * n - 15.0 * n * 0.1;
13         }
14     }
15     if (s == true) x = x + 5.0 * n;   // plus 5 mal n
16     return x;
17 }

Originalaufgaben zum Üben

Diese echten Prüfungsaufgaben passen zu diesem Block (Dateien im Ordner Prüfungsvorbereitung). Lösungen gibt es nur für 2023 Sommer, 2023 Winter, 2024 Sommer und 2025 Winter (dort vom u-form-Verlag). Testen fehlte in Winter 2024 ganz; Sommer 2026 fragte nur ISO 25010.