EDI Regressiontest und Interface DIFF: wie intelligente, automatisierte und sichere Tests aufgebaut sein müssen.
Für alle, die dafür sorgen müssen, dass produktiv laufende EDI Daten und Interfaces auch nach Patches, Updates, Upgrades, Prozessänderungen oder Versionsänderungen noch laufen.
Neue Prozesse, Funktionen bereitstellen, Fehlerbehebungen vornehmen oder Support Packs installieren: in allen Fällen darf die vorhandene Funktionalität nicht beeinträchtigt werden. Gleichzeitig soll das Testen nicht zu zeitaufwändig sein. Hoffen, dass alles weiterhin ohne Regressiontest und DIFF funktioniert, ist oft das praktizierte Prozedere.
Testen Sie automatisiert, intelligent und damit schnell und professionell mit dem EDI Regressiontest und DIFF Service. Risiken, die durch Änderungen in Systemen wegen Support-Packs, Updates, Upgrades und Funktionsanpassungen (z. B. bei der Migration von SEEBURGER BIS 6.5 auf BIS 6.7) hervorgerufen werden können, werden eliminiert.
Verschaffen Sie sich mehr freie Zeit für Ihre Entwicklungen und für Ihre Entwickler. Nutzen Sie die Möglichkeiten, um massenweise verlässliche Tests Ihrer Interfaces zu machen.
Kein Hoffen und Beten, dass alles schon irgendwie klappt. Stattdessen begleitet Sie ein gutes Gefühl bei allen bevorstehenden Änderungen, die den produktiven Betrieb beeinflussen könnten. Wie wäre es, wenn Sie bei jedem go-live einen ruhigen Puls behalten können?
Regressiontest
Automatische Tests, die nach dem Einspielen einer Änderung unerwünschte Auswirkungen auf andere Funktionen abtesten, werden Regressionstests genannt.
Sie machen die Software bezüglich ihrer Qualität erst messbar und zeigen mögliche Nebeneffekte von vorgenommenen Änderungen direkt und erkennbar an.
Sie dienen als direkte Rückkopplung für Entwickler und für Tester, die unter Umständen nicht in der Lage sind, das Gesamtsoftwaresystem auf einmal zu überschauen, sowie zur Erkennung von Nebeneffekten und Folgefehlern.
Quelle: WIKIPEDIA
Interfaces, die innerhalb von EDI- oder EAI- Szenarien produktiv im Einsatz sind, verbinden Business-Partner oder Systeme automatisiert und zuverlässig miteinander. Jedes Interface beruht auf einer technischen Beschreibung, die die Syntax und Semantik des Interfaces beschreibt. Auf Basis dieser Beschreibungen tauschen interne und externe Systeme strukturiert Daten miteinander aus.
Bei Patches, Updates, Upgrades, Prozessänderungen oder Versionsänderungen von Systemen sind die zugehörigen Interfaces ebenfalls von Änderungen betroffen. Die Änderungen können sich in vielen Fällen dermaßen auf die Struktur und Semantik der Interfaces auswirken, dass sie anschließend nicht mehr „funktionieren“. Das bedeutet, dass Daten nach Systemänderungen möglicherweise nicht mehr erwartungsgemäß übertragen werden.
Im produktiven Betrieb muss die Sicherheit der Interfaces gewährleistet werden.
Im Zuge der Änderung eines Systems A muss sichergestellt sein, dass es keine Auswirkungen auf das mit A verbundene System B gibt.
Interfaces müssen einem „vorher“ / „nachher“ Vergleich standhalten, damit System B die Daten weiterhin verarbeiten kann.
Da Interfaces über zahlreiche unterschiedliche Ausprägungen verfügen, sollte die Regressiontest und DIFF Prüfung von Interfaces mit einer möglichst großen Anzahl von Referenzdaten erfolgen. Je mehr Referenzdaten getestet werden (Vergleich vorher/nachher), desto höher ist die Wahrscheinlichkeit, dass alle Ausprägungen eines Interfaces getestet wurden. Die Herausforderung dabei ist in erster Linie die mitunter große Komplexität von Interfaces und der immense Aufwand der entsteht, wenn sehr viele Daten „manuell“ und ohne Tool-Unterstützung miteinander verglichen werden müssen.
Interfaces sollten intelligent, automatisiert und massenweise getestet werden.
Der XVAN cloud regressiontest-diff service ist auf der Grundlage von tatsächlichen, wiederkehrenden Kunden-Anwendungsfällen entwickelt worden.
Der Service ist ständig verfügbar. Durch eine nahtlose Integration prüft der Service den SOLL-Zustand über bestehende Interfaces gründlich. Damit ist eine Test-Abdeckung von nahezu 100% der täglichen Geschäftsprozesse sehr einfach möglich.
Mit dem XVAN DIFF bieten wir einen 100% in bestehende Middleware– und ERP-Systemlandschaften integrierbaren Service an, der per REST / HTTP angesprochen wird und massenweise elektronische, strukturierte (und unstrukturierte) Daten vergleicht.
Ein aus der Praxis entwickelter Datenvergleichsdienst, der durch REST / HTTP Adapter 100% in bestehende Landschaften integriert werden kann.
Der DIFF Service ist „intelligent“, denn er versteht die Struktur der zu vergleichenden Daten.
Er kann daher einerseits Zähler/Counter, Timestamps oder UUIDs und vergleichbare Wertfelder vom Vergleich ausschließen und andererseits Reihenfolgen in strukturierten Datenströmen (wie zum Beispiel die (unwichtige) Reihenfolge von NAD-Segmenten innerhalb einer EDIFACT Nachricht) erkennen und bei Bedarf ebenfalls unberücksichtigt lassen.
Apropos Massenverarbeitung: wir verarbeiten und vergleichen mit unserem XVAN DIFF-Service 240.000 strukturierte Datensätze pro Stunde – oder 4.000 Dateien pro Minute – oder 66 Dateien pro Sekunde. Es ist also durchaus möglich die EDI-Archive eines ganzen Jahres als Referenzdaten zu verwenden, um in kürzester Zeit belastbare Ergebnisse zu erhalten.
Das XVAN DIFF ist eine API-first Anwendung.
Auf alle Funktionen kann über eine REST-Schnittstelle (oder GraphQL) zugegriffen werden.
Der Vergleich eines Payloads-1 mit einem Payload-2 erfolgt durch einen Differenzerkennungsalgorithmus, der in hohem Maße anpassbar ist und sowohl Payload-Syntax (EDIFACT, ANSI X.12, VDA, CSV, u.s.w. …) erkennen kann, als auch Datei-Normierungen vor einem Vergleich durchführen kann (Ausschließen von Timestamps, Laufnummern, Countern u.s.w …).
Die Konfiguration der Differenzerkennung wird als Testfall bezeichnet. Ein Testfall fasst alle Konfigurationseinstellungen für den Test zusammen.
Es ist möglich, Testfälle zu organisieren, indem man sie Testsuiten zuweist.
Ein Testfall kann Mitglied von null oder mehr Testsuiten sein.
Eine Testsuite bietet erweiterte Möglichkeiten zum Verwalten einer Reihe von Testfällen, z.B.: Testfallausführung, Überwachung der Testausführung.
Die Ausführung eines Testfalls wird als Testausführung oder Testlauf bezeichnet.
Innerhalb einer Testausführung ist es möglich, beliebig viele „Payload-Paare“ zu vergleichen.
Das Vergleichen eines einzelnen Paares innerhalb einer Testausführung wird als Testausführungsschritt bezeichnet.
Es ist auch möglich, eine ganze Testsuite auszuführen. Dies bedeutet, dass alle der Testsuite zugeordneten Testfälle ausgeführt werden.
Ein Payload-Pool ist eine Sammlung von Payloads / Dateien. Er beschreibt, wie ein Testfall auf diese Payloads zugreift. Folgende Payload – Pools zur Integration von XVAN DIFF stehen zur Verfügung:
OneDrive, Dropbox, HTTP Request / Response, SFTP, CIFS, HTTP-Webdav, GIT-Repository
Ein SEEBURGER BIS 6.5.n-System wird auf die nächst höhere aktuelle Version 6.7.n aktualisiert.
Um die Funktionalität der Mappings / Zuordnungen in der neuen Softwareversion zu testen, sollen Regressiontests mit produktiven Daten durchgeführt werden.
Dadurch soll sichergestellt werden, dass das Konvertierungsergebnis jedes Mappings / jeder Zuordnung in der neuen Version 6.7.n genau mit dem Ergebnis der Konvertierung in Version 6.5.n übereinstimmt.
In jeder für den Test relevanten konfigurierten Partner-Nachrichten-Beziehung auf SEEBURGER BIS6.5.n (PNB-1) wird die EDI Quelldatei (EDIFACT, SAP IDoc, etc.) in einem zusätzlichen Verzeichnis für die Quelldatei (VQ-1) bereitgestellt
In PNB-1 erfolgt die 6.5.n Konvertierung. Das Ergebnis der Konvertierung wird in PNB-1 dem XVAN REST Service zur Verfügung gestellt (REST-1).
Die Datei in VQ-1 wird mit der neuen Version aus 6.7.n verarbeitet. Das Ergebnis der Konvertierung wird ebenfalls über den XVAN REST Service bereitgestellt (REST-2)
Für den Testcase wird im XVAN DIFF Webfrontend die Nachrichten Syntax und die DIFF-Logik festgelegt und über eine Konfiguration K-1 eindeutig definiert. Die Referenz zu K-1 wird über REST-1 und REST-2 mitgeliefert.
Im XVAN DIFF befinden sich nun bereits die 2 Zieldateien. Eine 6.5.n-Zieldatei und ein 6.7.n-Zieldatei.
Auf Basis der mitgelieferten Metainformation K-1 wird der DIFF-Service ausgeführt.
Fortan laufen Produktiv- und Regressiontest- Prozesse parallel.
Das Ergebnis des Regressiontest DIFF wird strukturiert im XVAN DIFF – Webfrontend dargestellt.
Zusätzlich kann das Ergebnis bei Bedarf als synchroner HTTP-Response an BIS 6.7.n zurückgeliefert werden. Hier kann er ausgewertet und im BIS 6.7.n Monitoring dargestellt werden.
Die Darstellung im XVAN DIFF Webfrontend lässt auf den ersten Blick erkennen, in welchen Interfaces Unterschiede existieren. Durch zahlreiche Filter können bestimmte Unterschiede direkt gefunden werden.
aurebus.de verwendet ausschließlich FUNKTIONALE Cookies. Funktionale Cookies, müssen nicht vom Besucher akzeptiert werden. Weitere Informationen in unserer Datenschutzerklärung