AHB-Testfälle entwickeln

Kurzantwort

Ein AHB-Testfall übersetzt genau einen fachlichen Use-Case und seine zulässigen Varianten in prüfbare Eingaben, erwartete Nachrichten und ein erwartetes Ergebnis. Er muss drei Ebenen auseinanderhalten: Erstens ist die EDIFACT-Syntax formal korrekt (oder wird mit einer passenden CONTRL abgelehnt)? Zweitens ist die Nachricht fachlich verarbeitbar (oder folgt eine APERAK)? Drittens entsteht im Zielsystem tatsächlich das erwartete Geschäftsprozessresultat? Ein grünes Ergebnis auf einer Ebene beweist nichts über die nächste.

Das Anwendungshandbuch (AHB) ist dabei die maßgebliche Quelle für Pflichtfelder, Bedingungen, Codes, Prüfidentifikatoren und Antwortregeln. Testfälle werden gegen eine konkrete AHB-/MIG-Version geschrieben und mit dem Umsetzungstermin versioniert.

Vom AHB zum Testfall

Beginne nicht mit einer Beispielnachricht, sondern mit dem Use-Case. Dokumentiere Marktrolle, Richtung, Nachrichtentyp, Prüfidentifikator, AHB-Version und fachlichen Anlass. Ein Lieferbeginn per UTILMD, eine Messwertübermittlung per MSCONS und eine Rechnung per INVOIC benötigen jeweils andere Testfallfamilien. Der gleiche Nachrichtentyp kann mehrere Use-Cases abbilden.

Lies im AHB zunächst die Geschäftsvorfallbeschreibung und die Antwortregeln. Übertrage danach jede relevante Tabellenzeile in eine Testfallentscheidung: Muss ein Segment vorhanden sein? Ist es nur unter einer Bedingung erlaubt? Welche Codeliste gilt? Welche Abhängigkeit besteht zwischen zwei Werten? Ein Testfall sollte auf die AHB-Stelle verweisen, damit ein Prüfer die Erwartung nachvollziehen kann.

Eine brauchbare Testfallkarte enthält mindestens:

Positiv-, Negativ- und Grenzfälle

Ein Positivfall verwendet einen vollständigen, in sich konsistenten Datensatz. Er beweist, dass die Verarbeitungskette im Normalfall funktioniert. Negativfälle verändern jeweils nur eine Ursache: etwa ein fehlendes Pflichtsegment, ein ungültiger Code, eine falsche Datumslogik oder eine nicht bekannte Marktlokation. So lässt sich die tatsächliche Fehlerreaktion einer erwarteten CONTRL oder APERAK zuordnen.

Grenzfälle liegen an AHB-Bedingungen: frühester oder spätester zulässiger Termin, minimale beziehungsweise maximale Länge, wiederholte Segmente, Nullwerte und Wechsel von Sommer- zu Winterzeit. Variiere nicht mehrere Regeln gleichzeitig. Sonst kann ein System zwar ablehnen, aber der Test sagt nicht, warum.

Für jede Ablehnung gehört die erwartete Fehlerreferenz in den Fall: Segment, Datenelement, Code oder fachlicher Prüfgrund. Die genaue Fehlerausprägung muss zur eingesetzten AHB-Version passen. Eine pauschale Erwartung „APERAK kommt“ ist zu grob, weil auch eine technische Nichtannahme, ein Transportfehler oder ein Timeout möglich ist.

Eine Testfallmatrix macht die Abdeckung sichtbar. In den Zeilen stehen Use-Case und Variante, in den Spalten die drei Prüfebenen sowie die erwarteten Folgeaktionen. Markiere Fälle, die nur in einer Rolle oder nur für Strom beziehungsweise Gas gelten. So fallen Lücken bei Rollenwechseln, unbekannten IDs und Wiederholungen früh auf. Für automatisierte Tests sollten Referenzen und fachliche Schlüssel parametrisiert werden, während die eigentliche Regelverletzung als einzelne, lesbare Änderung erhalten bleibt. Nach jedem AHB-Update wird die Matrix gegen die Änderungsmitteilung geprüft; betroffene Fälle erhalten eine neue Version und ein nachvollziehbares Freigabedatum.

CONTRL und APERAK getrennt prüfen

CONTRL ist die Rückmeldung zur Syntaxprüfung und Empfangsbestätigung einer gesamten Übertragungsdatei. Der Test prüft deshalb Segmentstruktur, Trennzeichen, UNH/UNT-Konsistenz, Nachrichtenzählung, Zeichensatz und die formale Referenz auf die Originalnachricht. Eine Empfangsbestätigung bedeutet: Die Datei konnte formal gelesen werden. Sie bedeutet nicht, dass jeder enthaltene Geschäftsvorfall fachlich verarbeitet oder das Geschäftsergebnis erreicht wurde. Die genaue Anwendung unterscheidet sich zudem nach Sparte: In Gas wird grundsätzlich eine CONTRL gesendet, in Strom eine CONTRL-Syntaxfehlermeldung nur bei syntaktisch falscher Datei.

APERAK meldet einen Anwendungs- oder Verarbeitbarkeitsfehler für Geschäftsvorfälle; in den Stromprozessen dient sie zusätzlich als Anerkennungsmeldung für ordnungsgemäß verarbeitbare Geschäftsvorfälle. Der Testfall muss die Nachricht daher syntaktisch gültig lassen und gezielt eine fachliche Regel verletzen: beispielsweise einen nicht zulässigen Prüfidentifikator-Kontext oder eine widersprüchliche Zuordnung. Erwartet werden APERAK-Schlüssel, Fehlerort und fachliche Referenz. Die Fehlerwirkung ist geschäftsvorfallbezogen: Bei gemischten Dateien können fehlerfreie Geschäftsvorfälle weiterverarbeitet werden, während beanstandete nicht verarbeitet werden. Die BNetzA beschreibt CONTRL und APERAK in einem eigenen AHB; Version und Umsetzungstermin sind deshalb Teil der Testdaten.

