Die meisten Schnittstellenprojekte zwischen ERP und Online-Shop scheitern nicht am Code. Sie scheitern daran, dass niemand vor dem Go-live gefahrlos testen kann. Das ERP hat keinen freien Mandanten, die Testdaten sind eine Kopie der Produktion mit echten Kundenadressen, und die erste Massenbuchung läuft ungebremst gegen das Live-System. Das BSI formuliert die Gegenmaßnahme als Basis-Anforderung: Software MUSS in einer Test- und Entwicklungsumgebung getestet werden, die getrennt von der Produktionsumgebung ist (BSI IT-Grundschutz CON.8). Für personenbezogene Testdaten gilt zusätzlich, dass sie mindestens pseudonymisiert werden MÜSSEN (BSI IT-Grundschutz OPS.1.1.6). Dieser Beitrag beschreibt eine Umgebungsstrategie für ERP-Shop-Anbindungen, die diese Anforderungen erfüllt und trotzdem realitätsnah testet: Sandbox-Mandanten und ihre Grenzen, Testdaten zwischen Datenminimierung und Aussagekraft, Contract-Tests gegen Mocks, Last- und Backfill-Tests sowie Freigabe- und Cutover-Kriterien mit Rückfallplan.
Das Wichtigste in Kürze
- Getrennte Entwicklungs-, Test- und Produktionsumgebungen sind eine Basis-Anforderung des BSI (IT-Grundschutz CON.8.A7), keine Kür. Ein Test im Livesystem zieht Nummernkreise weiter, erzeugt Belege und schickt Bestätigungsmails an echte Adressen.
- Ein Sandbox-Mandant in Business Central erlaubt 300 OData-Anfragen pro Minute gegenüber 600 in der Produktion (Microsoft Learn) und läuft auf einem anderen Performance-Tier. Für belastbare Lasttests wird deshalb eine dedizierte Umgebung vom Typ Produktion benötigt.
- Beim Kopieren in eine Sandbox deaktiviert Microsoft Job Queue, Webhooks, SMTP-Daten und Belegaustausch, blockiert ausgehende HTTP-Aufrufe und verweigert den Datenbank-Export (Microsoft Learn). Mailversand, Belegausgabe und Webhooks brauchen eine Ersatzstrecke.
- Personenbezogene Testdaten müssen mindestens pseudonymisiert, möglichst anonymisiert werden (BSI OPS.1.1.6.A11); Artikel 5 DSGVO verlangt Beschränkung auf das notwendige Maß. Zwischen Produktion und Test gehört eine Anonymisierungsstrecke statt Backup-Restore.
- Ein kleiner synthetischer Stammdatensatz deckt jeden Randfall ab: Sonderpreis, Streckenartikel, Steuerbefreiung, Kreditlimit, Stückliste, Gebinde. Contract-Tests gegen Mocks ersetzen einen langsamen Integrationstest durch zwei Sätze schneller Tests (Pact Foundation).
- Backfill und Last gehören vor die Freigabe: 120.000 Artikel bei 100 Operationen je $batch ergeben 1.200 Aufrufe (Microsoft Learn), dazu Wiederaufnahme nach Abbruch. Der Abnahmeplan nach OPS.1.1.6.A10 nennt Freigabekriterien und einen Ablehnungspfad.
Warum Schnittstellenprojekte am Testen scheitern
Der Ablauf ähnelt sich in vielen Projekten. Die Anbindung zwischen ERP und Shop ist technisch fertig, die Mappings sind abgestimmt, die Authentifizierung steht. Dann kommt die Frage, wo das Ganze ausprobiert werden soll – und die Antwort lautet zu oft: im Livesystem, aber vorsichtig. Vorsichtig heißt in der Praxis, dass eine Entwicklerin zu Randzeiten einzelne Bestellungen anlegt, während der Vertrieb hofft, dass keine echte Rechnung dabei herausfällt. Das ist kein Test. Das ist ein Experiment mit Kundendaten.
Das BSI beschreibt genau dieses Muster in der Gefährdungslage des Bausteins OPS.1.1.6. Werden Software-Tests mit Produktivdaten durchgeführt, können vertrauliche Daten von Personen eingesehen werden, die lediglich mit dem Test beauftragt sind; wird nicht mit Kopien, sondern mit den originalen Produktivdaten getestet, können diese ungewollt geändert oder gelöscht werden (BSI IT-Grundschutz OPS.1.1.6). Der Baustein CON.8 ergänzt, dass ungewollte Veränderungen an Produktivdaten auch dadurch entstehen, dass Software fehlerhaft getestet oder bedient wird, dass diese Veränderung möglicherweise nicht zeitnah festgestellt wird und dass sich solche Fehler auf andere Anwendungen auswirken können, die auf die gleichen Datenbestände zugreifen (BSI IT-Grundschutz CON.8).
Bei einer ERP-Shop-Schnittstelle ist dieser Effekt besonders unangenehm, weil die Nebenwirkungen nicht im System bleiben. Eine Testbestellung im Produktivmandanten zieht einen Nummernkreis weiter, erzeugt womöglich einen Beleg, löst eine Bestätigungsmail an eine echte Adresse aus und wandert in die Buchhaltung. Das BSI benennt auch die Ursache dieser Schieflage: Während Software getestet wird, steht nicht der Schutz der Testdaten im Vordergrund, sondern die Frage, ob sich die Software wie gewünscht verhält (BSI IT-Grundschutz CON.8). Genau deshalb steht am Anfang eines belastbaren Schnittstellenprojekts keine Codefrage, sondern eine Umgebungsfrage.
Der erste Massenlauf gehört nicht in die Produktion
Getrennte Umgebungen sind Basis-Anforderung, nicht Kür
Die Vorgabe ist eindeutig formuliert. Im Baustein CON.8 Software-Entwicklung heißt es in der Anforderung A7: Die Software MUSS in einer Test- und Entwicklungsumgebung getestet werden, die getrennt von der Produktionsumgebung ist (BSI IT-Grundschutz CON.8). Diese Anforderung gehört zu den 8 Basis-Anforderungen des Bausteins (BSI IT-Grundschutz CON.8), und Basis heißt im IT-Grundschutz: vorrangig umzusetzen, nicht optional. In derselben Anforderung steht zweierlei, das im Projektalltag gern untergeht: Testdaten SOLLTEN sorgfältig ausgewählt und geschützt werden, und es MUSS geprüft werden, ob die Systemvoraussetzungen für die vorgesehene Software ausreichend dimensioniert sind (BSI IT-Grundschutz CON.8). Der zweite Punkt ist die Lastfrage – sie steht damit nicht am Ende einer Wunschliste, sondern in einer Basis-Anforderung.
Der Betriebsbaustein OPS.1.1.6 Software-Tests und -Freigaben schärft das nach. Er umfasst 6 Basis-Anforderungen (BSI IT-Grundschutz OPS.1.1.6) und verlangt in der Standard-Anforderung A13 die Trennung der Testumgebung von der Produktivumgebung: Software SOLLTE nur in einer hierfür vorgesehenen Testumgebung getestet werden, die getrennt betrieben wird; die verwendeten Architekturen und Mechanismen SOLLTEN dokumentiert werden, ebenso das Verfahren, wie mit der Testumgebung nach Abschluss der Software-Tests zu verfahren ist (BSI IT-Grundschutz OPS.1.1.6). Der letzte Halbsatz wird gern überlesen: Eine Testumgebung, die nach dem Projekt mit einer alten Produktionskopie weiterläuft, ist ein Datenrisiko ohne Gegenwert.
Entwicklungsumgebung
Hier arbeitet der Code gegen Mocks und einen kleinen synthetischen Stammdatensatz. Kein Personenbezug, keine Fremdsysteme, dafür Sekunden statt Minuten bis zum Feedback.
Testumgebung
Hier laufen Integration und Regression gegen einen echten ERP-Testmandanten mit anonymisierten Daten. Getrennt betrieben, dokumentiert, mit definiertem Umgang nach Projektende.
Produktionsumgebung
Hier sind Belegausgabe, Mailversand und Nummernkreise scharf. Was hier zum ersten Mal passiert, war vorher kein Test, sondern eine Annahme.
In der Praxis liegt der Ort, an dem diese Trennung technisch durchgesetzt wird, meist in der Middleware: Sie kennt die Zielsysteme je Umgebung, hält Zugangsdaten getrennt und verhindert, dass eine Testkonfiguration versehentlich auf einen Produktiv-Endpunkt zeigt. Punkt-zu-Punkt-Verbindungen, bei denen die Ziel-URL in jedem Skript einzeln gepflegt wird, machen genau diesen Fehler wahrscheinlich – und er fällt oft erst auf, wenn eine Testbestellung im echten Auftragseingang liegt.
Sandbox-Mandanten und ihre Grenzen
Moderne Cloud-ERP-Systeme liefern Testumgebungen mit. In Dynamics 365 Business Central enthalten die Abonnements Essential und Premium je eine Produktionsumgebung und drei Sandbox-Umgebungen ohne Zusatzkosten; jede zusätzlich erworbene Produktionsumgebung bringt drei weitere Sandbox-Umgebungen und 4 GB zusätzliche mandantenweite Datenbankkapazität mit (Microsoft Learn). Das ist eine gute Ausgangslage – solange man weiß, worin sich eine Sandbox von der Produktion unterscheidet. Und die Unterschiede sind genau die, die eine Schnittstelle betreffen.
Der erste Unterschied sind die Limits. Für OData-Anfragen dokumentiert Microsoft je Umgebung eine Rate von 300 Anfragen pro Minute im Sandbox-Mandanten gegenüber 600 pro Minute in der Produktion (Microsoft Learn). Wer seinen Massenabgleich gegen die Sandbox testet und dabei am Limit entlangfährt, misst die halbe Wahrheit. Ergänzend gelten seit Ende 2023 nutzerbezogene Limits: 6.000 Anfragen je gleitendem 5-Minuten-Fenster, 5 gleichzeitig verarbeitete Anfragen, 95 wartende Anfragen in der Warteschlange und 100 gleichzeitige Verbindungen (Microsoft Learn). Wird die Rate oder die Warteschlange überschritten, antwortet der Dienst mit 429 Too Many Requests; wartende Anfragen laufen nach 8 Minuten in ein 503 Service Temporarily Unavailable, und eine einzelne OData-Operation bricht nach 8 Minuten mit 408 Request Timeout ab (Microsoft Learn). Die API-Referenz nennt zusätzlich ein Zeitlimit von 10 Minuten Ausführungszeit, nach dem eine Anfrage mit 504 Gateway Timeout endet (Microsoft Learn).
| Merkmal | Sandbox-Umgebung | Produktionsumgebung |
|---|---|---|
| Im Abonnement enthalten (Essential/Premium) | 3 | 1 |
| Dokumentierte OData-Rate je Umgebung | 300 Anfragen/Minute | 600 Anfragen/Minute |
| Performance-Tier in Azure | abweichend, nicht für Benchmarks | Zieltier des Echtbetriebs |
| Datenbank-Export | nicht möglich | möglich |
| Ausgehende HTTP-Aufrufe aus Extensions | standardmäßig blockiert | je Extension freizugeben |
| Debugging-Endpunkt | standardmäßig offen | nicht dafür vorgesehen |
Die Werte in dieser Übersicht stammen aus der Produktdokumentation (Microsoft Learn). Der zweite große Unterschied betrifft das, was beim Kopieren einer Produktionsumgebung in eine Sandbox absichtlich abgeschaltet wird. Microsoft dokumentiert dafür eine Reihe von Vorkehrungen: Aufgaben in der Job Queue werden automatisch gestoppt, Agents werden mitkopiert, aber in der Zielumgebung deaktiviert, sämtliche Webhooks werden auf inaktiv gesetzt, die Einträge der Service-Connection-Tabelle und die Exchange-Synchronisation werden deaktiviert, Integrationseinstellungen der Basisanwendung werden geleert, SMTP-Serverdaten werden gelöscht und E-Mail-Konten der Typen Microsoft 365 und Current User werden entfernt; auch die Konfiguration für den Belegaustausch und die Prüfung von Umsatzsteuer-Identifikationsnummern werden deaktiviert (Microsoft Learn).
Für ein Schnittstellenprojekt ist das eine zweischneidige Sache. Diese Vorkehrungen sind der Grund, warum eine Sandbox-Kopie überhaupt gefahrlos benutzbar ist: Sie verhindern, dass Testläufe echte Mails, echte Belege und echte Webhook-Aufrufe auslösen. Zugleich bedeuten sie, dass der Test nicht den vollständigen Prozess abbildet. Belegausgabe, Mailversand und Webhook-Zustellung sind genau die Teile, die erst in der Produktion wieder scharf sind. Wer sie im Test nicht durch eine bewusst gebaute Ersatzstrecke nachbildet – einen Empfänger auf einer Testdomäne, einen Webhook-Endpunkt unter eigener Kontrolle --, hat sie schlicht nicht getestet.
Was der Sandbox-Mandant nicht abbildet
Der dritte Unterschied ist der wichtigste für Lasttests. Sandbox-Umgebungen laufen in Azure auf einem anderen Performance-Tier als Produktionsumgebungen und sind für Performance-Tests oder vergleichbares Benchmarking nicht zuverlässig; Microsoft empfiehlt für diesen Zweck ausdrücklich eine dedizierte Umgebung vom Typ Produktion, um dieselbe Erfahrung und Performance wie im Echtbetrieb zu erhalten (Microsoft Learn). Wer ein Mengengerüst prüfen will, braucht also eine zweite Produktionsumgebung, nicht die im Abonnement enthaltene Sandbox. Das ist eine Budgetentscheidung, und sie sollte früh im Projekt fallen statt drei Tage vor dem Cutover.
Auf SAP-Seite ist die Lage ähnlich abgestuft. Die SAP Integration Suite bietet eine Simulation von Integration Flows, mit der sich ein Ausschnitt eines Flows ohne Deployment und ohne eigens aktiviertes Tracing prüfen lässt. Die Grenzen sind dokumentiert: maximal 10 Integrationsschritte je Simulationslauf und maximal 1 MB Payload (SAP Help Portal). Für die Teststrategie noch wichtiger: Während der Simulation finden keine Backend- oder Connector-Aufrufe statt, die Antwort des Empfänger-Adapters wird stattdessen als Simulationsantwort hinterlegt (SAP Help Portal). Das ist im Kern ein Mock, eingebaut ins Werkzeug – und ein gutes Zeichen dafür, dass der Plattformhersteller selbst nicht davon ausgeht, dass man bei jedem Zwischenschritt gegen das echte Backend fährt.
Wer eine Anbindung an die SAP-Integration oder an Dynamics 365 Business Central plant, sollte diese Grenzen kennen, bevor der Testplan geschrieben wird. Welche API-Generation dabei das Ziel ist, ist eine eigene Entscheidung – dazu haben wir die Migration auf die Business-Central-API v2.0 beschrieben. Liegen Test- und Produktivumgebung in der Cloud, lohnt zusätzlich ein Blick auf die Portabilitäts- und Wechselpflichten, die der EU Data Act für ERP-Cloud-Schnittstellen mit sich bringt.
Testdaten zwischen Datenminimierung und Realitätsnähe
Die bequemste Testdatenstrategie ist die Produktionskopie. Sie ist realitätsnah, sofort verfügbar und enthält jeden Sonderfall, den das Unternehmen je gebaut hat. Sie ist zugleich die Variante, die datenschutzrechtlich am wenigsten trägt. Artikel 5 Absatz 1 Buchstabe c der Datenschutz-Grundverordnung verlangt, dass personenbezogene Daten dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sind (EUR-Lex, Verordnung (EU) 2016/679). Ein Funktionstest einer Bestellschnittstelle braucht weder echte Namen noch echte Lieferadressen noch echte Bankverbindungen. Er braucht Daten, die sich verhalten wie echte.
Artikel 32 ergänzt die technische Seite. Er nennt die Pseudonymisierung und Verschlüsselung personenbezogener Daten ausdrücklich als geeignete Maßnahme (Artikel 32 Absatz 1 Buchstabe a) und verlangt ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen (Artikel 32 Absatz 1 Buchstabe d) (EUR-Lex, Verordnung (EU) 2016/679). Testdatenmanagement ist damit kein Nebenschauplatz der Entwicklung, sondern Teil der Maßnahmen, die eine Organisation ohnehin nachweisen muss.
Das BSI übersetzt das in eine Basis-Anforderung. OPS.1.1.6.A11 verlangt: Werden Produktivdaten mit schützenswerten Informationen für Software-Tests verwendet, MÜSSEN diese Testdaten angemessen geschützt werden; enthalten sie personenbezogene Informationen, MÜSSEN sie mindestens pseudonymisiert werden, und falls möglich SOLLTEN die Testdaten mit Personenbezug vollständig anonymisiert werden. Könnte ein Personenbezug aus den Testdaten abgeleitet werden, MUSS die oder der Datenschutzbeauftragte hinzugezogen werden, unter Umständen auch die Personalvertretung (BSI IT-Grundschutz OPS.1.1.6). Bemerkenswert daran ist die Reihenfolge: Pseudonymisierung ist die Untergrenze, Anonymisierung das Ziel.
Eine Produktionskopie ist keine Testumgebung. Sie ist die Produktion an einem Ort, an dem niemand mit Produktionssorgfalt arbeitet.
Praktisch heißt das: Zwischen Produktion und Testumgebung gehört eine Anonymisierungsstrecke, kein Backup-Restore. Diese Strecke ersetzt personenbezogene Felder und behält dabei die strukturellen Eigenschaften, auf die die Schnittstelle reagiert. Sie ist ein Stück Software, das gepflegt und versioniert wird – und sie ist der Grund, warum ein Testdatenstand reproduzierbar ist statt gewachsen.
- Namen und Adressen ersetzen, Struktur behalten: Aus einer echten Lieferadresse wird eine synthetische – mit derselben Länderkennung, derselben Postleitzahlenlogik und denselben Sonderzeichen. Genau daran scheitern Mappings, nicht am Namen selbst.
- Identifikatoren konsistent umschlüsseln: Kundennummern werden über alle Tabellen hinweg mit derselben Abbildung ersetzt. Sonst zerfallen die Referenzen zwischen Auftrag, Beleg und Zahlung, und der Testdatensatz wird fachlich wertlos.
- Kontaktkanäle ins Leere leiten: E-Mail-Adressen und Telefonnummern werden auf eine kontrollierte Testdomäne umgeschrieben, damit kein Testlauf einen echten Empfänger erreicht – auch dann nicht, wenn jemand den Mailversand versehentlich aktiviert.
- Zahlungs- und Bankdaten entfernen statt verfremden: Was fachlich nicht getestet werden muss, gehört nicht in die Testumgebung. Das ist Datenminimierung nach Artikel 5 Absatz 1 Buchstabe c in ihrer einfachsten Form (EUR-Lex, Verordnung (EU) 2016/679).
- Umschlüsselung dokumentieren, Schlüssel trennen: Wer die Abbildung von echt auf synthetisch aufbewahrt, hat weiterhin Personenbezug im Spiel. Diese Abbildung gehört nicht in die Testumgebung, sondern in die Obhut der Stelle, die sie verantwortet.
- Löschfrist setzen: OPS.1.1.6.A13 verlangt ein dokumentiertes Verfahren für den Umgang mit der Testumgebung nach Abschluss der Tests (BSI IT-Grundschutz OPS.1.1.6). Ein Ablaufdatum je Testdatenstand erspart diese Diskussion später.
Synthetische Stammdaten mit echten Randfällen
Anonymisierte Produktionsdaten lösen das Datenschutzproblem, aber nicht das Abdeckungsproblem. Sie enthalten, was in der Vergangenheit passiert ist – und ausgerechnet die Fälle, die eine Schnittstelle zum Kippen bringen, sind selten. Deshalb gehört neben die anonymisierte Kopie ein kleiner, bewusst gebauter Stammdatensatz, der jeden bekannten Randfall genau einmal enthält. Klein genug, um ihn zu pflegen; vollständig genug, um als Regressionsbasis zu taugen. OPS.1.1.6.A1 formuliert den Anspruch: Testfälle MÜSSEN so ausgewählt werden, dass sie möglichst repräsentativ alle Funktionen der Software überprüfen, und Negativ-Tests SOLLTEN berücksichtigt werden (BSI IT-Grundschutz OPS.1.1.6).
Sonderpreise und Preislisten
Kundenindividuelle Konditionen, Staffelpreise und befristete Aktionen sind der Klassiker, bei dem Shop und ERP unterschiedliche Ergebnisse liefern. Ein Testkunde je Preisfindungsregel deckt das ab.
Streckenartikel
Positionen, die der Lieferant direkt versendet, laufen anders durch Bestand, Beleg und Versandmeldung als Lagerware. Ohne einen Streckenfall im Testdatensatz bleibt dieser Pfad ungetestet.
Steuerbefreiung
Innergemeinschaftliche Lieferung, Reverse Charge, Ausfuhr und der Kunde mit gültiger USt-IdNr.: Jede Konstellation braucht einen eigenen Testkunden mit passender Adresse und Kennzeichnung.
Kreditlimit und Sperren
Ein Kunde am Limit, ein gesperrter Kunde und einer mit Vorkasse-Pflicht zeigen, ob der Checkout die Antwort des ERP korrekt verarbeitet, statt sie im Zweifel zu ignorieren.
Stücklisten und Sets
Verkaufsstücklisten, Sets und Varianten erzeugen im ERP mehr Positionen, als der Shop gesendet hat. Ein Set im Testdatensatz deckt diese Mengenlogik und ihre Rückmeldung ab.
Mengeneinheiten und Gebinde
Gebindegrößen, Mindestabnahmen und abweichende Verkaufseinheiten sind eine häufige Fehlerquelle bei der Mengenumrechnung zwischen Shop und ERP – und ein dankbarer Negativtest.
Dieser synthetische Datensatz ist zugleich die Brücke zum Stammdatenmanagement. Was hier als Randfall auftaucht, ist meistens eine Regel, die im Stammdatenmanagement sauber beschrieben gehört. Ein Testdatensatz, der Randfälle enthält, deckt Lücken in der Datenpflege oft schneller auf als jede Analyse – weil er sie erzwingt, statt sie zu suchen. Und weil er synthetisch ist, darf er in jeder Umgebung liegen, auch auf dem Rechner der Entwicklerin.
Contract-Tests gegen Mocks statt Vollintegration bei jedem Commit
Wenn die Umgebungen stehen, stellt sich die Frage, wie oft gegen das echte ERP getestet wird. Die naheliegende Antwort – bei jedem Commit – ist meist die falsche. Ein Vollintegrationstest belegt zwei Systeme, ist langsam, hängt an Testdatenständen und schlägt fehl, sobald der ERP-Mandant gerade aktualisiert wird. Fehlschläge aus Umgebungsgründen sind aber teurer als kein Test, weil das Team beginnt, rote Läufe zu ignorieren. Ein Test, dem niemand mehr glaubt, ist Ballast.
Consumer-Driven Contract Testing dreht das Verhältnis um. Der Konsument – hier der Shop oder die Middleware – schreibt einen Test gegen einen Mock-Provider. Aus diesem Test entsteht ein Vertrag, der genau die Anfragen und Antworten beschreibt, die der Konsument tatsächlich nutzt. Der Provider spielt diesen Vertrag anschließend gegen seine echte Implementierung nach. Die Pact-Dokumentation beschreibt den Kern so: Ein langsamer Integrationstest wird durch zwei Sätze schneller Unit-Tests ersetzt, die schnelles Feedback geben (Pact Foundation). Der Nebeneffekt ist ebenso wertvoll: Es wird nur der Teil der Kommunikation getestet, den die Konsumenten tatsächlich verwenden – Provider-Verhalten, das kein Konsument nutzt, kann sich ändern, ohne Tests zu brechen (Pact Foundation).
Die Argumente gegen den Vollintegrationstest in der Pipeline stehen in derselben Dokumentation: End-to-End-Tests sind langsam, langsame Builds führen zu gebündelten Änderungen, und Bündelung ist schlecht für Continuous Delivery; die Komplexität von End-to-End-Tests wächst nicht linear, sondern wird mit der Zeit unübersichtlicher (Pact Foundation). Contract-Tests laufen dagegen schneller als die Integrationstests, die sie ersetzen, lassen sich lokal auf dem Rechner debuggen statt über Systemprotokolle, und sie zeigen im Fehlerfall deutlich, wo das Problem liegt (Pact Foundation). Für eine ERP-Anbindung heißt das konkret: Ein geändertes Pflichtfeld im Auftragskopf fällt in Sekunden auf, nicht erst im nächtlichen Lauf.
# Bei jedem Commit -- Sekunden bis Minuten, ohne Fremdsysteme
- unit-tests # Mapping-, Rundungs- und Steuerlogik
- contract-tests # Consumer-Test gegen Mock-Provider erzeugt den Vertrag
- provider-verification # Vertrag gegen die echte API-Implementierung nachspielen
# Nächtlich -- gegen den Sandbox-Mandanten
- integration-suite # echte Aufträge, echte Belege, anonymisierte Testdaten
- regression-suite # Randfälle: Sonderpreis, Strecke, Steuerbefreiung
# Vor der Freigabe -- gegen eine Umgebung mit Produktions-Tier
- load-test # Mengengerüst des Echtbetriebs
- backfill-test # Erstbefüllung mit vollem KatalogWichtig ist, die Grenze zu kennen. Contract-Tests prüfen die Integration zweier Seiten, nicht die Fachlichkeit und nicht die Performance (Pact Foundation). Ob der Steuerbetrag stimmt, gehört in einen Unit-Test; ob 120.000 Artikel in ein Zeitfenster passen, gehört in einen Lasttest. Und ein rein providerseitiger Vertragstest ohne Konsumententests gibt keine testbasierte Sicherheit darüber, dass die Konsumenten den Provider korrekt aufrufen (Pact Foundation). Die Methode ersetzt keine Teststufe – sie sortiert sie.
Warum Mocks kein Selbstbetrug sind
Diese Teststufen greifen ineinander mit dem, was die Schnittstelle im Betrieb aushalten muss. Wie sich Wiederholungen und doppelte Zustellungen sauber abfangen lassen, beschreibt unser Beitrag zu Idempotenz und Retry-Strategien; wie Fehlerfälle strukturiert behandelt werden, steht in der Fehlerbehandlung an Schnittstellen. Damit Verträge über Releases hinweg halten, gehört eine saubere API-Versionierung dazu – und die API-Entwicklung selbst sollte von Beginn an so geschnitten sein, dass sie sich ohne Fremdsysteme prüfen lässt.
Last- und Backfill-Tests mit echten Mengengerüsten
Der Testlauf, der in Projekten am häufigsten fehlt, ist die Erstbefüllung. Im laufenden Betrieb fließen pro Stunde vielleicht ein paar Dutzend Bestellungen und ein paar hundert Bestandsänderungen. Am Tag des Go-live fließt der gesamte Katalog auf einmal. Wer nur den laufenden Betrieb getestet hat, testet den Backfill zum ersten Mal in der Produktion – und zwar an dem Tag, an dem am wenigsten Zeit für Überraschungen ist.
Rechnen Sie das Mengengerüst vorher durch. Ein Beispiel: Ein Katalog mit 120.000 Artikeln, übertragen per OData-Batch mit maximal 100 Operationen je $batch-Anfrage (Microsoft Learn), ergibt 1.200 Batch-Anfragen. Bei der dokumentierten Rate von 300 Anfragen pro Minute je Sandbox-Umgebung sind das rechnerisch 4 Minuten, in der Produktion mit 600 pro Minute rund 2 Minuten (Microsoft Learn) – vorausgesetzt, keine andere Last teilt sich das Kontingent. Beim Lesen begrenzt zusätzlich die maximale Seitengröße von 20.000 Entitäten je OData-Antwort (Microsoft Learn), wie viele Datensätze eine einzelne Abfrage zurückgeben kann. Solche Zahlen sind in einer Viertelstunde ermittelt und ersparen die unangenehmste Überraschung des Projekts.
Ein Detail lohnt dabei besondere Aufmerksamkeit: Microsoft hat die umgebungsbezogenen Raten inzwischen auf nutzerbezogene Limits umgestellt und weist ausdrücklich darauf hin, dass die früheren umgebungsbezogenen Raten nicht streng durchgesetzt wurden, die aktuellen nutzerbezogenen dagegen schon (Microsoft Learn). Wer seine gesamte Integration über einen einzigen technischen Nutzer oder Service Principal fahren lässt, erreicht diese Grenzen entsprechend schnell; als Gegenmittel nennt die Dokumentation die Verteilung der Last auf mehrere Nutzer oder Service Principals, etwa im Round-Robin-Verfahren (Microsoft Learn). Für die Testplanung heißt das: Ein Massenlauf unter einem einzigen Konto verhält sich anders als einer, der die Last verteilt – und beide Varianten sollten vor dem Go-live einmal gemessen worden sein.
- Passt die Menge ins Fenster? Katalogumfang, Batchgröße und Rate ergeben eine Dauer. Diese Dauer muss in das geplante Wartungsfenster passen, mit Reserve für Wiederholungen und Nacharbeit.
- Was passiert beim Abbruch in der Mitte? Ein Backfill, der bei Datensatz 80.000 abbricht, muss fortsetzbar sein, ohne die ersten 80.000 erneut zu schreiben. Das ist ein eigener Testfall, kein Nebeneffekt.
- Werden 429-Antworten korrekt behandelt? Der Client muss bei einem 429 zurückweichen und nach einer Abkühlphase erneut versuchen (Microsoft Learn), statt in einer Schleife weiter gegen die Wand zu laufen.
- Läuft parallel noch der Normalbetrieb? Wenn der Backfill das Kontingent aufbraucht, stehen Bestandsabgleich und Bestellabruf still. Beide Lasten gehören gemeinsam gemessen, nicht nacheinander.
- Stimmt das Ergebnis? Ein Abgleich der Datensatzzahlen und Stichproben auf Feldebene zwischen Quelle und Ziel gehören ins Abnahmeprotokoll – nachvollziehbar, nicht als Bauchgefühl.
Solche Läufe sind auch der Moment, in dem sich zeigt, ob die Beobachtbarkeit taugt. Ein Backfill ohne Metriken ist eine Blackbox; was dabei zu messen ist, beschreibt unser Beitrag zu Observability und Monitoring an Schnittstellen. Bei Ablösungen kommt hinzu, dass Alt- und Neusystem eine Zeit lang parallel laufen – die typischen Fallstricke dabei behandelt der Beitrag zur ERP-Migration von Legacy-Systemen.
Der Lasttest ist eine Budgetfrage, keine Fleißfrage
Freigabe, Cutover und Rückfallplan
Tests ohne Freigabekriterien enden in der Diskussion, ob das Ergebnis gut genug ist. Das BSI kennt dafür den Abnahmeplan: Nach OPS.1.1.6.A10 SOLLTEN darin die durchzuführenden Testarten, die Testfälle und die erwarteten Ergebnisse dokumentiert sein; außerdem SOLLTE der Abnahmeplan die Freigabekriterien enthalten und eine Vorgehensweise für die Situation festlegen, in der eine Freigabe abgelehnt wird (BSI IT-Grundschutz OPS.1.1.6). Der letzte Halbsatz ist der wichtigste. Ein Abnahmeplan, der keinen Ablehnungspfad beschreibt, ist eine Absichtserklärung – denn unter Termindruck wird sonst genau das getan, was ohne Regel am einfachsten ist: freigeben.
Dazu kommen zwei Basis-Anforderungen aus demselben Baustein. A3 verlangt, dass die Ergebnisse der Software-Tests ausgewertet und die Auswertung dokumentiert wird, mit einem Soll-Ist-Vergleich gegen definierte Vorgaben (BSI IT-Grundschutz OPS.1.1.6). A4 verlangt, dass die fachlich zuständige Organisationseinheit die Software freigibt und die Freigabe in Form einer Freigabeerklärung dokumentiert – und dabei überprüft, ob gemäß den Anforderungen getestet wurde und ob die Ergebnisse mit den vorher festgelegten Erwartungen übereinstimmen (BSI IT-Grundschutz OPS.1.1.6). Übersetzt in die Projektwirklichkeit: Nicht die Entwicklung gibt frei, sondern der Fachbereich, und zwar schriftlich.
- Alle Randfälle des synthetischen Stammdatensatzes laufen grün, dokumentiert mit Testfall-Nummer und Ergebnis.
- Regressionstests sind vollständig durchgelaufen; ausgelassene Testfälle sind begründet und dokumentiert (BSI IT-Grundschutz OPS.1.1.6).
- Der Backfill hat das Mengengerüst im geplanten Fenster geschafft, inklusive erfolgreicher Wiederaufnahme nach einem künstlich erzeugten Abbruch.
- Der Lasttest auf einer Umgebung mit Produktions-Tier hat das Zielprofil gehalten, ohne dass der Normalbetrieb stehen blieb (Microsoft Learn).
- Die Ausgangsstrecken, die im Sandbox-Mandanten deaktiviert sind – Mailversand, Belegausgabe, Webhooks --, sind über eine Ersatzstrecke geprüft (Microsoft Learn).
- Der Rückfallplan ist einmal geprobt worden, nicht nur aufgeschrieben.
Der Rückfallplan ist der Punkt, an dem die meisten Projekte schweigen. Er beantwortet drei Fragen: Woran erkennen wir, dass wir zurück müssen – welche Kennzahl über welchen Zeitraum? Wer entscheidet das, und bis wann ist die Entscheidung überhaupt möglich? Und was passiert mit den Daten, die zwischen Cutover und Rückfall entstanden sind? Gerade die dritte Frage entscheidet, ob ein Rückfall real eine Option ist. Wenn im neuen Prozess bereits Belege erzeugt und Nummernkreise gezogen wurden, ist ein Zurück ohne Nacharbeit ausgeschlossen. Wer das vorher weiß, plant den Cutover anders – etwa mit einem lesenden Vorlauf, bevor die schreibenden Prozesse scharf gestellt werden.
Nach dem Cutover bleibt eine Aufgabe offen, die A13 ausdrücklich benennt: das dokumentierte Verfahren, wie mit der Testumgebung nach Abschluss der Software-Tests zu verfahren ist (BSI IT-Grundschutz OPS.1.1.6). Testumgebungen mit alten Kundendaten, die niemand mehr anfasst, sind ein Risiko ohne Gegenwert. Und weil die Abnahme selbst ein Nachweis ist: Was getestet, freigegeben und wann geändert wurde, gehört in die GoBD-Verfahrensdokumentation für ERP-Shop-Schnittstellen – dort trifft die Teststrategie auf die Nachweispflicht.
Was eine belastbare Teststrategie im Projekt verändert
Der Aufwand für Umgebungen, Anonymisierung und Testdaten fällt am Anfang an, der Nutzen zeigt sich am Ende. Das ist der Grund, warum diese Positionen in Angeboten gern gestrichen werden, und zugleich der Grund, warum Go-live-Termine reißen. Eine Schnittstelle, die vorher unter realistischen Bedingungen gelaufen ist, geht mit einer anderen Erwartungshaltung live als eine, die nur in der Entwicklungsumgebung gesehen wurde. Der Unterschied ist selten technischer Natur – er ist eine Frage der Vorbereitung.
Die Bausteine sind überschaubar: getrennte Entwicklungs-, Test- und Produktionsumgebung, wie CON.8.A7 sie als Basis-Anforderung verlangt (BSI IT-Grundschutz CON.8); Testdaten aus einer Anonymisierungsstrecke statt aus dem Backup, mindestens pseudonymisiert nach OPS.1.1.6.A11 (BSI IT-Grundschutz OPS.1.1.6); ein kleiner synthetischer Stammdatensatz mit jedem bekannten Randfall; Contract-Tests in der Pipeline und Vollintegration in größeren Abständen; Last- und Backfill-Tests auf einer Umgebung mit Produktions-Tier (Microsoft Learn); und ein Abnahmeplan mit Freigabekriterien und Ablehnungspfad nach OPS.1.1.6.A10 (BSI IT-Grundschutz OPS.1.1.6). Kein Punkt davon ist für sich aufwendig. Zusammen entscheiden sie, ob der Go-live ein Termin ist oder ein Ereignis.
Wir bauen ERP-Shop-Anbindungen mit genau dieser Umgebungsstrategie: reproduzierbare Testumgebung, dokumentierte Herkunft der Testdaten, Contract-Tests gegen Mocks und ein Abnahmeprotokoll, das die Freigabe trägt. Welche Umgebungen Ihr ERP mitbringt, welche Sie zusätzlich brauchen und was das kostet, klären wir vor der ersten Codezeile – ein Blick auf unsere Leistungen rund um ERP-Schnittstellen zeigt, wie wir ein solches Projekt schneiden.
Quellen und Studien