Auch positive Rückmeldungen sind zu prüfen. Eine fehlerfreie CONTRL darf nicht automatisch den Status „fachlich verarbeitet“ setzen. Ebenso darf eine APERAK nicht als Ersatz für eine Geschäftsbestätigung behandelt werden. Die Rückmeldung ist ein Ereignis im Nachrichtenmonitoring, das Prozessresultat entsteht erst durch die Anwendung.

Geschäftsprozessresultat testen

Nach erfolgreicher Syntax- und Fachprüfung kontrolliert der Test die Wirkung: Wird die richtige Marktlokation gefunden? Entsteht oder endet die Zuordnung zum erwarteten Datum? Wird ein Messwert mit korrekter Werteart, Einheit und Status gespeichert? Wird eine Folgeantwort erzeugt und der Klärfall geschlossen? Diese Assertions gehören in den Testfall, nicht nur in eine manuelle Checkliste.

Für SAP IS-U bedeutet das, die externen Werte mit den internen Fachobjekten zu verbinden. Ein UTILMD-Test kann Geschäftspartner, Vertragskonto, Marktlokation und Zuordnung prüfen. Ein MSCONS-Test prüft Messlokation, Zählwerk, Zeitintervall und Messwertstatus. Die Beleg- oder Prozessnummer sollte als technischer Nachweis festgehalten werden. Vorbedingungen müssen reproduzierbar sein; produktive Stammdaten sind dafür ungeeignet.

Integrationstest im SAP-IS-U-Umfeld

Ein Integrationstest umfasst Erzeugung, Konvertierung, Transport, Eingang, Rückmeldung und fachliche Verbuchung. Lege Testpartner und Testlokationen mit realistischen, aber anonymisierten Daten an. Simuliere den Transportweg (etwa AS2 oder einen Test-EDI-Dienst) und bewahre Originaldatei, CONTRL/APERAK, Kommunikationsprotokoll und SAP-Anwendungslog gemeinsam auf.

Trenne dabei Systemgrenzen: Der Konverter testet EDIFACT, der Kommunikationsadapter den Versand, SAP IS-U die fachliche Verarbeitung. Ein Fehler muss einer Grenze zugeordnet werden können. Prüfe außerdem Wiederholung und Reihenfolge: Eine erneut zugestellte Nachricht darf keine doppelte Zuordnung oder doppelte Werte erzeugen; eine APERAK muss im Monitoring sichtbar und bearbeitbar sein.

Praxisbeispiel: fachlich falsche UTILMD

Für einen Lieferbeginn wird eine gültige UTILMD erzeugt. Im Negativfall ist die Marktlokation zwar syntaktisch korrekt, aber im Testmandanten nicht dem angegebenen Netzbetreiber zugeordnet. Die erwartete CONTRL ist positiv, weil die Nachricht formal lesbar ist. Danach erwartet der Test eine APERAK mit fachlichem Grund. Im SAP-System darf kein Lieferbeginn gebucht werden; stattdessen muss der Klärfall mit Originalreferenz entstehen.

Ein zweiter Fall korrigiert nur die Zuordnung und wiederholt die Nachricht nach der Fehlerbehebung. Nun werden positive Rückmeldung und das erwartete Prozessresultat geprüft: korrekter Beginnzeitpunkt, korrekte Marktrolle und genau eine Zuordnung. Damit werden CONTRL, APERAK und Geschäftsprozess in einer nachvollziehbaren Kette abgedeckt.

Typische Missverständnisse

„Eine positive CONTRL ist eine fachliche Bestätigung.“ Nein. Sie betrifft Empfang/Syntax der Übertragungsdatei; die Fachprüfung und das Prozessresultat folgen separat. In Strom ist für die ordnungsgemäße Weiterverarbeitung zusätzlich die APERAK-Anerkennung maßgeblich.

„Jede Ablehnung ist eine APERAK.“ Nein. Bei nicht lesbarer EDIFACT ist zunächst die Syntaxebene betroffen; außerdem können Transport- oder Kommunikationsfehler vorliegen.

„Ein Positivbeispiel reicht für die AHB-Abdeckung.“ Nein. Pflichtbedingungen, Codes, Abhängigkeiten und Grenzwerte brauchen gezielte Negativ- und Grenzfälle.

„Die Nachricht ist das Ergebnis.“ Nein. Das Ergebnis ist der veränderte Fachstatus im Zielsystem und seine Folgekommunikation.

„Testfälle können über Versionswechsel unverändert bleiben.“ Nein. AHB, MIG, Codelisten und Umsetzungstermine können Erwartungen ändern; die Testfallversion muss das sichtbar machen.

Quellen und Pflegehinweis

Verbindliche Regeln stammen aus dem für den Use-Case geltenden AHB, der zugehörigen MIG und den veröffentlichten Festlegungen. Die BNetzA führt Versionsstände und Umsetzungstermine in ihren Mitteilungen; EDI@Energy stellt die Formatdokumente bereit. Vor einem Release sind die aktuell geltenden Dokumente zu prüfen, Testdaten zu versionieren und mindestens ein Ende-zu-Ende-Szenario erneut auszuführen.

• BNetzA: CONTRL / APERAK AHB 2.4a
• BNetzA: Mitteilung Nr. 51
• BNetzA: Allgemeine Festlegungen
• EDI@Energy: Datenformate

Abrufdatum: 8. September 2026.